Extending #AddExportsInManifest proposal

Hi Jigsaw Team, #AddExportsInManifest is good proposal for "uber" jars. How about extending this proposal to cover: --upgrade-module-path --module-path --add-modules --limit-modules options too? Both Module-Path and Upgrade-Module-Path manifest entries would be relative to the 'jar'

Re: Maven annotation processing fails with JDK9-ea+138

Hi Christian, the following snippet should work for you: org.apache.maven.plugins maven-compiler-plugin true -J--add-modules -Jjava.xml.bind Richard On 10/05/2016 08:24 AM, Christian Beikov wrote: So

Jigsaw b136 ServiceLoader Regression

Hi Jigsaw team, there is a regression in Jigsaw JDK9 build 136 causing ServiceLoader.iterator().next() to propagate other error than ServiceConfigurationError, see below. According to javadoc (java.util.ServiceLoader.iterator()): " To write robust code it is only necessary to catch

Re: Class names in java.lang.Module

+1 I'd also propose FindException -> ModuleNotFoundException Richard On 09/21/2016 12:58 PM, Remi Forax wrote: I agree. And Layer should also be called Module Layer. Remi On September 21, 2016 12:36:51 PM GMT+02:00, Kasper Nielsen wrote: Hi, I was wondering if there

Re: Upgradeable Modules Question

On 09/07/2016 10:32 AM, Alan Bateman wrote: On 07/09/2016 08:49, Richard Opalka wrote: Your guess was correct Alan (my english isn't perfect). Yes my distorted question was whether it should be possible to "upgrade" Jigsaw module with automatic module. Yes, you do can do thi

Re: Upgradeable Modules Question

Hi Alan, On 09/07/2016 08:24 AM, Alan Bateman wrote: On 06/09/2016 23:37, Alex Buckley wrote: On 9/6/2016 3:31 PM, Richard Opalka wrote: Can Jigsaw module be both upgreadeable and automatic? No. By definition, an upgradeable module is a module linked into a runtime image. An automatic

Upgradeable Modules Question

Hi Jigsaw team, Can Jigsaw module be both upgreadeable and automatic? Thanks, Richard

Re: Multiple versions of a non-exported dependency

On 09/02/2016 10:27 AM, Alan Bateman wrote: On 01/09/2016 21:04, cowwoc wrote: 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. Look at

Re: Multiple versions of a non-exported dependency

Reformulating the idea to make it more clear: On 09/01/2016 06:34 PM, Richard Opalka wrote: On 09/01/2016 03:59 PM, Alan Bateman wrote: The issue is of course that there is lot more in picture, esp. when you have the unnamed module (= class path) reading all modules, also automatic modules

Re: Multiple versions of a non-exported dependency

On 09/01/2016 06:58 PM, Alan Bateman wrote: On 01/09/2016 17:34, Richard Opalka wrote: Further I can't see the real benefit of automatic modules (they read UNNAMED module(s) and all other explicit modules). I am aware of two real world usecases it might solve: 1) to workaround licensing

Re: Multiple versions of a non-exported dependency

On 09/01/2016 03:59 PM, Alan Bateman wrote: The issue is of course that there is lot more in picture, esp. when you have the unnamed module (= class path) reading all modules, also automatic modules that bridge to the class path (and so read the unnamed module). Then add upgradable modules

Re: ClassLoader::getPlatformResource*() methods

Hi Alan, On 08/31/2016 01:12 PM, Alan Bateman wrote: On 31/08/2016 11:33, Richard Opalka wrote: Hi Jigsaw Team, There's new ClassLoader::getPlatformClassLoader() method introduced with project Jigsaw. There are three ClassLoader::getSystemResource*() methods available that fallback

ClassLoader::getPlatformResource*() methods

Hi Jigsaw Team, There's new ClassLoader::getPlatformClassLoader() method introduced with project Jigsaw. There are three ClassLoader::getSystemResource*() methods available that fallback to BootLoader if SystemClassLoader is not available. Shouldn't ClassLoader::getPlatformResource*()

Re: JEP-238 & JEP-261 Coexistence

Comments below: On 04/06/2016 01:53 PM, Alan Bateman wrote: On 06/04/2016 12:47, Richard Opalka wrote: BTW: Just looking at the contents of your JAR file then it looks like this is the EE version of the Common Annotations. In that case you shouldn't need a multi-release JAR. Instead you

Re: JEP-238 & JEP-261 Coexistence

Clarification below: On 04/06/2016 01:47 PM, Richard Opalka wrote: Comments below: On 04/06/2016 12:34 PM, Alan Bateman wrote: On 06/04/2016 11:17, Richard Opalka wrote: Hi Experts, I expected if users provide 'multirelease' jar file with modules-info.class placed in its META-INF

Re: JEP-238 & JEP-261 Coexistence

Comments below: On 04/06/2016 12:34 PM, Alan Bateman wrote: On 06/04/2016 11:17, Richard Opalka wrote: Hi Experts, I expected if users provide 'multirelease' jar file with modules-info.class placed in its META-INF/versions/9 folder would work without problems. But I'm getting: Caused

JEP-238 & JEP-261 Coexistence

Hi Experts, I expected if users provide 'multirelease' jar file with modules-info.class placed in its META-INF/versions/9 folder would work without problems. But I'm getting: Caused by: java.lang.IllegalArgumentException: META-INF.versions.9: Invalid package name: Illegal character at

Re: modulepath and classpath mixture

Hi, I just solved it by adding -Xmodule option: javac -Xmodule:java.annotations.common -sourcepath src `find -type f -name *.java` Rio On 03/22/2016 11:29 PM, Richard Opalka wrote: Hi, I'm experiencing the same problem locally. When trying to build Oracle provided maven artifact

Re: libraries that split packages

Hi Nicolai, some examples can be found here: https://issues.jboss.org/browse/WFLY-6375 Any "Service Provider" based jar is a potential problem. Rio On 03/21/2016 06:39 PM, Nicolai Parlog wrote: Hi! Are there any numbers on how severe the split package situation is, i.e. how many