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

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

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

Benedikt Ritter-4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Ralph Goers
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 <[hidden email]> 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" <[hidden email]> 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: [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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

Benedikt Ritter-4
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 <[hidden email]>:
>
> 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 <[hidden email]> 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" <[hidden email]> 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: [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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

garydgregory
In reply to this post by Ralph Goers
I was trying to follow Stephen's guidance that the build needs Java 9 and
the code can stay at Java 6-8.

Gary

On Oct 28, 2017 10:21, "Ralph Goers" <[hidden email]> wrote:

> 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 <[hidden email]>
> 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" <[hidden email]> 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: [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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

garydgregory
In reply to this post by Benedikt Ritter-4
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 <[hidden email]>
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 <[hidden email]>:
> >
> > 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 <[hidden email]>
> 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" <[hidden email]> 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: [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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

Ralph Goers
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>
>> 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" <[hidden email]> 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: [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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

jodastephen
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!).

Stephen


On 28 October 2017 at 21:31, Ralph Goers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>
>>> 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" <[hidden email]> 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: [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]
>

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
On 30 October 2017 at 23:09, Stephen Colebourne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]>
>>>> 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" <[hidden email]> 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: [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]
>>
>
> ---------------------------------------------------------------------
> 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: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

Benedikt Ritter-4
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 <[hidden email]>:
>
> On 30 October 2017 at 23:09, Stephen Colebourne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>> 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" <[hidden email]> 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: [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]
>>>
>>
>> ---------------------------------------------------------------------
>> 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]