Re: Prepare commons to JDK 9

[ajs6f]

> On Mar 12, 2018, at 1:13 PM, Ralph Goers  wrote:
> 
> 
> 
>> On Mar 12, 2018, at 9:27 AM, Jörg Schaible  wrote:
>> 
>> Hi Ralph,
>> 
>> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>>> 
>>> Actually, you really do need to use a multi-release jar to include a 
>>> module-info class file. Otherwise it may be sitting alongside of classes 
>>> compiled for an earlier java release and various tools will fail becaus of 
>>> it.
>> 
>> Not necessarily. XStream contains for more than a decade class files 
>> targeting different Java versions. Works  normally fine as long as nobody 
>> tries to load a class that cannot handled by the current runtime. Android 
>> has its problems with it, but it has already problems with Java 8 ;-)
> 
> You statement just proved my point. “Works fine as long as …”.  So as soon as 
> you want to support those various tools you have to stop doing that.
> 
> Ralph

Is there actually a standard list of tools or other build apparatus that is to 
be supported by Commons releases? I can name lots and lots of tools that won't 
work with Java 7 or even earlier versions. Most of them don't matter at all. 
I'm not making a claim about any particular tool or toolchain (including 
Android), but a general point.

I'd like to understand when "if we try X, our artifacts won't work on Y" is a 
valid blocker for a Commons project. In this case, the project (as has been 
repeatedly explained) aims to do nothing more than understand the conditions 
for using X and how to meet them, so I don't see how Android's (or any other 
specific project's) problems are a blocker at all. If anything, concern with 
problems for Android usage should be assuaged by a project that will help turn 
up more data about those problems.

Adam Soroka ; aj...@apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Prepare commons to JDK 9

[Ralph Goers]

> On Mar 12, 2018, at 9:27 AM, Jörg Schaible  wrote:
> 
> Hi Ralph,
> 
> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
> 
>>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne 
>>> wrote:
>>> 
>>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>>> six-month release which is about to be replaced by Java 10, which will
>>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>>> right now.
>>> 
>>> 2) Compiling a single jar file such that it works on Java 8 but has a
>>> module-info.class for Java 9 using Maven is a right pain in the
>>> backside. Most maven plugins cannot seamlessly handle it making the
>>> pom.xml much more complex. Note that you do not need a multi-release
>>> jar file to make it work. See
>>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>>> 
>> 
>> Actually, you really do need to use a multi-release jar to include a
>> module-info class file. Otherwise it may be sitting alongside of classes
>> compiled for an earlier java release and various tools will fail because
>> of it.
> 
> Not necessarily. XStream contains for more than a decade class files 
> targeting different Java versions. Works 
> normally fine as long as nobody tries to load a class that cannot handled by 
> the current runtime. Android has 
> its problems with it, but it has already problems with Java 8 ;-)

You statement just proved my point. “Works fine as long as …”.  So as soon as 
you want to support those various tools you have to stop doing that.

Ralph

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

Re: Prepare commons to JDK 9

[Jörg Schaible]

Hi Ralph,

On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:

>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne 
>> wrote:
>> 
>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>> six-month release which is about to be replaced by Java 10, which will
>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>> right now.
>> 
>> 2) Compiling a single jar file such that it works on Java 8 but has a
>> module-info.class for Java 9 using Maven is a right pain in the
>> backside. Most maven plugins cannot seamlessly handle it making the
>> pom.xml much more complex. Note that you do not need a multi-release
>> jar file to make it work. See
>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>> 
> 
> Actually, you really do need to use a multi-release jar to include a
> module-info class file. Otherwise it may be sitting alongside of classes
> compiled for an earlier java release and various tools will fail because
> of it.

Not necessarily. XStream contains for more than a decade class files targeting 
different Java versions. Works 
normally fine as long as nobody tries to load a class that cannot handled by 
the current runtime. Android has 
its problems with it, but it has already problems with Java 8 ;-)

Cheers,
Jörg


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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[ajs6f]

> On Mar 8, 2018, at 12:48 PM, Gary Gregory  wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles 
> wrote:
>> Then these modules can define "module-info" files, and an actual build will 
>> prove that the dependencies are as expected.
>> 
> As Ralph as pointed out, you cannot generate a module-info file without also 
> using an MR Jar unless you also want to make Java 9 your base line.

I'm not sure whether we would want to do this in a Maven profile (certainly the 
other way can work) but if not, we can use a Git branch for the purpose. In any 
event, there is a difference between working with Java 9 for a GSoC project and 
moving the component to Java 9. 

Again, just to clarify, in no way does this project propose to move the normal 
(release) baseline for anything at all. (As a side note, I would like to be the 
first to argue against _ever_ moving it to the non-LTS Java 9, but I think I 
will have to get in a long line of people who would argue against that! :) )

Adam Soroka ; aj...@apache.org


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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[Gary Gregory]

On Thu, Mar 8, 2018 at 10:29 AM, Gilles 
wrote:

> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>
>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f  wrote:
>>
>> > On Mar 8, 2018, at 8:33 AM, Gilles 
>>> wrote:
>>> > Would it be useful (and interesting as part of GSoC work) to
>>> > establish
>>> > (1) which tools requires fixing,
>>> > (2) prepare enhancement requests for the respective projects,
>>> > and in the meantime, adapt the "Commons" build (with a "JDK 9"
>>> > profile)
>>> > (3) to disable plugins that do not work yet,
>>> > (4) provide the option to generate a "multi-release" JAR (although
>>> >it would not be the deployed as part of the official release
>>> >process)?
>>>
>>> Hi, this is Adam Soroka (prospective mentor for this project). I'm sorry
>>> to have been absent from this conversation so far (been very busy this
>>> week) but Gilles has said much of what I would have said, so thanks
>>> Gilles!
>>>
>>> I would emphasize a couple of points:
>>>
>>> This is a GSoC project. The expectations and the marks of success are
>>> fundamentally different than for many other contributions.
>>>
>>> Gilles has rightly pointed out that this is about Commons RDF and that is
>>> all. Kamila unfortunately didn't make that clear in the subject line of
>>> the
>>> thread, but that was just a slip of the keyboard. It's not about any
>>> other
>>> piece of Commons. It won't affect them, so there's no need to worry about
>>> how release artifacts or other products for other components might be
>>> affected. They won't be.
>>>
>>> I don't think anyone would claim (or has claimed) that Commons (or any
>>> Commons component) should target Java9. The idea here is to work with the
>>> JPMS. There is no obvious or sensible way to do that without using Java9.
>>>
>>> The tasks that Kamila and Gilles have talked about are (IMHO) sensible
>>> and
>>> useful. We can discuss how soon and in what way Commons as a whole should
>>> engage with JPMS, but I don't see why that should stop individual
>>> components from exploring it. In fact, as Gilles points out, that will
>>> be a
>>> useful way of gathering info for a larger set of efforts.
>>>
>>> Lastly, on the assumption that Kamila's work involves a lot of "well,
>>> plugin X doesn't work, so I'll have to talk to that project", we are
>>> doing
>>> good. That is _EXACTLY_ what should happen during a GSoC project. The
>>> student should be discovering that working on open source software is
>>> often
>>> (I would say _very_ often) just as much about understanding how different
>>> software projects and communities relate to each other and how to get
>>> efforts synchronized than about just banging out line after line of code
>>> in
>>> isolation, only to throw the results over a fence to a single project.
>>>
>>> In summary-- this proposed project shouldn't affect anything or -one
>>> outside of the user base of Commons RDF (which hasn't even reached 1.0),
>>> and it may only result in a lot of documentation and "speculative" work,
>>> and that would be fine, as long as Kamila learns a lot about working with
>>> open source software efforts, which I'm confident she can and will.
>>>
>>> Adam Soroka ; aj...@apache.org
>>>
>>
>>
>> That's all quite nice but the hard reality is that the tool chains out
>> there are simply not ready for JPMS, as I've painfully learned
>> contributing
>> to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and
>> tools left and right.
>>
>
> OK but, assuming JDK 9+, there must a way to create artefacts by
> avoiding everything that breaks (hence the "profile" which all
> components could use).
> The end result would be a module whose access rights are enforced.
>
> So I do not see MR-jars as a viable options for any
>> Commons Components at this time. The best we can do ATM is play with
>> automatic module names in manifest files
>>
>
> As I've wondered many times here: How do you ensure anything
> by only writing this in the manifest?
>
> and look at what jdeps say about a
>> given component and see if we want to only depend on java.base or create
>> Maven modules to compartmentalize dependencies.
>>
>
> Then these modules can define "module-info" files, and an actual
> build will prove that the dependencies are as expected.
>

As Ralph as pointed out, you cannot generate a module-info file without
also using an MR Jar unless you also want to make Java 9 your base line.

Gary



>
> Best regards,
> Gilles
>
>
> Gary
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[Gary Gregory]

On Thu, Mar 8, 2018 at 10:21 AM, ajs6f  wrote:

>
> > On Mar 8, 2018, at 12:09 PM, Gary Gregory 
> wrote:
> >
> > That's all quite nice but the hard reality is that the tool chains out
> > there are simply not ready for JPMS, as I've painfully learned
> contributing
> > to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and
> > tools left and right. So I do not see MR-jars as a viable options for any
> > Commons Components at this time. The best we can do ATM is play with
> > automatic module names in manifest files and look at what jdeps say
> about a
> > given component and see if we want to only depend on java.base or create
> > Maven modules to compartmentalize dependencies.
> >
> > Gary
> >
>
> "breaks Maven plugins and tools left and right"
>
> Yes. That's the point. That's perfectly fine. Kamila will find out which
> break, and how, and what options we have to deal with them, and when we
> might need to go upstream and come back, and she will document that, and
> she will do what work can be done now on those problems.
>
> If Commons RDF does not release MR JARs as part of the GSoC project, but
> we do understand specifically and in detail why and what the blockers are,
> the project will have been a success.  With respect, I think you are now
> objecting to a project that hasn't actually been proposed, for which
> success would be releasing MR JARs. _That is not what is being proposed._
>

Good! :-)

Gary



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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[Gilles]

On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:

On Thu, Mar 8, 2018 at 10:01 AM, ajs6f  wrote:

> On Mar 8, 2018, at 8:33 AM, Gilles  
wrote:

> Would it be useful (and interesting as part of GSoC work) to
> establish
> (1) which tools requires fixing,
> (2) prepare enhancement requests for the respective projects,
> and in the meantime, adapt the "Commons" build (with a "JDK 9"
> profile)
> (3) to disable plugins that do not work yet,
> (4) provide the option to generate a "multi-release" JAR (although
>it would not be the deployed as part of the official release
>process)?

Hi, this is Adam Soroka (prospective mentor for this project). I'm 
sorry
to have been absent from this conversation so far (been very busy 
this
week) but Gilles has said much of what I would have said, so thanks 
Gilles!


I would emphasize a couple of points:

This is a GSoC project. The expectations and the marks of success 
are

fundamentally different than for many other contributions.

Gilles has rightly pointed out that this is about Commons RDF and 
that is
all. Kamila unfortunately didn't make that clear in the subject line 
of the
thread, but that was just a slip of the keyboard. It's not about any 
other
piece of Commons. It won't affect them, so there's no need to worry 
about
how release artifacts or other products for other components might 
be

affected. They won't be.

I don't think anyone would claim (or has claimed) that Commons (or 
any
Commons component) should target Java9. The idea here is to work 
with the
JPMS. There is no obvious or sensible way to do that without using 
Java9.


The tasks that Kamila and Gilles have talked about are (IMHO) 
sensible and
useful. We can discuss how soon and in what way Commons as a whole 
should

engage with JPMS, but I don't see why that should stop individual
components from exploring it. In fact, as Gilles points out, that 
will be a

useful way of gathering info for a larger set of efforts.

Lastly, on the assumption that Kamila's work involves a lot of 
"well,
plugin X doesn't work, so I'll have to talk to that project", we are 
doing
good. That is _EXACTLY_ what should happen during a GSoC project. 
The
student should be discovering that working on open source software 
is often
(I would say _very_ often) just as much about understanding how 
different
software projects and communities relate to each other and how to 
get
efforts synchronized than about just banging out line after line of 
code in
isolation, only to throw the results over a fence to a single 
project.


In summary-- this proposed project shouldn't affect anything or -one
outside of the user base of Commons RDF (which hasn't even reached 
1.0),
and it may only result in a lot of documentation and "speculative" 
work,
and that would be fine, as long as Kamila learns a lot about working 
with

open source software efforts, which I'm confident she can and will.

Adam Soroka ; aj...@apache.org



That's all quite nice but the hard reality is that the tool chains 
out
there are simply not ready for JPMS, as I've painfully learned 
contributing
to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins 
and

tools left and right.


OK but, assuming JDK 9+, there must a way to create artefacts by
avoiding everything that breaks (hence the "profile" which all
components could use).
The end result would be a module whose access rights are enforced.


So I do not see MR-jars as a viable options for any
Commons Components at this time. The best we can do ATM is play with
automatic module names in manifest files


As I've wondered many times here: How do you ensure anything
by only writing this in the manifest?


and look at what jdeps say about a
given component and see if we want to only depend on java.base or 
create

Maven modules to compartmentalize dependencies.


Then these modules can define "module-info" files, and an actual
build will prove that the dependencies are as expected.

Best regards,
Gilles


Gary




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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[ajs6f]

> On Mar 8, 2018, at 12:09 PM, Gary Gregory  wrote:
> 
> That's all quite nice but the hard reality is that the tool chains out
> there are simply not ready for JPMS, as I've painfully learned contributing
> to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and
> tools left and right. So I do not see MR-jars as a viable options for any
> Commons Components at this time. The best we can do ATM is play with
> automatic module names in manifest files and look at what jdeps say about a
> given component and see if we want to only depend on java.base or create
> Maven modules to compartmentalize dependencies.
> 
> Gary
> 

"breaks Maven plugins and tools left and right"

Yes. That's the point. That's perfectly fine. Kamila will find out which break, 
and how, and what options we have to deal with them, and when we might need to 
go upstream and come back, and she will document that, and she will do what 
work can be done now on those problems.

If Commons RDF does not release MR JARs as part of the GSoC project, but we do 
understand specifically and in detail why and what the blockers are, the 
project will have been a success.  With respect, I think you are now objecting 
to a project that hasn't actually been proposed, for which success would be 
releasing MR JARs. _That is not what is being proposed._

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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[Gary Gregory]

On Thu, Mar 8, 2018 at 10:01 AM, ajs6f  wrote:

> > On Mar 8, 2018, at 8:33 AM, Gilles  wrote:
> > Would it be useful (and interesting as part of GSoC work) to
> > establish
> > (1) which tools requires fixing,
> > (2) prepare enhancement requests for the respective projects,
> > and in the meantime, adapt the "Commons" build (with a "JDK 9"
> > profile)
> > (3) to disable plugins that do not work yet,
> > (4) provide the option to generate a "multi-release" JAR (although
> >it would not be the deployed as part of the official release
> >process)?
>
> Hi, this is Adam Soroka (prospective mentor for this project). I'm sorry
> to have been absent from this conversation so far (been very busy this
> week) but Gilles has said much of what I would have said, so thanks Gilles!
>
> I would emphasize a couple of points:
>
> This is a GSoC project. The expectations and the marks of success are
> fundamentally different than for many other contributions.
>
> Gilles has rightly pointed out that this is about Commons RDF and that is
> all. Kamila unfortunately didn't make that clear in the subject line of the
> thread, but that was just a slip of the keyboard. It's not about any other
> piece of Commons. It won't affect them, so there's no need to worry about
> how release artifacts or other products for other components might be
> affected. They won't be.
>
> I don't think anyone would claim (or has claimed) that Commons (or any
> Commons component) should target Java9. The idea here is to work with the
> JPMS. There is no obvious or sensible way to do that without using Java9.
>
> The tasks that Kamila and Gilles have talked about are (IMHO) sensible and
> useful. We can discuss how soon and in what way Commons as a whole should
> engage with JPMS, but I don't see why that should stop individual
> components from exploring it. In fact, as Gilles points out, that will be a
> useful way of gathering info for a larger set of efforts.
>
> Lastly, on the assumption that Kamila's work involves a lot of "well,
> plugin X doesn't work, so I'll have to talk to that project", we are doing
> good. That is _EXACTLY_ what should happen during a GSoC project. The
> student should be discovering that working on open source software is often
> (I would say _very_ often) just as much about understanding how different
> software projects and communities relate to each other and how to get
> efforts synchronized than about just banging out line after line of code in
> isolation, only to throw the results over a fence to a single project.
>
> In summary-- this proposed project shouldn't affect anything or -one
> outside of the user base of Commons RDF (which hasn't even reached 1.0),
> and it may only result in a lot of documentation and "speculative" work,
> and that would be fine, as long as Kamila learns a lot about working with
> open source software efforts, which I'm confident she can and will.
>
> Adam Soroka ; aj...@apache.org


That's all quite nice but the hard reality is that the tool chains out
there are simply not ready for JPMS, as I've painfully learned contributing
to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and
tools left and right. So I do not see MR-jars as a viable options for any
Commons Components at this time. The best we can do ATM is play with
automatic module names in manifest files and look at what jdeps say about a
given component and see if we want to only depend on java.base or create
Maven modules to compartmentalize dependencies.

Gary

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

Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[ajs6f]

> On Mar 8, 2018, at 8:33 AM, Gilles  wrote:
> Would it be useful (and interesting as part of GSoC work) to
> establish
> (1) which tools requires fixing,
> (2) prepare enhancement requests for the respective projects,
> and in the meantime, adapt the "Commons" build (with a "JDK 9"
> profile)
> (3) to disable plugins that do not work yet,
> (4) provide the option to generate a "multi-release" JAR (although
>it would not be the deployed as part of the official release
>process)?

Hi, this is Adam Soroka (prospective mentor for this project). I'm sorry to 
have been absent from this conversation so far (been very busy this week) but 
Gilles has said much of what I would have said, so thanks Gilles!

I would emphasize a couple of points:

This is a GSoC project. The expectations and the marks of success are 
fundamentally different than for many other contributions. 

Gilles has rightly pointed out that this is about Commons RDF and that is all. 
Kamila unfortunately didn't make that clear in the subject line of the thread, 
but that was just a slip of the keyboard. It's not about any other piece of 
Commons. It won't affect them, so there's no need to worry about how release 
artifacts or other products for other components might be affected. They won't 
be.

I don't think anyone would claim (or has claimed) that Commons (or any Commons 
component) should target Java9. The idea here is to work with the JPMS. There 
is no obvious or sensible way to do that without using Java9.

The tasks that Kamila and Gilles have talked about are (IMHO) sensible and 
useful. We can discuss how soon and in what way Commons as a whole should 
engage with JPMS, but I don't see why that should stop individual components 
from exploring it. In fact, as Gilles points out, that will be a useful way of 
gathering info for a larger set of efforts.

Lastly, on the assumption that Kamila's work involves a lot of "well, plugin X 
doesn't work, so I'll have to talk to that project", we are doing good. That is 
_EXACTLY_ what should happen during a GSoC project. The student should be 
discovering that working on open source software is often (I would say _very_ 
often) just as much about understanding how different software projects and 
communities relate to each other and how to get efforts synchronized than about 
just banging out line after line of code in isolation, only to throw the 
results over a fence to a single project.

In summary-- this proposed project shouldn't affect anything or -one outside of 
the user base of Commons RDF (which hasn't even reached 1.0), and it may only 
result in a lot of documentation and "speculative" work, and that would be 
fine, as long as Kamila learns a lot about working with open source software 
efforts, which I'm confident she can and will.

Adam Soroka ; aj...@apache.org





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

Re: Prepare commons to JDK 9

[Ralph Goers]

Log4j has run into a few of them. The OSGi bind tool has some issues although 
the latest release fixes some of them. Android’s tools have problems with any 
jar that contains anything Java 9 related.  We have created issues against both 
of these.

Ralph

> On Mar 8, 2018, at 6:33 AM, Gilles  wrote:
> 
> Hello.
> 
> On Wed, 7 Mar 2018 22:21:44 +, Stephen Colebourne wrote:
>> On 7 March 2018 at 18:56, Ralph Goers  wrote:
>>> Actually, you really do need to use a multi-release jar to include a 
>>> module-info class file. Otherwise it may be sitting alongside of classes 
>>> compiled for an earlier java release and various tools will fail because of 
>>> it.
>> 
>> Then those tools need fixing.
>> 
>> Using multi-release jar files doesn't really help either, as other
>> tools don't understand those.
> 
> Would it be useful (and interesting as part of GSoC work) to
> establish
> (1) which tools requires fixing,
> (2) prepare enhancement requests for the respective projects,
> and in the meantime, adapt the "Commons" build (with a "JDK 9"
> profile)
> (3) to disable plugins that do not work yet,
> (4) provide the option to generate a "multi-release" JAR (although
>it would not be the deployed as part of the official release
>process)?
> 
> Regards,
> Gilles
> 
>> Stephen
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 



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

Re: Prepare commons to JDK 9

[Gilles]

Hello.

On Wed, 7 Mar 2018 22:21:44 +, Stephen Colebourne wrote:
On 7 March 2018 at 18:56, Ralph Goers  
wrote:
Actually, you really do need to use a multi-release jar to include a 
module-info class file. Otherwise it may be sitting alongside of 
classes compiled for an earlier java release and various tools will 
fail because of it.


Then those tools need fixing.

Using multi-release jar files doesn't really help either, as other
tools don't understand those.


Would it be useful (and interesting as part of GSoC work) to
establish
(1) which tools requires fixing,
(2) prepare enhancement requests for the respective projects,
and in the meantime, adapt the "Commons" build (with a "JDK 9"
profile)
(3) to disable plugins that do not work yet,
(4) provide the option to generate a "multi-release" JAR (although
it would not be the deployed as part of the official release
process)?

Regards,
Gilles


Stephen



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

Re: Prepare commons to JDK 9

[Stephen Colebourne]

On 7 March 2018 at 18:56, Ralph Goers  wrote:
> Actually, you really do need to use a multi-release jar to include a 
> module-info class file. Otherwise it may be sitting alongside of classes 
> compiled for an earlier java release and various tools will fail because of 
> it.

Then those tools need fixing.

Using multi-release jar files doesn't really help either, as other
tools don't understand those.

Stephen

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

Re: Prepare commons to JDK 9

[Ralph Goers]

> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne  wrote:
> 
> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
> six-month release which is about to be replaced by Java 10, which will
> then be replaced by Java 11. Thus, Java 8 is the only sensible
> baseline right now.
> 
> 2) Compiling a single jar file such that it works on Java 8 but has a
> module-info.class for Java 9 using Maven is a right pain in the
> backside. Most maven plugins cannot seamlessly handle it making the
> pom.xml much more complex. Note that you do not need a multi-release
> jar file to make it work. See
> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml 
> 

Actually, you really do need to use a multi-release jar to include a 
module-info class file. Otherwise it may be sitting alongside of classes 
compiled for an earlier java release and various tools will fail because of it.

Ralph

Re: Prepare commons to JDK 9

[Gilles]

Hi.

On Wed, 7 Mar 2018 09:47:00 +, Stephen Colebourne wrote:

1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
six-month release which is about to be replaced by Java 10, which 
will

then be replaced by Java 11. Thus, Java 8 is the only sensible
baseline right now.


Maybe it was incorrectly formulated, but I didn't understand it
that way: Java 9 is *not* to be the default target; the idea is
that the (Commons) artefacts should be usable in an application
that wants to enforce module access rules (the app being based
on JDK 9+, obviously).


2) Compiling a single jar file such that it works on Java 8 but has a
module-info.class for Java 9 using Maven is a right pain in the
backside. Most maven plugins cannot seamlessly handle it making the
pom.xml much more complex. Note that you do not need a multi-release
jar file to make it work. See
https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml


So IMO, it's useful that someone does the work that will enable
any Commons component to benefit without going through the pain. ;-)


3) It is yet to be demonstrated that JPMS is going to be widely used.


?


To release a jar file with JPMS module-info.class, it requires that
ALL dependencies are also JPMS modules with either module-info.class
or Automatic-Module-Name in the manifest. Most projects are nowhere
near this position yet.


But most Commons projects are (or should be), since they purports
to be "components" (i.e. bona fide "modules").


Right now the plan for commons should be simple:

- add Automatic-Module-Name to MANIFEST.mf to lock down the module 
name


I think that most did it already, following your first post about
this.
But it does not *prove* that they are JPMS-compliant. Hence the
usefulness to develop actual tests for asserting it.
For the next release of "Commons RNG", I resorted to move that
proof over to an "example" of usage, but it would certainly be
safer and cleaner to have real, component-agnostic, unit tests.
If feasable, they should probably fit in "Commons Testing" (?).


- if the project has no dependencies and runs on Java 6 or later,
consider adding a module-info.java, with the awareness that this is a
complex task


Is it complex, or is the POM going to grow?  If most of the
additions are in the parent POM, it will be mostly transparent
to the individual projects.

Regards,
Gilles



Stephen


On 7 March 2018 at 03:46, Kamila Molina Orellana
 wrote:

Dear all,

As an idea for GSoC that came up in [1], we want to settle some 
guidelines
that other commons projects might follow to make the shift. We came 
up with
some ideas in [2]. I wanted to ask about some experience you have 
had while

moving to JDK 9 in other commons-projects.

I wanted to propose this:

   1. Make the movement of commons-rdf to JDK 9 generating modules
   descriptions automatically through Maven.
   2. Generate integration tests to guarantee that modules are 
working as

   expected with JDK 9.
   3. Maybe have multi-release JARs?

Since other commons projects follow a similar structure, we can 
generate
some documentation in a wiki-like media. So, they can make the shit 
to JPMS

or at least have a guideline. Or I can contribute :D.

Wha do you think?

Regards,
~Kamila.


[1] https://issues.apache.org/jira/browse/COMMONSSITE-103
[2] https://issues.apache.org/jira/browse/COMMONSRDF-75



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

Re: Prepare commons to JDK 9

[Stephen Colebourne]

1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
six-month release which is about to be replaced by Java 10, which will
then be replaced by Java 11. Thus, Java 8 is the only sensible
baseline right now.

2) Compiling a single jar file such that it works on Java 8 but has a
module-info.class for Java 9 using Maven is a right pain in the
backside. Most maven plugins cannot seamlessly handle it making the
pom.xml much more complex. Note that you do not need a multi-release
jar file to make it work. See
https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml

3) It is yet to be demonstrated that JPMS is going to be widely used.
To release a jar file with JPMS module-info.class, it requires that
ALL dependencies are also JPMS modules with either module-info.class
or Automatic-Module-Name in the manifest. Most projects are nowhere
near this position yet.

Right now the plan for commons should be simple:

- add Automatic-Module-Name to MANIFEST.mf to lock down the module name
- if the project has no dependencies and runs on Java 6 or later,
consider adding a module-info.java, with the awareness that this is a
complex task

Stephen


On 7 March 2018 at 03:46, Kamila Molina Orellana
 wrote:
> Dear all,
>
> As an idea for GSoC that came up in [1], we want to settle some guidelines
> that other commons projects might follow to make the shift. We came up with
> some ideas in [2]. I wanted to ask about some experience you have had while
> moving to JDK 9 in other commons-projects.
>
> I wanted to propose this:
>
>1. Make the movement of commons-rdf to JDK 9 generating modules
>descriptions automatically through Maven.
>2. Generate integration tests to guarantee that modules are working as
>expected with JDK 9.
>3. Maybe have multi-release JARs?
>
> Since other commons projects follow a similar structure, we can generate
> some documentation in a wiki-like media. So, they can make the shit to JPMS
> or at least have a guideline. Or I can contribute :D.
>
> Wha do you think?
>
> Regards,
> ~Kamila.
>
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75

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

Re: Prepare commons to JDK 9

[Gary Gregory]

Hi All:

On a slightly different tack, I think that it is way to early to require
Java 9 for ANY Commons components.

I see a case for updating all components to at least Java 7, and hopefully
8.

What you will likely hear from some quarters are comments of the type "What
feature of Java X is required for a better Commons Y".

Note that from my POV, MR Jars are a catastrophe, breaking tool chains left
and right and I will avoid these like the plague until tools support that
feature through and through, especially Android; as well as the myriad of
Maven plugins that might blow up by looking at class files in the "wrong"
place (META-INF).

The least worst solution is to do the minimum for jars to play in the Java
9 module system, which should not require Java 9 byte codes.

Another item to chew on: There is no LTS plans from Oracle for Java 9 AND
10, in fact the next LTS is for Java 11. So it seems to me then that Java
>=9 and < 11 is a moving target and I would not bend over backward for
anything in that range. Not yet at least.

Gary

On Tue, Mar 6, 2018 at 8:46 PM, Kamila Molina Orellana <
kamila.molin...@gmail.com> wrote:

> Dear all,
>
> As an idea for GSoC that came up in [1], we want to settle some guidelines
> that other commons projects might follow to make the shift. We came up with
> some ideas in [2]. I wanted to ask about some experience you have had while
> moving to JDK 9 in other commons-projects.
>
> I wanted to propose this:
>
>1. Make the movement of commons-rdf to JDK 9 generating modules
>descriptions automatically through Maven.
>2. Generate integration tests to guarantee that modules are working as
>expected with JDK 9.
>3. Maybe have multi-release JARs?
>
> Since other commons projects follow a similar structure, we can generate
> some documentation in a wiki-like media. So, they can make the shit to JPMS
> or at least have a guideline. Or I can contribute :D.
>
> Wha do you think?
>
> Regards,
> ~Kamila.
>
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75
>

Prepare commons to JDK 9

[Kamila Molina Orellana]

Dear all,

As an idea for GSoC that came up in [1], we want to settle some guidelines
that other commons projects might follow to make the shift. We came up with
some ideas in [2]. I wanted to ask about some experience you have had while
moving to JDK 9 in other commons-projects.

I wanted to propose this:

   1. Make the movement of commons-rdf to JDK 9 generating modules
   descriptions automatically through Maven.
   2. Generate integration tests to guarantee that modules are working as
   expected with JDK 9.
   3. Maybe have multi-release JARs?

Since other commons projects follow a similar structure, we can generate
some documentation in a wiki-like media. So, they can make the shit to JPMS
or at least have a guideline. Or I can contribute :D.

Wha do you think?

Regards,
~Kamila.


[1] https://issues.apache.org/jira/browse/COMMONSSITE-103
[2] https://issues.apache.org/jira/browse/COMMONSRDF-75