I have code that uses Java 17 features and I am using JDK 17. Is it possible to make a JAR file with bytecode from this Java code that will be executable in 32b JRE 1.8?
Unfortunately, no.
You can instruct the compiler to generate bytecode for java 8, but then you can not use language features that were introduced after java 8. If you attempt to do so, your code will not compile.
Here are some details how to specify the target java version maven's pom.xml file.
Your only option is to re-write your code so that it compiles with java 8.
Related
I am having java JDK version 11 and JRE version 8, it will occur any problem in feature or not? is it mandatory to have same jdk version and jre version?
If your code is using features of Java 11, you will need the JRE 11 to run it. But as long as you develop your code against JRE 8, it doesn't matter which JDK you use to develop and compile with.
You can set your project in your IDE to a compatibility level of JRE 8 (like here). This prevents any usage of features newer than Java 8.
Example: Develop with JDK 11 but only use features from Java 8 -> code will run in JRE 8. See the older versions as subsets of the newer ones.
If you compile code targeting Java 8, and don't use any newer APIs, you can run it on either.
If you build for Java 11, but try to run on Java 8 it won't work.
The simplest thing to do is to use the JVM the software was built on (or a newer version)
No. Because you never use both of them at the same time.
JRE is Subset of JDK.
JDK includes the Java Runtime Environment (JRE), an interpreter/loader (java), a compiler (javac), an archiver (jar), a documentation generator (javadoc) and other tools needed in Java development.
If you Open your JDK folder (C:\Program Files\Java\jdk1.8.0_152) , you can find JRE there.
Coming to your Question; No it is not necessary to have both JDK and JRE of same version as we don't use both at the same time.
Fast-ClassPath-Scanner
https://github.com/lukehutch/fast-classpath-scanner using latest version.
On executing(get names of all classes in war which includes all jars and classes)
new FastClasspathScanner(basePackage).scan().getNamesOfAllClasses()
getting:
unsupportedclassversion error with jre 6
Please provide a solution to it or alternative to perform same.
FastClasspathScanner is compiled for java 1.7
When you try to load it in a 1.6 (JRE6) environment it fails with an UnsupportedClassVersionError. This error indicates that the class version (here 1.7) is not compatible with the JVM version (here 1.6).
Java 7 is not backwards compatible with Java 6. You could try to build the FastClasspathScanner library yourself unter 1.6 (not sure if that's possible). Or upgrade your project to Java 7.
Correct, I am the author of FastClasspathScanner, and it's not a goal to get this working with JRE6. However, patches for supporting 1.6 are welcome.
I am using JDK8 on my normal desktop and I have a separate linux box that I am trying to run the Java program on.
The problem I'm running into is that the linux box is running jdk7, so the computer has JRE7 basically that it is running off of. My question is, is it possible to create a jar file in JDK8 that will be compatible with java 7?
I'm using IntelliJ to compile. I tried to compile in 1.7, but it gave an error when I did end up trying to do it. I compile it here:
In 1.8 it works fine to compile, but when I try to compile in 1.7 it doesn't work.
I know the short answer is to update the linux to JRE 8. But I am curious, is there a way to make it backwards compatible? Or is the other answer to simply install JDK7 on the desktop in order for it to run on the linux box using JRE7?
Java programs built with JDK 8 will only run on machines running JRE 8 (or higher).
I found this when trying to compile classes on my local Linux machine (using JDK 8) and deploying to a remote server running JRE 7. The classes just wouldn't work (like you're finding).
If you want to use JRE 8 on linux, I recommend using the oracle-java8-installer package from webupd8team. Installation instructions found here (assuming Debian based distro).
If you want to compile to JDK 7, it's not good enough to only have JDK 8 installed and pick to compile 1.7. You need JDK 7 installed to and restage your project to use JDK 7.
The thing you have to remember is that the difference between JRE/JDK versions is not just the extra features developers can use (e.g Lambda functions) but it's also that the JRE itself is improved (efficiency, garbage collection, etc.).
As a extreme example: If you wrote code that only used JDK 1 features but compiled it using JDK 8, it wouldn't run on a machine running JRE 1 because the Java classes had been compiled with JRE 8 in mind.
Do note though, that if you're Java Code uses only features from JDK 7 or 6 etc., you might think it good practice to compile using the minimum JDK required to allow for compatibility with more machines. Well...you'd have that compatibility but at a cost of using inefficient, out of date, possibly vulnerable compiled classes (At little extreme, but you get my point).
Are you using any new Java 8 features? Because if you are, this means you cannot build the project against the JRE7.
If you are not using any Java 8 features, you can build to Java 7 most easily by downloading the JDK7 and switching the project to use that instead of the JDK8.
You should also set project language level to 1.7 (and module language level(s) as well, if they're different). It's done in Project Structure settings dialog. After that the project should compile.
Note that you shouldn't use any of the APIs that appeared in 1.8, but such usages will most likely be highlighted in the editor.
I have program compiled on java 6. And library compiled on java 7. Can I call from java 6 compiled code to java 7 compiled code or I will have run time errors. I know that I will have errors on compilation, but i will change jar after compilation. I run my application on jvm 7.
In general Java 7 is backward compatible, so you can use libraries compiled with Java 6.
For example: If your library compiled with Java 6 uses a javax package, it will use the library comming with Java 7 and compiled with Java 7.
I use Apache CXF 2.4.6 (compiled with Java 5) with Java 7. Apache CXF calls Servlet API (compiled with Java 6) of JBoss 7.
Yes, you can, but there are issues with the classfile formats; see this question for the exact mapping of Java versions and classfile format versions.
Specifically, if you have source code A that you are compiling with JDK 6 but you have JAR in the compilation path that has .class files that are with major version 51, then the compilation will fail because the compiler will not be able to load the class files.
However, when compiling you can specify a '-target 1.6' flag so that the generated classfile is compatible with Java 6. If you have access to the source of your library you can recompile it with that target so that it's compatible with a 1.6 compiler.
Lastly (and obviously), the classfile format version must be understood by the JVM.
I have Java 7 installed but set my projects JDK compliance to Java 6. Unfortunately it turned out that this is not the same as compiling with Java 6.
For example, the interface javax.imageio.stream.ImageInputStream
extends Closable in Java 7 which is not the case in Java 6. Using an ImageInputStream where a Closable is expected compiles fine under my settings (Java 7 complying to Java 6) but gives an compile error when using Java 6.
Is this supposed to be this way?
In order to compile Java code for an older JRE, you need to do two things:
Set the compliance level appropriately. This, as explained by dystroy, makes sure the compiler produces bytecode that the old JVM can understand.
Use the old Java system libraries. This makes sure you compile against the version of the Java system libraries (java.lang.* , java.net.* etc.) that shipped with the old JRE.
You have covered the first point, but not the second, hence your problem.
How to do this depends on your build environment.
In Eclipse, the Java system library to use is set as part of the build path: Go to Project properties / Java Build Path / Libraries, then remove the wrong "JRE System Library" and add the right one using "Add Library...".
When compiling with plain javac, you use option -bootclasspath. Example: javac -target 1.5 -bootclasspath jdk1.5.0/lib/rt.jar OldCode.java (from the javac manpage, section "Cross-Compilation Options").
What you have set with the JDK compliance is mostly the class format.
There were several evolutions in the bytecode format of classes. A JDK can compile in a previous format while a VM can't execute a class compiled on a more recent format.
But the used libraries always are the one available in the JDK you use for execution. The JDK 6 version of javax.imageio.stream.ImageInputStream isn't bundled with Java 7.
Use the bootclasspath option when compiling. I thought the JDK 7 warned of not doing so, if doing cross-compilation.