Re: MethodHandles.Lookup and modules

On Dec 17, 2015, at 6:01 PM, John Rose wrote: > > I think I would prefer case 2. The user model is PUBLIC is the weakest > (non-empty) access > mode available to bytecode behaviors. As such it respects the LC's position > in the module > graph, and excludes module-private, package-private, an

hg: jigsaw/jake/jdk: 4 new changesets

Changeset: 387f9070f3bf Author:alanb Date: 2015-12-18 12:11 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/387f9070f3bf Layer.createWithXXX need additional permisions specified Misc. clean-up ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/shar

Re: Spring's need for optional dependencies

Hi Paul, I think we are not in disagreement. We are just talking of slightly different things. So let me answer your concerns... On 12/17/2015 06:14 PM, Paul Benedict wrote: Peter, thanks for your comments. I differ in that I don't see any problems with optional dependencies. Right now, like

Re: Spring's need for optional dependencies

On 12/18/2015 04:49 PM, Peter Levart wrote: You can check whether the optional module is included in a runtime configuration or not with a simple Class.forName() check even if you don't depend on the module (i.e. don't list it in "requires" descriptor at runtime). The visibility of classes is

Re: Spring's need for optional dependencies

Hi, In general, your workaround has some disadvantages: 1) Existing code does not work as is: (your need read edges) 2) command line options only apply to boot layer not to dynamic configurations created by future containers On Fri, Dec 18, 2015 at 7:19 PM, Peter Levart wrote: > Hi Paul, > > I t

Re: Spring's need for optional dependencies

Adding read edges at runtime is not a backward compatible solution. Jigsaw should automatically allow you to read anything your Module Descriptor gives you access to -- required or optional. Cheers, Paul On Fri, Dec 18, 2015 at 10:02 AM, Peter Levart wrote: > > > On 12/18/2015 04:49 PM, Peter L

Re: Spring's need for optional dependencies

Hi Ali, On 12/18/2015 05:05 PM, Ali Ebrahimi wrote: Hi, In general, your workaround has some disadvantages: 1) Existing code does not work as is: (your need read edges) See my message written concurrently with your's ;-) Optional dependency could add a read edge for you if the target module w

Re: Spring's need for optional dependencies

Hi, Can we all agree that native Optional dependency support would be clean, best and reasonable solution. On Fri, Dec 18, 2015 at 7:47 PM, Peter Levart wrote: > Hi Ali, > > On 12/18/2015 05:05 PM, Ali Ebrahimi wrote: > > Hi, > In general, your workaround has some disadvantages: > 1) Existing co

Re: Spring's need for optional dependencies

Hi Paul, On 12/18/2015 05:14 PM, Paul Benedict wrote: Adding read edges at runtime is not a backward compatible solution. Jigsaw should automatically allow you to read anything your Module Descriptor gives you access to -- required or optional. I was maybe not clear enough. So here's in the e

Re: Spring's need for optional dependencies

Peter, when you say Jigsaw "doesn't search for module B" when it's optional, what do you mean by "search"? Cheers, Paul On Fri, Dec 18, 2015 at 10:42 AM, Peter Levart wrote: > Hi Paul, > > On 12/18/2015 05:14 PM, Paul Benedict wrote: > > Adding read edges at runtime is not a backward compatibl

Re: Spring's need for optional dependencies

On 12/18/2015 05:28 PM, Ali Ebrahimi wrote: Hi, Can we all agree that native Optional dependency support would be clean, best and reasonable solution. I think we 3 do agree ;-). Regards, Peter On Fri, Dec 18, 2015 at 7:47 PM, Peter Levart > wrote: Hi

Re: Spring's need for optional dependencies

I do not see any statement in the Module System Requirements document (http://openjdk.java.net/projects/jigsaw/spec/reqs/) such that Java 9 is required to be backwards compatible, except where code runs in “classpath mode” (aka the unnamed module). Therefore it is an acceptable solution — at le

Re: Spring's need for optional dependencies

That doesn't bode well for frameworks that must run in JDK 8 and 9 -- either in classpath mode or module mode. That means the addReads() call will have to be reflective so it can work in both worlds. That's just another hack. Cheers, Paul On Fri, Dec 18, 2015 at 11:33 AM, Neil Bartlett wrote: >

hg: jigsaw/jake/langtools: 8145012: Javac doesn't report errors on duplicate uses or provides

Changeset: f22706341c4d Author:vromero Date: 2015-12-16 17:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f22706341c4d 8145012: Javac doesn't report errors on duplicate uses or provides ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! s

hg: jigsaw/jake/langtools: 8145016: Javac doesn't report errors on service implementation which cannot be initialized

Changeset: 4a70ae037273 Author:vromero Date: 2015-12-17 13:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4a70ae037273 8145016: Javac doesn't report errors on service implementation which cannot be initialized ! src/jdk.compiler/share/classes/com/sun/tools/java

hg: jigsaw/jake/jaxws: 8144342: javac doesn't report errors if module exports non-existent package

Changeset: ab43de1d28fd Author:vromero Date: 2015-12-17 14:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ab43de1d28fd 8144342: javac doesn't report errors if module exports non-existent package ! src/jdk.xml.bind/share/classes/module-info.java

Re: MethodHandles.Lookup and modules

On 12/18/2015 12:20 AM, John Rose wrote: On Dec 17, 2015, at 6:01 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: I think I would prefer case 2. The user model is PUBLIC is the weakest (non-empty) access mode available to bytecode behaviors. As such it respects the LC's position in the mod

Re: MethodHandles.Lookup and modules

> On Dec 18, 2015, at 4:44 PM, Alex Buckley wrote: ... > So let's recap full power lookups: > > - Start with an arbitrary class in an arbitrary module calling > MethodHandles.Lookup.lookup() to get a "full power" lookup object L. L's > lookup modes are PUBLIC + QUALIFIED + MODULE + PROTECTED +