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
Related
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.
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.
While creating jars, if I create two jars of the same source code but each one in different jre version, will there be a difference in the jars created (i.e. will they function the same)?? please help
Yes they should. Make sure jre versions are compatible with your code.
As previously mentioned, a jre can can execute code compiled by on a JDK having the same or an earlier version (ex: JRE 1.8 can execute code compiled on 1.6 JDK).
Note that you can specify a target version when you compile your sources so you can make it compatible with a previous version of JRE.
Use the -targetoption of javac for this. You can also use the -sourceoption to specify the version with which your source code is compatible; it will imply a target version.
Have a look on Oracle's documentation.
I'm using the PostToWeb library for Processing (http://libraries.seltar.org/postToWeb/), but when I try to run the sketch, I get an error telling me that the JAR for the class is compiled against Java 1.6, whereas the version of Processing that I'm using (1.5) uses Java 1.5
So, how would I go about recompiling the code src against Java 1.5?
Or, is there some other potential workaround?
Thanks.
If you are using a dev tool, you should be able to mention the compile version in the project properties.
in Eclipse, Project Properties, Java Compiler, set compliance level to 1.5.
It's as simple as:
javac -target 1.5
Otherwise you can specify it in maven with the compiler plugin
<compilerVersion>1.5</compilerVersion>
You could switch the version of Java you are running with to be version 6. Any jar compiled with version 5 will work with version 6. Just not vice versa. Then in the end you have a system running with an updated Java.
There are command line parameters for the compiler that can control this. I have done this with Ant.
I googled for you and found http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javac.html which tells you to use -source 1.5 and -target 1.5 for these compiles.
The article "Don’t be fooled by javac -target 1.4" shows that compiling with -target 1.4 still can create class files which will not run on JRE 1.4.
It also describes how the -bootclasspath parameter can solve this problem.
Now my question: if I compile with the Sun JDK 1.6 version of javac, using the source and target parameters set to 1.3, is safe to assume that the compiled classes will work on a JRE 1.3?
They won't work if you use any methods or classes in the standard library that didn't exist in 1.3, as these files are not compiled into your program, but are part of the JVM's libraries.
In fact, like the article says, your code will be bytecode compatible with 1.3, but not linkable with 1.3. As a consequence, it is possible for you to use post 1.3 classes or method (as states their example) as long as you use a rt.jar coming from a version more recent than the expected 1.3.
As a consequence, the only sure way to develop for 1.3 is to use a 1.3 JDK ... or to rely on verification tools, like ... oh crap ! i'm sure there is one maven reporting plugin that can check your code is compatible with expected JDK, but can't find back how it's named.
However, notice there exist tools like Retrotranslator, that will take your post 1.5 code to adapt it to previous versions ... as long as your code solely relys on JDK, as they may not be able to handle all external APIs dependencies