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
Related
I want to install Java on a few different servers for running a third party service on tomcat.
I am not a Java developer and I got a bit confused when I began searching for the installer.
I checked the different Java versions and their long term support dates.
It seems that Java 11 JDK is - LTS so i decided to use it.
But when I was trying to find a runtime version (JRE?) since this is the version I am supposed to install on the server(?) I only found Java JRE 8.X.X, and this got me confused.
There is no higher major version of the JRE?
How does it work if you use the JDK 11 or even 14-15 as a developer and then use Java 8 JRE on your deployed servers?
Maybe the JDK holds inside of it the Java 8 JRE version?
Or do you actually need to install the JDK version on the servers instead?
The JRE is a subset of JDK. It contains everything needet to run Java applications but no support for development. So, if you need a JRE, a JDK is also good, although it conatins much stuff that you will not need.
Normally, for executing a Java application, you need a JRE with the same version or higher than the JDK used for development. But the developer can advise the compiler to generate code for a lower version. If he does so, he cannot use the features of the higher versions. For example the compiler of JDK 1.8 can produce code for JRE 1.6. You should consult the manual, to see which old versions are supported by the compiler of a specific version.
After some research,
It seems there is no separate JRE section anymore.
Also JDK 11 for production is not free and I guess this is an ongoing trend for the near future.
On a side note there is the open JDK 11 version but it does warn you about outdated security updates.
So basically in my case sticking to updated Java JRE 8 version is good enough for the near future.
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 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.
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.
Has Java always maintained source-code backward compatibility during its development?
More precisely: given two Java versions X and Y with X < Y, is any program for Java X also a valid program for Java Y, with the same semantics?
E.g. X = Java 2 (or 1.2 with the old numbering) and Y = Java 5.
Or is there only compatibility at the JVM level: e.g. a class compiled for the JVM 1.2 can be run by the JVM 5?
If it is possible to run Java 2 code on a Java 5 (or 6, or 7), what are the exact steps that I have to follow? Compile directly with a Java 5 compiler? Compile with a Java 2 compiler and run on JVM 5?
Sun, and now Oracle, have always been extremely careful with backward compatibility with regards to Java.
Binary compatibility: You should be able to run Java code compiled with older versions on newer versions without modification. There might, however, be small incompatibilities.
Source compatibility: Code originally written for an older JDK version should almost always compile without modification with a newer Java compiler, but there are a number of small incompatibilities. One of them is the enum keyword added in Java 5; on older versions of Java, enum was a valid identifier, but not on Java 5. Also, importing classes from the default package has been removed (I think since Java 1.4). So you can't do:
import SomeClassName;
anymore on Java 1.4 or newer.
In the documentation of every JDK release there is a document about backward compatibility with previous releases, which lists the details.
Java SE 7 and JDK 7 Compatibility
Java SE 6 Compatibility
Incompatibilities in J2SE 5.0 (since 1.4.2)
Java 2 Platform, Standard Edition Version 1.4.0 Compatibility with Previous Releases
Starting witg Java 1.5 enum became a reserved word. Thus any Java 1.4 source code containing enum became broken starting with 1.5
As far as I know JVMs are backwards compatible. A class compiled with JDK 1 will work in the latest JRE 7.
The libraires are definitely not 100% compatible. Some methods have been deprecated (and subsequently removed). Some classes changed behavior in (usually) subtle ways which will cause programs to behave differently.
You can always run with a newer version of the JDK then the one used for compilation. The other way around is not possible (unless you compile using the -target parameter).
You might want to read this document (in particular the Cross-Compilation Options section), which explains the target parameter and the default behavior
You can look at the backward compatibility analysis of the Java (Jre) library classes here: http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
Java is generally compatible with previous releases but anyway it may be a lot f issues with migration.
See my article about migration from JDK 6 to 8 for details