commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [LANG] Add module-info.java?
Date Mon, 16 Oct 2017 07:54:00 GMT
Hi Ralph,

> Am 15.10.2017 um 21:20 schrieb Ralph Goers <ralph.goers@dslextreme.com>:
> 
> 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 <scolebourne@joda.org> 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 <britter@apache.org> 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 <boards@gmail.com>:
>>>> 
>>>> 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 <ralph.goers@dslextreme.com>
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 <garydgregory@gmail.com>
>>>>> 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 <
>>>>> scolebourne@joda.org>
>>>>>> wrote:
>>>>>> 
>>>>>>> On 14 October 2017 at 14:05, Rob Tompkins <chtompki@gmail.com>
wrote:
>>>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <britter@apache.org>
>>>>>>> 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: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Matt Sicker <boards@gmail.com>
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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


Mime
View raw message