Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-2041

2.9.0 contains classes built to class version 53

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.9.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      2.9.0 is built to class version 53, presumably because it includes attempts at support for JDK9.

      But JDK has not been released yet, so build tools that introspect class files (such as Proguard) do not yet support consuming version 53 classes.

      Can I suggest that an appropriate forward path is to build using and against JDK9 but to build to class version 52 until some time after JDK9 has been released so as to not break existing tooling.

        Activity

        Hide
        ralph.goers@dslextreme.com Ralph Goers added a comment -

        Log4j 2 uses a multi-release jar for log4j-api. The jar contains 2 classes that were compiled with Java 9 in the META-INF/versions directory. This was never a valid place to put class files and utilities should be ignoring that directory. Furthermore, Java 9 will be released on September 21 - 11 days from now. Given that processing stack traces is slower in Java 9 without using the new StackWalker class (which is much faster) removing the two added classes is not going to happen.

        Show
        ralph.goers@dslextreme.com Ralph Goers added a comment - Log4j 2 uses a multi-release jar for log4j-api. The jar contains 2 classes that were compiled with Java 9 in the META-INF/versions directory. This was never a valid place to put class files and utilities should be ignoring that directory. Furthermore, Java 9 will be released on September 21 - 11 days from now. Given that processing stack traces is slower in Java 9 without using the new StackWalker class (which is much faster) removing the two added classes is not going to happen.
        Hide
        william_f_au William Ferguson added a comment -

        I never suggested the 2 classes be removed.
        I suggested that they be compiled to class version 52 instead of 53.

        Show
        william_f_au William Ferguson added a comment - I never suggested the 2 classes be removed. I suggested that they be compiled to class version 52 instead of 53.
        Hide
        ralph.goers@dslextreme.com Ralph Goers added a comment -

        That is impossible as they use classes only available in Java 9. They will not compile with Java 8.

        Show
        ralph.goers@dslextreme.com Ralph Goers added a comment - That is impossible as they use classes only available in Java 9. They will not compile with Java 8.
        Hide
        william_f_au William Ferguson added a comment -

        Again, I am not suggesting that you compile using JDK 8.
        I am suggesting that you compile with JDK 9 to class version 52.

        Show
        william_f_au William Ferguson added a comment - Again, I am not suggesting that you compile using JDK 8. I am suggesting that you compile with JDK 9 to class version 52.
        Hide
        remkop@yahoo.com Remko Popma added a comment -

        William Ferguson It it possible to run javac with -source 9 and -target 8?

        Show
        remkop@yahoo.com Remko Popma added a comment - William Ferguson It it possible to run javac with -source 9 and -target 8?
        Hide
        william_f_au William Ferguson added a comment -

        That was how it was in JDK8 and below.
        But it looks like JDK9 now uses the "--release" parameter.
        So "--release 8" looks like it will generate version 52 byte code.

        Show
        william_f_au William Ferguson added a comment - That was how it was in JDK8 and below. But it looks like JDK9 now uses the "--release" parameter. So "--release 8" looks like it will generate version 52 byte code.
        Hide
        william_f_au William Ferguson added a comment -

        But I'm reading between the lines here, because JDK9 has not been released yet, so the doco is nil to none.

        Show
        william_f_au William Ferguson added a comment - But I'm reading between the lines here, because JDK9 has not been released yet, so the doco is nil to none.
        Hide
        ralph.goers@dslextreme.com Ralph Goers added a comment -

        Java 9 still supports -source and -target. They added --release as it combines -source, -target and -bootclasspath. Most people don't add the third option which verifies that the code will actually run in the target release as that is the JDK that is used to perform the compile.

        Show
        ralph.goers@dslextreme.com Ralph Goers added a comment - Java 9 still supports -source and -target. They added --release as it combines -source, -target and -bootclasspath. Most people don't add the third option which verifies that the code will actually run in the target release as that is the JDK that is used to perform the compile.
        Hide
        remkop@yahoo.com Remko Popma added a comment -

        It just looked weird to me that one would be able to compile sources that rely on Java 9-only API to Java 8 byte code. But now that I think about it I guess that javac has no way to check...

        Show
        remkop@yahoo.com Remko Popma added a comment - It just looked weird to me that one would be able to compile sources that rely on Java 9-only API to Java 8 byte code. But now that I think about it I guess that javac has no way to check...
        Hide
        jvz Matt Sicker added a comment -

        If there were an easy way to compile for the earliest bytecode version possible for every class file while dynamically supporting new Java SE APIs, then Java would be a lot like JavaScript in that regard. I could see that sort of thing being more supported in the future when Java starts their 6-month release cadence, but it still seems a bit hacky for older versions.

        Show
        jvz Matt Sicker added a comment - If there were an easy way to compile for the earliest bytecode version possible for every class file while dynamically supporting new Java SE APIs, then Java would be a lot like JavaScript in that regard. I could see that sort of thing being more supported in the future when Java starts their 6-month release cadence, but it still seems a bit hacky for older versions.
        Hide
        ralph.goers@dslextreme.com Ralph Goers added a comment -

        I tried compiling with a source of 9, target of 1.8 and commenting out the release. Javac fails saying

            javac: source release 9 requires target release 1.9
        
        Show
        ralph.goers@dslextreme.com Ralph Goers added a comment - I tried compiling with a source of 9, target of 1.8 and commenting out the release. Javac fails saying javac: source release 9 requires target release 1.9
        Hide
        ralph.goers@dslextreme.com Ralph Goers added a comment -

        I should have added that specifying either -source 1.8 or --release 8 will not work as it will get compile errors since the classes being referenced don't exist there.

        Show
        ralph.goers@dslextreme.com Ralph Goers added a comment - I should have added that specifying either -source 1.8 or --release 8 will not work as it will get compile errors since the classes being referenced don't exist there.
        Hide
        remkop@yahoo.com Remko Popma added a comment -

        Thanks for trying, Ralph!

        Show
        remkop@yahoo.com Remko Popma added a comment - Thanks for trying, Ralph!
        Hide
        jvz Matt Sicker added a comment -

        Sounds like a bug report should be filed with Proguard and any other relevant tools that haphazardly scan jar files for anything resembling a class file.

        Show
        jvz Matt Sicker added a comment - Sounds like a bug report should be filed with Proguard and any other relevant tools that haphazardly scan jar files for anything resembling a class file.
        Hide
        william_f_au William Ferguson added a comment -

        Thanks for the attention guys.

        I have raised an issue with Proguard https://sourceforge.net/p/proguard/bugs/665/

        Though I am surprised and concerned that JDK9 does not allow the "--target" parameter to generate class files for previous JVMs. That is going to become painful.

        Show
        william_f_au William Ferguson added a comment - Thanks for the attention guys. I have raised an issue with Proguard https://sourceforge.net/p/proguard/bugs/665/ Though I am surprised and concerned that JDK9 does not allow the "--target" parameter to generate class files for previous JVMs. That is going to become painful.

          People

          • Assignee:
            Unassigned
            Reporter:
            william_f_au William Ferguson
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development