Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

; >> 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 <[hidden
> >> > email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=4>
> >> > > > > > >
> >> > > > > > >> > 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
> >> > > > > > >> > >
> >> > > > > > >> > > 
> >> > > > > > >> > > jdk9
> >> > > > > > >> > > 
> >> > > > > > >> > > [9,)
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > >
> >> > > >  org.apache.maven.plugins
> >> > > > >
> >> > > > > > >> > >
> >> > > > > >  maven-javadoc-plugin
> >> > > > > > >> > > 
> >> > > > > > >> > > --add-
> >> modules
> >> > > > > > >> > > ALL-SYSTEM
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > >
> >> > > >  org.apache.maven.plugins
> >> > > > >
> >> > > > > > >> > > maven-surefire-pl
> >> > > > > > >> ugin
> >> > > > > > >> > > 2.20
> >> > > > > > >> > > 
> >> > > > > > >> > > --add-modules
> >> > > > > > >> ALL-SYSTEM
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > > 
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > >> > > -- Enrico
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden
> >> > email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=5>>:
> >> > > > > > >> > > > 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 <[hidden
> email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=7>
> >> > > > > > >> > > > For additional commands, e-mail: [hidden email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=8>
> >> > > > > > >> > > >
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > 
> >> > > -
> >> > > > > > >> > > To unsubscribe, e-mail: [hidden email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=9>
> >> > > > > > >> > > For additional commands, e-mail: [hidden email]
> >> > > > > <http:///user/SendEmail.jtp?type=node=5912520=10>
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Cheers
> >> > > > > > > Tibor
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Cheers
> >> > > > > > Tibor
> >> > > > > >
> >> > > > > --
> >> > > > >
> >> > > > >
> >> > > > > -- Enrico Olivelli
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > If you reply to this email, your message will be added to the
> >> > > discussion
> >> > > > > below:
> >> > > > >
> >> > > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> >> > > just-using-JDK9-
> >> > > > > tp5905517p5912520.html
> >> > > > > To start a new topic under Maven Developers, email
> >> > > > > ml+s40175n142166...@n5.nabble.com
> >> > > > > To unsubscribe from Maven Developers, click here
> >> > > > > <
> >> > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> >> > > macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAY
> >> XBhY2hlLm9yZ3
> >> > > wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >> > > > >
> >> > > > > .
> >> > > > > NAML
> >> > > > > <
> >> > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> >> > > macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> >> > > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> >> > > web.template.NabbleNamespace-nabble.view.web.template.
> >> > > NodeNamespace=notify_subscribers%21nabble%
> >> > > 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> >> > > instant_email%21nabble%3Aemail.naml
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > View this message in context:
> >> > > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> >> > > just-using-JDK9-tp5905517p5912569.html
> >> > > > Sent from the Maven Developers mailing list archive at Nabble.com.
> >> > >
> >> > > --
> >> > >
> >> > >
> >> > > -- Enrico Olivelli
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers
> >> > Tibor
> >> >
> >> --
> >>
> >>
> >> -- Enrico Olivelli
> >>
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
>
>
> --
> Cheers
> Tibor
>

Re: Building a Java9 project just using JDK9

[Tibor Digana]

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 <[hidden
>> > email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=4>
>> > > > > > >
>> > > > > > >> > 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
>> > > > > > >> > >
>> > > > > > >> > > 
>> > > > > > >> > > jdk9
>> > > > > > >> > > 
>> > > > > > >> > > [9,)
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > >
>> > > >  org.apache.maven.plugins
>> > > > >
>> > > > > > >> > >
>> > > > > >  maven-javadoc-plugin
>> > > > > > >> > > 
>> > > > > > >> > > --add-
>> modules
>> > > > > > >> > > ALL-SYSTEM
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > >
>> > > >  org.apache.maven.plugins
>> > > > >
>> > > > > > >> > > maven-surefire-pl
>> > > > > > >> ugin
>> > > > > > >> > > 2.20
>> > > > > > >> > > 
>> > > > > > >> > > --add-modules
>> > > > > > >> ALL-SYSTEM
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > > 
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > > -- Enrico
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden
>> > email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=5>>:
>> > > > > > >> > > > 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 <[hidden email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=7>
>> > > > > > >> > > > For additional commands, e-mail: [hidden email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=8>
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > 
>> > > -
>> > > > > > >> > > To unsubscribe, e-mail: [hidden email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=9>
>> > > > > > >> > > For additional commands, e-mail: [hidden email]
>> > > > > <http:///user/SendEmail.jtp?type=node=5912520=10>
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Cheers
>> > > > > > > Tibor
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Cheers
>> > > > > > Tibor
>> > > > > >
>> > > > > --
>> > > > >
>> > > > >
>> > > > > -- Enrico Olivelli
>> > > > >
>> > > > >
>> > > > > --
>> > > > > If you reply to this email, your message will be added to the
>> > > discussion
>> > > > > below:
>> > > > >
>> > > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
>> > > just-using-JDK9-
>> > > > > tp5905517p5912520.html
>> > > > > To start a new topic under Maven Developers, email
>> > > > > ml+s40175n142166...@n5.nabble.com
>> > > > > To unsubscribe from Maven Developers, click here
>> > > > > <
>> > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
>> > > macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAY
>> XBhY2hlLm9yZ3
>> > > wxNDIxNjZ8LTI4OTQ5MjEwMg==
>> > > > >
>> > > > > .
>> > > > > NAML
>> > > > > <
>> > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
>> > > macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
>> > > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
>> > > web.template.NabbleNamespace-nabble.view.web.template.
>> > > NodeNamespace=notify_subscribers%21nabble%
>> > > 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
>> > > instant_email%21nabble%3Aemail.naml
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > View this message in context:
>> > > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
>> > > just-using-JDK9-tp5905517p5912569.html
>> > > > Sent from the Maven Developers mailing list archive at Nabble.com.
>> > >
>> > > --
>> > >
>> > >
>> > > -- Enrico Olivelli
>> > >
>> >
>> >
>> >
>> > --
>> > Cheers
>> > Tibor
>> >
>> --
>>
>>
>> -- Enrico Olivelli
>>
>
>
>
> --
> Cheers
> Tibor
>



-- 
Cheers
Tibor

Re: Building a Java9 project just using JDK9

[Tibor Digana]

 > > > 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.
> > > > > > >> >
> > > > > > >> >
> > > > > > >

Re: Building a Java9 project just using JDK9

[Bernd Eckenfels]

You recreate a limited modules JRE with jlink. Haven't tried it but maybe you 
can generate an image with Java.se.ee as root that way, too.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Tibor Digana <tibor.dig...@googlemail.com>
Sent: Wednesday, August 16, 2017 8:28:02 AM
To: Maven Developers List
Subject: Re: Building a Java9 project just using JDK9

Btw. Can be JRE/JDK configures after installation in terms not doing these
things and so that non-modular application would have access to java.se.ee
by default?

And second question, which would be cool feature to have, is some script
which allows me to recreate a new JRE from installed one but much smaller
with the only *java.base* module and all binaries like *bin/modules, src,
jmods* sudenly become much smaller.

On Wed, Aug 16, 2017 at 8:19 AM, Tibor Digana <tibor.dig...@googlemail.com>
wrote:

> Still I do not understand what is the difference between *all_system* and 
> *java.se.ee
> <http://java.se.ee>*.
> Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> warning? It looks like it wants to be exposed out of the jdk to our
> application which is not legal but then why jdk allows.
>
> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli <eolive...@gmail.com>
> wrote:
>
>> Il mer 16 ago 2017, 02:44 Tibor Digana <tibordig...@apache.org> ha
>> scritto:
>>
>> > Hi Enrico,
>> >
>> > It does not appear on console output however it is stored as native
>> std/out
>> > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
>> >
>>
>> Yep, it is as I suspected. If we want ro get rid of it we have to only add
>> java.se.ee module
>>
>>
>> > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
>> > ml+s40175n5912520...@n5.nabble.com> wrote:
>> >
>> > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
>> > > <http:///user/SendEmail.jtp?type=node=5912520=0>> ha
>> > > scritto:
>> > >
>> > > > I found an issue. JDK printed this on std/out:
>> > > > WARNING: Using incubator modules: jdk.incubator.httpclient
>> > > >
>> > >
>> > > IMHO This is because we are importing all system modules. Maybe
>> importing
>> > > only java.se.ee would cover most of the cases.
>> > > I did not notice the warning on test I have run today
>> > >
>> > > Enrico
>> > >
>> > >
>> > > > It hapens after my test:
>> > > >
>> > > > import org.junit.Test;
>> > > >
>> > > > public class J9Test
>> > > > {
>> > > > @Test
>> > > > public void testMiscellaneousAPI() throws java.sql.SQLException
>> > > > {
>> > > > System.out.println( "loaded class " +
>> > > > java.sql.SQLException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.ws.Holder.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.bind.JAXBException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.xpath.XPath.class.getName() );
>> > > > System.out.println( "java.specification.version=" +
>> > > > System.getProperty( "java.specification.version" ) );
>> > > > }
>> > > >
>> > > > @Test
>> > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
>> > > > {
>> > > > }
>> > > > }
>> > > >
>> > > >
>> > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
>> > > <http:///user/SendEmail.jtp?type=node=5912520=1>
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > But why to add it? It's a hack. I do not use module-info.java and
>> so
>> > > > there
>> > > > > is no reason to break the backwards compatibility.
>> > > > >
>> > > > > This is no more about Maven. It is about entire Java world.
>> > > > > If we in Maven do it then everybody has to.
>> > > > >

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

e 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 <[hidden
> email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=4>
> > > > > >
> > > > > >> > 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
> > > > > >> > >
> > > > > >> > > 
> > > > > >> > > jdk9
> > > > > >> > > 
> > > > > >> > > [9,)
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > >
> > >  org.apache.maven.plugins
> > > >
> > > > > >> > >
> > > > >  maven-javadoc-plugin
> > > > > >> > > 
> > > > > >> > > --add-modules
> > > > > >> > > ALL-SYSTEM
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > >
> > >  org.apache.maven.plugins
> > > >
> > > > > >> > > maven-surefire-pl
> > > > > >> ugin
> > > > > >> > > 2.20
> > > > > >> > > 
> > > > > >> > > --add-modules
> > > > > >> ALL-SYSTEM
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > > 
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > -- Enrico
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden
> email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=5>>:
> > > > > >> > > > 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 <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=7>
> > > > > >> > > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=8>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > 
> > -
> > > > > >> > > To unsubscribe, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=9>
> > > > > >> > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node=5912520=10>
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > > Tibor
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > > Tibor
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > > >
> > > > --
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> > just-using-JDK9-
> > > > tp5905517p5912520.html
> > > > To start a new topic under Maven Developers, email
> > > > ml+s40175n142166...@n5.nabble.com
> > > > To unsubscribe from Maven Developers, click here
> > > > <
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> > wxNDIxNjZ8LTI4OTQ5MjEwMg==
> > > >
> > > > .
> > > > NAML
> > > > <
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> > web.template.NabbleNamespace-nabble.view.web.template.
> > NodeNamespace=notify_subscribers%21nabble%
> > 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> > instant_email%21nabble%3Aemail.naml
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> > just-using-JDK9-tp5905517p5912569.html
> > > Sent from the Maven Developers mailing list archive at Nabble.com.
> >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>
>
>
> --
> Cheers
> Tibor
>
-- 


-- Enrico Olivelli

Re: Building a Java9 project just using JDK9

[Tibor Digana]

Btw. Can be JRE/JDK configures after installation in terms not doing these
things and so that non-modular application would have access to java.se.ee
by default?

And second question, which would be cool feature to have, is some script
which allows me to recreate a new JRE from installed one but much smaller
with the only *java.base* module and all binaries like *bin/modules, src,
jmods* sudenly become much smaller.

On Wed, Aug 16, 2017 at 8:19 AM, Tibor Digana 
wrote:

> Still I do not understand what is the difference between *all_system* and 
> *java.se.ee
> *.
> Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
> warning? It looks like it wants to be exposed out of the jdk to our
> application which is not legal but then why jdk allows.
>
> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli 
> wrote:
>
>> Il mer 16 ago 2017, 02:44 Tibor Digana  ha
>> scritto:
>>
>> > Hi Enrico,
>> >
>> > It does not appear on console output however it is stored as native
>> std/out
>> > in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
>> >
>>
>> Yep, it is as I suspected. If we want ro get rid of it we have to only add
>> java.se.ee module
>>
>>
>> > On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <
>> > ml+s40175n5912520...@n5.nabble.com> wrote:
>> >
>> > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
>> > > > ha
>> > > scritto:
>> > >
>> > > > I found an issue. JDK printed this on std/out:
>> > > > WARNING: Using incubator modules: jdk.incubator.httpclient
>> > > >
>> > >
>> > > IMHO This is because we are importing all system modules. Maybe
>> importing
>> > > only java.se.ee would cover most of the cases.
>> > > I did not notice the warning on test I have run today
>> > >
>> > > Enrico
>> > >
>> > >
>> > > > It hapens after my test:
>> > > >
>> > > > import org.junit.Test;
>> > > >
>> > > > public class J9Test
>> > > > {
>> > > > @Test
>> > > > public void testMiscellaneousAPI() throws java.sql.SQLException
>> > > > {
>> > > > System.out.println( "loaded class " +
>> > > > java.sql.SQLException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.ws.Holder.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.bind.JAXBException.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
>> > > > System.out.println( "loaded class " +
>> > > > javax.xml.xpath.XPath.class.getName() );
>> > > > System.out.println( "java.specification.version=" +
>> > > > System.getProperty( "java.specification.version" ) );
>> > > > }
>> > > >
>> > > > @Test
>> > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
>> > > > {
>> > > > }
>> > > > }
>> > > >
>> > > >
>> > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email]
>> > > 
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > But why to add it? It's a hack. I do not use module-info.java and
>> so
>> > > > there
>> > > > > is no reason to break the backwards compatibility.
>> > > > >
>> > > > > This is no more about Maven. It is about entire Java world.
>> > > > > If we in Maven do it then everybody has to.
>> > > > > And I am sure that the voices says that Kotlin is better and
>> Scala is
>> > > > > better would make sense. Why to help these attempts to happen? No
>> > > reason!
>> > > > >
>> > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email]
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using
>> plugin
>> > > > >> specific
>> > > > >> tags like below is going to be painful.
>> > > > >>
>> > > > >> Gary
>> > > > >>
>> > > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email]
>> > > > wrote:
>> > > > >>
>> > > > >> > 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 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

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 <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=4>
> > > > >
> > > > >> > 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
> > > > >> > >
> > > > >> > > 
> > > > >> > > jdk9
> > > > >> > > 
> > > > >> > > [9,)
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > >
> >  org.apache.maven.plugins
> > >
> > > > >> > >
> > > >  maven-javadoc-plugin
> > > > >> > > 
> > > > >> > >         --add-modules
> > > > >> > > ALL-SYSTEM
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > >
> >  org.apache.maven.plugins
> > >
> > > > >> > > maven-surefire-pl
> > > > >> ugin
> > > > >> > > 2.20
> > > > >> > > 
> > > > >> > > --add-modules
> > > > >> ALL-SYSTEM
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > > 
> > > > >> > >
> > > > >> > >
> > > > >> > > -- Enrico
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=5>>:
> > > > >> > > > 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 <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=7>
> > > > >> > > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=8>
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > 
> -
> > > > >> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=9>
> > > > >> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node=5912520=10>
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > > Tibor
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> > >
> > > --
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> just-using-JDK9-
> > > tp5905517p5912520.html
> > > To start a new topic under Maven Developers, email
> > > ml+s40175n142166...@n5.nabble.com
> > > To unsubscribe from Maven Developers, click here
> > > <
> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==
> > >
> > > .
> > > NAML
> > > <
> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> web.template.NabbleNamespace-nabble.view.web.template.
> NodeNamespace=notify_subscribers%21nabble%
> 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Building-a-Java9-project-
> just-using-JDK9-tp5905517p5912569.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
>
> --
>
>
> -- Enrico Olivelli
>



-- 
Cheers
Tibor

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

e 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 <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=4>
> > > >
> > > >> > 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
> > > >> > >
> > > >> > > 
> > > >> > > jdk9
> > > >> > > 
> > > >> > > [9,)
> > > >> > > 
> > > >> > > 
> > > >> > >     
> > > >> > > 
> > > >> > >
>  org.apache.maven.plugins
> >
> > > >> > >
> > >  maven-javadoc-plugin
> > > >> > > 
> > > >> > > --add-modules
> > > >> > > ALL-SYSTEM
> > > >> > > 
> > > >> > > 
> > > >> > > 
> > > >> > >
>  org.apache.maven.plugins
> >
> > > >> > > maven-surefire-pl
> > > >> ugin
> > > >> > > 2.20
> > > >> > >     
> > > >> > > --add-modules
> > > >> ALL-SYSTEM
> > > >> > > 
> > > >> > > 
> > > >> > > 
> > > >> > > 
> > > >> > > 
> > > >> > >
> > > >> > >
> > > >> > > -- Enrico
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=5>>:
> > > >> > > > 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 <[hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=7>
> > > >> > > > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=8>
> > > >> > > >
> > > >> > >
> > > >> > >
> > > -
> > > >> > > To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=9>
> > > >> > > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node=5912520=10>
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9-
> > tp5905517p5912520.html
> > To start a new topic under Maven Developers, email
> > ml+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9-tp5905517p5912569.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

-- 


-- Enrico Olivelli

Re: Building a Java9 project just using JDK9

[Tibor Digana]

gt; > > [9,)
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > > org.apache.maven.plugins
>
> > >> > >
> >  maven-javadoc-plugin
> > >> > > 
> > >> > > --add-modules
> > >> > > ALL-SYSTEM
> > >> > > 
> > >> > > 
> > >> > >             
> > >> > > org.apache.maven.plugins
>
> > >> > > maven-surefire-pl
> > >> ugin
> > >> > > 2.20
> > >> > > 
> > >> > > --add-modules
> > >> ALL-SYSTEM
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > > 
> > >> > >
> > >> > >
> > >> > > -- Enrico
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=5>>:
> > >> > > > 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 <[hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=6>> 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: [hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=7>
> > >> > > > For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=8>
> > >> > > >
> > >> > >
> > >> > >
> > -
> > >> > > To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=9>
> > >> > > For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node=5912520=10>
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> --
>
>
> -- Enrico Olivelli
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9-
> tp5905517p5912520.html
> To start a new topic under Maven Developers, email
> ml+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9-tp5905517p5912569.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: Building a Java9 project just using JDK9

[Karl Heinz Marbaise]

Hi Gary,

as Robert already pointed out Maven can run fine on JDK 9...for a very 
long time..


I'm working on support for jlink, jmod to support creation of run time 
images with Maven simple (currently in its alpha states if this is 
appropriate) ...which can be looked at the currenty example project[1] 
also in my blog[2] etc.


Furthermore we have at the moment only left few problems (see 
maven-ear-plugin)...The maven-ejb-plugin where currently the VOTE is 
running for which fixes issues related to JDK 9...


Robert is making many efforts on getting things done in 
maven-compiler-plugin and many other plugins/components as well...


The current state can be looked at the wiki[4]

It would be great to see people trying to use JDK 9 and see how it works 
with Maven...in particular issues related to migration to JDK 9 and 
modularization? What are the pain points ?


I've taken an example project which does some usage of JDK 9 and modules 
in a way I don't like (changind maven default directory layout) so I'm 
trying to fix in the way I like to see how it should work...and if it 
works...And currently there is an issue in maven-compiler-plugin which 
will be fixed with the next released which will come very soon...


Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/jdk9-jlink-jmod-example
[2]: 
http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/
[3]: 
https://dzone.com/articles/jdk9-howto-create-a-java-run-time-image-with-maven

[4]: https://s.apache.org/maven-j9



On 15/08/17 20:10, Robert Scholte wrote:
On Tue, 15 Aug 2017 19:57:37 +0200, Gary Gregory 
 wrote:


I'm guessing that all the pain of doing this will not be fully known 
until

Maven is Java 9-ified.


Not sure what you mean by this. Maven itself can run on Java 9, most 
plugins work with Java 9, most Java 9 features are supported.


Don't expect Maven to become a modularized project. We have split 
packages, which we cannot remove.
Based on the 2 pillars of Jigsaw, i.e strong encapsulation and reliable 
configuration, I think Maven would like to benefit from the first one, 
but I don't see the reliable configuration as an issue.
Modularizing would mean a complete rewrite with new packages, which 
would make all current maven-plugins probably useless.

To sum it all up: modularizing is probably not worth it for this project.

Robert



Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:


Il mar 15 ago 2017, 17:51 Gary Gregory  ha
scritto:

> You will need the same tricks at runtime for the command line that 
Maven

> might hide at build time... :-( I guess hacks like --add-modules
ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be 
hacked

in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully 
migrate to

the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven 
goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now 
we are

going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana 
ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of 
modules is

> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however 
JEE8

has
> > not
> > > yet been released even if the ambition was to develop JEE9 in
parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from 
jigsaw.
> > I think that the strong encapsulation work will make development 
of the

> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from 
java8

to
> > java9 ad far as we can. Maybe most of developers which are using 
maven

> will
> > not see all the tricks under the hood
> >
> > 

Re: Building a Java9 project just using JDK9

[Robert Scholte]

On Tue, 15 Aug 2017 19:57:37 +0200, Gary Gregory   
wrote:


I'm guessing that all the pain of doing this will not be fully known  
until

Maven is Java 9-ified.


Not sure what you mean by this. Maven itself can run on Java 9, most  
plugins work with Java 9, most Java 9 features are supported.


Don't expect Maven to become a modularized project. We have split  
packages, which we cannot remove.
Based on the 2 pillars of Jigsaw, i.e strong encapsulation and reliable  
configuration, I think Maven would like to benefit from the first one, but  
I don't see the reliable configuration as an issue.
Modularizing would mean a complete rewrite with new packages, which would  
make all current maven-plugins probably useless.

To sum it all up: modularizing is probably not worth it for this project.

Robert



Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:


Il mar 15 ago 2017, 17:51 Gary Gregory  ha
scritto:

> You will need the same tricks at runtime for the command line that  
Maven

> might hide at build time... :-( I guess hacks like --add-modules
ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be  
hacked

in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully migrate  
to

the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven  
goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now we  
are

going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana 
ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of  
modules is

> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however  
JEE8

has
> > not
> > > yet been released even if the ambition was to develop JEE9 in
parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from  
jigsaw.
> > I think that the strong encapsulation work will make development of  
the

> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from  
java8

to
> > java9 ad far as we can. Maybe most of developers which are using  
maven

> will
> > not see all the tricks under the hood
> >
> > Thank you
> >
> >
> > Enrico
> >
> >
> > > I understand that development parties of application servers and
> > libraries
> > > suppliers are slow but this still would not guarantee that there  
is

no
> > risk
> > > that Jigsaw project made some mistake which (if happens) cannot be
> taken
> > > back after the final release of JSE9.
> > >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <
eolive...@gmail.com
> >
> > > wrote:
> > >
> > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
tibor.dig...@googlemail.com>
> > ha
> > > > scritto:
> > > >
> > > > > Hello Enrico,
> > > > >
> > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > I need an approval for the Jira SUREFIRE-1403 for you and  
Robert.

> Thx
> > > in
> > > > > advance.
> > > > >
> > > >
> > > > I will check as soon as I wil be back from vacation. Thank you  
very

> > much.
> > > > For me it is very important
> > > >
> > > > >
> > > > > I have added integration tests for Failsafe plugin, added
> > > documentation "
> > > > > java9.md" and removed JAXB which is located in module
> > > > *javax.xml.binding*.
> > > > >
> > > > > *Here is a clarification on why I was unhappy with Java status
and
> > why
> > > > > Surefire project could not run with Java 9 and how it was  
fixed:*

> > > > >
> > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not
run
> in
> > > > > Java9.
> > > > > Reason is that module *javax.xml.binding* is however in Java  
API

> but
> > > not
> > > > > propagated on classpath when running Maven process (different

Re: Building a Java9 project just using JDK9

[Gary Gregory]

I'm guessing that all the pain of doing this will not be fully known until
Maven is Java 9-ified.

Gary

On Tue, Aug 15, 2017 at 10:16 AM, Enrico Olivelli 
wrote:

> Il mar 15 ago 2017, 17:51 Gary Gregory  ha
> scritto:
>
> > You will need the same tricks at runtime for the command line that Maven
> > might hide at build time... :-( I guess hacks like --add-modules
> ALL-SYSTEM
> > will become part of our daily grind...
> >
>
> Gary, I think you are right, scripts to launch applications will be hacked
> in the same way, at least during the transition.
> New j9 applications which do not use the classpath will not suffer from
> this problem. Anyway in order to launch a jigsaw enabled application you
> have to change the arguments passed to the jvm and so to fully migrate to
> the new j9 style a lot of work is to be done.
>
> For many developers most of the work life is bound to running maven goals.
> When I just wanted to try j9 I got into a lot of blocker issues. Now we are
> going to make the life easier to develop and test java8 applications and
> gradually switch to java9
>
> Cheers
> Enrico
>
>
> > Gary
> >
> > On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> > wrote:
> >
> > > Il mar 15 ago 2017, 00:03 Tibor Digana 
> ha
> > > scritto:
> > >
> > > > I do not want to be too pessimistic but the inheritance of modules is
> > > > crucial for all the world.
> > > >
> > > > The common sense tells me that I should not release Java 9 on
> > September,
> > > > 2017 unless Java EE application servers work properly.
> > > >
> > > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS
> and
> > > > maybe we will find out new issues which regarding for module
> > java.se.ee.
> > > >
> > > > Without waiting for JEE9 this release would be too fast.
> > > > Oracle had an ambition to align JSE9 release with JEE9 however JEE8
> has
> > > not
> > > > yet been released even if the ambition was to develop JEE9 in
> parallel
> > > with
> > > > JEE8.
> > > >
> > > > Isn't this too fast for the release of JSE9?
> > > >
> > >
> > > We are all waiting java9 and all the new features, apart from jigsaw.
> > > I think that the strong encapsulation work will make development of the
> > jdk
> > > more simple and new java releases will follow a faster pace.
> > > I am really worried about the lack of interest in defining exacly at
> > least
> > > the behaviour of most used frameworks, first of all the wrb
> > > applications/servlet world
> > >
> > > I am happy that the maven world will make it easy to switch from java8
> to
> > > java9 ad far as we can. Maybe most of developers which are using maven
> > will
> > > not see all the tricks under the hood
> > >
> > > Thank you
> > >
> > >
> > > Enrico
> > >
> > >
> > > > I understand that development parties of application servers and
> > > libraries
> > > > suppliers are slow but this still would not guarantee that there is
> no
> > > risk
> > > > that Jigsaw project made some mistake which (if happens) cannot be
> > taken
> > > > back after the final release of JSE9.
> > > >
> > > >
> > > >
> > > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
> tibor.dig...@googlemail.com>
> > > ha
> > > > > scritto:
> > > > >
> > > > > > Hello Enrico,
> > > > > >
> > > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert.
> > Thx
> > > > in
> > > > > > advance.
> > > > > >
> > > > >
> > > > > I will check as soon as I wil be back from vacation. Thank you very
> > > much.
> > > > > For me it is very important
> > > > >
> > > > > >
> > > > > > I have added integration tests for Failsafe plugin, added
> > > > documentation "
> > > > > > java9.md" and removed JAXB which is located in module
> > > > > *javax.xml.binding*.
> > > > > >
> > > > > > *Here is a clarification on why I was unhappy with Java status
> and
> > > why
> > > > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > > > >
> > > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not
> run
> > in
> > > > > > Java9.
> > > > > > Reason is that module *javax.xml.binding* is however in Java API
> > but
> > > > not
> > > > > > propagated on classpath when running Maven process (different
> > > situation
> > > > > in
> > > > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > > > This is strange and will be strange for most people, for instance
> > in
> > > > our
> > > > > > *Java
> > > > > > EE project using REST* the WildFly server has to use
> > *"--add-modules
> > > > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working
> again.
> > > > > > As a solution in Surefire project I removed JAXB which was simple
> > XML
> > > > in
> > > > > my
> > > > > > case but not simple in 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il mar 15 ago 2017, 17:51 Gary Gregory  ha scritto:

> You will need the same tricks at runtime for the command line that Maven
> might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
> will become part of our daily grind...
>

Gary, I think you are right, scripts to launch applications will be hacked
in the same way, at least during the transition.
New j9 applications which do not use the classpath will not suffer from
this problem. Anyway in order to launch a jigsaw enabled application you
have to change the arguments passed to the jvm and so to fully migrate to
the new j9 style a lot of work is to be done.

For many developers most of the work life is bound to running maven goals.
When I just wanted to try j9 I got into a lot of blocker issues. Now we are
going to make the life easier to develop and test java8 applications and
gradually switch to java9

Cheers
Enrico


> Gary
>
> On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
> wrote:
>
> > Il mar 15 ago 2017, 00:03 Tibor Digana  ha
> > scritto:
> >
> > > I do not want to be too pessimistic but the inheritance of modules is
> > > crucial for all the world.
> > >
> > > The common sense tells me that I should not release Java 9 on
> September,
> > > 2017 unless Java EE application servers work properly.
> > >
> > > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> > > maybe we will find out new issues which regarding for module
> java.se.ee.
> > >
> > > Without waiting for JEE9 this release would be too fast.
> > > Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has
> > not
> > > yet been released even if the ambition was to develop JEE9 in parallel
> > with
> > > JEE8.
> > >
> > > Isn't this too fast for the release of JSE9?
> > >
> >
> > We are all waiting java9 and all the new features, apart from jigsaw.
> > I think that the strong encapsulation work will make development of the
> jdk
> > more simple and new java releases will follow a faster pace.
> > I am really worried about the lack of interest in defining exacly at
> least
> > the behaviour of most used frameworks, first of all the wrb
> > applications/servlet world
> >
> > I am happy that the maven world will make it easy to switch from java8 to
> > java9 ad far as we can. Maybe most of developers which are using maven
> will
> > not see all the tricks under the hood
> >
> > Thank you
> >
> >
> > Enrico
> >
> >
> > > I understand that development parties of application servers and
> > libraries
> > > suppliers are slow but this still would not guarantee that there is no
> > risk
> > > that Jigsaw project made some mistake which (if happens) cannot be
> taken
> > > back after the final release of JSE9.
> > >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli  >
> > > wrote:
> > >
> > > > Il lun 14 ago 2017, 11:46 Tibor Digana 
> > ha
> > > > scritto:
> > > >
> > > > > Hello Enrico,
> > > > >
> > > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert.
> Thx
> > > in
> > > > > advance.
> > > > >
> > > >
> > > > I will check as soon as I wil be back from vacation. Thank you very
> > much.
> > > > For me it is very important
> > > >
> > > > >
> > > > > I have added integration tests for Failsafe plugin, added
> > > documentation "
> > > > > java9.md" and removed JAXB which is located in module
> > > > *javax.xml.binding*.
> > > > >
> > > > > *Here is a clarification on why I was unhappy with Java status and
> > why
> > > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > > >
> > > > > Because of I used *javax.xml.binding*, plugin Failsafe did not run
> in
> > > > > Java9.
> > > > > Reason is that module *javax.xml.binding* is however in Java API
> but
> > > not
> > > > > propagated on classpath when running Maven process (different
> > situation
> > > > in
> > > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > > This is strange and will be strange for most people, for instance
> in
> > > our
> > > > > *Java
> > > > > EE project using REST* the WildFly server has to use
> *"--add-modules
> > > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > > > As a solution in Surefire project I removed JAXB which was simple
> XML
> > > in
> > > > my
> > > > > case but not simple in general.
> > > > >
> > > >
> > > > I will have to do it for several projects, or at leastleast to add
> > > > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > > > default, that is weird to me
> > > >
> > > > >
> > > > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > > > modularity".
> > > > > But there are reasons where you will use it.
> > > > > For instance new API in Java or Java EE 9 in the future.
> > > > >
> > > >
> > > 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il dom 13 ago 2017, 17:31 Tibor Digana  ha
scritto:

> I found an issue. JDK printed this on std/out:
> WARNING: Using incubator modules: jdk.incubator.httpclient
>

IMHO This is because we are importing all system modules. Maybe importing
only java.se.ee would cover most of the cases.
I did not notice the warning on test I have run today

Enrico


> It hapens after my test:
>
> import org.junit.Test;
>
> public class J9Test
> {
> @Test
> public void testMiscellaneousAPI() throws java.sql.SQLException
> {
> System.out.println( "loaded class " +
> java.sql.SQLException.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.ws.Holder.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.bind.JAXBException.class.getName() );
> System.out.println( "loaded class " +
> org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.xpath.XPath.class.getName() );
> System.out.println( "java.specification.version=" +
> System.getProperty( "java.specification.version" ) );
> }
>
> @Test
> public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> {
> }
> }
>
>
> On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana  >
> wrote:
>
> > But why to add it? It's a hack. I do not use module-info.java and so
> there
> > is no reason to break the backwards compatibility.
> >
> > This is no more about Maven. It is about entire Java world.
> > If we in Maven do it then everybody has to.
> > And I am sure that the voices says that Kotlin is better and Scala is
> > better would make sense. Why to help these attempts to happen? No reason!
> >
> > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> > wrote:
> >
> >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> >> specific
> >> tags like below is going to be painful.
> >>
> >> Gary
> >>
> >> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
> >>
> >> > 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.

Re: Building a Java9 project just using JDK9

[Gary Gregory]

You will need the same tricks at runtime for the command line that Maven
might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
will become part of our daily grind...

Gary

On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli 
wrote:

> Il mar 15 ago 2017, 00:03 Tibor Digana  ha
> scritto:
>
> > I do not want to be too pessimistic but the inheritance of modules is
> > crucial for all the world.
> >
> > The common sense tells me that I should not release Java 9 on September,
> > 2017 unless Java EE application servers work properly.
> >
> > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> > maybe we will find out new issues which regarding for module java.se.ee.
> >
> > Without waiting for JEE9 this release would be too fast.
> > Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has
> not
> > yet been released even if the ambition was to develop JEE9 in parallel
> with
> > JEE8.
> >
> > Isn't this too fast for the release of JSE9?
> >
>
> We are all waiting java9 and all the new features, apart from jigsaw.
> I think that the strong encapsulation work will make development of the jdk
> more simple and new java releases will follow a faster pace.
> I am really worried about the lack of interest in defining exacly at least
> the behaviour of most used frameworks, first of all the wrb
> applications/servlet world
>
> I am happy that the maven world will make it easy to switch from java8 to
> java9 ad far as we can. Maybe most of developers which are using maven will
> not see all the tricks under the hood
>
> Thank you
>
>
> Enrico
>
>
> > I understand that development parties of application servers and
> libraries
> > suppliers are slow but this still would not guarantee that there is no
> risk
> > that Jigsaw project made some mistake which (if happens) cannot be taken
> > back after the final release of JSE9.
> >
> >
> >
> > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli 
> > wrote:
> >
> > > Il lun 14 ago 2017, 11:46 Tibor Digana 
> ha
> > > scritto:
> > >
> > > > Hello Enrico,
> > > >
> > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx
> > in
> > > > advance.
> > > >
> > >
> > > I will check as soon as I wil be back from vacation. Thank you very
> much.
> > > For me it is very important
> > >
> > > >
> > > > I have added integration tests for Failsafe plugin, added
> > documentation "
> > > > java9.md" and removed JAXB which is located in module
> > > *javax.xml.binding*.
> > > >
> > > > *Here is a clarification on why I was unhappy with Java status and
> why
> > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > >
> > > > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > > > Java9.
> > > > Reason is that module *javax.xml.binding* is however in Java API but
> > not
> > > > propagated on classpath when running Maven process (different
> situation
> > > in
> > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > This is strange and will be strange for most people, for instance in
> > our
> > > > *Java
> > > > EE project using REST* the WildFly server has to use *"--add-modules
> > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > > As a solution in Surefire project I removed JAXB which was simple XML
> > in
> > > my
> > > > case but not simple in general.
> > > >
> > >
> > > I will have to do it for several projects, or at leastleast to add
> > > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > > default, that is weird to me
> > >
> > > >
> > > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > > modularity".
> > > > But there are reasons where you will use it.
> > > > For instance new API in Java or Java EE 9 in the future.
> > > >
> > >
> > > The main reason for migration is to keep up to date, java8 will soon
> > reach
> > > EOL.
> > > Java9 comes with many improvements that just upgrading will speed up
> most
> > > applications, just think about nee compat strings. New API are great
> and
> > > were expected from long time ago, like the new Process API
> > >
> > >
> > > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> > principle.
> > > >
> > >
> > > Yep, new applications will be more fine tuned, the problem here is only
> > for
> > > the migration
> > >
> > > As a workaround to this in Maven would be to develop *smart
> > > > maven-compiler-plugin* which automatically generates
> > *module-info.class*
> > > > upon import sections in Java classes and Maven dependencies.
> > > > Not easy I guess.
> > > >
> > >
> > > I think this will be not feasible in general and very dangerous and
> > maybe I
> > > hope maven will never do such things
> > >
> > > Cheers
> > > Enrico
> > >
> > > >
> > > >
> 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il mar 15 ago 2017, 00:03 Tibor Digana  ha
scritto:

> I do not want to be too pessimistic but the inheritance of modules is
> crucial for all the world.
>
> The common sense tells me that I should not release Java 9 on September,
> 2017 unless Java EE application servers work properly.
>
> This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> maybe we will find out new issues which regarding for module java.se.ee.
>
> Without waiting for JEE9 this release would be too fast.
> Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has not
> yet been released even if the ambition was to develop JEE9 in parallel with
> JEE8.
>
> Isn't this too fast for the release of JSE9?
>

We are all waiting java9 and all the new features, apart from jigsaw.
I think that the strong encapsulation work will make development of the jdk
more simple and new java releases will follow a faster pace.
I am really worried about the lack of interest in defining exacly at least
the behaviour of most used frameworks, first of all the wrb
applications/servlet world

I am happy that the maven world will make it easy to switch from java8 to
java9 ad far as we can. Maybe most of developers which are using maven will
not see all the tricks under the hood

Thank you


Enrico


> I understand that development parties of application servers and libraries
> suppliers are slow but this still would not guarantee that there is no risk
> that Jigsaw project made some mistake which (if happens) cannot be taken
> back after the final release of JSE9.
>
>
>
> On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli 
> wrote:
>
> > Il lun 14 ago 2017, 11:46 Tibor Digana  ha
> > scritto:
> >
> > > Hello Enrico,
> > >
> > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx
> in
> > > advance.
> > >
> >
> > I will check as soon as I wil be back from vacation. Thank you very much.
> > For me it is very important
> >
> > >
> > > I have added integration tests for Failsafe plugin, added
> documentation "
> > > java9.md" and removed JAXB which is located in module
> > *javax.xml.binding*.
> > >
> > > *Here is a clarification on why I was unhappy with Java status and why
> > > Surefire project could not run with Java 9 and how it was fixed:*
> > >
> > > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > > Java9.
> > > Reason is that module *javax.xml.binding* is however in Java API but
> not
> > > propagated on classpath when running Maven process (different situation
> > in
> > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > This is strange and will be strange for most people, for instance in
> our
> > > *Java
> > > EE project using REST* the WildFly server has to use *"--add-modules
> > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > As a solution in Surefire project I removed JAXB which was simple XML
> in
> > my
> > > case but not simple in general.
> > >
> >
> > I will have to do it for several projects, or at leastleast to add
> > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > default, that is weird to me
> >
> > >
> > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > modularity".
> > > But there are reasons where you will use it.
> > > For instance new API in Java or Java EE 9 in the future.
> > >
> >
> > The main reason for migration is to keep up to date, java8 will soon
> reach
> > EOL.
> > Java9 comes with many improvements that just upgrading will speed up most
> > applications, just think about nee compat strings. New API are great and
> > were expected from long time ago, like the new Process API
> >
> >
> > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> principle.
> > >
> >
> > Yep, new applications will be more fine tuned, the problem here is only
> for
> > the migration
> >
> > As a workaround to this in Maven would be to develop *smart
> > > maven-compiler-plugin* which automatically generates
> *module-info.class*
> > > upon import sections in Java classes and Maven dependencies.
> > > Not easy I guess.
> > >
> >
> > I think this will be not feasible in general and very dangerous and
> maybe I
> > hope maven will never do such things
> >
> > Cheers
> > Enrico
> >
> > >
> > >
> > > On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli  >
> > > wrote:
> > >
> > > > Il dom 13 ago 2017, 17:31 Tibor Digana 
> > ha
> > > > scritto:
> > > >
> > > > > I found an issue. JDK printed this on std/out:
> > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > >
> > > > > It hapens after my test:
> > > > >
> > > > > import org.junit.Test;
> > > > >
> > > > > public class J9Test
> > > > > {
> > > > > @Test
> > > > > public void testMiscellaneousAPI() 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

I do not want to be too pessimistic but the inheritance of modules is
crucial for all the world.

The common sense tells me that I should not release Java 9 on September,
2017 unless Java EE application servers work properly.

This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
maybe we will find out new issues which regarding for module java.se.ee.

Without waiting for JEE9 this release would be too fast.
Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has not
yet been released even if the ambition was to develop JEE9 in parallel with
JEE8.

Isn't this too fast for the release of JSE9?

I understand that development parties of application servers and libraries
suppliers are slow but this still would not guarantee that there is no risk
that Jigsaw project made some mistake which (if happens) cannot be taken
back after the final release of JSE9.



On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli 
wrote:

> Il lun 14 ago 2017, 11:46 Tibor Digana  ha
> scritto:
>
> > Hello Enrico,
> >
> > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx in
> > advance.
> >
>
> I will check as soon as I wil be back from vacation. Thank you very much.
> For me it is very important
>
> >
> > I have added integration tests for Failsafe plugin, added documentation "
> > java9.md" and removed JAXB which is located in module
> *javax.xml.binding*.
> >
> > *Here is a clarification on why I was unhappy with Java status and why
> > Surefire project could not run with Java 9 and how it was fixed:*
> >
> > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > Java9.
> > Reason is that module *javax.xml.binding* is however in Java API but not
> > propagated on classpath when running Maven process (different situation
> in
> > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > This is strange and will be strange for most people, for instance in our
> > *Java
> > EE project using REST* the WildFly server has to use *"--add-modules
> > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > As a solution in Surefire project I removed JAXB which was simple XML in
> my
> > case but not simple in general.
> >
>
> I will have to do it for several projects, or at leastleast to add
> java.se.ee, in fact many programs need JDBCTO and it is excluded by
> default, that is weird to me
>
> >
> > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > modularity".
> > But there are reasons where you will use it.
> > For instance new API in Java or Java EE 9 in the future.
> >
>
> The main reason for migration is to keep up to date, java8 will soon reach
> EOL.
> Java9 comes with many improvements that just upgrading will speed up most
> applications, just think about nee compat strings. New API are great and
> were expected from long time ago, like the new Process API
>
>
> > I do not think that using *"--add-modules ALL-SYSTEM"* is good principle.
> >
>
> Yep, new applications will be more fine tuned, the problem here is only for
> the migration
>
> As a workaround to this in Maven would be to develop *smart
> > maven-compiler-plugin* which automatically generates *module-info.class*
> > upon import sections in Java classes and Maven dependencies.
> > Not easy I guess.
> >
>
> I think this will be not feasible in general and very dangerous and maybe I
> hope maven will never do such things
>
> Cheers
> Enrico
>
> >
> >
> > On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli 
> > wrote:
> >
> > > Il dom 13 ago 2017, 17:31 Tibor Digana 
> ha
> > > scritto:
> > >
> > > > I found an issue. JDK printed this on std/out:
> > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > >
> > > > It hapens after my test:
> > > >
> > > > import org.junit.Test;
> > > >
> > > > public class J9Test
> > > > {
> > > > @Test
> > > > public void testMiscellaneousAPI() throws java.sql.SQLException
> > > > {
> > > > System.out.println( "loaded class " +
> > > > java.sql.SQLException.class.getName() );
> > > > System.out.println( "loaded class " +
> > > > javax.xml.ws.Holder.class.getName() );
> > > > System.out.println( "loaded class " +
> > > > javax.xml.bind.JAXBException.class.getName() );
> > > > System.out.println( "loaded class " +
> > > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > > > System.out.println( "loaded class " +
> > > > javax.xml.xpath.XPath.class.getName() );
> > > > System.out.println( "java.specification.version=" +
> > > > System.getProperty( "java.specification.version" ) );
> > > > }
> > > >
> > > > @Test
> > > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> > > > {
> > > > }
> > > > }
> > > >
> > > >
> > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il lun 14 ago 2017, 11:46 Tibor Digana  ha
scritto:

> Hello Enrico,
>
> I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx in
> advance.
>

I will check as soon as I wil be back from vacation. Thank you very much.
For me it is very important

>
> I have added integration tests for Failsafe plugin, added documentation "
> java9.md" and removed JAXB which is located in module *javax.xml.binding*.
>
> *Here is a clarification on why I was unhappy with Java status and why
> Surefire project could not run with Java 9 and how it was fixed:*
>
> Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> Java9.
> Reason is that module *javax.xml.binding* is however in Java API but not
> propagated on classpath when running Maven process (different situation in
> forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> This is strange and will be strange for most people, for instance in our
> *Java
> EE project using REST* the WildFly server has to use *"--add-modules
> ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> As a solution in Surefire project I removed JAXB which was simple XML in my
> case but not simple in general.
>

I will have to do it for several projects, or at leastleast to add
java.se.ee, in fact many programs need JDBCTO and it is excluded by
default, that is weird to me

>
> Someone may say that "do not use Java 9 if you do not use Jigsaw
> modularity".
> But there are reasons where you will use it.
> For instance new API in Java or Java EE 9 in the future.
>

The main reason for migration is to keep up to date, java8 will soon reach
EOL.
Java9 comes with many improvements that just upgrading will speed up most
applications, just think about nee compat strings. New API are great and
were expected from long time ago, like the new Process API


> I do not think that using *"--add-modules ALL-SYSTEM"* is good principle.
>

Yep, new applications will be more fine tuned, the problem here is only for
the migration

As a workaround to this in Maven would be to develop *smart
> maven-compiler-plugin* which automatically generates *module-info.class*
> upon import sections in Java classes and Maven dependencies.
> Not easy I guess.
>

I think this will be not feasible in general and very dangerous and maybe I
hope maven will never do such things

Cheers
Enrico

>
>
> On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli 
> wrote:
>
> > Il dom 13 ago 2017, 17:31 Tibor Digana  ha
> > scritto:
> >
> > > I found an issue. JDK printed this on std/out:
> > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > >
> > > It hapens after my test:
> > >
> > > import org.junit.Test;
> > >
> > > public class J9Test
> > > {
> > > @Test
> > > public void testMiscellaneousAPI() throws java.sql.SQLException
> > > {
> > > System.out.println( "loaded class " +
> > > java.sql.SQLException.class.getName() );
> > > System.out.println( "loaded class " +
> > > javax.xml.ws.Holder.class.getName() );
> > > System.out.println( "loaded class " +
> > > javax.xml.bind.JAXBException.class.getName() );
> > > System.out.println( "loaded class " +
> > > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > > System.out.println( "loaded class " +
> > > javax.xml.xpath.XPath.class.getName() );
> > > System.out.println( "java.specification.version=" +
> > > System.getProperty( "java.specification.version" ) );
> > > }
> > >
> > > @Test
> > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> > > {
> > > }
> > > }
> > >
> > >
> > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <
> > tibor.dig...@googlemail.com
> > > >
> > > wrote:
> > >
> > > > But why to add it? It's a hack. I do not use module-info.java and so
> > > there
> > > > is no reason to break the backwards compatibility.
> > > >
> > > > This is no more about Maven. It is about entire Java world.
> > > > If we in Maven do it then everybody has to.
> > > > And I am sure that the voices says that Kotlin is better and Scala is
> > > > better would make sense. Why to help these attempts to happen? No
> > reason!
> > > >
> > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > > > wrote:
> > > >
> > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> > > >> specific
> > > >> tags like below is going to be painful.
> > > >>
> > > >> Gary
> > > >>
> > > >> On Aug 13, 2017 07:30, "Tibor Digana" 
> wrote:
> > > >>
> > > >> > Hi @Enrico,
> > > >> >
> > > >> > I am very unhappy with Java 9 status and very afraid.
> > >
> >
> > Tibor, thank you very much for your time and your effort.
> > I think that we should have chimed in long time before the approval of
> > those decisions on the jre. Now the game is over, we can only 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

Hello Enrico,

I fixed SUREFIRE-1403 and now Surefire works with Java 9.
I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx in
advance.

I have added integration tests for Failsafe plugin, added documentation "
java9.md" and removed JAXB which is located in module *javax.xml.binding*.

*Here is a clarification on why I was unhappy with Java status and why
Surefire project could not run with Java 9 and how it was fixed:*

Because of I used *javax.xml.binding*, plugin Failsafe did not run in Java9.
Reason is that module *javax.xml.binding* is however in Java API but not
propagated on classpath when running Maven process (different situation in
forked JVM in Surefire which is here fixed by SUREFIRE-1403).
This is strange and will be strange for most people, for instance in our *Java
EE project using REST* the WildFly server has to use *"--add-modules
ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
As a solution in Surefire project I removed JAXB which was simple XML in my
case but not simple in general.

Someone may say that "do not use Java 9 if you do not use Jigsaw
modularity".
But there are reasons where you will use it.
For instance new API in Java or Java EE 9 in the future.

I do not think that using *"--add-modules ALL-SYSTEM"* is good principle.
As a workaround to this in Maven would be to develop *smart
maven-compiler-plugin* which automatically generates *module-info.class*
upon import sections in Java classes and Maven dependencies.
Not easy I guess.


On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli 
wrote:

> Il dom 13 ago 2017, 17:31 Tibor Digana  ha
> scritto:
>
> > I found an issue. JDK printed this on std/out:
> > WARNING: Using incubator modules: jdk.incubator.httpclient
> >
> > It hapens after my test:
> >
> > import org.junit.Test;
> >
> > public class J9Test
> > {
> > @Test
> > public void testMiscellaneousAPI() throws java.sql.SQLException
> > {
> > System.out.println( "loaded class " +
> > java.sql.SQLException.class.getName() );
> > System.out.println( "loaded class " +
> > javax.xml.ws.Holder.class.getName() );
> > System.out.println( "loaded class " +
> > javax.xml.bind.JAXBException.class.getName() );
> > System.out.println( "loaded class " +
> > org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> > System.out.println( "loaded class " +
> > javax.xml.xpath.XPath.class.getName() );
> > System.out.println( "java.specification.version=" +
> > System.getProperty( "java.specification.version" ) );
> > }
> >
> > @Test
> > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> > {
> > }
> > }
> >
> >
> > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <
> tibor.dig...@googlemail.com
> > >
> > wrote:
> >
> > > But why to add it? It's a hack. I do not use module-info.java and so
> > there
> > > is no reason to break the backwards compatibility.
> > >
> > > This is no more about Maven. It is about entire Java world.
> > > If we in Maven do it then everybody has to.
> > > And I am sure that the voices says that Kotlin is better and Scala is
> > > better would make sense. Why to help these attempts to happen? No
> reason!
> > >
> > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> > > wrote:
> > >
> > >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> > >> specific
> > >> tags like below is going to be painful.
> > >>
> > >> Gary
> > >>
> > >> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
> > >>
> > >> > Hi @Enrico,
> > >> >
> > >> > I am very unhappy with Java 9 status and very afraid.
> >
>
> Tibor, thank you very much for your time and your effort.
> I think that we should have chimed in long time before the approval of
> those decisions on the jre. Now the game is over, we can only decide how
> maven users will deal with running classpath based applications on java9.
> I see two approaches:
> 1) add a lot of tricks in every base maven plugin and make it very easy to
> transition
> 2) leave the complexity to developers who will add a lot of profiles and
> hacks to detect java9
>
> My personal feeling is that I am very disappointed by the fact the few
> developers diffs not report this issues to the maven community long time
> ago. I think that the java9 adoption has not been taken into account by
> most developers and this will be an huge pain for the java community.
> I hope that Maven will help the java world to go on and to step over this
> painful transition
>
> I will test your patch as soon as I can
> Cheers
> Enrico
>
> >> > 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 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il dom 13 ago 2017, 17:31 Tibor Digana  ha
scritto:

> I found an issue. JDK printed this on std/out:
> WARNING: Using incubator modules: jdk.incubator.httpclient
>
> It hapens after my test:
>
> import org.junit.Test;
>
> public class J9Test
> {
> @Test
> public void testMiscellaneousAPI() throws java.sql.SQLException
> {
> System.out.println( "loaded class " +
> java.sql.SQLException.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.ws.Holder.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.bind.JAXBException.class.getName() );
> System.out.println( "loaded class " +
> org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.xpath.XPath.class.getName() );
> System.out.println( "java.specification.version=" +
> System.getProperty( "java.specification.version" ) );
> }
>
> @Test
> public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> {
> }
> }
>
>
> On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana  >
> wrote:
>
> > But why to add it? It's a hack. I do not use module-info.java and so
> there
> > is no reason to break the backwards compatibility.
> >
> > This is no more about Maven. It is about entire Java world.
> > If we in Maven do it then everybody has to.
> > And I am sure that the voices says that Kotlin is better and Scala is
> > better would make sense. Why to help these attempts to happen? No reason!
> >
> > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> > wrote:
> >
> >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> >> specific
> >> tags like below is going to be painful.
> >>
> >> Gary
> >>
> >> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
> >>
> >> > Hi @Enrico,
> >> >
> >> > I am very unhappy with Java 9 status and very afraid.
>

Tibor, thank you very much for your time and your effort.
I think that we should have chimed in long time before the approval of
those decisions on the jre. Now the game is over, we can only decide how
maven users will deal with running classpath based applications on java9.
I see two approaches:
1) add a lot of tricks in every base maven plugin and make it very easy to
transition
2) leave the complexity to developers who will add a lot of profiles and
hacks to detect java9

My personal feeling is that I am very disappointed by the fact the few
developers diffs not report this issues to the maven community long time
ago. I think that the java9 adoption has not been taken into account by
most developers and this will be an huge pain for the java community.
I hope that Maven will help the java world to go on and to step over this
painful transition

I will test your patch as soon as I can
Cheers
Enrico

>> > 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
> >> 

Re: Building a Java9 project just using JDK9

[Fred Cooke]

I'll throw my 2c in here, too:

Java 9 runtime forces me to rewrite parts of my application because
non-root thread priority control is no longer available. Plenty of people
have relied on lines like this to achieve their desired behaviour:

java -jar -Xms128m -Xmx1024m *-XX:ThreadPriorityPolicy=42*
/usr/share/java/some.jar "$@"

Not only is thread deprioritisation as non-root no longer available
(arbitrary decision on JRE's part, OS can do it!), the JRE won't even start
up with that line, rejecting it entirely as invalid when it's been
*unofficially* valid since who knows when.

I understand that it's roughly equivalent to equivalent importing from
com.sun, however the existing behaviour could simply have been documented
and an official numeric option for "reasonable behaviour" added, then
making it compatible without breaking J8 JRE compatibility would have been
as simple as dropping the 4, or similar.

Aside from that, the extra class included when compiled with J9 is not
bytecode compatible, even if the rest of the jar is. That breaks the
obfuscator. Solvable by not using the latest/greatest, but... somewhat
annoying when the rest of the jar is fine.

Regards,

Fred.


On 14 August 2017 at 03:30, Tibor Digana 
wrote:

> I found an issue. JDK printed this on std/out:
> WARNING: Using incubator modules: jdk.incubator.httpclient
>
> It hapens after my test:
>
> import org.junit.Test;
>
> public class J9Test
> {
> @Test
> public void testMiscellaneousAPI() throws java.sql.SQLException
> {
> System.out.println( "loaded class " +
> java.sql.SQLException.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.ws.Holder.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.bind.JAXBException.class.getName() );
> System.out.println( "loaded class " +
> org.omg.CORBA.BAD_INV_ORDER.class.getName() );
> System.out.println( "loaded class " +
> javax.xml.xpath.XPath.class.getName() );
> System.out.println( "java.specification.version=" +
> System.getProperty( "java.specification.version" ) );
> }
>
> @Test
> public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
> {
> }
> }
>
>
> On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana  >
> wrote:
>
> > But why to add it? It's a hack. I do not use module-info.java and so
> there
> > is no reason to break the backwards compatibility.
> >
> > This is no more about Maven. It is about entire Java world.
> > If we in Maven do it then everybody has to.
> > And I am sure that the voices says that Kotlin is better and Scala is
> > better would make sense. Why to help these attempts to happen? No reason!
> >
> > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> > wrote:
> >
> >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
> >> specific
> >> tags like below is going to be painful.
> >>
> >> Gary
> >>
> >> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
> >>
> >> > 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
> 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

I found an issue. JDK printed this on std/out:
WARNING: Using incubator modules: jdk.incubator.httpclient

It hapens after my test:

import org.junit.Test;

public class J9Test
{
@Test
public void testMiscellaneousAPI() throws java.sql.SQLException
{
System.out.println( "loaded class " +
java.sql.SQLException.class.getName() );
System.out.println( "loaded class " +
javax.xml.ws.Holder.class.getName() );
System.out.println( "loaded class " +
javax.xml.bind.JAXBException.class.getName() );
System.out.println( "loaded class " +
org.omg.CORBA.BAD_INV_ORDER.class.getName() );
System.out.println( "loaded class " +
javax.xml.xpath.XPath.class.getName() );
System.out.println( "java.specification.version=" +
System.getProperty( "java.specification.version" ) );
}

@Test
public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
{
}
}


On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana 
wrote:

> But why to add it? It's a hack. I do not use module-info.java and so there
> is no reason to break the backwards compatibility.
>
> This is no more about Maven. It is about entire Java world.
> If we in Maven do it then everybody has to.
> And I am sure that the voices says that Kotlin is better and Scala is
> better would make sense. Why to help these attempts to happen? No reason!
>
> On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
> wrote:
>
>> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin
>> specific
>> tags like below is going to be painful.
>>
>> Gary
>>
>> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
>>
>> > 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 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

But why to add it? It's a hack. I do not use module-info.java and so there
is no reason to break the backwards compatibility.

This is no more about Maven. It is about entire Java world.
If we in Maven do it then everybody has to.
And I am sure that the voices says that Kotlin is better and Scala is
better would make sense. Why to help these attempts to happen? No reason!

On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory 
wrote:

> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin specific
> tags like below is going to be painful.
>
> Gary
>
> On Aug 13, 2017 07:30, "Tibor Digana"  wrote:
>
> > 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 
> > 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
> > >
> > > 
> > > jdk9
> > > 
> > > [9,)
> > > 
> > > 
> > > 
> > > 
> > 

Re: Building a Java9 project just using JDK9

[Gary Gregory]

Is there a Maven way to add ALL-SYSTEM to everything? Using plugin specific
tags like below is going to be painful.

Gary

On Aug 13, 2017 07:30, "Tibor Digana"  wrote:

> 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 
> 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
> >
> > 
> > jdk9
> > 
> > [9,)
> > 
> > 
> > 
> > 
> > org.apache.maven.plugins
> > maven-javadoc-plugin
> > 
> > --add-modules
> > ALL-SYSTEM
> > 
> > 
> > 
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > 2.20
> > 
> > --add-modules ALL-SYSTEM
> > 
> > 
> > 
> > 
> > 
> >
> >
> > -- Enrico
> >
> >
> >
> > 2017-04-24 19:08 GMT+02:00 Karl Heinz 

Re: Building a Java9 project just using JDK9

[Tibor Digana]

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 
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
>
> 
> jdk9
> 
> [9,)
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 
> --add-modules
> ALL-SYSTEM
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
> 
> --add-modules ALL-SYSTEM
> 
> 
> 
> 
> 
>
>
> -- Enrico
>
>
>
> 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise :
> > 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  ha scritto:
> 

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

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


jdk9

[9,)




org.apache.maven.plugins
maven-javadoc-plugin

--add-modules
ALL-SYSTEM



org.apache.maven.plugins
maven-surefire-plugin
2.20

--add-modules ALL-SYSTEM







-- Enrico



2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise :
> 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  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

Re: Building a Java9 project just using JDK9

[Karl Heinz Marbaise]

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  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

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

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  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
>
-- 


-- Enrico Olivelli

Re: Building a Java9 project just using JDK9

[Paul Hammant]

>
>
>> 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

Re: Building a Java9 project just using JDK9

[Robert Scholte]

Yes, I think that makes sense. Will do so.

Robert

On Wed, 12 Apr 2017 03:15:41 +0200, Hervé BOUTEMY   
wrote:



Robert,

Should this war plugin be added to the Java 9 - Jigsaw Wiki page in the
plugins section?
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

Regards,

Hervé

Le mardi 11 avril 2017, 10:14:12 CEST Enrico Olivelli a écrit :

Thank you all for your quick answers

@Robert
I have checked out the code and took a deeper look:
the implementation of MWAR-397 is complex and will take some time, on  
the

mid term I agree that it will an awesome solution
https://issues.apache.org/jira/browse/MWAR-397

@Jörg
The option --permit-illegal-access will not work for me as it will hide
most of the problems of Java9 fo

I would like to propose a simpler patch which prevents the  
maven-war-plugin

from crashing at clinit
https://github.com/apache/maven-plugins/pull/112

this will make it work just by disabling the cache
I see it is a very temporary fix but lets everyone go on with Java9  
Webapps


If the idea is good a can file a JIRA, clean up the code respecting the
conventions or the project and file a clean PR

Another fallback would be to use the Kryo library, which let's you
serialize non-serializable objects, but I have not tests

2017-04-10 22:46 GMT+02:00 Jörg Schaible :
> Enrico Olivelli wrote:
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> >
> > scritto:
> >> Hi,
> >>
> >> On 10/04/17 17:37, Enrico Olivelli wrote:
> >> > Hi,
> >> > I would like be able to build an existing project developed for  
java8

> >> > by simple running Maven on jdk9.
> >> >
> >> > Actually it is not possible, I am aware of that and I am  
currently

> >> > following all the news about Maven and Java9
> >>
> >> What is not possible ? Do you have an error message / log file  
etc. ?

> >
> > Actually I am blocked on the TreeMap issue with xstream and
> > maven-war-plugin.
> > Is there any active work on that issue?
> >
> >  I see it is marked as an external dep problem but on xstream issue
> >  tracker
> >
> > it seems that it is not a priority
>
> You should be able to run it with  
MAVEN_OPTS="--permit-illegal-access" -

> at
> least until a solution is available.
>
> Cheers,
> Jörg
>
>
> -
> 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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

I have created the JIRA to better track my proposal

https://issues.apache.org/jira/browse/MWAR-405


2017-04-12 3:15 GMT+02:00 Hervé BOUTEMY :

> Robert,
>
> Should this war plugin be added to the Java 9 - Jigsaw Wiki page in the
> plugins section?
> https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw
>
> Regards,
>
> Hervé
>
> Le mardi 11 avril 2017, 10:14:12 CEST Enrico Olivelli a écrit :
> > Thank you all for your quick answers
> >
> > @Robert
> > I have checked out the code and took a deeper look:
> > the implementation of MWAR-397 is complex and will take some time, on the
> > mid term I agree that it will an awesome solution
> > https://issues.apache.org/jira/browse/MWAR-397
> >
> > @Jörg
> > The option --permit-illegal-access will not work for me as it will hide
> > most of the problems of Java9 fo
> >
> > I would like to propose a simpler patch which prevents the
> maven-war-plugin
> > from crashing at clinit
> > https://github.com/apache/maven-plugins/pull/112
> >
> > this will make it work just by disabling the cache
> > I see it is a very temporary fix but lets everyone go on with Java9
> Webapps
> >
> > If the idea is good a can file a JIRA, clean up the code respecting the
> > conventions or the project and file a clean PR
> >
> > Another fallback would be to use the Kryo library, which let's you
> > serialize non-serializable objects, but I have not tests
> >
> > 2017-04-10 22:46 GMT+02:00 Jörg Schaible :
> > > Enrico Olivelli wrote:
> > > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> > > >
> > > > scritto:
> > > >> Hi,
> > > >>
> > > >> On 10/04/17 17:37, Enrico Olivelli wrote:
> > > >> > Hi,
> > > >> > I would like be able to build an existing project developed for
> java8
> > > >> > by simple running Maven on jdk9.
> > > >> >
> > > >> > Actually it is not possible, I am aware of that and I am currently
> > > >> > following all the news about Maven and Java9
> > > >>
> > > >> What is not possible ? Do you have an error message / log file etc.
> ?
> > > >
> > > > Actually I am blocked on the TreeMap issue with xstream and
> > > > maven-war-plugin.
> > > > Is there any active work on that issue?
> > > >
> > > >  I see it is marked as an external dep problem but on xstream issue
> > > >  tracker
> > > >
> > > > it seems that it is not a priority
> > >
> > > You should be able to run it with MAVEN_OPTS="--permit-illegal-access"
> -
> > > at
> > > least until a solution is available.
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > -
> > > 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
>
>

Re: Building a Java9 project just using JDK9

[Hervé BOUTEMY]

Robert,

Should this war plugin be added to the Java 9 - Jigsaw Wiki page in the 
plugins section?
https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

Regards,

Hervé

Le mardi 11 avril 2017, 10:14:12 CEST Enrico Olivelli a écrit :
> Thank you all for your quick answers
> 
> @Robert
> I have checked out the code and took a deeper look:
> the implementation of MWAR-397 is complex and will take some time, on the
> mid term I agree that it will an awesome solution
> https://issues.apache.org/jira/browse/MWAR-397
> 
> @Jörg
> The option --permit-illegal-access will not work for me as it will hide
> most of the problems of Java9 fo
> 
> I would like to propose a simpler patch which prevents the maven-war-plugin
> from crashing at clinit
> https://github.com/apache/maven-plugins/pull/112
> 
> this will make it work just by disabling the cache
> I see it is a very temporary fix but lets everyone go on with Java9 Webapps
> 
> If the idea is good a can file a JIRA, clean up the code respecting the
> conventions or the project and file a clean PR
> 
> Another fallback would be to use the Kryo library, which let's you
> serialize non-serializable objects, but I have not tests
> 
> 2017-04-10 22:46 GMT+02:00 Jörg Schaible :
> > Enrico Olivelli wrote:
> > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> > > 
> > > scritto:
> > >> Hi,
> > >> 
> > >> On 10/04/17 17:37, Enrico Olivelli wrote:
> > >> > Hi,
> > >> > I would like be able to build an existing project developed for java8
> > >> > by simple running Maven on jdk9.
> > >> > 
> > >> > Actually it is not possible, I am aware of that and I am currently
> > >> > following all the news about Maven and Java9
> > >> 
> > >> What is not possible ? Do you have an error message / log file etc. ?
> > > 
> > > Actually I am blocked on the TreeMap issue with xstream and
> > > maven-war-plugin.
> > > Is there any active work on that issue?
> > > 
> > >  I see it is marked as an external dep problem but on xstream issue
> > >  tracker
> > > 
> > > it seems that it is not a priority
> > 
> > You should be able to run it with MAVEN_OPTS="--permit-illegal-access" -
> > at
> > least until a solution is available.
> > 
> > Cheers,
> > Jörg
> > 
> > 
> > -
> > 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

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

@Jörg
I have updated the PR with your proposal of registering only a bunch of
converters.
https://github.com/apache/maven-plugins/pull/112

It is working very well (with a very simple webapp) !

I think it is the most simple solution for the Java9 problem actually. It
does not require invasive code change.

Is this a good short/mid term solution ? Can a submit a JIRA ?




2017-04-11 10:25 GMT+02:00 Jörg Schaible :

> Hi Enrico,
>
> Enrico Olivelli wrote:
>
> > Thank you all for your quick answers
> >
> > @Robert
> > I have checked out the code and took a deeper look:
> > the implementation of MWAR-397 is complex and will take some time, on the
> > mid term I agree that it will an awesome solution
> > https://issues.apache.org/jira/browse/MWAR-397
> >
> > @Jörg
> > The option --permit-illegal-access will not work for me as it will hide
> > most of the problems of Java9 fo
>
> At least it writes still any violation to stderr. As said, that is also
> just
> a temporary solution.
>
> > I would like to propose a simpler patch which prevents the
> > maven-war-plugin from crashing at clinit
> > https://github.com/apache/maven-plugins/pull/112
> >
> > this will make it work just by disabling the cache
> > I see it is a very temporary fix but lets everyone go on with Java9
> > Webapps
> >
> > If the idea is good a can file a JIRA, clean up the code respecting the
> > conventions or the project and file a clean PR
>
> In that case you might simply overload XStream's setupConverters method and
> register only the converters used for the scenario in the war-plugin. If
> the
> object graph does not contain a TreeSet, there's no need to initialize and
> register a converter for it.
>
> > Another fallback would be to use the Kryo library, which let's you
> > serialize non-serializable objects, but I have not tests
>
> Cannot say anything about it.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Building a Java9 project just using JDK9

[Jörg Schaible]

Hi Enrico,

Enrico Olivelli wrote:

> Thank you all for your quick answers
> 
> @Robert
> I have checked out the code and took a deeper look:
> the implementation of MWAR-397 is complex and will take some time, on the
> mid term I agree that it will an awesome solution
> https://issues.apache.org/jira/browse/MWAR-397
> 
> @Jörg
> The option --permit-illegal-access will not work for me as it will hide
> most of the problems of Java9 fo

At least it writes still any violation to stderr. As said, that is also just 
a temporary solution.

> I would like to propose a simpler patch which prevents the
> maven-war-plugin from crashing at clinit
> https://github.com/apache/maven-plugins/pull/112
> 
> this will make it work just by disabling the cache
> I see it is a very temporary fix but lets everyone go on with Java9
> Webapps
> 
> If the idea is good a can file a JIRA, clean up the code respecting the
> conventions or the project and file a clean PR

In that case you might simply overload XStream's setupConverters method and 
register only the converters used for the scenario in the war-plugin. If the 
object graph does not contain a TreeSet, there's no need to initialize and 
register a converter for it.

> Another fallback would be to use the Kryo library, which let's you
> serialize non-serializable objects, but I have not tests

Cannot say anything about it.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Thank you all for your quick answers

@Robert
I have checked out the code and took a deeper look:
the implementation of MWAR-397 is complex and will take some time, on the
mid term I agree that it will an awesome solution
https://issues.apache.org/jira/browse/MWAR-397

@Jörg
The option --permit-illegal-access will not work for me as it will hide
most of the problems of Java9 fo

I would like to propose a simpler patch which prevents the maven-war-plugin
from crashing at clinit
https://github.com/apache/maven-plugins/pull/112

this will make it work just by disabling the cache
I see it is a very temporary fix but lets everyone go on with Java9 Webapps

If the idea is good a can file a JIRA, clean up the code respecting the
conventions or the project and file a clean PR

Another fallback would be to use the Kryo library, which let's you
serialize non-serializable objects, but I have not tests




2017-04-10 22:46 GMT+02:00 Jörg Schaible :

> Enrico Olivelli wrote:
>
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> > scritto:
> >
> >> Hi,
> >>
> >> On 10/04/17 17:37, Enrico Olivelli wrote:
> >> > Hi,
> >> > I would like be able to build an existing project developed for java8
> >> > by simple running Maven on jdk9.
> >> >
> >> > Actually it is not possible, I am aware of that and I am currently
> >> > following all the news about Maven and Java9
> >>
> >> What is not possible ? Do you have an error message / log file etc. ?
> >>
> >
> > Actually I am blocked on the TreeMap issue with xstream and
> > maven-war-plugin.
> > Is there any active work on that issue?
> >  I see it is marked as an external dep problem but on xstream issue
> >  tracker
> > it seems that it is not a priority
>
> You should be able to run it with MAVEN_OPTS="--permit-illegal-access" -
> at
> least until a solution is available.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Building a Java9 project just using JDK9

[Jörg Schaible]

Enrico Olivelli wrote:

> Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> scritto:
> 
>> Hi,
>>
>> On 10/04/17 17:37, Enrico Olivelli wrote:
>> > Hi,
>> > I would like be able to build an existing project developed for java8
>> > by simple running Maven on jdk9.
>> >
>> > Actually it is not possible, I am aware of that and I am currently
>> > following all the news about Maven and Java9
>>
>> What is not possible ? Do you have an error message / log file etc. ?
>>
> 
> Actually I am blocked on the TreeMap issue with xstream and
> maven-war-plugin.
> Is there any active work on that issue?
>  I see it is marked as an external dep problem but on xstream issue
>  tracker
> it seems that it is not a priority

You should be able to run it with MAVEN_OPTS="--permit-illegal-access" - at 
least until a solution is available.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il lun 10 apr 2017, 22:32 Robert Scholte  ha scritto:

> On Mon, 10 Apr 2017 22:23:27 +0200, Enrico Olivelli 
> wrote:
>
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> > scritto:
> >
> >> Hi,
> >>
> >> On 10/04/17 17:37, Enrico Olivelli wrote:
> >> > Hi,
> >> > I would like be able to build an existing project developed for java8
> >> by
> >> > simple running Maven on jdk9.
> >> >
> >> > Actually it is not possible, I am aware of that and I am currently
> >> > following all the news about Maven and Java9
> >>
> >> What is not possible ? Do you have an error message / log file etc. ?
> >>
> >
> > Actually I am blocked on the TreeMap issue with xstream and
> > maven-war-plugin.
> > Is there any active work on that issue?
> >  I see it is marked as an external dep problem but on xstream issue
> > tracker
> > it seems that it is not a priority
> >
> >
> I don't see any activity either, so my idea is to replace XStream, see
> MWAR-397[1]
> But it's not that easy, classes are mixture of pojo's and business logic,
> which need to be separated.
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MWAR-39
> 



Thank you Robert. I will take a deep look into the plugin. If possible I
will be happy to contribute. I will be back soon




>
>
>
> >> Kind regards
> >> Karl Heinz
> >>
> >> >
> >> > So I would like to "help" in order to "get things working" as Java9
> >> now
> >> > reached the "Developer Preview
> >> > 
> >> milestone"
> >> > and a really would like to start checking all of my projects against
> >> Java9.
> >> >
> >> >
> >> > Thanks
> >> > -- Enrico
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> --
> >
> >
> > -- Enrico Olivelli
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --


-- Enrico Olivelli

Re: Building a Java9 project just using JDK9

[Robert Scholte]

On Mon, 10 Apr 2017 22:23:27 +0200, Enrico Olivelli   
wrote:



Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
scritto:


Hi,

On 10/04/17 17:37, Enrico Olivelli wrote:
> Hi,
> I would like be able to build an existing project developed for java8  
by

> simple running Maven on jdk9.
>
> Actually it is not possible, I am aware of that and I am currently
> following all the news about Maven and Java9

What is not possible ? Do you have an error message / log file etc. ?



Actually I am blocked on the TreeMap issue with xstream and
maven-war-plugin.
Is there any active work on that issue?
 I see it is marked as an external dep problem but on xstream issue  
tracker

it seems that it is not a priority


I don't see any activity either, so my idea is to replace XStream, see  
MWAR-397[1]
But it's not that easy, classes are mixture of pojo's and business logic,  
which need to be separated.


Robert

[1] https://issues.apache.org/jira/browse/MWAR-397


Kind regards
Karl Heinz

>
> So I would like to "help" in order to "get things working" as Java9  
now

> reached the "Developer Preview
> 
milestone"
> and a really would like to start checking all of my projects against
Java9.
>
>
> Thanks
> -- Enrico
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--



-- Enrico Olivelli


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Building a Java9 project just using JDK9

[Enrico Olivelli]

Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
scritto:

> Hi,
>
> On 10/04/17 17:37, Enrico Olivelli wrote:
> > Hi,
> > I would like be able to build an existing project developed for java8 by
> > simple running Maven on jdk9.
> >
> > Actually it is not possible, I am aware of that and I am currently
> > following all the news about Maven and Java9
>
> What is not possible ? Do you have an error message / log file etc. ?
>

Actually I am blocked on the TreeMap issue with xstream and
maven-war-plugin.
Is there any active work on that issue?
 I see it is marked as an external dep problem but on xstream issue tracker
it seems that it is not a priority


> Kind regards
> Karl Heinz
>
> >
> > So I would like to "help" in order to "get things working" as Java9 now
> > reached the "Developer Preview
> > 
> milestone"
> > and a really would like to start checking all of my projects against
> Java9.
> >
> >
> > Thanks
> > -- Enrico
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --


-- Enrico Olivelli

Re: Building a Java9 project just using JDK9

[Karl Heinz Marbaise]

Hi,

On 10/04/17 17:37, Enrico Olivelli wrote:

Hi,
I would like be able to build an existing project developed for java8 by
simple running Maven on jdk9.

Actually it is not possible, I am aware of that and I am currently
following all the news about Maven and Java9


What is not possible ? Do you have an error message / log file etc. ?

Kind regards
Karl Heinz



So I would like to "help" in order to "get things working" as Java9 now
reached the "Developer Preview
 milestone"
and a really would like to start checking all of my projects against Java9.


Thanks
-- Enrico



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Building a Java9 project just using JDK9

[Enrico Olivelli]

Hi,
I would like be able to build an existing project developed for java8 by
simple running Maven on jdk9.

Actually it is not possible, I am aware of that and I am currently
following all the news about Maven and Java9

So I would like to "help" in order to "get things working" as Java9 now
reached the "Developer Preview
 milestone"
and a really would like to start checking all of my projects against Java9.


Thanks
-- Enrico