I'm doing some upgrade work now. From java 7 to java 8, and also upgrade some jar files. How do I know if the jar file is compatible with java 8? Is there any website telling that?
Classes that were compiled with Java 7 almost always run on Java 8. This is backward compatibility requirement. However, there are some incompatibilities that are documented here
If there is some issue with a particular library, you should look for this information on the library's website.
Related
For a project I must use Java 6, so I set my eclipse compiler setting to 1.6 (JDK compliance level).
However, I included java.nio.file.Files which is a Java 7 library and I am not getting any complaints. I can ensure that my project specific setting is set to 1.6. I even changed my entire workspace to 1.6 and rebuilt, still no complaints. My colleagues are seeing the complaint on java.nio.files.
Is it becuase I have a jdk7 which is recognizing the java.nio.file.Files even when set to 1.6 spcs?
These are two different things:
the compliance level is about the syntax that you can use when writing Java code (respectively about the Java version number that gets put into compiled byte code)
but the libraries that are available to you depend on the JDK that your project is using!
In other words: if you truly want to restrict your project to Java 6 libraries, you will have to install a Java 6 JDK on your system, and point to that within your project setup ( most likely, your current project setup makes use of a newer-than-Java-6 JDK ).
And the usual disclaimer: Java 6 has had end of life many years ago. You should do whatever you can to upgrade your setup.
JDK compliance level is the level of the Java syntax, not the runtime libraries. It will just prevent you from using language features that were introduced in later versions like try-with-resources which was introduced in JDK 7.
If you want to develop for JDK6, you need to use JDK6.
Java 6 is able to interpret java.nio.file.Files because there is no special Java 7 syntax in contrast to Java 7 and Java 8 (lambda expressions etc.). So you are working on standard libraries. Uninstall Java 7 JDK and install Java 6 JDK and you will that java.nio.file.Files is not available anymore.
According to PyDev's documentation:
PyDev requires Java 8 and Eclipse 4.6 (Neon) in order to run and only supports Python 2.6 onwards. [...]
The documentation states that the installation will silently fail if Java 8 is not installed. However, I have the more recent Java 9 installed.
Is PyDev compatible with Java 9? Or will I need to reinstall Java 8?
PyDev is currently only tested with Java 8, so, that's what's recommended.
Still, it should work with Java 9 too (as java is usually backward-compatible). If something doesn't work, please create a bug report (see: http://www.pydev.org/about.html for links).
I'm reading the document about the new Java 9 module system.
The paragraph 3 Compatibility & migration explains how to migrate code
from Java 8 to Java 9, but says nothing on how "migrate" or run an application
written in Java 9 to pre Java 9 runtimes.
So, if I have, say a JAR application written in a modularity way (every module has a module descriptor) what does happen if I deploy it on, i.e, a JDK 8 runtime?
If your class files are compiled with --release 8 flag, then they should run fine on Java 8. module-info.class files will be ignored by the older JVMs.
If your Java 8 project is maven-based, you can easily configure it to include module-info.java: https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
Also, take a look at JEP 238 (Multi-Release JAR Files). This allows you to take even more advantages of Java 9 features without breaking compatibility with Java 8.
You cannot start a Java application with a JRE which is less than the one it is built for.
If you just use javac without any special options it will produces classes which do run on JREs equal or bigger than the one of the used JDK.
However javac supports cross compilation. You can use JDK 8 to compile JDK 6 compatible class files. Search for Cross-Compilation Options in the javac docs.
Java Class files contain version information. As with any Java version it should not be possible to execute a class file (or jar) that was compiled with a newer major version than your runtime. See: https://stackoverflow.com/a/4692743/6239524
I have a old project running in java 6 and am trying to implement sso using onelogin's javasaml library. I see the java-saml-core and java-saml dependencies compiled with higher versions. I also see that in the github that it is compatable with java 6,7 and 8. What does it mean? May i use the libraries as it is to develop my solution in java6 project? any thoughts? thank you!
https://github.com/onelogin/java-saml
Version 2.X of java-saml was originally designed to be compatible with Java 6,7 and 8.
but in the road we introduced some incompatibilities with Java 6 that we described on that github issue
Just in case someone is interested, I managed to recompile java-saml under Java 6 to run on an old WebSphere instance.
Changes are limited to a few Java 7 specific syntax (diamonds, multi catch, closeable)
Fork is available at: https://github.com/mguessan/java-saml
A jar is being ran with JVM 8 , which is compiled with java 6.
Can this jar load another one as a 'library'/plugin that is compiled with java 8 which has
dependency the first jar?
Sure, it can. You can mix jars compiled against different Java versions.
Also note that there's couple of things when talking about Java version used. One is the Java Class Library you compile your code against. This defines APIs you can use in your code.
The second thing is java bytecode version. You can instruct Java 8 to compile code to be Java 6 binary compatible. This doesn't mean that your code will execute against Java 6 though. If you use calls/classes added in Java 7 or 8 then you will hit problems at runtime.
These two are the most important aspects when talking about Java compatibility. Google for Java compatibility or Java source vs. binary compatibility to get more info on the subject.