Re: [equinox-dev] [e4-dev] Resolver Problem with guava and e4 (javax.ann

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

On 11.06.14 08:07, David M Williams wrote:
> My main question is ... is this required for Luna? (I assume not, that
> it shows up in "e4 incubator"?  so could wait to SR1 if we find a safe,
> non-breaking change? Or Mars if breaking?)

No I don't think we can fix the problem in Luna at all.

> 
> Second, I've only barely read the details (they make my head spin) but
>  wondering if it is reasonable for "resolver.problem" to require Java 8
> AND javax.annotaion 1.0.0? That seems quite a mix of "old and new"? I
> assume this is an attempt to "be compatible" with older bundles that
> require javax.annotation 1.0?

The problem is that "resolver.problem" e.g. makes use of it like this:

class MyPart {
  @PostConstruct
  public void initUI(Composite comp) {
  }
}

and because "resolver.problem" requires JavaSE-8 it could live without
any javax.annotation import itself and wire to the JRE but the problem
is that this annotation is read by the e4 DI-Container
(org.eclipse.e4.core.di) who himself requires javax.annotation 1.0.0 so
if my bundle gets wired against the JRE and core.di against 1.0.0 it
will of course *not* find my @PostConstruct resulting in the method not
called at all.

My current thinking is that we at e4/platform made the bad choice of not
requireing JavaSE-1.6 2 years ago when we made Eclipse 4 generally
available and so remove the need for javax.annotation bundle.

> 
> If it helps, and if you haven't already, you might want to read
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=424909#c0and what it
> points to, https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5
> 
> Now for some "wild ideas" to show my ignorance ... which helps
> occasionally :) ...
> 
> I notice in Orbit, all our "javax.annotation" bundles follow the import
> what you export pattern .... that's good, such as
> 
> *Export-Package*: javax.annotation;/version/="1.2.0",
>  javax.annotation.security;/version/="1.2.0",
>  javax.annotation.sql;/version/="1.2.0"
> *Import-Package*: javax.annotation;/version/="1.2.0",
>  javax.annotation.security;/version/="1.2.0",
>  javax.annotation.sql;/version/="1.2.0"
> 
> BUT, in this case, I wonder if we should be so "restrictive" about what
> we import? Would the following be better?
> 
> *Export-Package*: javax.annotation;/version/="1.2.0",
>  javax.annotation.security;/version/="1.2.0",
>  javax.annotation.sql;/version/="1.2.0"
> *Import-Package*: javax.annotation,
>  javax.annotation.security,
>  javax.annotation.sql
> 
> I suppose that's  about the same as "requiring system.bundle"? Just "mix
> in" with what ever in in running JRE? (Which, from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5sounds like it
> would work, in this case ... that is, high degree of similarity, except
> for "new" things?
> I'm just throwing this out as an idea ... only the experts could say if
> it makes sense.  
> 
> As for your suggestion
> b) guava does import javax.annotation;1.0.0 instead
> 
> I'm assuming our Orbit guava version is what they (the "third party")
> provides (which is what we always strive for) so you might work with
> them, to find out if there's a reason they did it the way they did, if
> they'd be willing to change, etc.
> 

I don't think so because from their point of view they are requireing
JavaSE-1.6 and so they can wire to javax.annotation without packages.

They could remove the javax.annotation import completely because they
anyways require JavaSE-1.6

Tom