I tried to open the Groovy Shell (groovysh) on Windows 8 and got the following output:
java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs
at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
After printing the above message the shell started as expected.
Dennis answer is correct. However I would like to explain the solution in a bit more detailed way (for Windows User):
Go into your Start Menu and type regedit into the search field.
Navigate to path HKEY_LOCAL_MACHINE\Software\JavaSoft (Windows 10 seems to now have this here: HKEY_LOCAL_MACHINE\Software\WOW6432Node\JavaSoft)
Right click on the JavaSoft folder and click on New -> Key
Name the new Key Prefs and everything should work.
Alternatively, save and execute a *.reg file with the following content:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs]
I was able to resolve the problem by manually creating the following registry key:
HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs
This is actually a JDK bug. It has been reported several times over the years, but only in 8139507 was it finally taken seriously by Oracle.
The problem was in the JDK source code for WindowsPreferences.java. In this class, both nodes userRoot and systemRoot were declared static as in:
/**
* User root node.
*/
static final Preferences userRoot =
new WindowsPreferences(USER_ROOT_NATIVE_HANDLE, WINDOWS_ROOT_PATH);
/**
* System root node.
*/
static final Preferences systemRoot =
new WindowsPreferences(SYSTEM_ROOT_NATIVE_HANDLE, WINDOWS_ROOT_PATH);
This means that the first time the class is referenced both static variables would be initiated and by this the Registry Key for HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs (= system tree) will be attempted to be created if it doesn't already exist.
So even if the user took every precaution in his own code and never touched or referenced the system tree, then the JVM would actually still try to instantiate systemRoot, thus causing the warning. It is an interesting subtle bug.
There's a fix committed to the JDK source in June 2016 and it is part of Java9 onwards. There's also a backport for Java8 which is in u202.
What you see is really a warning from the JDK's internal logger. It is not an exception. I believe that the warning can be safely ignored .... unless the user code is indeed wanting the system preferences, but that is very rarely the case.
Bonus info
The bug did not reveal itself in versions prior to Java 1.7.21, because up until then the JRE installer would create Registry key HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs for you and this would effectively hide the bug. On the other hand you've never really been required to run an installer in order to have a JRE on your machine, or at least this hasn't been Sun/Oracle's intent. As you may be aware Oracle has been distributing the JRE for Windows in .tar.gz format for many years.
If anyone is trying to solve this on a 64-bit version of Windows, you might need to create the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Prefs
The problem is that simple console can't edit the registry. No need to edit the registry by hand, just launch the groovysh once with administrative priveleges. All subsequent launches work without error.
Had a similar problem when starting apache jmeter on windows 8 64 bit:
[]apache-jmeter-2.13\bin>jmeter
java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
Successfully used Dennis Traub solution, with Mkorsch explanations. Or you can create a file with the extension "reg" and write into it the following:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs]
... then execute it.
I was getting the following message:
Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002
and it was gone after creating one of these registry keys, mine is 64 bit so I tried only that.
32 bit Windows
HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs
64 bit Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Prefs
This happened to me.
Apparently it is because Java does not have permission to create registry keys.
See: Java: java.util.Preferences Failing
The problem is indeed the register key that is missing. It can be created manually
OR
it can be created automagically by running the program as administrator once. That will give the program the permissions required, and when it will be ran as normal it will still work correctly.
Related
I try looking online for solution, but couldn't find one. It my first time using codenameone , why does import java.util.Scanner doesn't work with codenameone project in eclipse?
I know the JAVA_HOME path is good and everything is updated.
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
This is a common issue with a freshly installed Java on windows, you can solve this by doing the following:
Go to your Start Menu and type regedit into the search field.
Navigate to path HKEY_LOCAL_MACHINE\Software\JavaSoft (Windows 10 seems to now have this here: HKEY_LOCAL_MACHINE\Software\WOW6432Node\JavaSoft)
Right click on the JavaSoft folder and click on New -> Key
Name the new Key Prefs and everything should work.
Alternatively, create a new file named java.reg with the following content and execute it:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs]
I met with this error when I used a package in R for loading data, in this package, pakcage rJava was used.
Every time I run a function, the error is
Error in ls(envir = envir, all.names = private) :
invalid 'envir' argument
This package has been proved without any problem, just some environment problem in my computer.
when I debugged, I found that in the last process before
ls(envir=envir,all.names = private )
the variable envir is NULL,which should be some value but not NULL I think.
After some trials, I kind of solved the problem, by installing rJava every time. And in addition, only when the error comes out, then I install 'rJava', it will work. If I install at the first, it won't work. So, I guess, installing 'rJava'(or probably installing packages), will cause some environment variables to change.
Either Java 7 and Java 8, including jdk or jre are tested, doesn't work. And for R, I am using the 3.1.3 R and all the packages are up to date.
Following is some information that I think may be useful for the troubleshooting.
By installing the package, jvm.dll needs to be added to the windows environment path: "Path" and I did that.
My sessionInfo is shown below:
R version 3.1.3 (2015-03-09)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=Danish_Denmark.1252 LC_CTYPE=Danish_Denmark.1252 LC_MONETARY=Danish_Denmark.1252 LC_NUMERIC=C
[5] LC_TIME=Danish_Denmark.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets methods base
other attached packages:
[1] rgdal_0.9-1 fields_8.2-1 spam_1.0-1 raster_2.3-33 sp_1.0-17 ecomsUDG.Raccess_2.2-6
[7] downscaleR_0.5-2 maps_2.3-9 downscaleR.java_0.0-2 rJava_0.9-6 gWidgetsRGtk2_0.0-83 cairoDevice_2.22
[13] RGtk2_2.20.31 gWidgets_0.0-54 R.utils_2.0.0 R.oo_1.19.0 R.methodsS3_1.7.0
loaded via a namespace (and not attached):
[1] abind_1.4-3 bitops_1.0-6 boot_1.3-15 CircStats_0.2-4 colorspace_1.2-6 dtw_1.17-1 lattice_0.20-30 MASS_7.3-39
[9] munsell_0.4.2 plyr_1.8.1 proxy_0.4-14 Rcpp_0.11.5 RCurl_1.95-4.5 scales_0.2.4 tools_3.1.3 verification_1.41
Thank you for any help you can provide.
Have u fully solved your issue? i had a similar issue just a few days ago, sorted it out and would like to share with the community. Actually those wrapper functions (in my case, Rbbg package) call rJava functions had a log file in your user folder under C drive, you could delete those log files as it will enable you to escape from the the error message.
In my case, I need to delete the blpjavaapi0.log.0 and org.findata.blpwrapper.0 files created by Rbbg package.
I need to use Grails 2.1.0 (specifically that version) and have installed this on Java 7 (ditto specific version) by extracting it to "C:\Users\new.username\grails\grails-2.1.0\grails-2.1.0" Unfortunately when I run grails I get an error as follows:
C:\>grails
Caching deactivated: failed to create cache directory: C:\Users\old.username\.grails
Exception: java.lang.RuntimeException thrown from the UncaughtExceptionHandler in thread "main"
This seems to show that either Grails or Java is picking up an old user name that Windows was created with and I need to know where this is being gotten from and how to change it to my current user "new.username" ?
I have looked through the registry and removed everything I dare that had old.username in it but am too scared to remove everything...
Any ideas ?
It's available in the environment, and you can access the values via System.getenv(). Both HOMEPATH and USERPROFILE point to my home directory when I tried this just now on a Windows machine, and my username showed up in USERPROFILE, LOCALAPPDATA, USERNAME, and APPDATA.
I recommend a ceremonial destruction by fire and the purchase of a Linux-based laptop, but not in that order.
I have a simplified program that produces the following output, in which the lines starting with ^ are generated by my code. Note that I deliberately deleted the Prefs key in HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.
^ A preferences file was found
Aug 09, 2013 2:45:23 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002.
Windows RegCreateKeyEx(...) returned error code 5.
^ doallunconditionally: false
^ footnotespopup: false
^ thumbnailsgenerated: true
^ thumbnailwidth: 200
^ pathin: C:/Users/Das/Google Drive
^ pathout: C:/Users/Das/ottmar/site
^ pathlog: C:/Users/Das/ottmar/logs
My question is, can I bypass the registry entirely? I thought I should be able to.
I can post the source code (180 lines) if needed.
I eventually discovered a workaround (not a solution) to this problem. As I stated before, I had inadvertently/foolishly deleted the Prefs node in Software\JavaSoft in the Registry, and when I recreated it the message went away.
I now assume that the Windows registry is used whether you like it or not.
This page explains how to use a preferences store apart from the Windows registry:
http://www.davidc.net/programming/java/java-preferences-using-file-backing-store
I've not tried it but it seems to be fairly straightforward. You can also checkout:
Is there a way to use java.util.Preferences under Windows without it using the Registry as the backend?
I encountered an error when my application tries to load a RSA Algorithm provider class from JAVA. The exception stack is as follow:
javax.jms.JMSException: RSA premaster secret error
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1255)
at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1350)
at org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:388)
at com.trendmicro.tmsm.TMSMAgent.open(TMSMAgent.java:63)
Caused by: javax.net.ssl.SSLKeyException: RSA premaster secret error
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:97)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:634)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)
at java.io.DataOutputStream.flush(DataOutputStream.java:106)
at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:167)
at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:237)
at org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:168)
at org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:84)
at org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:74)
at org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:715)
at org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:115)
at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)
... 22 more
I've googled the error message and most of posts says it's because JVM cannot find sunjce_provider.jar. However, I can find the file in /Library/Java/Home/lib/ext folder.
The platform is Mac OS X 10.6 and Java version is 1.6.0_17.
My questions are:
Why JVM does not search /Library/Java/Home/lib/ext for jar files?
Can we change CLASSPATH or java.ext.dirs property by modify any config file?
Any suggestion to solve this problem?
Thanks in advance.
I've had the same problem after upgrading to new Java version on Mac.
My (maven) project ran OK from command line but got the "SunTlsRsaPremasterSecret" error in Eclipse.
The solution was to remove Installed JREs in Eclipse configuration and add them again (using the "Search..." button).
had a similar issue. Adding the classpath to the ext directory fixed it for me. This fix worked for me on windows 7 with java 1.6
java -Djava.ext.dirs=lib -classpath "%java_home%\lib\ext\*" myapp.jar
I think we find the root cause so here is an answer of my own question.
the Java system property "java.ext.dirs" in Mac OS X 10.5 is:
/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext. The sunjce_provider.jar should be in /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext but also be found in /Library/Java/Extensions/ in the problem mac.
the sunjce_provider.jar in /Library/Java/Extensions/ belongs to Java Cryptography Extension(JCE) 1.2.2, which has been installed in the mac. JCE 1.2.2 is an optional package of J2SE 1.3.1 and may not includes enough libraries for J2SE 1.4 and later.
the Java applcation works normally after all JCE 1.2.2 related jar files have been removed from /Library/Java/Extensions/.
It happened to me while launching the tomcat server from eclipse. I solved it by changing the configuration in Windows -> Preferences -> Java -> Installed JREs -> Edit. I had to update all the JRE system libraries with the corresponding jars from the folders in:
%JAVA_HOME%/jre/lib/ext
%JAVA_HOME%/jre/lib/
It seems that after the last update I have changed the JRE_Home but forgot those libraries.
I also had this issue, noticed that the problem was in my Eclipse configuration.
Window > Preferences > Java > Installed JREs > jdk8_64bit > Edit...
The path of my sunjce_provider.jar was pointing to jdk8_64bit\lib\ext\sunjce.provider.jar. It should point to the JRE's equivalent in jdk8_64bit\jre\lib\ext\sunjce.provider.jar.
Had to spend almost a day on this while trying to use JavaMail in Eclipse Luna.
Tried all approaches suggested in various forums, but no luck.
Digged into the complete flow and found the exception arising due to Class is on BootClassPath
from KeyAgreement.getInstance()->JceSecurity.canUseProvider()->JceSecurity.getVerificationResult()->JarVerifier.verify()
void verify()
throws JarException, IOException
{
if (jarURL == null) {
throw new JarException("Class is on the bootclasspath");
}.......
I removed sunjce_provider jar from \ext\ folder and can send mail now.
This might not be right but atleast a quick workaround.
Refer Eclipse bug.
I know, I am joining late here. But for me, this error came suddenly as soon as I changed the Preference -> Java -> Installed JREs -> Execution Environments as JavaSE-1.8 to jdk1.8 path. But it should be jre1.8 path.
I don't know why is it happening now. But It sorted the problem.
Probable solution: Check if jdk path is set till C:\Program Files\Java\jdk1.8.0_171 but not including bin
In my case, I got above same issue, after reading above solutions, I changed JRE Definition and Restore Default. It is working fine now.