Backward compatibility / Version Concern

Paul Benedict pbenedict at apache.org
Mon Jul 18 15:01:32 UTC 2016


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


More information about the verona-dev mailing list