I am trying to build an application which has a GUI built with JavaFX and targeting java 8 with java 9's new release flag.
Compiling
import javafx.application.Application;
public class Testing {
public static void main(String... args) {
}
}
when targeting java 9 with
javac Testing.java
works fine (also when using --release 9), but when I add the release flag
javac --release 8 Testing.java
it fails to compile giving does not exist errors
Testing.java:1:error: package javafx.application does not exist
There is no problem when compiling this under a JDK8 javac. I've tried using the --add-modules flag to add the jfx modules, but that flag is not allowed when setting a release to 8.
Is there a way to make this work under java 9? It seems that it doesn't think that the jfx packages are included with java 8, but they are (at least in oracle's release).
I am using the release version of java 9 on Windows, and have built the same application without problems under the most recent java 8 release.
I have tried to add the jfxrt.jar from my java 8 installation (and not rt.jar) to the classpath while compiling with the --release 8 flag, and it does work.
My understanding is that one purpose of the release flag was to remove the need to have multiple versions of the JDK installed (or at least their rt.jar files). I'm not sure if the intent was to only remove the need to compile against this one file, or if the intent was to remove the need to compile against any JDK packaged files (and jfxrt.jar is included with JDK8 [at least in Oracle's version] requiring no special flags or classpath modifications to use it).
Without being certain of the intent, it somehow seems wrong that something would compile perfectly under java 8 but would require an additional jar to compile (and only compile not run) under java 9 targeting java 8 (but not when targeting java 9), and thus requiring multiple JDKs. For anyone more familiar with the intended implementation of the release flag, should this be working this way?
The behaviour seems strange though in terms of how the --release flag internally resolved the required jdk internal classes. But owing to the fact that *rt.jars are removed in JDK9 and that javafx.application was a part of jfxrt.jar, it could be a probable reason why the same would complain about the missing package.
The compiling section from migration guide though details this out that the --release N flag is conceptually a macro for:
-source N -target N -bootclasspath $PATH_TO_rt.jar_FOR_RELEASE_N
Hence it should work, if you try something like this for sure:
javac -source 8 -target 8 -bootclasspath some/path/to/jdk1.8.0_65.jdk/Contents/Home/jre/lib/rt.jar Testing.java
A simple solution in the replacement of above, of course, is to add the jfxrt.jar file to the classpath and then compile using the --release 8 flag.
Note: Still leaves me puzzled why --release won't find the previous versions rt.jar? -- Might want to check for any such reported bugs.
From comments:- JavaFX is considered an included extension in Java 8, so is not resolved when targeting version 8. Only the classes that would have been in the rt.jar file are resolved.
Related
Recently, a teammate used the following function in our Java 8 code: Matcher.replaceAll​(Function replacer).
The function was introduced in Java 9, but because he is using a newer compiler, the API function was simply found in the JDK's rt.jar and nobody noticed this won't work under real Java 8 environments.
The compatibility settings are correctly set, and the gradle subproject has the following settings:
sourceCompatibility = 1.8
targetCompatibility = 1.8
I had very similar issues at the time when I first used the Java 6 function String.isEmpty in Java 5 code - the code made it into the release and crashed there.
What can I do to enforce the usage of the correct API. As it is a shared library, do I have to use (and install, maintain..) a different JDK for this gradle subproject, or is there some kind of compatibility scanner which runs through a built jar and checks all rt references?
As you've noticed, the two compatibility configurations does not consider the APIs of older versions - only the syntax, semantics and the resulting byte code.
There are two options you can take. One is to have JDK 8 installed on your computer, and the configure Gradle to use it when compiling your project. It looks like this:
tasks.withType(JavaCompile) {
options.fork = true
options.forkOptions.executable = "$java8Home/bin/javac"
options.bootstrapClasspath = files("$java8Home/jre/lib/rt.jar")
}
The disadvantage here is that you will need to have JDK 8 installed in the first place, and as it will probably be installed in different locations, you will need probably want to configure it with an environment variable or property (I've called it java8Home here).
However, since Java 9, the JDK now knows about the documented APIs of previous versions, and you can select which one to use with a new --release flag. This is not going to work if you use undocumented APIs, but it means you can compile your project with any versions of Java and still make the resulting classes compatible with Java 8. You can do it like this:
tasks.withType(JavaCompile) {
if (JavaVersion.current() > JavaVersion.VERSION_1_8) {
options.compilerArgs.addAll(['--release', '8'])
}
}
Note that the 'if' statement is only there in case you still need to support running Gradle with Java 8 (through your JAVA_HOME variable). If you are only using later versions, it can be removed so you always set the 'compilerArgs'.
For some versions of Java, it is possible build Java code on a newer JDK to run on an older JDK / JRE. You have already discovered the --source and --target options for javac and the corresponding Gradle settings. The other thing you can do is to use --bootclasspath to tell javac to compile against the runtime libraries for an older version of Java.
Since you are using Gradle, check out "gradle-java-cross-compile-plugin" (https://github.com/nebula-plugins/gradle-java-cross-compile-plugin). I can't find any documentation for it, but it apparently deals with --target and --bootclasspath.
Having said that, I don't think cross-compiling Java is a good solution.
I would actually recommend that you set up a Continuous Integration (CI) server (e.g. Jenkins) with JDK installations for all of the Java versions you are interested in supporting. Then set up jobs to build your code and run your unit tests for each Java versions.
Note that simply compiling your code against the older Java libraries is not sufficient to verify backwards compatibility. Sometimes the behavior of libraries changes. You need to run your tests, and your tests need to cover the cases where compatibility issues may exist.
We're using java 8 for most modules/projects, but for some of the modules, we use java 6 (customer requirements).
The developers have java 8 installed and we compile the java 6 projects using these flags:
compileJava {
sourceCompatibility = 1.6
targetCompatibility = 1.6
}
We thought we're all good until we upgraded guava from v20 to latest - 28.1-jre.
To our surprise, the build was successful but failed at runtime.
We have a workaround for building for java 6 using a specific javac found in JDK 6. See more info here. This workaround wields the error class file has wrong version 52.0, should be 50.0 in compile time. The downside is that it requires a download+config+usage of JDK 6 for developers.
Is there a way to validate the dependencies' java version at compile time when using a higher java version? (without installing lower version java) Thanks.
Setting -source and -target values to 1.6 is insufficient to ensure that the resulting output is compatible with 1.6. The program itself must not have any library API dependencies on later versions, and the -source and -target options don't do that. (GhostCat said pretty much the same thing.)
For example, in Java 8, ConcurrentHashMap added a covariant override for the keySet method that returns a new type ConcurrentHashMap.KeySetView. This type didn't exist in earlier versions of Java. However, in the class binary, the return type is encoded at the call site. Thus, even if the source code is compiled with -source 1.6 -target 1.6, the resulting class file contains a dependency on the Java 8 class library API.
The only solution to this is to ensure that only Java 1.6 compatible libraries are in the classpath at compile time. This can be done using the -Xbootclasspath option to point to a JDK 1.6 class library, or it might be simpler just to use a JDK 1.6 installation in the first place.
This applies to external libraries in addition to the JDK, as you've discovered with Guava. The Animal Sniffer project provides plugins for Ant and Maven that checks library dependencies for version problems. Offhand I don't know if there is something similar for Gradle. There might be a way to get Animal Sniffer to work with Gradle, but I have no experience with doing that.
Is there a way to validate the dependencies' java version at compile time when using a higher java version? (without installing lower version java).
You specify your dependencies. When you tell your built system to explicitly use some library X in version Y, then you made a very clear statement.
And you see, it is not only about the class file version number. What if some person doesn't pay attention, and compiles something with Java8 ... with Java6 target, but forgets that the code bases uses Java8-only API calls?!
In other words: you are looking in the wrong place.
The person who makes updates to the build description, and changes a library version from Y to Y+8, that person needs to carefully assess that change. For example by reading release letters.
I agree that a really clever build system could check if libraries you are using come in with a matching class file version. But as said, that is only one aspect of the problem. So instead of looking into a technical solution, I think the real answer is: don't step version numbers because you can, but because you have to. And that manual step of changing that version number, that is something that requires due diligence (on the side of the human doing it).
Thus: I think the most sane approach here is to compile the Java6 deliverables within their own specific build setup. Which you only touch after careful inspection of such details. And sure: convince your customer to move on, and give up a long dead version of Java.
The target system, on which my application is supposed to run, uses Java 6. On my development machine, I have Java 7. Can I do the development, without downloading Java 6?
I found on http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html one example for cross compilation:
javac -source 1.6 -target 1.6 -bootclasspath C:\jdk1.6.0\lib\rt.jar -extdirs "" OldCode.java
However, this too requires the existence of a rt.jar, which belongs to Java 6. Is there a simpler way?
New Java versions generally change both the Java Language (source and class file format) and the Java API.
The Java compiler can emit class files in the old format, even if the source is in a new format (these versions are specified by -target and -source, respectively). Therefore, you don't need the old compiler to target an old JVM.
However, the changes to the Java API are somewhat harder to account for. The easiest is to compile using the API of the Java version you target (-bootclasspath). Of course, you may feel confident that you are not using newer APIs, and skip this step, but the only way to make sure is actually compiling against, and testing on, the old runtime library.
In short, while cross compilation is helpful in that the same source can be used with different Java versions, you should compile and test against the actual Java version you intend to use, which does require the old JRE (or JDK).
BTW, all of these settings are also available in Java IDEs. For instance, in eclipse, one would set the compliance level in the project's compiler settings, and add the appropriate "JRE System Library" to the project's "Build Path":
The below command should suffice to meet your requirement.
'javac -source 1.6 -target 1.6 OldCode.java'
With this command you are telling that the compiler should generate class file that is compatible with java 6. Any java 7 specific will result in compilation error. Regarding rt.jar, you don't need to have java6 specific version. As mentioned the above command automatically ensures output is java6 compatible.
UPDATE/CORRECTION:
After going through the following link http://www.javaworld.com/article/2077388/core-java/what-version-is-your-java-code.html it is clear why it is recommended and is important to use -bootstrap flag along with -source and/or -target flags.
My applet application compiles at JRE 7 and created signed jar. I deployed .jar file at my client machine. But I got exception i.e.,"Unsupported major.minor version 51.0" at IE. I want provide an applet jar file to compatibility all browsers. How to make compatibility a jar file?
The best way is to compile your application using an older JDK. I guess that is the only way you will directly see that you are using the correct JDK API available on older JREs and also dependencies (3rd party JAR files on the classpath) in the correct binary version usable on the older JRE/JDK. Go as far as you need, i.e. use the JDK in version 1.3, 1.4, 1.5, or 1.6.
If the library is not available for older JRE version, you will need to somehow back-port it (and possibly its transitive dependencies too). This may get quite tricky and may involve a lot of effort (using tools such as RetroWeaver or similar). So make your backward compatibility choice very carefully.
Compile your source files to a lower target version - specifically, the target JVM version you want to support, using the -source and -target flags in javac.
So, for instance:
javac -source 5 -target 5 -sourcepath /path/to/code -d /path/to/compiled/code *.java
I'm using Ant to compile Java.The project has to be compiled using JDK 1.5 , however some part of the code references a package compiled with JDK 1.6 version.
I set the JAVA_HOME to 1.5 , error is thrown at this reference as
[javac] class file has wrong version 50.0, should be 49.0
What is the way out without downgrading the reference version to 1.5
What you are asking isn't possible. You should compile your library with JDK 1.5.
Once Java has been compiled at a certain version, you cannot use that version on older versions of Java.
The package you are using might have a version available which is suitable for an older version of Java, alternatively you may be able to get the source code and recompile with the older version (if it doesn't use any Java 6 libraries / features).
Think this way:
The library you use has been compiled using JDK 6. It may be using some features introduced in Java 6 (that were not part of previous versions of Java)
When you use JDK 5 to compile and run, what do you expect the compiler (and the runtime) to do when this "new" feature is encountered? The JDK 5 does not know this feature and will be "confused"
To avoid this confusion at runtime, the compile itself fails.
You have two options:
Compile your project using JDK 6.
Get a JDK 5 compiled version of your library
If your project were using JDK 6 and the library was compiled with JDK 5, then you wouldn't have faced this issue because of backwards compatibility.