commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@joda.org>
Subject Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code
Date Mon, 30 Oct 2017 23:09:12 GMT
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 <ralph.goers@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 <garydgregory@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 <britter@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 <ralph.goers@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 <garydgregory@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" <britter@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


Mime
View raw message