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.
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.
A small Java applet [Edited: that might not even be the right word: this is JNLP] in a site I support is currently compiled for Java v1.7. As v1.8 becomes increasingly common, our users are getting warnings like Firefox's "This application would like to use a version of Java (1.7) that is not installed on your system. We recommend running the application with the latest version of Java on your computer." Is there some way we could rebuild our applet to try for the 1.8 Java first and only try for the older 1.7 if 1.8 isn't available, preferably without needing to ask the user in either case? (FWIW, I'm a very experienced developer, but a rather inexperienced Java developer.)
The applet can specify the version of java required using a line like this in the <resources> section of the code:
<j2se version="1.7*">
The version number specified can either end with a number, and asterisk or a plus sign.
1.7 would mean the version must be 1.7.
1.7* means anything at or higher than 1.7 but less than 1.8 (like 1.7.1).
1.7+ means anything 1.7 or higher (including 1.8).
If your code should run fine on Java 7 or Java 8, then you'd want "1.7+" to indicate you're not that picky about it.
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 found out that Java 8 is officially released now. It seems that I need Eclipse Luna 4.4 for it to work. So I downloaded Luna and installed it. I also imported all my projects from my other Eclipse, everything worked as expected. When I wanted to try Java 8, I quickly found out I needed to install it first. After I installed it I managed to change JRE 8 to the default.
My question is: Why can I use the new date & time API, but I cannot use the new Lambda Expressions?
Some info that might be useful:
I'm using a Mac
I'm very certain that the time API works (Even the small Java Doc Box says it's since 1.8)
Could it have something to do with the fact that I didn't install Eclipse with Java 8 included?
Firstly, you don't need to use Luna - there's a feature patch for Kepler which works fine.
Secondly, the "source compatibility" part of the Java Compiler dialog has to be 1.8. Otherwise even though you're allowed to use the library features of Java 1.8, you won't be able to use the language features. (It's not just lambdas - there's method references, static methods in interfaces, and default methods for example.) Here's where to look:
It would be rare that you'd want to use library features from 1.8 but keep source/classfile compatibility with 1.7 or earlier, but I guess it could be useful if you were writing code that needed to run on various JREs, but you could have some feature implementations which required Java 1.8 and just wouldn't be used on earlier JREs.
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