Hi @Enrico,
I am very unhappy with Java 9 status and very afraid.
I do not like the style how Oracle has changed Java to Java 9 and forced
all the world to use additional effort to adapt to Oracle activities.
I am facing more unhappy Java development teams with Java 9 in the future.
For instance as I have tried to implement users wish in Maven Surefire
project and invested my personal time and effort to adapt to Oracle
requirements, this still does not convince me to say that Java 9 is ready
to go.
This is my comment from Jira:
"This is not nice on Java 9 that they broke backwards compatibility and
force the world to use the switch to use --add-modules ALL-SYSTEM instead
of providing all modules installed in JRE. For instance, small JRE having
{{java.base}} has advantage on embedded systems and the only should be
propagated. Big scope JRE should propagate all installed modules.
But for me it does not make security sense and common sense to force JRE to
provide modules. It should be opposite and the admin/Jenkins should
configure big scope JRE with selected modules propagated to Java runtime
applications.
If this admin does not do that then all modules should be available by
default which is backwards compatibility for me and we do not have to to
implement these stupid tricks."
As far as we remember Java Security, the policies can be configured.
I can imaging same paradigm in Jigsaw/Java 9 and then the admin who has
installed JDK or JRE would "switch off" some modules. But opposite, that
means the script which starts Java app currently enables "all" modules is
against security and against the principle of modular system because the
modules do not make sense then.
What makes sense to me is to enable "all java/javax" modules except for the
"com.sun" proprietary ones by default.
So yes enable them by default and please release specific JRE installations
with specific bunch of Java modules for specific use cases.
This means those modules in that particular release are all enabled by
default if not configured otherwise by admin, e.g. Jenkins, operation
staff, etc. (do NOT mean Sun packages - never visible).
Here it comes. The idea that we can install small 5MB/JRE on small Linux
device would be possible because Oracle would release such tiny JRE using
only "java.lang" and then another JRE installation using java.lang and
java.utils, and later NIO and later "java.desktop", etc.
Then vendors of web browsers and Linux dist would be happy to integrate
small JRE into and use JavaFX.
But now it is not possible because the modules are basically three:
java.base == 37MB
java.desktop == 36MB
java.xml ==20MB
All the other modules are pretty small but these three seen in "src.zip"
make the modular system unbalanced in size and nobody would ever wish to
integrate them because they are still big. That means the problem that
Oracle has with NIO implementation in com.sun package propagated to
"java.util", nobody in the world care and nobody should see as a problem to
split "java.base" much more.
If splitting "java.base" happened then not certified JVMs developed at
Universities would for instance implement only "java.lang" and embed it in
to JVM and develop a new programming language on the top of Java. But
implementing 10 packages in java.base is an effort again.
One more thing is regarding the size of the modules.
You really did not help embedded systems and installations of browsers.
On Thu, May 18, 2017 at 8:51 AM, Enrico Olivelli <eolive...@gmail.com>
wrote:
> I would like to share my current pom configuration which lets me to
> build and test java8 apps on latest and greatest jdk9
>
> This profile is activated when using jdk9.
>
> This is based on a suggestion of Robert, its suggestion for the
> javadoc plugin is working great with surefire too
>
> <profile>
> <id>jdk9</id>
> <activation>
> <jdk>[9,)</jdk>
> </activation>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <additionalparam>--add-modules
> ALL-SYSTEM</additionalparam>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.20</version>
> <configuration>
> <argLine>--add-modules ALL-SYSTEM</argLine>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </profile>
>
>
> -- Enrico
>
>
>
> 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:
> > Hi,
> >
> > yes I will do within this week...
> >
> > Kind regards
> > Karl Heinz Marbaise
> > On 23/04/17 21:37, Enrico Olivelli wrote:
> >>
> >> Thank you Robert,
> >> I saw that you have merged my patch.
> >>
> >> Is there any plan to release the new version of the war plugin?
> >>
> >> Enrico
> >>
> >>
> >> Il gio 13 apr 2017, 12:21 Paul Hammant <p...@hammant.org> ha scritto:
> >>
> >>>>
> >>>>
> >>>>> I don't see any activity either, so my idea is to replace XStream,
> see
> >>>>
> >>>> MWAR-397[1]
> >>>>
> >>>
> >>> Just for the record, Jörg is working through the Java9 issues for
> XStream
> >>> presently - https://github.com/x-stream/xstream/commits/master
> >>>
> >>> - Paul
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
