We're working on a project that still needs to run on a Java 6 environment, so I set in - Preferences - Java - Compiler - the Compliance Level and Source compatibility to 1.6. I expected to get compiler errors on stuff introduced in Java 7 or later.
While this is working for new features like the try-with-ressource statement, I don't get even a warning when using generics that were introduced after Java 6 like ComboBox<..> or JList<..>. In fact I get a warning when using raw types, even on ComboBox which wasn't generic in Java 6.
Two question:
Why do I get errors using try-with-ressource, but not when trying to use ComboBox<..>?
Is there some other options to toggle in order to see non-available generics as errors?
Note: I'm using IBM Rational Application Developer 8.5.5 which is built on Eclipse 3.6.3 (Helios) with a JDK 7 - not my choice, just what's given here ... deployment for the Java 6 environment is done elsewhere, I just have to guarantee that I'm not using Java 7 features, but the above doesn't seem to work as expected ...
The compliance level only covers language features such as try-with-resources.
The use of generics by a particular class is determined by the JRE/JDK library you are using. You will need to use an actual Java 6 JRE/JDK to get the correct checks. This also covers things like additional methods and classes introduced by later releases.
You can define additional JRE/JDKs in the Preferences in the 'Java > Installed JREs' page.
In the Properties for your project you can define the JRE/JDK to use in the 'Java Build Path' page.
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.
This may seem a daft question so I will be as brief as possible.
Where I work, we deal with lots of Java apps that are compiled on old versions of Java, in fact we recently upgraded one of them to Java 1.6
We've been given new laptops recently with no admin rights and Java 7 installed by default.
I am presently unable to get hold of and install a copy of JDK 1.5 (which I need)
In Eclipse, if I set my JDK Compliance level to 1.5 but the Installed JRE is 1.7
Which of these 2 statements is true... ?
1. I am building my code at Java 1.5 ?
2. I am building my code at Java 7 ?
I've seen and spoken to various people on this subject and I am still non-the-wiser.
It means the byte code that is generated from your source code will be compliant to the 1.5 JRE.
The syntax highlighter will not allow you to do things that were new to 1.6, 1.7 such as switching on strings.
Developing with a JDK higher than the target platform is in principle possible, using the "compliance settings" and/or target version switches with javac.
Its however not practically feasible for doing real development, as nothing will prevent/warn you from using the API's present in your installed JDK but not in the target platform.
If, for example you develop for java 1.4 using an installed 1.5, while the compiler will not let you use autoboxing (which was introduced in 1.5), but it will happily let you use (for example) Integer.valueOf(int). Which is not present in 1.4.
I was wondering if there is any difference running/building a software under JDK 8 and using compiler compliance level 1.7 vs JDK 7 as system default? I am more interested in reference to Android building, building apps, Eclipse, Android Studio, etc.
Yes, there are loads of new classes in the JDK 1.8, for example, the java.time classes. You won't get those if you build in JDK 1.7; but you will be able to use them if you build in JDK 1.8 with compiler compliance level 1.7.
Yes there is a difference between running/building a software under JDK 8 and using compiler compliance level 1.7 vs JDK 7 as system default.
running a software under JDK 8 and using compiler compliance level : You compile in jdk 1.7 but run on 1.8. No problem, your programm will work as needed.
JDK 7 as system default : You compile in 1.7 version and run on the same version.
I am wondering in waht case you would like to use the first case ?
truck load of difference actually. With JDKs the the compliance level is a directive to the compiler to specifically use the optimizations and linking features for the version you specified. It has a lot more going under the hood but I don't think you want to know that. New JDK versions bring new features and the compilers in those version are able to understand and link those features when building class files or assembled code of your source Java files. Consequently the JVM runtime in those JDKS is also equipped to handle such optimizations and cases and process them. So without compliance levels the class file that you build with JDK8 would only run correctly with JDK8 based runtimes. They may not do so with JDK7 or 6. To counter this problem and thus allow your JDK8 compiled code to run on JDK8,7 and maybe even on 6, hyou need to add compliance level to compiler directives accordingly. Downside is that you may not be able to use some latest features which the compiler offers but such cases are far few and outweigh the need for interoperability and potability.
I am using Java 7 SDK and IntelliJ IDEA IDE.
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)
I am still not able to use Java 7 features. After a bit of googling I could use all the features after setting project language level to 7(Diamond, ARM, multicatch etc). What exactly is this? If this has some relationship to syntax based on JDK in use what is level 8(Lambda, annotations etc)? Java 8 isn't released yet. Java 8 is expected in March 2014 according to Wiki. Someone please explain this language level concept.
The Language level setting sets which features the code assistance in the editor should support. For example, if you're using JDK 1.7 but want your code to be compatible with JDK 1.6, you can set the language level lower than your actual JDK supports (6.0 in the case of JDK 1.6) and only get refactorings/syntax suggested that are supported on 1.6 and lower. Depending on your compiler, it may also give the compiler options to remove support for newer syntax elements.
The 8.0 (which, as you're guessing corresponds to Java 8) is available for people that want to experiment with one of the Java 8 snapshots that are available. Since Java 8 isn't released, language level 8.0 may very well change before release.
As per the documentation within section Exploring the General Project Settings at the IntelliJ Wiki, the project language level impacts the intellisense provided by the IDE.
It also dictates the behavior of the compiler being used by IntelliJ when it compiles your Java code as you develop.
This setting tells all the facilities of the compiler that would be available for the project. For e.g. setting the language level to JDK 5 will allow the IntelliJ to recognize keywords such as enum that are present within the source code.
If you look at the options for the javac Java compiler command, you'll see that the -source and -target options allow you to compile against alternate versions of Java. I'm not sure to which option IntelliJ's language level setting corresponds (it is likely -source), but it essentially tells IntelliJ to use the provided Java SDK (in the Project SDK field) in the specified Java language version instead of the latest provided by said SDK.
So while you have Java 7 installed, you could set the language level to 6.0, and IntelliJ will compile your code against the Java 6 specification instead of the Java 7 spec. This includes all of the real-time suggestions and code checking done as you type.
The Java 8 option is there likely due to the fact that beta builds of Java 8 are available for testing.
I've never experimented with what would happen if you set a language level to something higher than the JDK version.
I am compiling my web app in Netbeans against Java EE 5. I know that the String.isEmpty() function is only supported in Java 6. Having said that, I can still compile my project using the .isEmpty() in my code.
How come Netbeans is allowing my web app to compile if I am compiling against Java EE 5?
The compiler level is not equal to the JDK level you use for compiling. The compiler level only checks for the syntax and of course creates a different output. But the compiler itself will use the jdk on your classpath so if you compiled with java 5 option but with the java 6 jars on your classpath the code will compile without an error.
You should check your classpath.
As many have pointed out, Java EE versions are not strictly tied with Java SE (JDK) versions. Mostly, they require a minimal Java SE version but are compatible with later versions.
Java EE 5 specification (downloadable PDF here) says:
This specification requires that containers provide a Java Compatible™ runtime
environment, as defined by the Java 2 Platform, Standard Edition, v5.0 specification
(J2SE)
Since JSE versions are backwards compatible, you can take a container compatible with Java 5 and run it on top of Java SE 6 or Java SE 7.
You can check the compatibility level that Netbeans is using by checking the project "Properties > Source > Source/Binary Format"
If you still have doubts about "Java vs Java EE" you can look for several questions here on SO about the difference between Java SE and Java EE.