I have both JRE 1.6 and JRE/JDK 1.7 installed on my PC. Do I need both JREs, or can I just keep JRE 1.7 and uninstall JRE 1.6?
I only occasionally have anything to do with the JDK so I'm largely unfamiliar with the Java world. Mostly I just need the JRE for the misc application that needs it.
I do know from PHP web development experience that I need both PHP 5.1 and 5.3 due to deprecation versus enhancement issues, so I was not sure if JRE 1.6 and 1.7 were similar.
Please advise.
Unless you have something that specifically depends on JRE 1.6, you can just keep 1.7.
In general, the Java language is very backwards compatible, so such dependencies on older versions are rare.
There is one special concern with the 6-to-7 leap, though: Oracle changed the licensing model for Java distribution, so you must be aware that OpenJDK 1.7 and Oracle Java 1.7 are not quite the same. So if you have Oracle JDK 1.6, you can't necessarily replace it with OpenJDK 1.7 -- you might have software that depends on the proprietary Oracle-only packages.
JRE 7 should be backward compatible with 6. Since you said JRE, and not JDK, I'd say you're safe to remove JRE 6.
if you have JRE 1.7 then I think you don't need the JRE 1.6. you will get all the features of JRE 1.6 in JRE 1.7
If you have JRE 7u45, you may have issue while reading system properties from JNLP files, in this case better to use java 6
Related
I have two jars: CLI.jar and Some.jar; CLI.jar depends on Some.jar.
The major version of CLI.jar classes is 51 (Java 7)
The major version of Some.jar classes is 52(Java 8)
I run java -jar CLI.jar with JRE 1.7 on a host, it gave "Unsupported major.minor version 52.0" error.
I initially thought it was a JRE version issue, but when I switched to another host which also had JRE 1.7, I did not see this error and everything worked fine.
What did I miss here? I am a professional software developer and I know the basics and double checked the JRE version I am using.
JRE 1.7 is not able to run 1.8 class files (and, by extension, JARs that require 1.8 class files). The error you have encountered points that out quite well.
If another computer can run the same JAR file, its Java version is not 1.8. Note that multiple JREs can be installed on one machine.
TL;DR - No, Java byte code is not forward compatible, but it is backwards compatible.
A bit more details:
Generally, files compiled with later Java version can't be run on the earlier Java machines (e.g. classes compiled with Jdk 1.8 can't be run with Jdk 1.7).
However, this statement is false in the way around context. Any version of Jdk is inherently, and by design, backwards compatible1, which means, that Jdk 1.8 can run programs compiled with compiler from Jdk 1.7.
1There is a little catch here. It's rare, but sometimes, later Java versions deprecate and then finally remove some APIs, Frameworks, Libraries or etc. from the build. For example, JavaFX has been removed since Java 11. So, if this kind of situation arises, and you upgrade your Java, you'll just need to manually add missing (in this case - JavaFX) dependency.
I have been developing my application in the Oracle JDK 1.6 development environment. When I move it to a different environment the code started getting broken, until I figured out the culprit was the environment was configured to OpenJDK 1.6.
After I installed Oracle JDK 1.6 in the second environment everything looks alright. Out of curiosity, how does the same Java version implementation have this effect? Aren't these implementations for the same specification?
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.
I have a question regarding the compatibility between different java versions.
On my computer, I have java version "1.7.0_02".
But when I uploaded the .class and embedded it in a webpage it does not work
I get the error:
"Unsupported major.minor version 51.0"
the heading at the top of the console says:
"Java Plug-in 1.6.0_31
Using JRE version 1.6.0_31-b05 Java HotSpot(TM) Client VM"
I would like to ask what is causing the problem. Is it really my java version?
I mean, I visited the site with the computer I compiled the applet in.
You can't use classes compiled to Java 1.7-compatibility class files with an earlier virtual machine, and that "Java Plug-in" error you're seeing says that's exactly what happen.
Two options:
if you're not using Java 1.7 only features, you can compile your code to be compatible with 1.6 JVM's using the option -target 1.6 (see docs here)
Upgrade the Java plug-in your browser is using to 1.7, if possible (I don't think you can do this on OS X, for example). You didn't note what OS and browser you're using so I'm not sure what the upgrade path would be, if any.
Thanks for the answers, I figured out what was wrong.
I started off with both 1.7 and 1.6 on my machine, and it was really confusing me.
The problem was, 1.7 was 64 bit, and 1.6 was 32 bit.
My browser was chrome 32 bit.
I just installed 1.7 32 bit and it was fine
Are Open JDK and JDK7 the same thing?
Open JDK is a free (but not certified) implementation of the JLS (java language specification) where JDK7 is the next version of Sun's JDK which is currently 1.6 (or just Java 6 as the marketing devision of Sun called it).
OpenJDK was initially based only on the JDK 7.0 version of the Java platform.
Since February 15, 2008, there are two separate OpenJDK projects:
The main OpenJDK project, which is based on the JDK 7.0 version of the Java platform
The JDK 6 project, which provides an Open-source version of Java 6.0.
I hope this clears the confusion a bit.
It appears to be a Solaris<-->OpenSolaris situation, viz. there's an open-source project with as much code as possible; the fixes get transferred back to the main software, which the vendor supports and sells. OpenJDK is a project. OpenJDK version 7 and JDK7 appear to be largely but not exactly the same (per here).