Building a Java9 project just using JDK9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

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
<http://openjdk.java.net/projects/jdk8/milestones#definitions> milestone"
and a really would like to start checking all of my projects against Java9.


Thanks
-- Enrico
Reply | Threaded
Open this post in threaded view
|

Building a Java8 project just using JDK9

Enrico Olivelli
Sorry for the typo in the subject

Il lun 10 apr 2017, 17:37 Enrico Olivelli <[hidden email]> ha scritto:

> 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
> <http://openjdk.java.net/projects/jdk8/milestones#definitions> milestone"
> and a really would like to start checking all of my projects against Java9.
>
>
> Thanks
> -- Enrico
>
>
> --


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Karl Heinz Marbaise-3
In reply to this post by Enrico Olivelli
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
> <http://openjdk.java.net/projects/jdk8/milestones#definitions> milestone"
> and a really would like to start checking all of my projects against Java9.
>
>
> Thanks
> -- Enrico
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Enrico Olivelli
Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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
> > <http://openjdk.java.net/projects/jdk8/milestones#definitions>
> milestone"
> > and a really would like to start checking all of my projects against
> Java9.
> >
> >
> > Thanks
> > -- Enrico
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

rfscholte
On Mon, 10 Apr 2017 22:23:27 +0200, Enrico Olivelli <[hidden email]>  
wrote:

> Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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
>> > <http://openjdk.java.net/projects/jdk8/milestones#definitions>
>> milestone"
>> > and a really would like to start checking all of my projects against
>> Java9.
>> >
>> >
>> > Thanks
>> > -- Enrico
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> --
>
>
> -- Enrico Olivelli

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Enrico Olivelli
Il lun 10 apr 2017, 22:32 Robert Scholte <[hidden email]> ha scritto:

> On Mon, 10 Apr 2017 22:23:27 +0200, Enrico Olivelli <[hidden email]>
> wrote:
>
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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
> <https://issues.apache.org/jira/browse/MWAR-397>



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
> >> > <http://openjdk.java.net/projects/jdk8/milestones#definitions>
> >> milestone"
> >> > and a really would like to start checking all of my projects against
> >> Java9.
> >> >
> >> >
> >> > Thanks
> >> > -- Enrico
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >> --
> >
> >
> > -- Enrico Olivelli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Jörg Schaible
In reply to this post by Enrico Olivelli
Enrico Olivelli wrote:

> Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> Enrico Olivelli wrote:
>
> > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Jörg Schaible-5
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Hervé BOUTEMY
In reply to this post by Enrico Olivelli
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 <[hidden email]>:
> > Enrico Olivelli wrote:
> > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 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 <[hidden email]>:
> > > Enrico Olivelli wrote:
> > > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

rfscholte
In reply to this post by Hervé BOUTEMY
Yes, I think that makes sense. Will do so.

Robert

On Wed, 12 Apr 2017 03:15:41 +0200, Hervé BOUTEMY <[hidden email]>  
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 <[hidden email]>:
>> > Enrico Olivelli wrote:
>> > > Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Paul Hammant
In reply to this post by rfscholte
>
>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

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

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
> >> 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 <[hidden email]
> >
> >> > wrote:
> >> >
> >> > > I would like to share my current pom configuration which lets me to
> >> > > build and test java8 apps on latest and greatest jdk9
> >> > >
> >> > > This profile is activated when using jdk9.
> >> > >
> >> > > This is based on a suggestion of Robert, its suggestion for the
> >> > > javadoc plugin is working great with surefire too
> >> > >
> >> > > <profile>
> >> > >             <id>jdk9</id>
> >> > >             <activation>
> >> > >                 <jdk>[9,)</jdk>
> >> > >             </activation>
> >> > >             <build>
> >> > >                 <plugins>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >
>  <artifactId>maven-javadoc-plugin</artifactId>
> >> > >                         <configuration>
> >> > >                             <additionalparam>--add-modules
> >> > > ALL-SYSTEM</additionalparam>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >                         <artifactId>maven-surefire-pl
> >> ugin</artifactId>
> >> > >                         <version>2.20</version>
> >> > >                         <configuration>
> >> > >                             <argLine>--add-modules
> >> ALL-SYSTEM</argLine>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                 </plugins>
> >> > >             </build>
> >> > >         </profile>
> >> > >
> >> > >
> >> > > -- Enrico
> >> > >
> >> > >
> >> > >
> >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]>:
> >> > > > 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]> 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]
> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
>
>
> --
> Cheers
> Tibor
>
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Tibor Digana-2
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 <[hidden email]>
wrote:

> Il lun 14 ago 2017, 11:46 Tibor Digana <[hidden email]> 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 <[hidden email]>
> > 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
> > > >
> > > > 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.
> > > >
> > >
> > > 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
> > > > >> 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 <
> > > [hidden email]
> > > > >
> > > > >> > wrote:
> > > > >> >
> > > > >> > > I would like to share my current pom configuration which lets
> me
> > > to
> > > > >> > > build and test java8 apps on latest and greatest jdk9
> > > > >> > >
> > > > >> > > This profile is activated when using jdk9.
> > > > >> > >
> > > > >> > > This is based on a suggestion of Robert, its suggestion for
> the
> > > > >> > > javadoc plugin is working great with surefire too
> > > > >> > >
> > > > >> > > <profile>
> > > > >> > >             <id>jdk9</id>
> > > > >> > >             <activation>
> > > > >> > >                 <jdk>[9,)</jdk>
> > > > >> > >             </activation>
> > > > >> > >             <build>
> > > > >> > >                 <plugins>
> > > > >> > >                     <plugin>
> > > > >> > >                         <groupId>org.apache.maven.
> > > plugins</groupId>
> > > > >> > >
> > > >  <artifactId>maven-javadoc-plugin</artifactId>
> > > > >> > >                         <configuration>
> > > > >> > >                             <additionalparam>--add-modules
> > > > >> > > ALL-SYSTEM</additionalparam>
> > > > >> > >                         </configuration>
> > > > >> > >                     </plugin>
> > > > >> > >                     <plugin>
> > > > >> > >                         <groupId>org.apache.maven.
> > > plugins</groupId>
> > > > >> > >                         <artifactId>maven-surefire-pl
> > > > >> ugin</artifactId>
> > > > >> > >                         <version>2.20</version>
> > > > >> > >                         <configuration>
> > > > >> > >                             <argLine>--add-modules
> > > > >> ALL-SYSTEM</argLine>
> > > > >> > >                         </configuration>
> > > > >> > >                     </plugin>
> > > > >> > >                 </plugins>
> > > > >> > >             </build>
> > > > >> > >         </profile>
> > > > >> > >
> > > > >> > >
> > > > >> > > -- Enrico
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <
> > [hidden email]
> > > >:
> > > > >> > > > 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]>
> 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]
> > > > >> > > > For additional commands, e-mail: [hidden email]
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > ------------------------------------------------------------
> ---------
> > > > >> > > To unsubscribe, e-mail: [hidden email]
> > > > >> > > For additional commands, e-mail: [hidden email]
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > > Tibor
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> --
>
>
> -- Enrico Olivelli
>



--
Cheers
Tibor
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Enrico Olivelli
In reply to this post by Paul Hammant
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 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 <[hidden email]
> >
> >> > wrote:
> >> >
> >> > > I would like to share my current pom configuration which lets me to
> >> > > build and test java8 apps on latest and greatest jdk9
> >> > >
> >> > > This profile is activated when using jdk9.
> >> > >
> >> > > This is based on a suggestion of Robert, its suggestion for the
> >> > > javadoc plugin is working great with surefire too
> >> > >
> >> > > <profile>
> >> > >             <id>jdk9</id>
> >> > >             <activation>
> >> > >                 <jdk>[9,)</jdk>
> >> > >             </activation>
> >> > >             <build>
> >> > >                 <plugins>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >
>  <artifactId>maven-javadoc-plugin</artifactId>
> >> > >                         <configuration>
> >> > >                             <additionalparam>--add-modules
> >> > > ALL-SYSTEM</additionalparam>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >                         <artifactId>maven-surefire-pl
> >> ugin</artifactId>
> >> > >                         <version>2.20</version>
> >> > >                         <configuration>
> >> > >                             <argLine>--add-modules
> >> ALL-SYSTEM</argLine>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                 </plugins>
> >> > >             </build>
> >> > >         </profile>
> >> > >
> >> > >
> >> > > -- Enrico
> >> > >
> >> > >
> >> > >
> >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]>:
> >> > > > 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]> 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]
> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
>
>
> --
> Cheers
> Tibor
>
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

rfscholte
In reply to this post by Tibor Digana-2
On Tue, 15 Aug 2017 19:57:37 +0200, Gary Gregory <[hidden email]>  
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 <[hidden email]>
> wrote:
>
>> Il mar 15 ago 2017, 17:51 Gary Gregory <[hidden email]> 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 <[hidden email]>
>> > wrote:
>> >
>> > > Il mar 15 ago 2017, 00:03 Tibor Digana <[hidden email]>
>> 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 <
>> [hidden email]
>> > >
>> > > > wrote:
>> > > >
>> > > > > Il lun 14 ago 2017, 11:46 Tibor Digana <
>> [hidden email]>
>> > > 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 <
>> > > [hidden email]
>> > > > >
>> > > > > > 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
>> > > > > > > >
>> > > > > > > > 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.
>> > > > > > > >
>> > > > > > >
>> > > > > > > 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
>> > > > > > > > >> 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 <
>> > > > > > > [hidden email]
>> > > > > > > > >
>> > > > > > > > >> > wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > I would like to share my current pom configuration
>> which
>> > > > lets
>> > > > > me
>> > > > > > > to
>> > > > > > > > >> > > build and test java8 apps on latest and greatest  
>> jdk9
>> > > > > > > > >> > >
>> > > > > > > > >> > > This profile is activated when using jdk9.
>> > > > > > > > >> > >
>> > > > > > > > >> > > This is based on a suggestion of Robert, its
>> suggestion
>> > > for
>> > > > > the
>> > > > > > > > >> > > javadoc plugin is working great with surefire too
>> > > > > > > > >> > >
>> > > > > > > > >> > > <profile>
>> > > > > > > > >> > >             <id>jdk9</id>
>> > > > > > > > >> > >             <activation>
>> > > > > > > > >> > >                 <jdk>[9,)</jdk>
>> > > > > > > > >> > >             </activation>
>> > > > > > > > >> > >             <build>
>> > > > > > > > >> > >                 <plugins>
>> > > > > > > > >> > >                     <plugin>
>> > > > > > > > >> > >                         <groupId>org.apache.maven.
>> > > > > > > plugins</groupId>
>> > > > > > > > >> > >
>> > > > > > > >  <artifactId>maven-javadoc-plugin</artifactId>
>> > > > > > > > >> > >                         <configuration>
>> > > > > > > > >> > >
>> >  <additionalparam>--add-modules
>> > > > > > > > >> > > ALL-SYSTEM</additionalparam>
>> > > > > > > > >> > >                         </configuration>
>> > > > > > > > >> > >                     </plugin>
>> > > > > > > > >> > >                     <plugin>
>> > > > > > > > >> > >                         <groupId>org.apache.maven.
>> > > > > > > plugins</groupId>
>> > > > > > > > >> > >                          
>> <artifactId>maven-surefire-pl
>> > > > > > > > >> ugin</artifactId>
>> > > > > > > > >> > >                         <version>2.20</version>
>> > > > > > > > >> > >                         <configuration>
>> > > > > > > > >> > >                             <argLine>--add-modules
>> > > > > > > > >> ALL-SYSTEM</argLine>
>> > > > > > > > >> > >                         </configuration>
>> > > > > > > > >> > >                     </plugin>
>> > > > > > > > >> > >                 </plugins>
>> > > > > > > > >> > >             </build>
>> > > > > > > > >> > >         </profile>
>> > > > > > > > >> > >
>> > > > > > > > >> > >
>> > > > > > > > >> > > -- Enrico
>> > > > > > > > >> > >
>> > > > > > > > >> > >
>> > > > > > > > >> > >
>> > > > > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <
>> > > > > > [hidden email]
>> > > > > > > >:
>> > > > > > > > >> > > > 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]
>> > > > >
>> > > > > 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].
>> > > org
>> > > > > > > > >> > > > For additional commands, e-mail:
>> > > > [hidden email]
>> > > > > > > > >> > > >
>> > > > > > > > >> > >
>> > > > > > > > >> > >
>> > > > > > > >  
>> ------------------------------------------------------------
>> > > > > ---------
>> > > > > > > > >> > > To unsubscribe, e-mail:
>> > [hidden email]
>> > > > > > > > >> > > For additional commands, e-mail:
>> > > [hidden email]
>> > > > > > > > >> > >
>> > > > > > > > >> > >
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Cheers
>> > > > > > > > > Tibor
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Cheers
>> > > > > > > > Tibor
>> > > > > > > >
>> > > > > > > --
>> > > > > > >
>> > > > > > >
>> > > > > > > -- Enrico Olivelli
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Cheers
>> > > > > > Tibor
>> > > > > >
>> > > > > --
>> > > > >
>> > > > >
>> > > > > -- Enrico Olivelli
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cheers
>> > > > Tibor
>> > > >
>> > > --
>> > >
>> > >
>> > > -- Enrico Olivelli
>> > >
>> >
>> --
>>
>>
>> -- Enrico Olivelli

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Tibor Digana
This post has NOT been accepted by the mailing list yet.
In reply to this post by Enrico Olivelli
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

On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] <[hidden email]> 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 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 <[hidden email]
> >

> >> > wrote:
> >> >
> >> > > I would like to share my current pom configuration which lets me to
> >> > > build and test java8 apps on latest and greatest jdk9
> >> > >
> >> > > This profile is activated when using jdk9.
> >> > >
> >> > > This is based on a suggestion of Robert, its suggestion for the
> >> > > javadoc plugin is working great with surefire too
> >> > >
> >> > > <profile>
> >> > >             <id>jdk9</id>
> >> > >             <activation>
> >> > >                 <jdk>[9,)</jdk>
> >> > >             </activation>
> >> > >             <build>
> >> > >                 <plugins>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >
>  <artifactId>maven-javadoc-plugin</artifactId>
> >> > >                         <configuration>
> >> > >                             <additionalparam>--add-modules
> >> > > ALL-SYSTEM</additionalparam>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                     <plugin>
> >> > >                         <groupId>org.apache.maven.plugins</groupId>
> >> > >                         <artifactId>maven-surefire-pl

> >> ugin</artifactId>
> >> > >                         <version>2.20</version>
> >> > >                         <configuration>
> >> > >                             <argLine>--add-modules
> >> ALL-SYSTEM</argLine>
> >> > >                         </configuration>
> >> > >                     </plugin>
> >> > >                 </plugins>
> >> > >             </build>
> >> > >         </profile>
> >> > >
> >> > >
> >> > > -- Enrico
> >> > >
> >> > >
> >> > >
> >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email]>:

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

> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> > --

> > 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 [hidden email]
To unsubscribe from Maven Developers, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Enrico Olivelli
On mer 16 ago 2017, 08:19 Tibor Digana <[hidden email]> 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.
>

I see your headache with this.
Maybe we could add only java.se.ee and document how to change to
all_system.
I will check the actual difference for normal applications


Cheers
Enrico


> On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli <[hidden email]>
> wrote:
>
> > Il mer 16 ago 2017, 02:44 Tibor Digana <[hidden email]> 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] <
> > > [hidden email]> wrote:
> > >
> > > > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=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&node=5912520&i=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.
> > > > > > 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]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=2>>
> > > > > > 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]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=3>> 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 <[hidden
> email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=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
> > > > > >> > >
> > > > > >> > > <profile>
> > > > > >> > >             <id>jdk9</id>
> > > > > >> > >             <activation>
> > > > > >> > >                 <jdk>[9,)</jdk>
> > > > > >> > >             </activation>
> > > > > >> > >             <build>
> > > > > >> > >                 <plugins>
> > > > > >> > >                     <plugin>
> > > > > >> > >
> > >  <groupId>org.apache.maven.plugins</groupId>
> > > >
> > > > > >> > >
> > > > >  <artifactId>maven-javadoc-plugin</artifactId>
> > > > > >> > >                         <configuration>
> > > > > >> > >                             <additionalparam>--add-modules
> > > > > >> > > ALL-SYSTEM</additionalparam>
> > > > > >> > >                         </configuration>
> > > > > >> > >                     </plugin>
> > > > > >> > >                     <plugin>
> > > > > >> > >
> > >  <groupId>org.apache.maven.plugins</groupId>
> > > >
> > > > > >> > >                         <artifactId>maven-surefire-pl
> > > > > >> ugin</artifactId>
> > > > > >> > >                         <version>2.20</version>
> > > > > >> > >                         <configuration>
> > > > > >> > >                             <argLine>--add-modules
> > > > > >> ALL-SYSTEM</argLine>
> > > > > >> > >                         </configuration>
> > > > > >> > >                     </plugin>
> > > > > >> > >                 </plugins>
> > > > > >> > >             </build>
> > > > > >> > >         </profile>
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > -- Enrico
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden
> email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=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&node=5912520&i=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&node=5912520&i=7>
> > > > > >> > > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=8>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > >> > > To unsubscribe, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=9>
> > > > > >> > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=5912520&i=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
> > > > [hidden email]
> > > > To unsubscribe from Maven Developers, click here
> > > > <
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> > wxNDIxNjZ8LTI4OTQ5MjEwMg==
> > > >
> > > > .
> > > > NAML
> > > > <
> > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?
> > macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&
> > base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> > web.template.NabbleNamespace-nabble.view.web.template.
> > NodeNamespace&breadcrumbs=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