Would I encounter any problems running Java programs and associated libraries compiled in Java version 1.6 and 1.7 (I'm compiling using 1.7 whereas some libraries are compiled using 1.6) and running the entire program in a 1.7 JRE?
As answered already you are mostly safe and most products and 3rd party libraries will simply work. However there do exist very rare cases where binary incompatibilities (ones where the class file compiled using older JDK will fail to run in the newer JVM) were introduced between JDK versions.
Official list of Oracle Java incompatibilities between versions:
in Java SE 9 since Java SE 8
in Java SE 8 since Java SE 7
in Java SE 7 since Java SE 6
in Java SE 6 since Java SE 5.0
in Java SE 5.0 since Java SE 1.4.2
Compatibility tool
Packaged with JDK 9, there is a tool called jdeprscan which will verify the compatibility, list no longer used APIs within your code and suggest alternatives(!). You can specify the target JDK version (works for JDK 9, 8, 7 and 6) and it will list incompatibilities specific to your target version.
Additional comment in case of libraries:
A reasonable rule of thumb is to use latest stable release version of library for the JRE version your software targets. Obviously you will find many exceptions from this rule, but in general stability of publicly available libraries usually increases with time.
Naturally API compatibility and versioning have to be considered when changing versions of dependencies.
Again most popular dependencies will have web pages where such information should be available.
If however you are using something a bit more obscure, you can discern which JRE were the classes within your dependency compiled for.
Here is a great answer on how to find out class version. You might need to unzip the JAR file first.
You would not encounter any problems - that's the magic of Java -it's backwards compatible.You can run almost all code from Java 1 on Java 8. There's no reason why Java 6 code won't run on a Java 8 Runtime.
What is interesting, is that for applications written in, let's say, Java 1.4, you even have speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language known as "Java", but also the JVM (Java virtual machine). I still have source code from more than 10 years ago that still work, as expected in the latest JVM.
If you want to target, let's say, a Java 5 VM, then you can do that with the Java 8 SDK tools. You can ultimately specify which target VM you wish to support, as long as you bear in mind that a version 5 VM might not support all the features a version 8 VM will.
I've just tested code I wrote in Java 5 against the new Java 8 runtime and everything works as expected, so, even though we have a more powerful language and runtime now, we can continue to use our investments of the past. Just that alone makes Java a great development choice for companies.
Related
When starting the standalone version via graphdb.cmd the following message is given:
"This GraphDB distribution requires Java 8, 11 or 12 but you have Java 15".
However, the startup is successsful and GraphDB WorkBench can be started.
Do I have to expect some "hidden" problems in the future use, when I keep running the system based on (Open)Java 15?
Theoretically speaking you should have no problems using Java 15, but this mean that GraphDB was not tested with this version and it's hard to say if there could be potential problems.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.
I have been using the dynamic code evaluation for dynamic loading of my changed classes in my Jboss server ,
I have found this tool very helpful and interesting , but it have a problem that it works with jdk 1.6 , but As i am trying to use java 7 in my project it fails .
Can anyone suggest similar type of tool with java7 support
I suggest using... the Dynamic Code Evolution VM for Java 7 :) The DCEVM web site is not up to date and the version available for download there doesn't work with the latest versions of Java 7. For some time the Mercurial repository contained a more recent version and it has been eventually forked on Github where binaries for Windows and Linux are provided. On Debian/Ubuntu DCEVM is also available after installing the openjdk-7-jre-dcevm package.
I understand that the Oracle Java SE contains closed source extensions and tools that are not part of the OpenJDK however is the Oracle Java SE JVM identical to the OpenJDK JVM or does Oracle make changes to the OpenJDK JVM before releasing it as a Java SE JVM?
Update 1:
I found some info from the JDK7 updates projects: http://openjdk.java.net/projects/jdk7u/qanda.html
Will the 7 Update Project receive security fixes from Oracle?
Yes.
As with OpenJDK 6, security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to effected JDK release trains. In addition, they will not go through the public code review and putback approval process, and their corresponding issues in the Project's issue tracker will not be publicly visible.
OpenJDK is the reference implementation of Java as of version 7.
OpenJDK 7 is the starting point for the version that Oracle distributes as Oracle JDK. Other vendors (e.g. RedHat for IcedTea) may also use OpenJDK as their starting point.
In terms of the differences between OpenJDK and a vendor VM, there may be patches which a vendor wants to apply but which the overall OpenJDK community has not accepted into mainline.
Vendor VMs must, of course, be able to prove that they are in conformance with the TCK if they want to use the Java trademarks to describe their product.
Oracle JDK is also not open-source. This is possible because of Java's dual licensing arrangements, and the fact that Oracle own Java overall.
Do you have more specific questions - as posed, your question is a bit vague. What specific aspects are you interested in?
I am writing a java program using JAVA 6. Our company server is using JAVA 5. They refuse to upgrade it to 6, so the workaround would be install another JRE 6 inside the same machine. They wonder, will installing different version of JRE causes instability?
What the installation process do? Simply copy over the files and setting up environment variable? Will it change any registry or other setting?
Multiple JREs can reside on the same machine. However, if you install JRE6, that's the same as upgrading to Java 6. Java 6 is (as far as I can tell) able to run all older Java code. However, Java 6 binary (.class and .jar files) can not be executed using Java 5, unless they were compiled to target the previous version.
If you need to, you can target Java 5 using a Java 6 JDK. There are command line arguments for javac that you can use (or incorporate into Ant, and probably other build tools) to specify a target JRE. For example, if you used the -target 1.5 command-line option using your JDK, the .class or .jar files that are produced will be executable using the Java 5 JRE.
It's been a while since I have ran two JREs side-by-side, but unless things have changed, there will be two separate java.exe (on Windows, anyway) files - one for the previous Java 5 JRE and a new one for the Java 6 JRE. Due to naming, only one can be in the path at a time - all of the files have the same names, so you can't include the Java 5 and Java 6 java.exe at the same time and expect the right one to magically run. However, you can leave the Java 5 JRE in your path and manually invoke the Java 6 java.exe when you execute your application.
If you use JAVA_HOME set to the Java 5 JRE and set a new environment variable to the Java 6 Java Home, let's say JAVA_1.6, as long as you properly reference the right environment variable, you should be fine.
You can definitely have both. If you are "allowed" maybe you could bundle the jre you want with your app? This URL talks about how..
http://forums.sun.com/thread.jspa?threadID=708451