Re: [eclipse-dev] Class file version of javax15api.jar
Sorry, previously I replied to the wrong message.
I can't think of a reason why the JAR has to be on the latest version. If at all, I would
imagine they are compiled at the same compliance as the containing project, which is 11.
Let me try to compile them with 1.8 and see how it goes.
Meanwhile, can you spare a moment to raise a bug please?
From: "Alexander Kriegisch"
Jay, it seems that mostly you are maintaining the file which currently
is named org.eclipse.jdt.compiler.apt/lib/javax15api.jar. Before I am
going to ask a question herwe is what I know so far:
-- This JAR file exists since Java 9, getting renamed to the currently
supported Java version ever since, as the Git history for the lib
folder tells us:
-- The contained files are binaries from the JDK, more precisely from
the java.compiler module. When I unpacked them from JDK 15 and 16,
I saw that they are compiled to the JDK's target version, i.e. Java
15 classes have the corresponding class file version.
-- Why however the files for Java 15 in javax15api.jar have a Java 14
class file version, I do not know. Maybe you actually extracted the
sources from OpenJDK and compiled them before zipping them up. That
would suggest, they could also be compiled using an older version
in order to lower the minimum compiler version necessary to build
the compiler module for APT.
I know this is not really relevant for JDT Core, because the test suite
runs all tests on different Java versions up to the latest supported one
using toolchains. But AspectJ forks the two modules
org.eclipse.jdt.apt.core and org.eclipse.jdt.compiler.apt, applying our
changes and then compiling and packaging them into a simple JAR (not as
OSGi bundles). Out target byte code version is Java 8, but because of
the compile-time dependency on javax15api.jar we need to run the build
at least on JDK 14 because of the Java 14 class file format inside
1. Are you compiling those files manually?
2. If so, would you consider always compiling them to the lowest
possible target version? That way we could return to a minimum
version of Java 8 for our own build, because the rest of AspectJ
Core does not need more, only the tests for higher Java versions
do. But they are skipped automatically if we build with an older