Re: Annotation processors and the --processor-module-path

Sorry, I asked the wrong question (similar to the above but different). What I was trying to say is that if you stick jmh on the module path, the annotation processor stops working: https://stackoverflow.com/q/53927874/14731 If I explicitly add the JAR file to the annotation processor path then i

Re: Annotation processors and the --processor-module-path

Alan Bateman wrote > On 22/11/2016 10:33, Eirik Bjørsnøs wrote: > >> : >> >> So again, I added -J-add-modules=java.xml.bind, and now my annotation >> processor is loading. >> >> Given that my annotation processor does require java.xml.bind and I'm >> using >> --processor-module-path, my expectatio

Qualified exports to an unknown module

Hi, Back in 2016 you guys had a discussion about qualified exports to a module that was not available at compile-time: http://jigsaw-dev.1059479.n5.nabble.com/Issue-with-qualified-exports-td5712839.html I could not find the conclusion to that discussion. How are users supposed to use qualified ex

Clarification needed regarding modulepath containing multiple modules with the same name

(Apologies if this gets posted twice. My first attempt didn't seem to go through) Hi, Can one of the committers for project jigsaw please post a comment in this issue https://issues.apache.org/jira/browse/MJLINK-27 I have been trying, unsuccessfully, to reach consensus with Maven committers.

JDK-8189251

Hi, I'm trying to understand the reasoning behind https://bugs.openjdk.java.net/browse/JDK-8189251 being closed as Won't Fix. Can someone please clarify the downside of named automatic-modules vs normal modules? I assume that there is some sort of downside; otherwise, we wouldn't be warning about

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

Alan Bateman wrote > A type safe approach would be to define a helper interface in a > non-exported package and have the enum register an implementation. > Static methods on the interface, or a separate helper, would provide > consumers in the module a way to obtain the implementation. We uses t

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

Hi Jan, I've got a specific use-case I'd like your feedback on: * My library exports an enum. * Users must be able to pass enum values into exported API methods. * The enum contains a method to ensure that each possible value defines a different implementation. * The method is only meant to be in

Re: Multiple versions of a non-exported dependency

Another possibility (not saying it's better, just putting it out there) is to do the following: 1. Provide a tool like "javah" that would generate module-info.java for non-modularized JAR files. 2. Provide a mechanism to "glue" the generated module-info files to the original non-modular

Re: Multiple versions of a non-exported dependency

" > <[hidden email] > > >>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email] > > > >>>> Envoyé: Mercredi 31 Août 2016 20:54:44 > >>>> Objet: Re: Multiple versions of a non-exported dependency > >>&g

Re: Multiple versions of a non-exported dependency

Rs on the modulepath as automatic modules? > > Alex > > On 8/31/2016 1:15 PM, cowwoc wrote: > > > Alex, > > > > Thank you for the clarification. > > > > I am a bit confused by your assertion... If you wanted to introduce > > first-class versions

Re: Multiple versions of a non-exported dependency

rsions. > > https://xkcd.com/927/ > > Rémi > > - Mail original - > > De: "Alex Buckley" <[hidden email] > > > > À: [hidden email] > > Envoyé: Mercredi 31 Août 2016 22:07:59 > > Objet: Re: Multiple versions of a non-exported dependenc

Re: Multiple versions of a non-exported dependency

2016-08-31 4:09 PM, Alex Buckley [via jigsaw-dev] wrote: > On 8/31/2016 12:51 PM, cowwoc wrote: > > I agree that the situation is better, but not by much. Developers > > routinely run across transitive dependencies that are incompatible with > > each other. You seem to be under the

Re: Multiple versions of a non-exported dependency

gher") there is minimal harm. What's the downside here? How much work is involved in taking in this string? Gili On 2016-08-31 3:51 PM, Alex Buckley [via jigsaw-dev] wrote: > On 8/31/2016 12:39 PM, cowwoc wrote: > > I don't even care if you keep the current restrictions i

Re: Multiple versions of a non-exported dependency

java launcher is > not becoming a mini container that spins loaders for multiple versions > of the same module -- code defined by the application loader on JDK 8 is > defined by the application loader on JDK 9. > > Alex > > On 8/31/2016 12:21 PM, cowwoc wrote: > > > We

Re: Multiple versions of a non-exported dependency

e repository or distribution which hosts the artifact, and > to which (for example) a CI system may refer. > > On 08/31/2016 02:21 PM, cowwoc wrote: > > > Well, this is unfortunate. As I stated earlier, I fail to see how > > depending on constant version numbers (not version range

Re: Multiple versions of a non-exported dependency

ex points out: your use-case can be supported in Java 9 but > only with the > > addition of custom ClassLoaders, or by using an existing > ClassLoader-based > > module system such as OSGi. > > > > The same is also true of Java 8, and Java 7, etc. > > > > Re

Re: Multiple versions of a non-exported dependency

ted in Java 9 but only > with the addition of custom ClassLoaders, or by using an existing > ClassLoader-based module system such as OSGi. > > The same is also true of Java 8, and Java 7, etc. > > Regards, > Neil > > > > On 31 Aug 2016, at 19:29, Alex Buckley <

Multiple versions of a non-exported dependency

Hi, I recently became aware of the fact that the Jigsaw specification declared "version-selection" as a non-goal. While I understand how we ended up here, I am hoping that you were able to support the following (very common) use-case: * Module "HelloWorld" depends on modules "Guava" and "JSoup".