I intend to write private-use command line tools in java for use both on my private system (jdk 7) and on my universities number-crunching servers (jre 1.4). An attempt at installing OpenJdk from sources failed, because it is missing several dependencies, that simply wouldn't make sense on a computation server -- e.g. CUPS. The work required for installing such dependencies and THEIR dependencies would probably defeat the whole point of automating tasks, i.e. making life easier.
Being used to the conveniences of generics, I don't want to write 1.4 SOURCE code though. I found that, when compiling from the command line, options like
javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip \
-extdirs "" OldCode.java
are available (see [1]), which should allow compiling jdk5 or even jdk7 specific syntax to jdk1.4 compatible bytecode, as long as I stay clear of newer library features (which -bootclasspath is for).
This brings up two problems:
While I can set the compliance level for each project to a given java version easily in Netbeans 7.3, it forces me to use 1.4 syntax as well (probably by adding -source 1.4 to the command above).
I couldn't find an old jdk (specifically classes.zip) anywhere except for oracle.com, where registration is required for downloading those with the registration mask alone making quite clear that those are not meant for private use.
All related answers I found so far give no hint how to do this kind of bytecode/source-separated cross-compilation in netbeans and none address the issue of finding old JDKs.
Eclipse is not really an option, as there I couldn't figure out how to get automatic generation of JARs like in netbeans.
Any ideas?
Platform details:
Local (from Netbeans "Help → About"):
Product Version: NetBeans IDE 7.3 (Build 201302132200)
Java: 1.7.0_11; Java HotSpot(TM) 64-Bit Server VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_11-b21
System: Windows 7 version 6.1 running on amd64; Cp1252; de_DE (nb)
Remote:
java version "1.4.2_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.2_11-b06, mixed mode)
Update: Just to be sure -- it IS possible to compile source with new syntax to Java 1.4. E.g. I wrote this file:
class Target<T>{
public T field;
public static void main(String[] args){
System.out.println("Hello World!");
Target<String> target = new Target<>();
target.field = "More Worlds.";
System.out.println(target.field);
}
}
Then I compiled it with JDK 7 doing
javac -target jsr14 Target.java
and uploaded it to the computation server, where only JRE 1.4 (and no JDK at all) is present. It gave the expected output
Hello World!
More Worlds.
Apparently the "jsr" targets are an undocumented feature though, see e.g. [2]. Also that link mentions, that it is a bit of a hack, as only for-each loops for the Collections library will be handled:
for-each loop: When iterating over an array, the compiler generates an induction variable and the standard array iteration idiom. When iterating over a Collection, the compiler generates the standard iterator-based idiom. When iterating over a non-Collection Iterable, the compiler produces an error.
I guess that means, that I will have no choice but to attempt getting a newer JRE onto the server, if I want to use any reasonably modern features...
[1] How do i compile a .java with support for older versions of java?
[2] http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
JDKs aren't forward-compatible. That is, you cannot compile new features for old JDK versions. (or JRE for that matter).
Language constructs, such as generics, are if I'm not totally mistaken, part of the bytecode or interpreter in Java.
AFAIK you have only two options. 1) install new JDK or 2) write 1.4 source code.
Related
I've used JLink + JPackage to build a JavaFX app into a self-contained application. I'm using JDK 14. However, when I try to open one of my FXML files in IntelliJ's Scenebuilder I get this error:
File has been compiled by a more recent version of the Java Runtime (class file version 58.0), this version of the Java Runtime only recognizes class file versions up to 55.0.
To run the app in development environment, I use mvn clean javafx:run.
When I check in the IDE's compiler settings, the JDK is correctly set to 14, and so is the JAVA_HOME variable, as shown below. How do I fix this?
PS C:\dev> java --version
openjdk 14.0.2 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12-46)
OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)
I'd say the problem are your custom components. You have probably compiled them with Java 14 and put the resulting jars into SceneBuilder. So each time when you load an FXML file which uses one of these components you will get that error message because the class file version of your components is younger than the version of SceneBuilder itself. For compatibility reasons it would be a good idea to compile your components with a target 11 anyway. You can do that with your Java 14 compiler. This would increase compatibility in general and solve your problem at hand.
I think (I'm not 100% sure but it makes sense) there are 2 answer's to this...
Your intellij is using an older version of java (It can range from 6 to 13). So you would need to allow intellij to use a newer version of java (JDK14).
Build your application with older version of java, of course you might need to change some functions because of older version of java.
I am just learning Java. I compiled and created a jar file for a simple quiz game with a light GUI. All done from Ubuntu 14.04 terminal manually with 'javac -d ...' and 'jar -xvmf...'
Here are my version details:
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
javac 1.8.0_11
I followed a tutorial dealing with Java SE 5.0 for creating it, so I guess no new features from '1.8' were used. It compiled and it worked fine for me. When my friend who uses OpenJDK (latest version available) in Ubuntu 14.04 tried running it he received a lot of errors including Unsupported major minor ... 52....
I don't have the full verbose output from the terminal. Is there any way to avoid this and why is this happening though I didn't use use any new features specific to the latest version?
I thought Java was supposed to be "Write Once ,Run Everywhere", and compatibility issues with even the simplest of things with just a slightly little older version involved makes me rethink things!
The version of the byte code doesn't depend on whether you use Java 8 new features or not. It simply depends on which compiler you use. A Java 8 compiler will by default produce Java 8 bytecode, unless you use the option -target to specify an earlier version.
Side note: your friend is not using the latest version of OpenJDK (which is Java 8), otherwise, he would not get this exception.
I have installed Java 1.8 from Oracle on Ubuntu because I though it would be best, newest version compatible with previous ones. But it is not.
javac 1.8 produces bytecode runnable only on the java-8-oracle, scala does not run.
Before upgrade I was using java-7-openjdk, everything was fine. While
I can choose my older virtual machine using sudo update-alternatives --config java, but I also need to be able to choose older compiler.
How can I do this?
Use the -target flag to generate bytecode for earlier version. E.g. javac -target 1.5 FooBar.java.
There's no need to downgrade.
At least for Oracle's JDK (not sure about OpenJDK): install either the oracle-java7-set-default or the oracle-java8-set-default package, depending on which java version you want to be the default on your system.
You can get it from: http://ppa.launchpad.net/webupd8team/java/ubuntu (including the actual Oracle JDKs) See: https://launchpad.net/~webupd8team/+archive/java
Alternatively you could set the PATH and JAVA_HOME environment variables e.g. in /etc/environment
That said, when you compile you could specify the source and target level to 1.7, which would generate Java SE 7 compatible bytecode also when using JDK 8. But note it won't check if you're using some API not available in Java SE 7.
For this reason I recommend to use always the JDK version you target rather than doing some cross-compiling (which would need some additional extra steps to do it right).
Note however that you can install several JDK versions on your systems. IDEs usually let you choose which one you want to use during development.
Set up java_home environment variable to older version and compile Java files using it. Make sure that java.exe in path variable is of earlier version.
Use -target flag while compiling.
So I'm trying to get the latest version of Java. When I run:
java -version
I get:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
When I run:
javac -version
I get:
javac 1.6.0_65
Now I've just downloaded and installed JDK 8. When I go into System Preferences --> Java --> Update, I see:
Your system has the recommended vesion of Java.
Java 8 Update 05.
I guess I have a few questions:
1) Don't I want the JDK and my version of Java to match up?
2) Why does my Java Control Panel claim I have Java 8, but my work in the terminal (when checking my Java version) says otherwise?
Thanks for the help,
Mariogs
The probably "simple" answer is you have two versions of java installed. On the command line you currently use 1.6. Thus the old one is active. In system preferences you see the version of java 8.
Windows:
You can change the version of the command line to java 8. Set PATH environment variable and JAVA_HOME or via windows preferences. I recommend the first one.
Mac: /usr/libexec/java_home is the starting point for switching java versions on the command line. Check out this post to understand how to handle different java versions on the Mac. IMHO this answer is a good solution.
The Java Platform offers both the JRE and the JDK in order for users to run Java programs. The JRE stands for the Java Runtime Environment, and the JDK stands for the Java Development Kit.
The JDK is meant for Java developers - that is, those who build applications/write programs in Java. It contains tools that are needed for Java coding, including -javac to compile programs.
The JRE is meant for regular users - those who only need to run Java programs on their computer and are not interested in development.
The reason for the discrepancy in your case is because you're looking at the JRE and JDK and trying to compare the two. The current JDK that you have is Java 8, whereas the current JRE that you have is 1.6.0_65. It is problematic that your JRE version does not match your JDK version, but without your PATH variable or other information about your install, we can't help you fix your installation.
1) Yes, if you use the JDK at all, you want the JRE (runtime environment) to come from the JDK (development environment) (a JDK necessarily includes a JRE).
2) Likely your path variable is set so that you invoke Java from your Java 6 installation; you need to find the equivalent for your Java 8 installation and set the path for that. Without information about your operating system, we can't help you do that.
We should know the reason for this
Our OS comes with a predefined (built-in)set of tools and utilities. When we try to execute the command e.g. cls in the Windows command line then it is already present in system path variable and os will refer the corresponding binary of cls to execute the command.
However, when we install any third party tool/software then path variable is not updated accordingly.
When we install different versions of java on your system then installations go to different directories. E.g. JDK installation directory for Windows will be
C:\Program Files\Java\jdk1.8.0_161
Similarly, JRE installation directory for Windows will be JDK installation directory for Windows will be
C:\Program Files\Java\jre1.8.0_161
We need to update the path variable of OS to point to the appropriate directory. If we set the path of JDK then it will execute a binary from JDK bin directory.
Solution
we need to update JDK or JRE version specific directory location into PATH Environment variable.
Let me see if I can clear it up for you.
1)Yes, arguably you nearly want this to be true.
2)It could be few things, but most likely that a previous instillation was not properly removed. So one gets called instead of the other.
I have a project for school written with jdk 1.7. This application will be distributed to other groups and we want to document the necessary user system requirements. I'm assuming that the user will need the jre corresponding to jdk 1.7. Is this correct? Or what is the best recommendation for the user? The latest jre version?
JRE 1.7 + version will be good to use.
On a side note:-
It is nothing like that your Java 6 code will not run on Java 7 code. The difference is that the speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language but also the JVM (Java virtual machine). SO it would be an added advantage of speed if you choose to use the later versions.
Latest JRE version which will be 1.7+ is good.
JRE 1.7 version.
If you want to target, let's say, a Java 6 VM, then you can do that with the Java 7 SDK tools. You can specify which target VM you wish to support, but you have to know that a version 6 VM might not support all the features a version 7 VM will.
Note that if you use the -target and/or the -source options to javac, you may be able to compile with a recent JDK and run with an older JRE.