Il dom 18 giu 2017, 09:38 Tibor Digana <[email protected]> ha scritto:
> @Enrico > What "--add-modules ALL-SYSTEM" really does ? > For me it would be maybe a handy hack but for you it would be just a hack > anyway as it first seems. Strong encapsulation in Java9 can be openly > passed by. > This is not about strong encapsulation per se, but it adds automatically every known system module to the module path. By default new java apps will see only the java.se module and not the full java8 jdk, which can be referenced using the java.se.ee module. It is a big jump and it makes impossible to simply upgrade your java installation from java8 to java9 and hope it will work >From my point of view the big problem is that existing libraries broke encapsulation of jdk. Recently there was a decision to allow illegal reraccessflective access by default to every legacy classpath based application and, this will ease the transition. This is available from jdk9b172. As third party library providers all of us should update our code and remove illegal code. > For instance in Surefire we extend UrlClassLoader and I need to access > entire Java API and let our users to load their classes with entire Java > API as in Java 8. Suppose no module-info is embedded in any jar. > Before my plan was to call [1] > findClass(String moduleName, String name) > in subclass of UrlClassLoader with javase-ee in moduleName. > Now I don't know which approach is better. > Honestly I do not know either. Maybe surefire should do its magic and make jdk8 apps work as before but for the otherside in real world they won't work on java9 without additional command line options Enrico > [1]: > > http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String- > > Offtopic: I see several Java EE vendors voted against Jigsaw release of > JDK9. I think JCP members should guarantee that application servers [2] are > compliant with JDK9 in first step and then cut release version JDK 9 of > Java SE. Otherwise Jigsaw may kill Java. > [2]: TomEE, JBoss, WebSphere, GlassFish, WildFly, Weblogic > I think that this could be a good read about this topic http://www.tomitribe.com/blog/2017/05/is-jigsaw-dead-not-quite/ > On Sat, Jun 17, 2017 at 9:53 PM, Robert Scholte <[email protected]> > wrote: > > > +1, fully agree with Guillaume > > > > There's no real need to make a plugin modular: it won't become a > > dependency and the dependency management as done by Maven is strong > enough > > to have a stable plugin (i.e no need to add requires-statements). > > > > In case of experiment if you want to add a module name, > > "org.apache.maven.plugins.site" would be my choice as well. > > > > Robert > > > > > > On Sat, 17 Jun 2017 16:31:14 +0200, Guillaume Boué <[email protected]> > > wrote: > > > > Hi, > >> > >> There was a link to Stephen Colebourne's blog about naming modules: > >> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what > >> about "org.apache.maven.plugins.site" for the module name? > >> > >> But I don't think it is necessary to make the plugin modular. The error > >> means that code launched by the Site plugin is trying to access the > private > >> "File(String,File)" constructor. Can you turn on stacktraces to see what > >> part of the code is doing that? We can perhaps fix the deep reflection > >> usage and only rely on public API. > >> > >> I've also noticed MSITE-789 about a similar error but it was in Findbugs > >> code. > >> > >> Guillaume > >> > >> Le 17/06/2017 à 15:54, Karl Heinz Marbaise a écrit : > >> > >>> Hi, > >>> currently I'm a bit on testing JDK 9 EA+174..and found the following > >>> issue: > >>> > >>> [INFO] > >>> [INFO] <<< maven-plugin-plugin:3.4:report < process-classes @ > >>> maven-install-plugin <<< > >>> [INFO] > >>> [INFO] 'process-classes' forked phase execution for > >>> maven-plugin-plugin:report report preparation done > >>> [INFO] configuring report plugin org.apache.maven.plugins:maven > >>> -invoker-plugin:2.0.0 > >>> [INFO] ------------------------------------------------------------ > >>> ------------ > >>> [INFO] BUILD FAILURE > >>> [INFO] ------------------------------------------------------------ > >>> ------------ > >>> [INFO] Total time: 14.810 s > >>> [INFO] Finished at: 2017-06-17T15:47:38+02:00 > >>> [INFO] Final Memory: 57M/256M > >>> [INFO] ------------------------------------------------------------ > >>> ------------ > >>> [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.6:site > >>> (default-site) on project maven-install-plugin: Execution default-site > of > >>> goal org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable > >>> to make private java.io.File(java.lang.String,java.io.File) accessible: > >>> module java.base does not "opens java.io" to unnamed module @44b002c9 > >>> -> [Help 1] > >>> [ERROR] > >>> [ERROR] To see the full stack trace of the errors, re-run Maven with > the > >>> -e switch. > >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. > >>> [ERROR] > >>> > >>> So based on what I understood at the moment is that the > >>> maven-site-plugin needs to have a module-info.java file.... > >>> > >>> The first thing which came into my mind was how-to name the module? > >>> > >>> module org.apache.maven.plugins.maven.site.plugin { > >>> requires java.io; > >>> requires java.base; > >>> } > >>> > >>> Do we have any kind of general naming convention for the plugins? > >>> > >>> Kind regards > >>> Karl Heinz Marbaise > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > >> --- > >> L'absence de virus dans ce courrier électronique a été vérifiée par le > >> logiciel antivirus Avast. > >> https://www.avast.com/antivirus > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Cheers > Tibor > -- -- Enrico Olivelli
