May I know if there are any issues running a Java 5-compiled code (with Java 1.3 source/target compliance) on a Java 1.3 JVM?
I know this is quite odd, but most of our customers are on Java 5 but we are restricted by a few still on Java 1.3 due to conditions beyond our control. Our CI tool uses Java 5 compiler but we set our source and target compliance to Java 1.3 for backward compatibility. We are not using Java 1.3 for CI because there are unit tests that does not compile on 1.3.
Will this be an issue?
Thank you in advance!
Cheers,
- Paul
The only way to get the compiler to check that source in your app. only uses 1.3 methods is to specify a -bootclasspath pointing to a 1.3 rt.jar. Note you can get that from a 1.3 JRE, it does not require a 1.3 SDK/compiler. Of course, specify a -target of 1.3.
The biggest problem you will have is that while the JVM generated byte code will be compliant with 1.3, the JDK you're compiling against is Java 5. It is very easy to use a class, or more likely, a method that exists in Java 5, but not in the 1.3 JDK. This code will compile fine but will fail to run on a 1.3 runtime.
Related
I am posting this question as I have limited resources to test or confirm by my own.
Problem statement : I have an old custom Jar working with java 1.6. We don't have source code as well.
To fix one of the issue we updated 2 .class file of this jar using 7-zip.The code change was just to update the existing loggers with more meaningful messages.
These 2 .class file compiled with java 1.7.
Now the questions is whether this jar will work correctly with java 1.6 or will generate java version issue as 2 of the .class files are compiled with java 1.7.
Note - I know it's easy to test this rather then asking here but my test environment is only supporting java 1.8 and it's working perfectly but whether it will run with java 1.6 or not I can't test.
If you compile using: javac Foo.java where that javac is from a JDK1.7 installation, and you then attempt to run the class file that results on a JDK1.6, it will not work.
However, all you need to do is this:
javac -source 1.6 -target 1.6 Foo.java, and then it will, unless you used features from 1.7. If you use language features (I can't think of any, so I doubt it), it won't compile, and thus you know. If you use API, it will compile and you won't know. There is no easy solution to this other than compiling with JDK1.6 (or compiling with javac7 against a bootcp of JDK1.6, but you need to download and install a JDK1.6 to get that; might as well just use javac6 then).
Binary Compatibility
The class file version for Java SE 7 is 51, as per the JVM Specification, because of the invokedynamic byte code introduced by JSR 292. Version 51 class files produced by the Java SE 7 compiler cannot be used in Java SE 6.
Java SE 7 is binary-compatible with Java SE 6 except for the incompatibilities . Except for the noted incompatibilities, class files built with the Java SE 6 compiler will run correctly in Java SE 7.
Friends Words ...
The compiler is not backwards compatible because bytecode generated with Java7 JDK won't run in Java 1.6 jvm (unless compiled with the -target 1.6 flag). But the JVM is backwards compatible, as it can run older bytecodes.
So they chose to consider the compatibility from the point of view of javac (as it is the part specific to the JDK), meaning that the bytecode generated can be run in future releases of the jvm (that is more related to the JRE, but also bundled in the JDK).
In brief, we can say:
JDK's are (usually) forward compatible.
JRE's are (usually) backward compatible.
Java Says
Cross-Compilation Options
By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling, where classes are compiled against a bootstrap and extension classes of a different Java platform implementation. It is important to use -bootclasspath and -extdirs when cross-compiling; see Cross-Compilation Example below.
-target version
Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).
The default for -target depends on the value of -source:
If -source is not specified, the value of -target is 1.7
If -source is 1.2, the value of -target is 1.4
If -source is 1.3, the value of -target is 1.4
If -source is 1.5, the value of -target is 1.7
If -source is 1.6, the value of -target is 1.7
For all other values of -source, the value of -target is the value of -source.
-bootclasspath bootclasspath
Cross-compile against the specified set of boot classes. As with the user class path, boot class path entries are separated by colons (:) and can be directories, JAR archives, or ZIP archives.
For More about Cross-Compilation look at
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#crosscomp-options
Better than me at
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
The code base for Java 7 and versions of Java 6 is very similar and even shares many of the same bugs. e.g. the was a well known bug in Java 7 when it was released to do with loop optimisation and people suggested waiting for it to be fixed before migrating. The interesting thing was the bug was also in Java 6, the only difference was that the optimisation was on by default in Java 7 and off by default in Java 6.
Most of the performance improvements in Java 7 were back ported into Java 6.
I try to find a use case when it is necessary to use a special target version of the compiler javac using the target parameter.
Java is backward compatible, isn't it? So, if I compile a hello world program with version 11, it could run on a JVM with version 8, or?
The only use case I could imagine is, when you have dependencies (other jars) which are compiled in a certain version and you have to match this special version when compiling the own code.
Java is backward compatible, isn't it? So, if I compile a hello world program with version 11, it could run on a JVM with version 8
That is exactly backward. If you have a version of a Java class compiled with version 8, Java 11 is backwards compatible and can run it. The reverse is not backwards compatibility, and is the purpose of the --target command line flag. Specifically so a class compiled by the Java 11 compiler can run on Java 8. Without that, you would get an java.lang.UnsupportedClassVersionError: Unsupported major.minor version
By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling.
-target version
Generate class files that target a specified version of the VM. Class
files will run on the specified target and on later versions, but not
on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4,
1.5 (also 5), 1.6 (also 6), and 1.7 (also 7) ... . The default for -target depends on the value of -source:
If -source is not specified, the value of -target is 1.7
If -source is 1.2, the value of -target is 1.4
If -source is 1.3, the value of -target is 1.4
If -source is 1.5, the value of -target is 1.7
If -source is 1.6, the value of -target is 1.7
For all other values of -source, the value of -target is the value of -source.
Refer javadoc for more details here.
I try to find a use case when it is necessary to use a special target version of the compiler javac using the target parameter.
A common scenario is roughly:
production system runs your Java program
individual engineers write/maintain that Java program
JDK versions on engineers' laptops is newer than JDK on production system
Using the "target" flag, it's possible for the engineers to write software using newer/later JDK versions, while still being able to run it on an older JDK (on a production system).
And "older" really doesn't need to be all that old... for example, a production system might be running in Amazon using the latest version of Corretto (which is currently 18, with all other available versions being 8, 11, and 17), and individual engineers could have JDK 19 or 20 on their machines.
The Java Language Spec discusses this topic in Chapter 13, Binary Compatibility:
This chapter specifies minimum standards for binary compatibility guaranteed by all implementations. The Java programming language guarantees compatibility when binaries of classes and interfaces are mixed that are not known to be from compatible sources, but whose sources have been modified in the compatible ways described here.
And various more specific comments in JLS 13.2, What Binary Compatibility Is and Is Not:
A change to a type is binary compatible with (equivalently, does not break binary compatibility with) pre-existing binaries if pre-existing binaries that previously linked without error will continue to link without error.
Note: I posted links specifically from JLS version 1.8 as it's relevant to versions in this question (8 and 11), but Java's treatment of binary compatibility hasn't changed
in prior or subsequent versions.
I want to recompile an old jar file (which was compiled in java 1.2). So that there are no errors i need to compile it in Java 1.2 aswell. But havent found a jdk 1.2 which i can install on windows 7 (and 64bit).
Any suggestions?
thanks in advance!
Yes, you can set the version of compiler at compile time. And compile your java code into old versions of java.
From Oracle article : http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javac.html
Cross-Compilation Example
Here we use javac to compile code that will run on a 1.4 VM.
% javac -target 1.2 -bootclasspath jdk1.2/lib/classes.zip \
-extdirs "" OldCode.java
There are two scenarios, just compiling old code and actually developing for an old JRE.
For just compiling you don't need an old JDK, you can adjust the target language level javac compiles with the -target option (see: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html) - Although there may be edge cases that may break the compiled code if the compiler decides to select a different overload for a method that does not exist in the old JRE.
For developing old JRE compatible code, you could use above method but you run the risk accidentially using an API that isn't present in the real old JRE. To avoid that problem you need the actual 1.2 API, meaning you need the rt.jar file from a real 1.2 JRE/JDK. This can be added into your project in your IDE (and the current e.g. 1.8 JDK removed). The detailed procedure how to set this up depends on the IDE. Likewise the 1.2 rt.jar can be provided to javac, also using command line switches. Again you need no runnable 1.2 JRE to compile/develop.
I'm trying to consume a third-party API, where I get support for the third party API upto JDK 1.6.
I have other few projects which are built using JDK 1.7 and as part of the product I'm also packaging JRE 1.7.
if compiler compliance level is set to JDK 1.6, compile & run using JDK 1.7 libraries produce same result as of compile & run using JDK 1.6?
Would it be safe to claim support from third-party vendor when compiler compliance level is set to JDK 1.6.
Update:
I presumed that setting compiler level in eclipse is same as setting -source & -target options of javac.
I'm not sure if compiling using JDK 1.7 setting source & target to 6/1.6 is same as compiling in jdk1.6.
The problem is in changes of Java API between versions. There are some classes and methods that are available in Java 7 but not in Java 6 and other way round. The code compiles with Java 7 but it will not run with Java 6 because of missing classes or methods.
Unless you compile with Java 6 JDK, you cannot be 100% sure.
Yes, if you compile with compliance level set to 1.6, it will be able to run on java 6 - compiler will guarantee that. It should be able to run on java 7 as well, since JRE is backward-compatible.
You can actually specify the .class files version compatibility in the "Preferences->Java->Compiler" (project specific), so at worst you are benefitting from a more recent compiler building probably exactly the same bytecode as using JDK 1.6.
"Compliance 1.6" however does not ensure that you get exactly the same result as using JDK1.6, but java standard ensures applications built with 1.6 will run the same on a >= 1.6 JRE.
So if you are really afraid of incompatibilities, build the project (on your CI server I suppose) with a project specific setting 1.6 on a machine with both JRE 1.6 for this one, and 1.7 for other projects, and bundle a 1.7 in your distribution, it is guaranteed to run ok by Sun/oracle/java.
i.e. if the code is built with JDK 1.6, and used by other JDK >= 1.7 code you are fine with respect to versioning. Probably this is the case of many jars you use everyday.
However, building the code that is stamped 1.6, with a real JDK 1.6 is the only sensible thing to do if you are afraid of real world problems (money involved).
So I think then you are safe to "claim support", build in 1.6 and use the jar in 1.7.
In my experience with Eclipse, Compliance level set to Java 5 is not the same as compiling with JDK5. It has allowed Java 6 methods to pass compilation locally when the Installed Java was set to Java 6 and the compliance was set to 5 and then our build failed when the files were checked in.
When using the Java compiler (javac), we can specify two kinds of compatibility. One is using -source and the other is using -target. What is the difference between these two?
For example, -source 1.5 and -target 1.6?
Also, is there any case where we use a different source and target compatibility level?
From the javac docs:
-source Specifies the version of source code accepted.
-target Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM.
In your example:
-source 1.5 and -target 1.6
This would be used to make sure that the source code is compatible with JDK 1.5, but should generate class files for use on JDK 1.6 and later.
Quite why you would do this is another matter.
The -source indicates what level of compliance your source code has: are you using Annotations? Then you would need at least 1.5; are you using #override on interface implementations, you would need 1.6 etc
The -target specifies what Java version you want to be able to run your classes on. You could use a Java SE 7 compiler and compile to run on Java SE 1.5.
This is mostly useful to produce a jar file working with an older version of Java.
I believe that so far all JDKs are able to execute older version too, so there is no real reason to have target larger than source.
It does however make sense to set target to e.g. 1.6 when using a 1.7 JDK.
I'm not sure, but I believe it could work in some situations to compile a 1.7 java code using a 1.7 compiler to a 1.6 jar, for example expressions such as
ArrayList<Integer> foo = new ArrayList<>();
that are only valid in 1.7+ source version should compile to 1.6 compatible byte code. But I have not verified whether the compiler will actually do this. Unfortunately, this doesn't seem to be implemented in practise.