Building a Java9 project just using JDK9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
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

Robert Scholte-6
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

Robert Scholte-6
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 Robert Scholte-6
>
>
>> 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
I would like to share my current pom configuration which lets me to
build and test java8 apps on latest and greatest jdk9

This profile is activated when using jdk9.

This is based on a suggestion of Robert, its suggestion for the
javadoc plugin is working great with surefire too

<profile>
            <id>jdk9</id>
            <activation>
                <jdk>[9,)</jdk>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <configuration>
                            <additionalparam>--add-modules
ALL-SYSTEM</additionalparam>
                        </configuration>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.20</version>
                        <configuration>
                            <argLine>--add-modules ALL-SYSTEM</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>


-- Enrico



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

Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Gary Gregory-2
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-plugin</artifactId>
> >                         <version>2.20</version>
> >                         <configuration>
> >                             <argLine>--add-modules ALL-SYSTEM</argLine>
> >                         </configuration>
> >                     </plugin>
> >                 </plugins>
> >             </build>
> >         </profile>
> >
> >
> > -- Enrico
> >
> >
> >
> > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[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]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

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

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

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

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

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

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

Regards,

Fred.


On 14 August 2017 at 03:30, Tibor Digana <[hidden email]>
wrote:

> I found an issue. JDK printed this on std/out:
> WARNING: Using incubator modules: jdk.incubator.httpclient
>
> It hapens after my test:
>
> import org.junit.Test;
>
> public class J9Test
> {
>     @Test
>     public void testMiscellaneousAPI() throws java.sql.SQLException
>     {
>         System.out.println( "loaded class " +
> java.sql.SQLException.class.getName() );
>         System.out.println( "loaded class " +
> javax.xml.ws.Holder.class.getName() );
>         System.out.println( "loaded class " +
> javax.xml.bind.JAXBException.class.getName() );
>         System.out.println( "loaded class " +
> org.omg.CORBA.BAD_INV_ORDER.class.getName() );
>         System.out.println( "loaded class " +
> javax.xml.xpath.XPath.class.getName() );
>         System.out.println( "java.specification.version=" +
> System.getProperty( "java.specification.version" ) );
>     }
>
>     @Test
>     public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER
>     {
>     }
> }
>
>
> On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[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
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Gary Gregory-2
In reply to this post by Gary Gregory-2
You will need the same tricks at runtime for the command line that Maven
might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
will become part of our daily grind...

Gary

On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli <[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
>
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Enrico Olivelli
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
Reply | Threaded
Open this post in threaded view
|

Re: Building a Java9 project just using JDK9

Bernd Eckenfels
In reply to this post by Paul Hammant
You recreate a limited modules JRE with jlink. Haven't tried it but maybe you can generate an image with Java.se.ee as root that way, too.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Tibor Digana <[hidden email]>
Sent: Wednesday, August 16, 2017 8:28:02 AM
To: Maven Developers List
Subject: Re: Building a Java9 project just using JDK9

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

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

On Wed, Aug 16, 2017 at 8:19 AM, Tibor Digana <[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.
>
> 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-ju
>> st-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?ma
>> cro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX
>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
>> > >
>> > > .
>> > > NAML
>> > > <
>> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?ma
>> cro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=
>> nabble.naml.namespaces.BasicNamespace-nabble.view.web.
>> template.NabbleNamespace-nabble.view.web.template.NodeNamesp
>> ace&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-ju
>> st-using-JDK9-tp5905517p5912569.html
>> > Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>> --
>>
>>
>> -- Enrico Olivelli
>>
>
>
>
> --
> Cheers
> Tibor
>



--
Cheers
Tibor
12