JRE version enough to run a jar - java

What is the smallest version of JRE to run a simple jar that calls other jars while running ?

That depends completely on what parts of the Standard API and what class file version the classes in that JAR (and the ones it calls) are using.

Related

How to have the java8 code that uses Unsafe working on jdk8 and jdk9?

I am using sun.misc.Unsafe in my Java8 codebase. This does not work on Java9.
I would like to have the fix for Java9, but with the same codebase that runs on Java8. If I put module-info.java, it will not work, as my codebase is Java8.
What to do?
Andreas comment points in the correct direction, you can make use of the Multi-Release JAR Files.
You can create a packaging such that the classes with code common to both the Java JDKs are in the root JAR while the one for which you need to overwrite the implementation is in both the root jar as well as META-INF/versions/9. As noted from the JEP:-
In a JDK that does not support MRJARs, only the classes and resources in the root directory will be visible.
In a JDK that does support MRJARs, the directories corresponding to any later Java platform release would be ignored; it would search for classes and resources first in the Java platform-specific directory corresponding to the currently-running major Java platform release version, then search those for lower versions, and finally the JAR root.
For example, on a Java 9 JDK, it would be as if there were a JAR-specific classpath containing first the version 9 files, and then the JAR root; on a Java 8 JDK, this classpath would contain only the JAR root.
Edit:- Here is a sample project for a similar packaging created with the help of a JetBrains blog using IntelliJ2017.3.

java.lang.NoSuchMethodError: jodd.Jodd.init(Ljava/lang/Class;)V

I am trying to use the Jodd-http version 3.6.6 library in a simple application. The application runs fine on a test machine which has java 1.8 installed but when I try to run the same application on another machine with java 1.7 it throws this excption.
java.lang.NoSuchMethodError: jodd.Jodd.init(Ljava/lang/Class;)V
is this version of jodd-http is not compatible with java 1.7?
Jodd modules are distributed in two flavors:
1 .as a single bundle jar, that contain all Jodd modules in one distribution archive.
separate jar for each module.
So Jodd may be used on any platform where there is a suitable Java 7+ runtime environment.
This shouldn't be related to java version, but to existance of jodd libraries - are you sure you have jodd-core jar in your classpath?
Because jodd-http can't work without jodd-core:) And from your exception it looks like only jodd-http jar is present in the classpath; but not jodd-core.
Can you check this please?
I don't know if you use maven repo (jCentar or Maven Central), but it would be good so all this dependencies can be loaded automatically.
EDIT:
Check httpclient example in the https://github.com/oblac/jodd-quickstart
EDIT:
Check the classloaders - if they see the Jodd class (or any class from jodd-core); maybe the classloader for some reason dont see it; or there are multiple different versions of jodd-http on the classpath.

How do I control what JRE version is bundled with my application?

I'm considering bundling a JRE with my Java application. I'm using Launch4J. Looking around stackoverflow this seems easy enough to do. What I've not seen any information on is where I get the JRE from in a controlled manner.
I'd like to be able to control from a single place what version of the JRE is bundled. I don't want to be manually updating/installing JRE's on n number of build machines each time we decided to use a different JRE. Placing the JRE under source control seems the most logical option. Our build is done using maven, I assumed there would be some kind of maven plugin that would download a configured JRE version and put it in the target folder for you.
So, what is best practice to control which JRE is bundled with my app?
check the Maven enforcer plugin http://maven.apache.org/enforcer/enforcer-rules/ and in that check for requireJavaVersion http://maven.apache.org/enforcer/enforcer-rules/requireJavaVersion.html . this will add checks to the build that fail when the inapproriate JRE is used.

Jar before jre - java classpath

is there a way to run java and tell it to use a certain jar higher in the classpath than the jre?
I know it is possible in eclipse run configuration, but I want it to work using java from command line.
The reason is that there is a class that is loaded from the jre and I wanted a different version that should have been loaded from an external jar. I saw this was the case using -verbose.
Thank you
try this Java arg
-Xbootclasspath/p:my.jar

Dependencies of a JAR

I created a Jar with Java 6. Now I'm creating a release document and recording the dependencies. How can I find the earliest version of Java that can successfully run the Jar, and the earliest version of Java that can successfully compile the source into a Jar?
I only know a manuel solution: try it out. There are, however, two things to consider.
For which version is the code language compatible?
For which JRE will it execute?
The first you can do with your current JDK, just iterate over the -source and -target arguments which you pass to your javac compiler. This will, however, not prevent you from using classes and methods from the JDK you are using. If you do, the code will not execute for a lower JRE, if you are using classes or methods that where not present back then.
The savest way would be to install all different JDKs along and try to compile the code with each of their compilers.
If you created the jar with java 6 and did not specify a different version of output bytecode, the generated class files will require Java 6 or greater. You can experiment to see what versions of bytecode you can generate with your source with the -target command line option if you're compiling manually, if you're using eclipse or some other IDE, most have settings that control the generated bytecode version in project options or somewhere similar.
A related post about determining the bytecode versions of class files: What version of javac built my jar?

Categories