Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

[Benedikt Ritter <br...@apache.org>]

Hello,

I don’t have intentions to add a module-info file to logging. I think we should just go with the Automatic-Module-Header solution.

I started this thread to find out why the Logging repo contains Java 1.3 files although the build targets Java 1.2. With the latest commons-parent, I get build failures because of the animal-sniffer plugin. I want to fix this, since I volunteered to be RM for the next release. Can we please go back to topic and discuss the potential addition of a module-info file on a different thread? I don’t see this for the next release…

Regards,
Benedikt

> Am 31.10.2017 um 12:37 schrieb sebb <se...@gmail.com>:
> 
> On 30 October 2017 at 23:09, Stephen Colebourne <sc...@joda.org> wrote:
>> Does commons-logging need to be a full module with a module-info.java?
>> Probably not at this point. Adding Automatic-Module-Name is probably
>> sufficient. However, if someone wants to do the work, then adding
>> module-info shouldn't be blocked IMO.
>> 
>> I don't believe that module-info.java requires Java 6 or later. It
>> would be possible to create the module-info.class file using java 9
>> and then use a much earlier compiler version to build the rest of the
>> jar. Or the module-info.class binary bytecode file could be checked
>> into git (probably simpler!).
> 
> The module-info.java file must also be stored somewhere in Git so the
> class file can be recreated.
> 
> An approach would be:
> 
> Add module-info.java to correct location so project compiles using Java 9.
> If using an earlier version of Java, skip the compilation and copy the
> pre-compiled class-file instead.
> [Ideally there should also be a check that the .class file is newer
> than the .java file]
> 
> Not sure how easy that would be to do in Maven, but once done, it
> could be applied to all Commons components
> 
>> Stephen
>> 
>> 
>> On 28 October 2017 at 21:31, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Gary,
>>> 
>>> As you know Log4j has a maven module for Java 9. It contains the module-info.java file. That module compiles with Java 9 and targets Java 9 as there isn’t much point targeting anything earlier.  That class files produced are then overlaid on top of the classes produced for Log4j-api, which is targeted at 1.7 and uses the 1.7 compiler. Commons Logging could do exactly the same thing and just have a maven module for the Java 9 support and then use whatever compiler it wants for the current commons logging classes.
>>> 
>>> That said, why does commons logging need to be a “real” module anyway?
>>> 
>>> Ralph
>>> 
>>>> On Oct 28, 2017, at 10:07 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> 
>>>> From a pragmatic POV, the oldest Java byte codes you can get Java 9 to emit
>>>> are for Java 1.6. Since we will want, I assume, to produce a module info
>>>> class in the jar, we will need to use Java 9 for that (to keep an RM's life
>>>> manageable.)
>>>> 
>>>> This means to me that we should set the bar at Java 1.6 for the bare
>>>> minimum, which seams reasonable in 2017 soon to be 2018 and considering
>>>> Java 6 and 7 are EOL.
>>>> 
>>>> Gary
>>>> 
>>>> On Sat, Oct 28, 2017 at 10:32 AM, Benedikt Ritter <br...@apache.org>
>>>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> maybe we should decide on what we want to achieve here, before I start the
>>>>> endeavor of creating an RC for such an old component.
>>>>> 
>>>>> My understanding of Logging is, that it is in semi dormant mode. That we
>>>>> don’t want to add any new features and instead point users to Log4j2. Since
>>>>> Logging has a wide installation base we decided not to upgrade the Java
>>>>> version requirement and instead stay at Java 1.2 and only release super
>>>>> critical fixes/updates.
>>>>> Upgrading to Java 6 seems to contradict this plan. So where do we want to
>>>>> go with Logging?
>>>>> 
>>>>> Regards,
>>>>> Benedikt
>>>>> 
>>>>>> Am 28.10.2017 um 18:20 schrieb Ralph Goers <ra...@dslextreme.com>:
>>>>>> 
>>>>>> That isn’t strictly true Gary, There are ways to build the module-info
>>>>> without upgrading the main code to Java 9. That said, it is a bit of a hack
>>>>> to do it.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 28, 2017, at 8:19 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>>> 
>>>>>>> Let's update to at least a minimum of Java 6 such that the build can run
>>>>>>> with Java 9. Builing with Java 9 will be a requirement to add module
>>>>> info.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Oct 28, 2017 01:21, "Benedikt Ritter" <br...@apache.org> wrote:
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> After I was able to update the the build to the latest parent POM, I’m
>>>>>>>> running into animal sniffer problems. The build is defined to target
>>>>> Java
>>>>>>>> 1.2 but there are classes which require later JDKs:
>>>>>>>> 
>>>>>>>> - Jdk13LumberjackLogger
>>>>>>>> - Jdk14Logger
>>>>>>>> 
>>>>>>>> This breaks the build because animal sniffer reports that these classes
>>>>>>>> don’t work on Java 1.2. I don’t understand how this is supposed to
>>>>> work.
>>>>>>>> Did we ship those classes and users have to decide whether they want to
>>>>>>>> load them or not depending on the JRE they are running on? Do we want
>>>>> to
>>>>>>>> exclude the two classes from animal sniffer?
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Benedikt
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>> 
>> 
>> ---------------------------------------------------------------------
>> 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