Is there any location where the JDK version supporting that GSON version is documented?
Specifically I want to know the highest GSON version that will run with Java 1.4.
I have a embedded JVM with version 1.4 that I cannot upgrade, and I want to test if GSON works on it.
GSON versions are available for download at this link.
Unfortunately it looks like GSON does not work with JDK 1.4. The answer provided by #Steven specifically states that GSON heavily uses features of JDK 1.5. Also, if you look at the oldest available GSON version in Maven Central (version 1.1), the pom.xml indicates that the minimum version for JDK is 1.5. Source, search for "targetJdk" and you'll see 1.5 listed.
Unfortunately this means GSON won't work with JDK 1.4.
I don't think you can run it with 1.4, even the Gson 1.0.1 is compiled for 1.5
You can check that, too:
download the jar you want to check
open a class-file inside
look for the bytes 6 and 7
compare result with this table https://en.wikipedia.org/wiki/Java_class_file#General_layout
Related
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.
I can see bcprov-jdk15 as well as bcprov-jdk16 on my project path. Can there be a scenario where we need both ?
The 15 and 16 point to JRE 1.5 and 1.6 for compatibility. Your version is 1.46 at most because that's the latest version where the JDK 1.5 and 1.6 were targeted separately. The 1.46 version was created on February 2011. The current version is 1.60, July 2018.
So you do not need nor should want either of those jars. You probably want the latest, otherwise you may be behind with regard to security fixes. Note that you should do some testing to see if the latest version runs with your code and change your code if it doesn't. Generally Bouncy Castle libs are backwards compatible, but some components such as its own ASN.1 API have gone through some serious changes.
So you'd better use this one from the Maven repository or download the latest from the Bouncy Castle site itself. You should use the one with 15on, which is for all versions of Java equal or greater than 1.5 (on = onwards).
Storing these jars without their version number is of course ludicrous. If you need to rename .jar files just to make your code run then there are some issues that you need to address.
The java version is relevant to Bouncy Castle. What you have are jars for Java 1.5 and Java 1.6
You should have only 1 in your classpath and use the Bouncy Castle jar closest to your Java runtime environment version. When you have more than one, you dont know which version of the code is being run. Class loading orders are not guaranteed and typically differs across environments, java versions, etc.
You are more likely to have bugs that are difficult to reproduce when you have two versions of the same jar.
What is important is the last 3 digits in the version e.g. 149 in bcprov-jdk15on-149.jar. This is the actual version of Bouncy Castle. Pick whichever is the newer one.
You should analyze your classpath dependencies (e.g. mvn dependency:tree) to understand which versions are you actually using. In principle the newer version should be backward compatible but this is not guranteed and there could be bugs.
I'm new to opentaps environment. I have some doubt in opentaps. I have opentaps1.5 version. It is contain apache 6.0.26 and ofbiz 10 version. I want to work using jdk1.8. While compile the program using jdk1.6 or 1.7 it is providing expected results. When I used jdk1.8 It showing
ExceptionInInitializerError.
Please tell me how to resolve this issue. I need to work opentaps1.5 with jdk1.8. Thanking you in Advance.
Apache OFBiz, which is the base of opentaps, just introduced Java 1.8 compatibility in the upcoming 14.12 branch. OFBiz 10 is very old and not maintained anymore. It is not compatible with Java 1.8.
As far as I know, opentaps is forked from OFBiz and might have newer versions which are Java 1.8 compatible.
You may want to contact the support (http://www.opentaps.org/services-support) to get more accurate informations.
I want to know the javolution and jna jar version which is supported by jdk 1.4.
Thanks in advance.
There is a pre built release for Javolution 5.5.1 which appears to be for Java 5.0. However, using ant it can built for j2me, gcj, 1.4, 1.5 and 1.6.
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.