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.
Related
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.
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.
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.
I'm using CLDC 1.1 + MIDP 2.0 .
The "Compiler compliance level" is set to 1.4 .
When I set "Compiler compliance level" to 1.6, I get the following error: "ALERT: java/lang/ClassFormatError: Bad version information.".
How can I use java 1.6 with J2ME?
This answer maybe outdated now, please refer below for latest answers.
Date: April 2011
How can I use java 1.6 with J2ME?
You can't
Core Reason: J2ME is meant for mobile device where the memory & cpu are the biggest constraint.
Java ME is a subset of Java, and most of the ME specific code will reside mostly on the client, so you don't need any special versions of Java to compile the program.
The problem here is that you are using a version of Java compiler that didn't exist when the phone was invented. The version of the Java compiler is written to the .class compilation output.
Ideally you would compile the project with an older version of Java, but it is very hard to install an old version. So we can act as a compiler ourselves, and manually set the version in the .class output files to the version we desire, and we should make sure that we don't use features from after that version. In this case we will target version 1.2.
You can use the -source and -target options of the compiler to prohibit as many features as possible but many javac compilers have a limit to the older versions they can target, my Java 9 (1.9) can go as low as 1.6. You will need to manually ensure that you are not using features introduced between 1.2 and 1.6
The first 4 bytes in a .class file are the infamous "CAFEBABE" magic string.
bytes 5 and 6 are usually 0
bytes 7 and 8 are the java minor and major versions.
Change Byte 8 to 0x2E. According to https://en.wikipedia.org/wiki/Java_class_file this corresponds to version 1.2 or Java2.
We are using Java2 because, as you can see in its initials J2ME, Micro Edition was released in Java 2. So for backwards compatibility reasons, you can be fairly confident that the phone will run such applications. If you need features introduced after this Java version, just keep increasing the version number until it fails again to find out the exact version of Java supported by your phone.
you can not use it because it is for se and ee version not compatible with mobile
latest sdk for j2me 3.0 is available