I am interested in running JBoss AS with the 32bit OpenJDK on a 64bit OS. I am struggling to find simple instructions on this on the web. I popped into the OpenJDK IRC technical help channel, and the only response to this I got was that someone tried it on Fedora 15-17, with much frrustation.
Using default repos, for both 64bit CentOS and 64bit RHEL, "yum search openjdk" produces only .x86_64 results. Instead of .x86_64, I am interested in laying down the 32bit version of OpenJDK on the 64bit OS .i586,.i686 or whatever it might be. Explicity searching for the same package name but using i586/i686/etc does not turn up any installable packages :-/
Is there a reason why you want to go with the 32-bit OpenJDK and not the 64-bit? Usually, the only reason to go with 32-bit is that your Java app needs to interact with native libraries that are available only in 32-bit.
You could try installing 32-bit Fedora or RHEL in a VM and then copying the JDK directory to your 64-bit machine (I have copied JDK directories between machines for years without issue- that's how I can still run 1.3.1!). Of course this will only work if you have 32-bit versions of the various system libraries. (That is sort of a given on Windows, not sure if a 64-bit Linux install would have the 32-bit libraries also.)
There is a slight memory benefit to using a 32-bit JDK when using smaller heaps, mainly because the references are 32-bit and not 64-bit. But if I recall correctly, there is an option you can use on a 64-bit JDK to get it to use 32-bit references (and consequently also restrict the size of the heap you can get), though that option is probably only relevant for the Oracle JDK and not OpenJDK (you could check the sources and see, grep the sources for an existing -XX option - you should get one hit, and all of the options are in that same source file). Personally, I wouldn't attempt the hassle with running a 32-bit OpenJDK on Linux, I'd just go with the 64-bit.
I recall something similar about using 'compressed references' to improve the small heap performance of 64bit, too. Regardless, it looks like just matching bits is going to be easier in my case. Thanks again.
If I run a Java application with oracle-java-8 in an X session, the windows and fonts are all normal size. When I run the same application with openjdk-11-jre, everything is scaled up to double size (see attached image, which shows an application on the left running in Java 8 and the same application on the right running in Java 10 (from the package openjdk-11, not openjdk-10 for some reason).
I've attached a comparison of xrandr's output for Wayland and X11. In Wayland, it only shows the currently configured resolution, whereas in X11 it lists all available resolutions and flags the current one with an asterisk.
It looks like the code in src/java.desktop/unix/native/common/awt/systemscale/systemScale.c is reading the dconf /com/ubuntu/user-interface/scale-factor value to determine scaling and using the highest setting. When openjdk is drawing windows too large, this is the value:
It seems to be related to Unity according to the few Google results I can see, so the question is whether a package failed to remove/move that setting or if OpenJDK should change what it looks at and/or in which order.
I did notice that when it was reading the scaling factor of 16 for my laptop monitor and drawing the windows double-size, they stayed double-size when I moved them to the external monitor (with a scaling factor of 8), so openjdk is not taking individual monitor scaling into account.
Installing multiple Java versions in parallel is incredibly easy in Windows. You can download and run the installer for each version, which automatically installs the versions in separate directories.
These variables should always point to the same Java installation to avoid inconsistencies. Some programs, such as Eclipse, define the Java version in a separate configuration file (for Eclipse, for example, this is the entry "-vm" in the eclipse.ini file).
The scripts update the JAVA_HOME environment variable and insert the bin directory at the beginning of the Path variable. That makes it the first directory to be searched for the corresponding executable when you run Java commands such as java or javac.
If you have installed the latest releases of all Java versions, you can use the scripts without any further adjustments. Open a new command line or PowerShell and enter, for instance, the following commands:
If one of the commands does not activate the expected Java version, please check if the path in the javaX.bat and javaX.ps1 files corresponds to the installation path of the Java version you want to activate.
The commands presented up to this point only affect the currently opened command line or PowerShell. As soon as you open another command line, the default version defined in step 2 is active again (Java 22, if you have not changed anything).
Attention: To set the Java version permanently, you must open the command line or PowerShell as an administrator. Otherwise, you will get the error message "ERROR: Access to the registry path is denied.
I did this and now I can use command prompts to switch between versions as verified with "java -version" BUT I still cannot get my browser based interface to function correctly on the version 6. It DOES function correctly if I uninstall all Javas and reinstall just 6. Does this method not work for browser based applications?
Hi Daniel, the scripts from the first version of this article worked only in the command line, in which you executed them. The latest version of the article now contains additional scripts to change the user and system defaults (see chapter "Temporary, Permanent and System-Wide Java Version Changes").
Or are you speaking of Java applets? Support for applets has been removed with Java 11, and I haven't worked with them in years, so I don't know if there's a way to change the Java version used for applets.
I had to move the %JAVA_HOME%\bin to the first option in the PATH as before when it was last in the list of values, when I ran java -version in cmd, it reported java 1.8 instead of java 1.6 which did show when I ran: echo %JAVA_HOME%
UPDATE: I have uploaded a new version of the scripts. Instead of "javaversion-user" and "javaversion-system" you now have to call "javaversion perm" to change the version permanently (see section "Temporary and Permanent Java Version Changes"). The new version is also more reliable than the old one.
Hello everyone.
First of all thanks for the script.
In my case the change of jdk worked but each time a new terminal was launched the default jdk came back ...
As a result, I modified the script so that now with each change, the jdk selected by script is 'saved'. You have to add the REG (be careful , only in one line) line as below by adapting the right path of the jdk to your configuration:
I've tried with this :
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment" undefined v "JAVA_HOME" undefined t "REG_SZ" undefined d "C:\Program Files\OpenJDK\openjdk-8u262-b10\" undefined f
But the commande is not working. do you see something wrong here ?
I didn't set it up on the Windows 10 Server but I think that when it starts as a service using Tomcat9.exe it is ignoring the environment variable and using the -auto option to locate the JVM in the registry. I am not a Windows aficionado so I am not sure what the registry key would be and there are only about 1500 of them.
This has been one of the most fruitful topics I have read and implemented in a long time. This problem of working on multiple Java versions simultaneously has been haunting me for a long time. The solution provided is cute, simple and it is going to save several hours of misery for me. Thanks
nice solution for switching versions, i was trying to merge all the version scripts in one bat file but and added a if else statement i am not able to run that bat file by default in my command prompt. Any idea
I'm trying to switch between Java 8 and Java 16. In the terminal I use the commands in ("java8"/"java16"), it confirms that my version has been switched, but as soon as I close and open a new terminal, it is still the version I tried to switch off of. I have very little experience with this stuff, and any help would be greatly appreciated.
Hi Chase, you can use the recently added commands "java8-user" and "java16-user" (for example) to set the Java version permanently for your user account (see the newly added section "Temporary, Permanent and System-Wide Java Version Changes").
UPDATE: I have uploaded a new version of the scripts. Instead of "javaversion-user" and "javaversion-system" you now have to call "javaversion perm" to change the version permanently (see section "Temporary and Permanent Java Version Changes").
This is fine, however, the script doesn't work properly with -user suffix, given, my computer seems to be special in how it does things. The user variable Path has one value, and it goes to %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
If there is a better value or values for it, please respond with such or at least one for JAVA_HOME variable for User to work.
Hi Evalyne, I have uploaded a new version of the scripts. Instead of "javaversion-user" and "javaversion-system" you now have to call "javaversion perm" to change the version permanently (see section "Temporary and Permanent Java Version Changes"). The new version is more reliable than the old one, let me know if it works for you.
c80f0f1006