[LANG] Add module-info.java?

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

[LANG] Add module-info.java?

Benedikt Ritter-4
Hi,

Stephen Colebourne has raised a PR on GitHub to add a module-info.java file to Commons Lang [1]. The build is configured in a way, that the resulting jar will also work on Java 7 and 8. Since module-info is a Java 9 feature, the build will only work on Java 9.
I’d like to hear opinions on this change.

Regards,
Benedikt

[1] https://github.com/apache/commons-lang/pull/299
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Pascal Schumacher
Am 14.10.2017 um 14:43 schrieb Benedikt Ritter:

> Hi,
>
> Stephen Colebourne has raised a PR on GitHub to add a module-info.java file to Commons Lang [1]. The build is configured in a way, that the resulting jar will also work on Java 7 and 8. Since module-info is a Java 9 feature, the build will only work on Java 9.
> I’d like to hear opinions on this change.
>
> Regards,
> Benedikt
>
> [1] https://github.com/apache/commons-lang/pull/299
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
If we go for the java 9 option I think we should wait a bit, because
currently there are (at least) two problems:

- the maven-site-plugin does not work on java 9 yet (version 3.7.0 with
the fix has yet to be released)

- the coveralls-maven-plugin does not work on java 9 yet
(https://github.com/trautonen/coveralls-maven-plugin/issues/112 has been
open for months with no feedback, plugin seems abandoned)


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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Rob Tompkins
In reply to this post by Benedikt Ritter-4


> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]> wrote:
>
> Hi,
>
> Stephen Colebourne has raised a PR on GitHub to add a module-info.java file to Commons Lang [1]. The build is configured in a way, that the resulting jar will also work on Java 7 and 8. Since module-info is a Java 9 feature, the build will only work on Java 9.
> I’d like to hear opinions on this change.
>

Feels like a change that would warrant a major version change, but that would have us maintaining another major version branch.

It would be interesting if we could somehow put that file in place as part of the build such that Lang 3 and Lang 4 gets built off the same codebase except that Lang 4 gets module-info.java placed up-front in the build process. But, I admit, that may be overly complex, and we might want to contribute those mechanics back to maven somehow.

-Rob


> Regards,
> Benedikt
>
> [1] https://github.com/apache/commons-lang/pull/299
> ---------------------------------------------------------------------
> 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: [LANG] Add module-info.java?

jodastephen
On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]> wrote:
> Feels like a change that would warrant a major version change, but that would have us maintaining another major version branch.

No need for a major version change. Its just one more .class file in
the jar file. The jar file is still usable on Java 7 and 8, its just
that the *build* is Java 9 specific.

As Pascal says, really we want all the maven plugins to be ready for
this, but we don't control those timescales.

Options to fix the site plugin problem:

1) Alter the PR so that releases have to be in two stages - jar file
build/deploy on Java 9 and site on Java 8. The risk is that someone
forgets to do the release using Java 9.

2) Compile the module-info.java file on Java 9 and check it in (as a
binary module-info.class file). Then the build could stay on Java 7/8.
The problem however is that whenever a new package is added, the
module-info.class file would have to be recreated and re-checked in,
an error-prone process.

Stephen

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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

garydgregory
I am wondering if this is a little too early. A lot of tooling our there
does not play well with Java 9 class files.

The last time I tried to use Log4j 2 (which contains Java 9 classes files
in the right multi-jar spot) with an Android app, the Android tooling threw
up all over itself because it was incorrectly trying to do something with
these Java 9 class file :-(

Gary

On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <[hidden email]>
wrote:

> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
> >> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
> wrote:
> > Feels like a change that would warrant a major version change, but that
> would have us maintaining another major version branch.
>
> No need for a major version change. Its just one more .class file in
> the jar file. The jar file is still usable on Java 7 and 8, its just
> that the *build* is Java 9 specific.
>
> As Pascal says, really we want all the maven plugins to be ready for
> this, but we don't control those timescales.
>
> Options to fix the site plugin problem:
>
> 1) Alter the PR so that releases have to be in two stages - jar file
> build/deploy on Java 9 and site on Java 8. The risk is that someone
> forgets to do the release using Java 9.
>
> 2) Compile the module-info.java file on Java 9 and check it in (as a
> binary module-info.class file). Then the build could stay on Java 7/8.
> The problem however is that whenever a new package is added, the
> module-info.class file would have to be recreated and re-checked in,
> an error-prone process.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Romain Manni-Bucau
Hi guys,

A side note but wonder if you noticed jar scanners were - indeed - not
supporting mjar and just filtering classes by extension leading to class
not found with mjar? For instance log4j2 broke meecrowave shade setup which
was working pre-mjar time - no impact on the not shade mode cause excluded
from the scanning. So tooling and library adoption can be worth checking
too.


Le 14 oct. 2017 21:02, "Gary Gregory" <[hidden email]> a écrit :

> I am wondering if this is a little too early. A lot of tooling our there
> does not play well with Java 9 class files.
>
> The last time I tried to use Log4j 2 (which contains Java 9 classes files
> in the right multi-jar spot) with an Android app, the Android tooling threw
> up all over itself because it was incorrectly trying to do something with
> these Java 9 class file :-(
>
> Gary
>
> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <[hidden email]>
> wrote:
>
> > On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
> > >> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
> > wrote:
> > > Feels like a change that would warrant a major version change, but that
> > would have us maintaining another major version branch.
> >
> > No need for a major version change. Its just one more .class file in
> > the jar file. The jar file is still usable on Java 7 and 8, its just
> > that the *build* is Java 9 specific.
> >
> > As Pascal says, really we want all the maven plugins to be ready for
> > this, but we don't control those timescales.
> >
> > Options to fix the site plugin problem:
> >
> > 1) Alter the PR so that releases have to be in two stages - jar file
> > build/deploy on Java 9 and site on Java 8. The risk is that someone
> > forgets to do the release using Java 9.
> >
> > 2) Compile the module-info.java file on Java 9 and check it in (as a
> > binary module-info.class file). Then the build could stay on Java 7/8.
> > The problem however is that whenever a new package is added, the
> > module-info.class file would have to be recreated and re-checked in,
> > an error-prone process.
> >
> > Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Bruno P. Kinoshita-3
In reply to this post by Benedikt Ritter-4
Can't cast an opinion on that as I haven't read much about modules yet.
But a major version was mentioned in other comments. I remember an issue in lang [1] for Java 9 modules around circuit breakers and the java.desktop (or something named like that) module. I have prepared a WIP alternative for the circuit breakers [2], but we would probably need to start deprecating parts of the circuit breaker that would not be binary compatible.
Is it something that we should do at the same time as adding module-info.java? If not, sorry for digressing :)
CheersBruno
[1] https://issues.apache.org/jira/browse/LANG-1339[2] https://github.com/apache/commons-lang/pull/275

      From: Benedikt Ritter <[hidden email]>
 To: Commons Developers List <[hidden email]>
Cc: [hidden email]
 Sent: Sunday, 15 October 2017 1:43 AM
 Subject: [LANG] Add module-info.java?
   
Hi,

Stephen Colebourne has raised a PR on GitHub to add a module-info.java file to Commons Lang [1]. The build is configured in a way, that the resulting jar will also work on Java 7 and 8. Since module-info is a Java 9 feature, the build will only work on Java 9.
I’d like to hear opinions on this change.

Regards,
Benedikt

[1] https://github.com/apache/commons-lang/pull/299
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


   
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Ralph Goers
In reply to this post by garydgregory
I need to point out that even after removing that there would be a lot of stuff in log4j-core that doesn’t work in Android.

Ralph

> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]> wrote:
>
> I am wondering if this is a little too early. A lot of tooling our there
> does not play well with Java 9 class files.
>
> The last time I tried to use Log4j 2 (which contains Java 9 classes files
> in the right multi-jar spot) with an Android app, the Android tooling threw
> up all over itself because it was incorrectly trying to do something with
> these Java 9 class file :-(
>
> Gary
>
> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <[hidden email]>
> wrote:
>
>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>> wrote:
>>> Feels like a change that would warrant a major version change, but that
>> would have us maintaining another major version branch.
>>
>> No need for a major version change. Its just one more .class file in
>> the jar file. The jar file is still usable on Java 7 and 8, its just
>> that the *build* is Java 9 specific.
>>
>> As Pascal says, really we want all the maven plugins to be ready for
>> this, but we don't control those timescales.
>>
>> Options to fix the site plugin problem:
>>
>> 1) Alter the PR so that releases have to be in two stages - jar file
>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>> forgets to do the release using Java 9.
>>
>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>> binary module-info.class file). Then the build could stay on Java 7/8.
>> The problem however is that whenever a new package is added, the
>> module-info.class file would have to be recreated and re-checked in,
>> an error-prone process.
>>
>> Stephen
>>
>> ---------------------------------------------------------------------
>> 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: [LANG] Add module-info.java?

garydgregory
Oh sure, but each roadblock matters... breaking up our core jar would help
too I am sure.

Gary



On Oct 14, 2017 16:05, "Ralph Goers" <[hidden email]> wrote:

> I need to point out that even after removing that there would be a lot of
> stuff in log4j-core that doesn’t work in Android.
>
> Ralph
>
> > On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > I am wondering if this is a little too early. A lot of tooling our there
> > does not play well with Java 9 class files.
> >
> > The last time I tried to use Log4j 2 (which contains Java 9 classes files
> > in the right multi-jar spot) with an Android app, the Android tooling
> threw
> > up all over itself because it was incorrectly trying to do something with
> > these Java 9 class file :-(
> >
> > Gary
> >
> > On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
> [hidden email]>
> > wrote:
> >
> >> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
> >>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
> >> wrote:
> >>> Feels like a change that would warrant a major version change, but that
> >> would have us maintaining another major version branch.
> >>
> >> No need for a major version change. Its just one more .class file in
> >> the jar file. The jar file is still usable on Java 7 and 8, its just
> >> that the *build* is Java 9 specific.
> >>
> >> As Pascal says, really we want all the maven plugins to be ready for
> >> this, but we don't control those timescales.
> >>
> >> Options to fix the site plugin problem:
> >>
> >> 1) Alter the PR so that releases have to be in two stages - jar file
> >> build/deploy on Java 9 and site on Java 8. The risk is that someone
> >> forgets to do the release using Java 9.
> >>
> >> 2) Compile the module-info.java file on Java 9 and check it in (as a
> >> binary module-info.class file). Then the build could stay on Java 7/8.
> >> The problem however is that whenever a new package is added, the
> >> module-info.class file would have to be recreated and re-checked in,
> >> an error-prone process.
> >>
> >> Stephen
> >>
> >> ---------------------------------------------------------------------
> >> 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: [LANG] Add module-info.java?

garydgregory
Oh sure, but each roadblock matters... breaking up our core jar would help
too I am sure.

Gary




On Oct 14, 2017 16:05, "Ralph Goers" <[hidden email]> wrote:

> I need to point out that even after removing that there would be a lot of
> stuff in log4j-core that doesn’t work in Android.
>
> Ralph
>
> > On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > I am wondering if this is a little too early. A lot of tooling our there
> > does not play well with Java 9 class files.
> >
> > The last time I tried to use Log4j 2 (which contains Java 9 classes files
> > in the right multi-jar spot) with an Android app, the Android tooling
> threw
> > up all over itself because it was incorrectly trying to do something with
> > these Java 9 class file :-(
> >
> > Gary
> >
> > On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
> [hidden email]>
> > wrote:
> >
> >> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
> >>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
> >> wrote:
> >>> Feels like a change that would warrant a major version change, but that
> >> would have us maintaining another major version branch.
> >>
> >> No need for a major version change. Its just one more .class file in
> >> the jar file. The jar file is still usable on Java 7 and 8, its just
> >> that the *build* is Java 9 specific.
> >>
> >> As Pascal says, really we want all the maven plugins to be ready for
> >> this, but we don't control those timescales.
> >>
> >> Options to fix the site plugin problem:
> >>
> >> 1) Alter the PR so that releases have to be in two stages - jar file
> >> build/deploy on Java 9 and site on Java 8. The risk is that someone
> >> forgets to do the release using Java 9.
> >>
> >> 2) Compile the module-info.java file on Java 9 and check it in (as a
> >> binary module-info.class file). Then the build could stay on Java 7/8.
> >> The problem however is that whenever a new package is added, the
> >> module-info.class file would have to be recreated and re-checked in,
> >> an error-prone process.
> >>
> >> Stephen
> >>
> >> ---------------------------------------------------------------------
> >> 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: [LANG] Add module-info.java?

Matt Sicker
In reply to this post by Ralph Goers
Which is mainly because the version of Java in Android is intentionally
lacking about half of the standard library. Perhaps this will improve in
the future now that they're adopting OpenJDK, though.

On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:

> I need to point out that even after removing that there would be a lot of
> stuff in log4j-core that doesn’t work in Android.
>
> Ralph
>
> > On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > I am wondering if this is a little too early. A lot of tooling our there
> > does not play well with Java 9 class files.
> >
> > The last time I tried to use Log4j 2 (which contains Java 9 classes files
> > in the right multi-jar spot) with an Android app, the Android tooling
> threw
> > up all over itself because it was incorrectly trying to do something with
> > these Java 9 class file :-(
> >
> > Gary
> >
> > On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
> [hidden email]>
> > wrote:
> >
> >> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
> >>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
> >> wrote:
> >>> Feels like a change that would warrant a major version change, but that
> >> would have us maintaining another major version branch.
> >>
> >> No need for a major version change. Its just one more .class file in
> >> the jar file. The jar file is still usable on Java 7 and 8, its just
> >> that the *build* is Java 9 specific.
> >>
> >> As Pascal says, really we want all the maven plugins to be ready for
> >> this, but we don't control those timescales.
> >>
> >> Options to fix the site plugin problem:
> >>
> >> 1) Alter the PR so that releases have to be in two stages - jar file
> >> build/deploy on Java 9 and site on Java 8. The risk is that someone
> >> forgets to do the release using Java 9.
> >>
> >> 2) Compile the module-info.java file on Java 9 and check it in (as a
> >> binary module-info.class file). Then the build could stay on Java 7/8.
> >> The problem however is that whenever a new package is added, the
> >> module-info.class file would have to be recreated and re-checked in,
> >> an error-prone process.
> >>
> >> Stephen
> >>
> >> ---------------------------------------------------------------------
> >> 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]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Benedikt Ritter-4
Okay, let’s get back to topic. I feel that the community want’s to wait some more until at least all maven plugins we use work with Java 9?

Regards,
Benedikt

> Am 15.10.2017 um 01:30 schrieb Matt Sicker <[hidden email]>:
>
> Which is mainly because the version of Java in Android is intentionally
> lacking about half of the standard library. Perhaps this will improve in
> the future now that they're adopting OpenJDK, though.
>
> On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:
>
>> I need to point out that even after removing that there would be a lot of
>> stuff in log4j-core that doesn’t work in Android.
>>
>> Ralph
>>
>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
>> wrote:
>>>
>>> I am wondering if this is a little too early. A lot of tooling our there
>>> does not play well with Java 9 class files.
>>>
>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>> in the right multi-jar spot) with an Android app, the Android tooling
>> threw
>>> up all over itself because it was incorrectly trying to do something with
>>> these Java 9 class file :-(
>>>
>>> Gary
>>>
>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>> [hidden email]>
>>> wrote:
>>>
>>>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>>>> wrote:
>>>>> Feels like a change that would warrant a major version change, but that
>>>> would have us maintaining another major version branch.
>>>>
>>>> No need for a major version change. Its just one more .class file in
>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>> that the *build* is Java 9 specific.
>>>>
>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>> this, but we don't control those timescales.
>>>>
>>>> Options to fix the site plugin problem:
>>>>
>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>> forgets to do the release using Java 9.
>>>>
>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>> The problem however is that whenever a new package is added, the
>>>> module-info.class file would have to be recreated and re-checked in,
>>>> an error-prone process.
>>>>
>>>> Stephen
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>


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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

jodastephen
Log4J is adding module-info.java now, and its not overly complicated
to do here either. The main question seems to be around the maven site
plugin, but thats likely to be fixed soon. ie. I'd like to get to the
point where all the basic commons projects have module-info.java
(because proper modularization is going to occur bottom up, so the
earlier we can get these out the better).

FWIW, its up to Android to sort out its tooling - Java 9 is not going away!

I'd like to establish if there are any fundamental objections to the
concept of building only on Java 9. I'm also willing to try and find a
way to get the build to still work on Java 7, but that releases have
to be on Java 9.

Stephen



On 15 October 2017 at 10:49, Benedikt Ritter <[hidden email]> wrote:

> Okay, let’s get back to topic. I feel that the community want’s to wait some more until at least all maven plugins we use work with Java 9?
>
> Regards,
> Benedikt
>
>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <[hidden email]>:
>>
>> Which is mainly because the version of Java in Android is intentionally
>> lacking about half of the standard library. Perhaps this will improve in
>> the future now that they're adopting OpenJDK, though.
>>
>> On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:
>>
>>> I need to point out that even after removing that there would be a lot of
>>> stuff in log4j-core that doesn’t work in Android.
>>>
>>> Ralph
>>>
>>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
>>> wrote:
>>>>
>>>> I am wondering if this is a little too early. A lot of tooling our there
>>>> does not play well with Java 9 class files.
>>>>
>>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>> threw
>>>> up all over itself because it was incorrectly trying to do something with
>>>> these Java 9 class file :-(
>>>>
>>>> Gary
>>>>
>>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>>> [hidden email]>
>>>> wrote:
>>>>
>>>>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>>>>> wrote:
>>>>>> Feels like a change that would warrant a major version change, but that
>>>>> would have us maintaining another major version branch.
>>>>>
>>>>> No need for a major version change. Its just one more .class file in
>>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>>> that the *build* is Java 9 specific.
>>>>>
>>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>>> this, but we don't control those timescales.
>>>>>
>>>>> Options to fix the site plugin problem:
>>>>>
>>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>>> forgets to do the release using Java 9.
>>>>>
>>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>>> The problem however is that whenever a new package is added, the
>>>>> module-info.class file would have to be recreated and re-checked in,
>>>>> an error-prone process.
>>>>>
>>>>> Stephen
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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]
>>>
>>>
>>
>>
>> --
>> Matt Sicker <[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: [LANG] Add module-info.java?

Benedikt Ritter-4


> Am 15.10.2017 um 12:04 schrieb Stephen Colebourne <[hidden email]>:
>
> Log4J is adding module-info.java now, and its not overly complicated
> to do here either. The main question seems to be around the maven site
> plugin, but thats likely to be fixed soon. ie. I'd like to get to the
> point where all the basic commons projects have module-info.java
> (because proper modularization is going to occur bottom up, so the
> earlier we can get these out the better).
>
> FWIW, its up to Android to sort out its tooling - Java 9 is not going away!
>
> I'd like to establish if there are any fundamental objections to the
> concept of building only on Java 9. I'm also willing to try and find a
> way to get the build to still work on Java 7, but that releases have
> to be on Java 9.

I don’t have a problem with this, as long as we can make sure (e.g. with animal sniffer) that the resulting jar will work on Java 7 or what ever we want to support.

Regards,
Benedikt

>
> Stephen
>
>
>
> On 15 October 2017 at 10:49, Benedikt Ritter <[hidden email]> wrote:
>> Okay, let’s get back to topic. I feel that the community want’s to wait some more until at least all maven plugins we use work with Java 9?
>>
>> Regards,
>> Benedikt
>>
>>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <[hidden email]>:
>>>
>>> Which is mainly because the version of Java in Android is intentionally
>>> lacking about half of the standard library. Perhaps this will improve in
>>> the future now that they're adopting OpenJDK, though.
>>>
>>> On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:
>>>
>>>> I need to point out that even after removing that there would be a lot of
>>>> stuff in log4j-core that doesn’t work in Android.
>>>>
>>>> Ralph
>>>>
>>>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
>>>> wrote:
>>>>>
>>>>> I am wondering if this is a little too early. A lot of tooling our there
>>>>> does not play well with Java 9 class files.
>>>>>
>>>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>>> threw
>>>>> up all over itself because it was incorrectly trying to do something with
>>>>> these Java 9 class file :-(
>>>>>
>>>>> Gary
>>>>>
>>>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>>>>>> wrote:
>>>>>>> Feels like a change that would warrant a major version change, but that
>>>>>> would have us maintaining another major version branch.
>>>>>>
>>>>>> No need for a major version change. Its just one more .class file in
>>>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>>>> that the *build* is Java 9 specific.
>>>>>>
>>>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>>>> this, but we don't control those timescales.
>>>>>>
>>>>>> Options to fix the site plugin problem:
>>>>>>
>>>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>>>> forgets to do the release using Java 9.
>>>>>>
>>>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>>>> The problem however is that whenever a new package is added, the
>>>>>> module-info.class file would have to be recreated and re-checked in,
>>>>>> an error-prone process.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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]
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <[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]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Ralph Goers
In reply to this post by jodastephen
I should point out - just for reference - that Log4j has a maven module dedicated to Java 9 and only that is built with the Java 9 compiler. Everything else uses Java 7. We also use Java 7 when running the maven site plugin. It complains when it finds Java 9 classes but it doesn’t fail.

I don’t think waiting is a very good option. At the very least commons lang should add the Automatic-Module-Name header. This can be done with any compiler version. But adding a module-info.java file is pretty straightforward - especially since it is likely that everything will be exported.

Ralph

> On Oct 15, 2017, at 3:04 AM, Stephen Colebourne <[hidden email]> wrote:
>
> Log4J is adding module-info.java now, and its not overly complicated
> to do here either. The main question seems to be around the maven site
> plugin, but thats likely to be fixed soon. ie. I'd like to get to the
> point where all the basic commons projects have module-info.java
> (because proper modularization is going to occur bottom up, so the
> earlier we can get these out the better).
>
> FWIW, its up to Android to sort out its tooling - Java 9 is not going away!
>
> I'd like to establish if there are any fundamental objections to the
> concept of building only on Java 9. I'm also willing to try and find a
> way to get the build to still work on Java 7, but that releases have
> to be on Java 9.
>
> Stephen
>
>
>
> On 15 October 2017 at 10:49, Benedikt Ritter <[hidden email]> wrote:
>> Okay, let’s get back to topic. I feel that the community want’s to wait some more until at least all maven plugins we use work with Java 9?
>>
>> Regards,
>> Benedikt
>>
>>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <[hidden email]>:
>>>
>>> Which is mainly because the version of Java in Android is intentionally
>>> lacking about half of the standard library. Perhaps this will improve in
>>> the future now that they're adopting OpenJDK, though.
>>>
>>> On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:
>>>
>>>> I need to point out that even after removing that there would be a lot of
>>>> stuff in log4j-core that doesn’t work in Android.
>>>>
>>>> Ralph
>>>>
>>>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
>>>> wrote:
>>>>>
>>>>> I am wondering if this is a little too early. A lot of tooling our there
>>>>> does not play well with Java 9 class files.
>>>>>
>>>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>>> threw
>>>>> up all over itself because it was incorrectly trying to do something with
>>>>> these Java 9 class file :-(
>>>>>
>>>>> Gary
>>>>>
>>>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>>>>>> wrote:
>>>>>>> Feels like a change that would warrant a major version change, but that
>>>>>> would have us maintaining another major version branch.
>>>>>>
>>>>>> No need for a major version change. Its just one more .class file in
>>>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>>>> that the *build* is Java 9 specific.
>>>>>>
>>>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>>>> this, but we don't control those timescales.
>>>>>>
>>>>>> Options to fix the site plugin problem:
>>>>>>
>>>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>>>> forgets to do the release using Java 9.
>>>>>>
>>>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>>>> The problem however is that whenever a new package is added, the
>>>>>> module-info.class file would have to be recreated and re-checked in,
>>>>>> an error-prone process.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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]
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <[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]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

Benedikt Ritter-4
Hi Ralph,

> Am 15.10.2017 um 21:20 schrieb Ralph Goers <[hidden email]>:
>
> I should point out - just for reference - that Log4j has a maven module dedicated to Java 9 and only that is built with the Java 9 compiler. Everything else uses Java 7. We also use Java 7 when running the maven site plugin. It complains when it finds Java 9 classes but it doesn’t fail.
>
> I don’t think waiting is a very good option. At the very least commons lang should add the Automatic-Module-Name header. This can be done with any compiler version. But adding a module-info.java file is pretty straightforward - especially since it is likely that everything will be exported.

We’re shipping with Automatic-module-name header since 3.6.

Cheers,
Benedikt

>
> Ralph
>
>> On Oct 15, 2017, at 3:04 AM, Stephen Colebourne <[hidden email]> wrote:
>>
>> Log4J is adding module-info.java now, and its not overly complicated
>> to do here either. The main question seems to be around the maven site
>> plugin, but thats likely to be fixed soon. ie. I'd like to get to the
>> point where all the basic commons projects have module-info.java
>> (because proper modularization is going to occur bottom up, so the
>> earlier we can get these out the better).
>>
>> FWIW, its up to Android to sort out its tooling - Java 9 is not going away!
>>
>> I'd like to establish if there are any fundamental objections to the
>> concept of building only on Java 9. I'm also willing to try and find a
>> way to get the build to still work on Java 7, but that releases have
>> to be on Java 9.
>>
>> Stephen
>>
>>
>>
>> On 15 October 2017 at 10:49, Benedikt Ritter <[hidden email]> wrote:
>>> Okay, let’s get back to topic. I feel that the community want’s to wait some more until at least all maven plugins we use work with Java 9?
>>>
>>> Regards,
>>> Benedikt
>>>
>>>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <[hidden email]>:
>>>>
>>>> Which is mainly because the version of Java in Android is intentionally
>>>> lacking about half of the standard library. Perhaps this will improve in
>>>> the future now that they're adopting OpenJDK, though.
>>>>
>>>> On 14 October 2017 at 17:04, Ralph Goers <[hidden email]> wrote:
>>>>
>>>>> I need to point out that even after removing that there would be a lot of
>>>>> stuff in log4j-core that doesn’t work in Android.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> I am wondering if this is a little too early. A lot of tooling our there
>>>>>> does not play well with Java 9 class files.
>>>>>>
>>>>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>>>> threw
>>>>>> up all over itself because it was incorrectly trying to do something with
>>>>>> these Java 9 class file :-(
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> On 14 October 2017 at 14:05, Rob Tompkins <[hidden email]> wrote:
>>>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <[hidden email]>
>>>>>>> wrote:
>>>>>>>> Feels like a change that would warrant a major version change, but that
>>>>>>> would have us maintaining another major version branch.
>>>>>>>
>>>>>>> No need for a major version change. Its just one more .class file in
>>>>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>>>>> that the *build* is Java 9 specific.
>>>>>>>
>>>>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>>>>> this, but we don't control those timescales.
>>>>>>>
>>>>>>> Options to fix the site plugin problem:
>>>>>>>
>>>>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>>>>> forgets to do the release using Java 9.
>>>>>>>
>>>>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>>>>> The problem however is that whenever a new package is added, the
>>>>>>> module-info.class file would have to be recreated and re-checked in,
>>>>>>> an error-prone process.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <[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]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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: [LANG] Add module-info.java?

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-4
Le 14/10/2017 à 14:43, Benedikt Ritter a écrit :

> I’d like to hear opinions on this change.

I wonder if we could somehow write a module-info.java compiler that
works with older version of Java. The syntax doesn't look terribly
complicated after all. It could be invoked from a plugin hooked to the
compile phase.

Emmanuel Bourg

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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Add module-info.java?

sebb-2-2
On 16 October 2017 at 10:34, Emmanuel Bourg <[hidden email]> wrote:
> Le 14/10/2017 à 14:43, Benedikt Ritter a écrit :
>
>> I’d like to hear opinions on this change.
>
> I wonder if we could somehow write a module-info.java compiler that
> works with older version of Java. The syntax doesn't look terribly
> complicated after all. It could be invoked from a plugin hooked to the
> compile phase.

Or skip the files if compiling with an older Java version?

> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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: [LANG] Add module-info.java?

Simon Spero
[In regards to original question, -0.0  (harmless, but pointless, since
applications should not use lang as a jpms module. To be usable as a jpms
module, EVERY  release that has ANY api change must use new module and
package names).[1]  ]

Since all dependencies have to be shad(e|ow)ed (and not exported) when
using jigsaw, it's not too much of a hassle to do a  ½-assed job. The only
thing that might take a bit more work is if you want to have extra support
for services.

I haven't checked if there's a non-beta release, but ASM 6 has had support
for the new module-info class format stuff for a year or so (Remy Forax
being on the  jpms EG).

For custom tooling there's no real win in using module-info.java as input
(there was no real point in putting the metadata in .java and .class files
in the first place 🤦‍♂️).

JSON would be one good lazy mode; this could also be used to generate the
.java file.

Another possibility is to derive  module-info data from  bundles. The
metadata can be extracted fairly easily using bndlib. This would be more
complicated if there were imports, but since the only modules commons
projects can safely import are the non-default jdk ones (and possibly not
even all of those), it's essy to use a static map (which can be pretty much
generated from jmod/jdep).

Simon

[1] A module can only appear in the modpath once. A package can only come
from one module. If an application uses multiple third party dependencies,
which use different versions of a fourth party module,  "*Lasciate ogne
speranza, voi ch'intrate".*


On Oct 16, 2017 5:57 AM, "sebb" <[hidden email]> wrote:

> On 16 October 2017 at 10:34, Emmanuel Bourg <[hidden email]> wrote:
> > Le 14/10/2017 à 14:43, Benedikt Ritter a écrit :
> >
> >> I’d like to hear opinions on this change.
> >
> > I wonder if we could somehow write a module-info.java compiler that
> > works with older version of Java. The syntax doesn't look terribly
> > complicated after all. It could be invoked from a plugin hooked to the
> > compile phase.
>
> Or skip the files if compiling with an older Java version?
>
> > Emmanuel Bourg
> >
> > ---------------------------------------------------------------------
> > 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: [LANG] Add module-info.java?

jodastephen
On 16 October 2017 at 14:14, Simon Spero <[hidden email]> wrote:
> [In regards to original question, -0.0  (harmless, but pointless, since
> applications should not use lang as a jpms module.

Huh? Of course they should.

> To be usable as a jpms
> module, EVERY  release that has ANY api change must use new module and
> package names).[1]  ]
> [1] A module can only appear in the modpath once. A package can only come
> from one module. If an application uses multiple third party dependencies,
> which use different versions of a fourth party module,  "*Lasciate ogne
> speranza, voi ch'intrate".*

Adding a package is fine so long as it is under the same root package
(that is why I argued for module names to be the same as the root
package name - to ensure ownership). Modules are supposed to be
shared, but they do place a high bar on backwards compatibility, which
[lang] already meets.

Changing the module name every release would be horrific for users and
make problems worse not better.

Stephen

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