We Keep Coding

Cannot run Apache Netbeans 11 using JDK 11

No matter what I do, I can't get Netbeans 11 to work with JDK 11. Can you help me out?
Please note that this issue does NOT occur with JDK 8.
Downloaded and installed JDK 11 to C:\Program Files\Java\jdk-11.0.4
Downloaded and unzipped Netbeans 11 to C:\Program Files\netbeans
The etc/netbeans.conf file has been edited to set JDK home:
netbeans_jdkhome="C:\Program Files\Java\jdk-11.0.4"
When trying to run bin/netbeans64.exe:
First time: The loading window appears, loads for a bit, and then the
whole program disappears.
Second time: Loading window does not appear. An empty Java application
appears.
If I go to Task Manager and manually end the Netbeans process, I can
get back to First time.
For the attachments listed below, please refer to the issue I created here:
https://issues.apache.org/jira/browse/NETBEANS-2865
Executing netbeans64.exe from PowerShell outputs error messages to the console. They can be found in consoleOutput.txt attachment.
The results from executing bin/netbeans64.exe --trace C:\netbeans.log can be found in netbeans.log attachment.
For reference, this is the tutorial I followed:
https://www.youtube.com/watch?v=cxh-hVty09g
Update & Solution
I FINALLY got it to work thanks to the answer provided by skomisa.
The issue was caused by Netbeans 11.0 importing settings from a previous version. There was a popup the first time I ran Netbeans 11.0 asking if I wanted to import my settings from a previous version. Refer to skomisa's answer for more details on why.
To solve it, I deleted ALL of the preference files for NetBeans 11 by deleting the entire folder in AppData.
C:\Users\Hunter\AppData\Roaming\NetBeans\11.0\
Skomisa's answer mentioned trying to create a new unzipped version of NetBeans 11 and not importing the settings. I had actually tried this previously, but never got the popup window asking if you want to import. I assume this is because the user preference files for this version of NetBeans have already been created and are still sitting in AppData.
This leaves you with two viable options:
Delete all of the user preference files for NetBeans 11.0.
Search through the entire folder for instances of \u0000 and remove them.
It seemed easier and more satisfactory to remove the entire folder and start from scratch. That way, all of my user preference files are using the newest practices accepted by the JDK and Netbeans and that, hopefully, there is no lingering legacy code that will randomly break the next time I update.
Thanks for everyone's help!

Your problem appears to be related to the IllegalArgumentException ("Key contains code point U+0000") in the console log output of your bug report. It looks like NetBeans is trying to import your preferences from an earlier release of Netbeans, and is is finding some invalid null character(s) in your preference file(s).
This has been bug reported before, but remains unresolved. See Bug 271652 - IllegalArgumentException: Key contains code point U+0000.
Your preference files are all XML files (with extension xml), and reside in various directories under C:\Users\user ID\AppData\Roaming\NetBeans\11.0\config.
In my case my only preference file for NetBeans 11 is named C:\Users\johndoe\AppData\Roaming\NetBeans\11.0\config\Editors\text\x-java\Preferences\org-netbeans-modules-editor-settings-CustomPreferences.xml but you may have more than one.
From the stack trace in your console log, the failing call is AbstractPreferences.getBoolean(), so the null is probably on a line containing Boolean in your preference file. However, as this somewhat related SO answer suggests, just blindly remove all nulls from all preference files. Nulls should never exist in any XML file anyway.
An alternative approach to solving your problem is to create a new unzipped version of NetBeans 11, but do not import your settings.
I suppose you could even locate the preference files in your existing (broken) NB 11 installation and delete them, though that seems like an unsatisfactory approach even if it works.
A few related points:
Seeing the NetBeans window appear briefly before it vanishes is often a symptom of having set netbeans_jdkhome to an invalid JDK path, but in your case the value looks fine.
JAVA_HOME is ignored by NetBeans, so that cannot be the cause of your problem. See the response to Bug 198950 - NetBeans should use the JAVA_HOME and JDK_HOME environment variables, if available, to determine which JDK to use for details on how NetBeans decides which JDK to use. Specifying the --jdkhome parameter when you start NetBeans will override everything else.
The IllegalArgumentException only arises with JDK versions >= 9 because of a JDK bug fix, but that's a good thing. See JDK-8075156 : (prefs) get*() and remove() should disallow the use of the null control character '\u0000' as key for details. You weren't getting the problem with NetBeans 8.x because you probably weren't ever importing any preference files, but even if you were the IllegalArgumentException would not have occurred due to the Java bug fixed by JDK-8075156.

"java.exe" exited with code 2 Xamarin.Android project

so I have my Xamarin.Android project which contains several libraries. When I try to build I receive an error which says "java.exe" exited with code 2.
After some hours of google research I found out that I could enable Multidex.
According to the blog entry of Jon Doublas I did the steps mentioned.
http://www.jon-douglas.com/2016/09/05/xamarin-android-multidex/
According to the blog entry Android API Level > 21 handles Multidex itself.
Well my experience is that it does not. I am building on API Level 25 and get the same error again and again with the same information.
The steps in the article do not help. It seems like Xamarin.Android does not support Multidex.
It seems like you have to handle Multidex by yourself but I haven't found any solution which is working. Dos anybody found a solution which works?
I am using Xamarin 4.6 and Visual studio 2017.

Found the answer after about 20 hours of searching in my project..
So here are the steps to resolve the problem "java.exe" exited with code 2
1) Change the MainDexClasses.bat as described in the link:
http://www.jon-douglas.com/2016/09/05/xamarin-android-multidex/
2) Make sure you have enabled Multidex Option in your Android Application! Have a look at the .csprj file if Multidex is set to true (in my case it wasn't even if I enabled Multidex)
3) Add the following part in your AndroidManifest file
<application android:name="android.support.multidex.MultiDexApplication"></application>
This will tell your Android project to actually use the Multidex-Option given.
After a clean and build I was able to run my application as it is.

After finding this question and #Daniel_97s answer I was able to solve this error only by adding multidex to the project without changing MainDexClasses.bat:
Check the option in Project Options:
Add MultiDexApplication to Android Manifest:
<application android:name="android.support.multidex.MultiDexApplication"></application>
Note I was getting this error code 2 on Visual Studio for Mac and on Windows the same app was building successfully. (why?)

The solution in my case was to disable the "Sign the .APK file using the following keystore details". Because the keystore location and/or password was incorrect, java.exe exited with code 2.

I only go to option > Build > Android Build and check Enable Multi-Dex it will resolve

My .csproj file had an entry for the KeyStore that was no longer valid, even thought right-clicking the project and inspecting the properties indicated that I had pointed it to the new location.
Within .csproj look for all instances of <AndroidSigningKeyStore> and update accordingly.

I've struggled with this issue for quite a long time. I found source of the error in signing - as I cloned project repo from company TFS, Android csproj file had entries for KeyStore settings and location. I didn't have the keystore and the location on my drive was invalid. Visual Studio is then unable to sign the app while deploying and instead of some sort of FileNotFoundException it gave me just java exited with code 2. So...
tl;dr: Go to android project properties, select package signing a uncheck "Sign the apk file..." (which changes csproj <AndroidKeyStore>true</AndroidKeyStore> to false) and voila, you can now run your solution.

Reassign the path of the keystore worked for me
==EDIT 01==
Double click on Android Project > Android Package Signing
On the Keystore path, don't know why but apparently the path was wrong, I re-select the .keystore file again from the same path, and the error "exited with code 2" went away and I was able to Archive for release

Disable sign the .APK file using the following keystore details as #Klemikaze

I had this error when switching from VS Mac to VS Windows.
Here the topic Switching From VS Mac To VS Windows got “java.exe” exited with code 2
The issue was comming from the Android.csproj and the Keystore Path.
It was set to my Mac Path even if I changed it on
VSWindows AndroidProject => Properties => Signin
So I removed this lines on Android.csproj (edited with third text editor):
<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>YourMacPath/Alias.keystore</AndroidSigningKeyStore>
<AndroidSigningStorePass>Password</AndroidSigningStorePass>
<AndroidSigningKeyAlias>Alias</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>AliasPassword</AndroidSigningKeyPass>
On debug & release Part.
Then you can edit them on VS Windows.
Hope I helped someone.
See ya

In my case this was link to the "Sign the .APK file using the following keystore details" option as Hein Andre Grønnestad mentioned.
The location was not correct.
I wanted to put a path that could work for everyone at work so I used $HOME/Library/... instead of /Users/Me/Library/...
The problem is $HOME doesn't mean anything special for java so the keystore file could not be found.
Solution: use relative path or absolute path without $HOME variable or ~

For me, it was a problem with my Keystore. Follow this link to enable diagnostics. This will give you a more detailed error message in the output window. If it says that your keystore failed to verify, you will have to fix your keystore. This solved the problem for me.

In my case solved the problem by signing the .APK whit the values signed into the keystore that we configured to create the APK file in Release mode.
I taked the Microsoft example in here
and here I put the same values
That way a solved my problem with
"java.exe" exited with code 2
But the real information problem was in output:
Failed to load signer "signer #1"
java.io.IOException: Invalid keystore format
At the moment I don't find the real solution to this problem but, this works.

Please Update your Visual Studio to Latest version, if you are still using an old version.
If you think there is no solution then go and enable the Multidex

In my case the one of keystore details was wrong, after saving-> cleaning -> building process it worked.

Try reset the keystore <AndroidSigningKeyStore> or change to false the key
>
<AndroidKeyStore>true</AndroidKeyStore>
Only to check. But remembering that it needs to be set to true.
After Clean and Rebuild the solution.

For me it turned out I had Eclipse Temurin JDK installed and that was being used. In VS Tools>Options>Xamarin I changed the path to Java Development Kit Location to from the Eclipse path to C:\Program Files\Microsoft\jdk-11.0.12.7-hotspot.
Maybe more importantly, I discovered Eclipse Temurin JDK was being used by running:
msbuild /bl /t:"Restore;SignAndroidPackage"
in my solution dir and then opening the resulting msbuild.binlog and clicking on the few errors and a path with Eclipse stood out. Your problem may be different but finding it this way may be the key to solving it.
EDIT: My settings don't stick after closing and reopening VS 2019. At this point I started using VS 2022 and don't have the issue.

Note: Multi-dex is enabled.
After 5 hours of looking or an answer, this is the conclusion I've found -
Enable diagnostic MSBuild output within Visual Studio, so you can see more details about your error:
Click Tools > Options...
In the left-hand tree view, select Projects and Solutions > Build and Run
In the right-hand panel, set the MSBuild build output verbosity dropdown to Diagnostic, Click OK
Clean and rebuild your package. Diagnostic output is visible within the Output panel.
If your error shows "java.io.IOException: Invalid keystore format", you are probably using an outdated Java sdk file, so do next:
Open Visual Studio and update the Java Development Kit Location to
point to the new JDK under Tools > Options > Xamarin > Android
Settings > Java Development Kit Location:
Be sure to restart Visual Studio.

My experience is...
I updated the following elements:
Xamarin.Android.Support.Design
Xamarin.Android.Support.v4
Xamarin.Android.Support.v7.AppCompat
Xamarin.Android.Support.v7.CardView
Xamarin.Android.Support.v7.MediaRouter
from 26.1.0.1 to 28.0.0.3
Then, after it started the issue with:
"java.exe" exited with code 2 Xamarin.Android project.
I just ticked the Enable Multi-Dex inside the Android project property. I am using VS 2017 in windows system.

Why is Visual Studio trying to use the wrong JDK version?

I am trying to build WeatherApp, which comes from this tutorial, but I am seeing this error:
The specified task executable location "C:\Program Files (x86)\Java\jdk1.7.0_55\bin\javac.exe" is invalid.
and this warning (not sure if they are related):
Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="System.Runtime" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" /><bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /></dependentAssembly></assemblyBinding>
I can doube-click the warning to make it go away, but the error remains. I am not sure why the project is trying to use that version of the jdk, as I have changed my xamarin optioins to point at Program Files instead:
Why is Visual Studio trying to use that versioin of the JDK?

Sometimes there's a sdk.caches file that will hold an old reference. Please try to delete both your obj/bin folders and see if that resolves the issue. If it doesn't, turn up your Build Output verbosity and attach a Build Output Log to your post:
https://forums.xamarin.com/discussion/27515/how-to-obtain-diagnostic-build-logs (XS)
http://blogs.msdn.com/b/msbuild/archive/2005/09/29/475157.aspx (VS)

Java popup saying applications contains both unsigned and signed code

I am using Mac 10.7 running Java 1.7.0_21. I am trying to run a Java applet application that is signed and towards the end of the application I get a mixed mode security popup saying "Block potentially unsafe components from being run?". All the jars that I am using are signed.
I am able to run the same applet application on Mac 10.6 running Java 6 and I don't get the mixed mode warning. I am also able to run the application on windows without the mixed mode warning coming up.
Why do I get this keep getting this error when all my jars are signed?
I googled mixed mode warning and found this link.
http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#manifest
and after reading this link, I am a little confused. According to this link it looks like I need to have either "Trusted-Only" or "Trusted-Library" attribute mentioned inside my manifest file. I looked at my manifest file and they don't have these attributes so should I put them in or just the fact that the jars is signed should have been enough.
Can someone please help me understand why I am getting this error even when everything is signed?

Update 21 of Java 7 is a strong security update that brings a certain number of breaking changes.
You should have a look to its release notes, there are two paragraphs and two known issues related to signed jars.
Your problem consists in this one:
Area: deploy/plugin
Synopsis: Security popup while closing application
Starting in JDK 7u21, JavaScript code that calls code within a signed applet running with all permissions is treated as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute. See Mixing Code With Permissions and Code Without Permissions(doc link)'.
For a signed applet running with all permissions to JavaScript call, no security dialog (with mixed code warning) should pop up. However mixed code warning is being shown in some scenarios.
The good news: there is a workaround:
As a workaround, if the applet jar is running with all-permissions and uses "Trusted-library:true" attribute as manifest entry, the mixed code warning will not popup.

The best fix is using the Trusted-Library=true, however, if you cannot get this to work for some reason you can also change how the computer handles mixed security applets.
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html
Create the follow file on the user's workstation. C:\Windows\Sun\Java\Deployment\deployment.properties
In the file add the following line:
deployment.security.mixcode="HIDE_RUN"
This will tell Java to hide the security warning and run the applet whenever there's a mixed code condition. Also, on the release notes it says:
As of JDK 7u21, JavaScript code that calls code within a privileged
applet is treated as mixed code and warning dialogs are raised if the
signed JAR files are not tagged with the Trusted-Library attribute.
For more information, see Mixing Privileged Code and Sandbox Code
documentation.
The JDK 7u21 release enables users to make more informed decisions
before running Rich Internet Applications (RIAs) by prompting users
for permissions before an RIA is run. These permission dialogs include
information on the certificate used to sign the application, the
location of the application, and the level of access that the
application requests. For more information, see User Acceptance of
RIAs.
FYI, JRE 6u19 if an applet contains both privileged components and sandbox components, warning dialogs are shown.

I also have an applet that generated this security warning starting with JRE 1.7.0_21.
Here is what I have learned. The "Trusted-Only: true" you would put in your applet manifest if you do not want the user to be asked if he will allow the call to another signed jar. The call will be blocked without the security warning. The "Trusted-Library: true" you add to the jar that you are calling. If this is in the jar's manifest and the jar is signed then when your applet calls it there will be no security warning and the call will not be blocked.
My applet uses the swing-layout-1.0.4.jar. To solve the problem I had to add the "Trusted-Library: true" to the swing-layout-1.0.4.jar. You should be able to do this by using the jar.exe application in the JDK.
jar vcmf swing-layout-1.0.4a.jar MyManifest.mf swing-layout-1.0.4.jar
MyManifest.mf is a text file containing "Trusted-Library: true". The space between the : and true is important and you must have a carriage return at the end of the line.
For some reason I could not get this to work so I rebuilt swing-layout using netbeans. The sources for swing-layout-1.0.4 are part of the netbeans install (under platform). I unzipped it opened it as a project. Under files I changed the manifest file to have the magic line (again it is important to have the space after the : and a blank line at the end of the manifest file) and hit the build. I then signed the jar and no more security warning.
I hope this helps or at least points you in the right direction

Thank you all for your replies. I tried adding Trusted-Library=true on a small sample and it seems to work. So now I will be trying to trying update the manifest file of all my jars. And since we use ant I will doing the following
<jar update="true" jarfile="${deploy.dir}/javaApp.jar">
<manifest>
<attribute name="Trusted-Library" value="true" />
</manifest>
</jar>
to update the manifest files.

Incompatible magic value 1008813135

I am writing a Java applet and embedding it in a web page.
It used to run Mac and Windows in different browsers without problem.
I was using NetBeans on the Mac to build the .jar file the applet used.
For some reason or another I decided to load the project on the Windows' NetBeans - I started getting the following error on the Windows machine when accessing the web page from any browser:
java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file
Fearing that it must have been my decision to open the project on Windows that caused this error - I tried to build from the Mac's NetBeans - but the error persisted.
I started a while new project on the Mac and imported the existing source code: still same problem.
I was doing some reading about this error and it seems that the magic number expected is 0xCAFEBABE in hex which is 3405691582 in decimal, not 1008813135. So it looks like the Mac version of Java doesn't produce this file header any more? Hoe can that be? I didn't do any updates or anything.

Yes, 0xCAFEBABE is the usual first 4 bytes of a Java file.
1008813135 is <!DO in Latin encoding, which is, in all probability, the start of <!DOCTYPE....
It is therefore likely the start of a 404 error, or some other error page.

I have not experienced this problem, but Googling this error yields several possible solutions:
forum.sun.com - Java Applet Development - Incompatible magic value 1008813135 in class file MyApplet
Thanks God the problem is solved.
Its the Java cache, so the solution go to Java Control Panel, "General" tab, and under "Temporary Internet Files" click "Settings", then click "Delete Files". Try using the applet again.
"Incompatible magic value 1008813135" Error?
The problem is now solved: I found out that the website host I was using didn't support .jar files at all. I mass-uploaded the files with my ftp program and didn't notice that it ignored the .jar files completely.
Errors on java initialization
Alright, so it was an apache configuration issue, removed this line from my httpd.conf file:
# DefaultType application/x-httpd-php
Fixed the issue.

If you are using Spring security or some sort of custom Servlet Filters, make sure, that the archive or codebase location is in "permitAll" access. This was to problem in my case

I was facing the same problem.The reason in my case was all dependency library that Applet uses was not signed and also applet not able to locate them.
So i Have added all the dependent library along with main applet in jsp file like below :
app.archive = '/esense/resources/lib/Applet.jar, /esense/resources/lib/jasypt-1.7.jar, /esense/resources/lib/mysql-connector-java-5.1.30.jar, /esense/resources/lib/runtime-api-1.0.jar';
I have also signed all the jar.
Hope this may work in your case.

The incompatible magic number is the first four bytes of a html file that has some error message in it, probably a message that the file isn't found.
I encountered this phenomenon when I didn't take case sensitivity into account in the codebase element of the applet tag. Things worked well on Windows, but the internet server I was using was running UNIX where filename case sensitivity is important. Making the case of all file and directory names in the code and codebase elements solved the problem.

I just clicked on maven->update project->include snapshot release in my spring boot and it worked.