Backward compatibility / Version Concern

[Volker Simonis]

Hi Paul,

good to see that somebody is finally really testing the full new
version schema "9.x.y.z" and not just the shorthand version "9".

Which version information is being used by Log4J? The one printed on
the command line or one of the various versions strings which are
stored in the system properties:

    java.specification.version = 9.0.0.1
    java.version = 9.0.0.1-internal
    java.vm.specification.version = 9
    java.vm.version = 9.0.0.1-internal+0-2016-07-14-165000.d046063.jdk9-dev

For java.specification.version there's still the chance that this gets
fixed by [1].

Building an old style version string from the new versioning scheme is
a little hard as there's no one-to-one mapping. But maybe we can have
an -X options which allows the user to set an arbitrary version
number?

Regards,
Volker

[1] https://bugs.openjdk.java.net/browse/JDK-8149519

On Mon, Jul 18, 2016 at 5:01 PM, Paul Benedict <pbenedict at apache.org> wrote:
> Hello! I have a concern and a question.
>
> With JDK 9 reporting itself with 9.x.y.z, it seems some very old yet still
> regarded libraries are going to be tripped up. For example, Apache Log4J
> 1.x and Apache Commons Lang, have both assumed the 1.x format [1]. The most
> unfortunate case, however, is Log4J 1.x because it is no longer an actively
> maintained library and has gone EOL over a year go [2]. As a consequence,
> for maintainers of systems where Log4J 1.x is deeply embedded, they will
> have to upgrade to 2.x -- if possible [3]. I say "if possible" because
> sometimes the choice of a logging framework is not optional. It may either
> be mandated by policy or embedded into the use of some third-party
> framework the system cannot afford to replace.
>
> For anyone Oracle people reading this, you should know that Log4J 1.x is a
> pretty important library. Actually, it is so important that the removal of
> some internal Java API was reverted in Java 7 until a suitable public API
> was exposed in Java 8 [4].
>
> In my opinion, the change of the version string is going to negatively
> impact old libraries and thus legacy systems. I don't see an easy upgrade
> path for these people with JDK 9.
>
> I'd like to propose a new -X switch to restore the "1.9.0" version string
> that's reported at runtime. It's my belief that an "escape hatch" should be
> provided as an emergency/stop-gap because I think too many systems may be
> negatively affected and caught off-guard by the new format.
>
> What are your thoughts?
>
> [1]
> https://lists.apache.org/thread.html/5d1d08cc1bbdf4bff318ebd2e4d4f54c91b28c533eb11e33b9c978ac@%3Cdev.commons.apache.org%3E
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008668.html
> [3] https://blogs.apache.org/logging/entry/moving_on_to_log4j_2
> [4]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019334.html
>
> Cheers,
> Paul