Will installing different version of JRE in one server causes instability? - jvm

I am writing a java program using JAVA 6. Our company server is using JAVA 5. They refuse to upgrade it to 6, so the workaround would be install another JRE 6 inside the same machine. They wonder, will installing different version of JRE causes instability?
What the installation process do? Simply copy over the files and setting up environment variable? Will it change any registry or other setting?

Multiple JREs can reside on the same machine. However, if you install JRE6, that's the same as upgrading to Java 6. Java 6 is (as far as I can tell) able to run all older Java code. However, Java 6 binary (.class and .jar files) can not be executed using Java 5, unless they were compiled to target the previous version.
If you need to, you can target Java 5 using a Java 6 JDK. There are command line arguments for javac that you can use (or incorporate into Ant, and probably other build tools) to specify a target JRE. For example, if you used the -target 1.5 command-line option using your JDK, the .class or .jar files that are produced will be executable using the Java 5 JRE.
It's been a while since I have ran two JREs side-by-side, but unless things have changed, there will be two separate java.exe (on Windows, anyway) files - one for the previous Java 5 JRE and a new one for the Java 6 JRE. Due to naming, only one can be in the path at a time - all of the files have the same names, so you can't include the Java 5 and Java 6 java.exe at the same time and expect the right one to magically run. However, you can leave the Java 5 JRE in your path and manually invoke the Java 6 java.exe when you execute your application.
If you use JAVA_HOME set to the Java 5 JRE and set a new environment variable to the Java 6 Java Home, let's say JAVA_1.6, as long as you properly reference the right environment variable, you should be fine.

You can definitely have both. If you are "allowed" maybe you could bundle the jre you want with your app? This URL talks about how..
http://forums.sun.com/thread.jspa?threadID=708451

Related

Deploying self contained Perl 6 script

What is the best strategy to deploy a Perl 6 script which use external modules like LWP::Simple?
For example in Perl we have PAR. Is there are an option in Perl 6 to deploy a self contained script that the user need only to run without bothering himself with installing Rakudo and external Perl 6 modules?
You can create a .jar file and then use java to execute the code. From there, there are plenty of tools to convert a .jar into a binary file (or .exe in Windows).
The syntax for that is:
perl6 --target=jvm --output=your_file.jar your_file.pl6
If that script were the trivial
say "this is running as a .jar file"
You should be able to run java -jar your_file.jar and get
this is running as a .jar file
On macOS, there is a bit of a wrinkle since this feature requires you to build perl6 (Rakudo Star) with Java 1.7+ instead of the Mac's system Java. For this reason the version on your system may not have shipped with JVM support.
If you're using homebrew, here's what you do to fix that:
brew uninstall perl6
brew tap homebrew/versions (so you can install Java 1.7)
brew install Caskroom/versions/java7 (install Java 1.7)
optionally: open a new tab in terminal (you only need to do this if, for some reason, you get an error that Java 1.6 is still in use. )
brew install perl6 --with-jvm (build perl6 with Java Virtual Machine support)

Error while running Jprofile8

I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.

Using Java 8 runtimes compiled against Java 7 [duplicate]

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.

iReport 5.5.0 won't start

I want to use iReport on ubuntu 12.04. When I try to start it, it stands still and just gives me this error:
Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library /tmp/jna4023560596826437553.tmp which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
How can I solve this problem ?
Edit: I tried: execstack -c /tmp/jna4023560596826437553.tmp but that didn't help.
This error seems more related to a JVM problem instead of jasper. Indeed, Java 7 on linux has a feature which blocks code written in C (or other languages like Ruby etc) and linked into Java (the so-called Java Native Interface - JNI) from halting the whole VM if it’s written badly or maliciously.
So, if you're using java version 1.7, getting back to 1.6 should do the trick. But if you want to keep this version, then try a clean uninstall and re-install of java:
Uninstall,
Install
Notice that if you're not running on 1.7 , it could be a compatibility problem. Try to match the right jars required for iReport to get it work on linux.
I'm using ubuntu and I did below,
Opened the ireport.conf
and uncomment jdkhome
and added java 7 paths (since my default is java 8)
jdkhome=/home/bhanuka/Apps/jdk-7u80-linux-x64/jdk1.7.0_80

java glassfish jdk 7 jre 6 version conflict

Downloaded JDK 7 from Oracle Java (comes w Glassfish) and installed on a Windows 7 machine.
In the shell, when I issue these commands:
javac -version
java -version
... I get two different versions. The compiler seems to be Java 7 but the JRE appears to be Java 6. Obviously this is a problem because programs compiled in Java 7 throw exceptions when run in Java 6 JRE.
Question 1: why does a JDK have different versions for the javac.exe compiler and the java.exe?
Question 2: how is it expected to be setup to work?
Question 1: why does a JDK have different versions for the javac.exe compiler and the java.exe?
It doesn't. You already have a Java 6 JRE installed and this is in your PATH before the JDK 7's bin directory. Remove the JRE 6 bin directory from your PATH.
Question 2: how is it expected to be setup to work?
Make sure the bin directory of your Java 7 JDK is in the PATH and not the Java 6 JRE bin directory.
See the JDK Installation Guide, especially the part Updating the PATH Environment Variable.
You need to check you JAVA_HOME environment variable and make sure it points to the correct JDK, then check the 'path' environment variable and make sure you don't have duplicate jre/jdk paths there.