This question already has answers here:
Error - trustAnchors parameter must be non-empty
(45 answers)
Closed 1 year ago.
Is there a known difference or incompatibility of some sort between
cacerts file (or cacerts file format) when used under Oracle JDK/JRE 8 vs. Open JDK/JRE 8?
I mean... it seems we have a cacerts file which works OK with:
(1) Oracle JRE 8 (CentOS release 6.8)
but does not work OK with
(2) Open JRE 8 (CentOS release 6.10).
The Java version on system (1) is
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
while on system (2) it is
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
The error we get is this one:
java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty
Is that possible to be due to the JRE being different or am I completely off base and the issue is elsewhere?
I am not finding any good explanation on the web.
cacerts sees updates in minor version updates of java. There is no difference between oracleJRE8 and OpenJRE8. As a sidenote, JRE as a concept is obsolete, please transition away from them (if you(r company) wrote the software and are running it yourself, run it on a full JDK. If someone else did, advise them they are using an obsolete stack; they should be giving you the runtime instead of asking you to download and install one and keep it up to date).
A bunch of other stuff has been changed, such as the default format (instead of JKS, it's PKCS12), but that only affects what happens when you make new keystores without explicitly specifying which format it should be in (java could, and can, read either format, for all versions of java8) - so that doesn't sound relevant.
It boils down to: No, there is no difference. Whatever problem you have is most likely either related to your platform (for example, ubuntu has a bug where it borks up your cacerts. Long fixed, but maybe you're on that exact version, or you were when you ran apt and ended up with a broken cacerts). That or a million other reasons - no way to tell without more information.
Related
This question already has an answer here:
Where is JRE 11? [duplicate]
(1 answer)
Closed 2 years ago.
I have installed JDK 13.2. However, I cannot find a JRE in that version. I have tried to install the OpenJDK version of 13.2 as well. but still. I get the below, when i do Java - version.
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)
also When i do Javac -version. i get 1.8.0.241
Because of this old version some of the latest functions are not working, for instance, i have to use Array.listAs instead of List.of
I tired to remove and re add the whole thing from Environment variable, but to no avail.
any thoughts pls?
Check the list of entries in the PATH environment variable. Java 8 may be the first item in the list. You need to remove it, or move it down. After that, you need to close the command-line and open a new one. If you reuse an open command-line, you won't get the change.
I work on Rstudio running on a dedicated linux server. I get an error initialising h2o:
> h2o.init()
H2O is not running yet, starting it now...
<simpleError in system2(command, "-version", stdout = TRUE, stderr = TRUE): error in running command>
Error in value[[3L]](cond) :
You have a 32-bit version of Java. H2O works best with 64-bit Java.
Please download the latest Java SE JDK 8 from the following URL:
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
I checked the java config and got:
system("java -version")
openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)
Apparently I have the good version of java. I have found people with similar problems on Windows. They were able to solve the problem by finding and indicating the good java path. However in the environnement I am working in, i am not sure how to do that.
Any idea on how to solve the problem ? to bypass the error ?
Check if the JAVA_HOME environment variable is set. It may be pointing to the wrong spot, tricking H2O to find the wrong one.
You want JAVA_HOME/bin/java to be a good 64-bit java.
(The other thing you can optionally do is, when you do find a 32-bit java, uninstall it. There is no real reason to have it unintentionally anymore these days; memory sizes are much bigger than 15 years ago.)
So, I had always thought there was no difference between the java.exe located in the jdk\bin and that in the jdk\jre\bin folders. Apparently, that is not the case, certainly not with java8 anyway.
I was testing the maverick ssh library and found that it would not auto-negotiate an encryption cipher from the list offered by the sshd server when using the java.exe from jdk\bin. Changing the java.exe used to that from the jre supplied with jdk (in the jdk\jre\bin folder) let the test app work fine.
So... what could possibly explain the difference - why would one java.exe work and the other not, if they are both the same?
They appear the same on the surface:
C:\Program Files\Java\jdk1.8.0_20>dir bin\java.exe
08/22/2014 03:35 PM 190,856 java.exe
C:\Program Files\Java\jdk1.8.0_20>dir jre\bin\java.exe
08/22/2014 03:35 PM 190,856 java.exe
But must be different under the hood:
C:\Program Files\Java\jdk1.8.0_20>diff bin\java.exe jre\bin\java.exe
Files bin\java.exe and jre\bin\java.exe differ
EDIT:
I did review the question which is suggested as a duplicate, however it did not address my question.
The versions of the binaries appear the same:
C:\Program Files\Java\jdk1.8.0_20>bin\java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
C:\Program Files\Java\jdk1.8.0_20>jre\bin\java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
I did not adjust the classpath or anything else on my commandline, other than the path to java.exe.
Compared the two using WinMerge... there are a few diffs nr the start and end (moreso) of the two files. All binary gobble-de-gook to me.
Re using that library and getting different results, that's almost certainly not anything to do with java.exe, but something to do with the classpath and jars used by the JDK install vs. the JRE install.
Re your different files, it's not just you: I dug up a Windows 8.1 machine with (an old copy of) Oracle's Java8 on it, and it's the same thing: Sizes, dates, and versions match, contents don't quite. This isn't true of my Linux box with Oracle's Java8 on it, where the jdk/bin/java and jdk/jre/bin/java files are identical (and not just symlinked). My guess is it relates to optimization defaults, but doesn't relate to your ssh library issue.
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 am trying to get remote debugging working with Java on Solaris OS. Following is what I have tried-
I have a Java class called TestP which has the main method.
When I try
java -classpath . TestP
the program works fine. But when I try adding the debug parameters to the JVM-
java -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -classpath . TestP
It fails giving this error-
UTF ERROR ["../../../src/solaris/npt/utf_md.c":49]: Failed to complete iconv_open() setup
Can anyone please help me on figuring out why this error is coming up?? The above works fine on my Linux box.
Java version on Solaris:
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode)
Java version on Linux:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-20.b16.fc10-i386)
OpenJDK Server VM (build 14.0-b15, mixed mode)
Hmm... This seems to be a known Solaris (not specific to Solaris 10) issue with Java 6, not a Java issue (see this thread).
Someone has successfully applied a workaround (see this blog post) from a Sun guy, Jeff Moguillansky, but I wouldn't recommend it and rather consider searching sunsolve for a patch as indicated on Sun's forums.
Look at this one: http://sunsolve.sun.com/search/document.do?assetkey=1-1-6586755-1 (you'll need a Sun Online Account with a valid Support Contract or Software Subscription).
Using truss I found out that the process was looking for /usr/lib/iconv/geniconvtbl/binarytables/UTF-8%646.bt and 646%UTF-8.bt, so I just copied ISO8859-1%ISO646.bt to UTF-8%646.bt and ISO646%ISO8859-1.bt to 646%UTF-8.bt (yes, it is "646", not "ISO646"!)
This is of course a very ugly workaround and I have no idea if it has any negative effects on the JVM, but at least it starts the JVM without aborting. (I did this on OpenSolaris 2009.06, btw)
If Pascal Thivent is right, then you may want to try running OpenSolaris (either on a blank machine or in a vm) and see if the problem is also there. If not, then consider using that version for now if possible.