I'm dealing with the same sort of problem as "Zombie http.proxyHost settings for JVM on OSX" except I'm on Kubuntu 8.04 and Eclipse 3.4.2. I had to use a proxy for work but have migrated off it. I've reset everything in my environment I can find inside and outside Eclipse to get rid of setting the proxy. However when I try to use the Software Update feature I find it's still using the proxy. In the error log I can see:
!ENTRY org.eclipse.core.net 1 0 2009-03-17 10:49:50.137 !MESSAGE System property http.proxyHost has been set to netproxy.blah.com by an external source. This value will be overwritten using the values from the preferences
!ENTRY org.eclipse.core.net 1 0 2009-03-17 10:49:50.164 !MESSAGE System property http.proxyPort has been set to 3128 by an external source. This value will be overwritten using the values from the preferences
Any ideas as to what the external source might be that's setting this property?
It's a bug in the preferences panel. You can see it if you tail your workspace/.metadata/.log file.
The workaround (at least in Eclipse 3.4.2) is:
Open Window > Preferences, then General > Network Connections
Select Manual proxy configuration
Click the Add Host... button to add a 'No Proxy' entry
Enter a random entry, say 'localhost' and click OK
Click Direct connection to the Internet
Close the property panel with the OK button.
Or go to your eclipse.ini file and check if there are some parameters like :
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient
-Dhttp.proxyPort=8080
-Dhttp.proxyHost=myproxy
-Dhttp.proxyUser=mydomain\myusername
-Dhttp.proxyPassword=mypassword
-Dhttp.nonProxyHosts=localhost|127.0.0.1
OR same parameters but the first one finishes in 4 like below:
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
Since release of Eclipse Kepler (4.3)
With this parameters you can disable the HttpClient provider and have ECF use the JRE URLConnection-based provider instead(line 1). And set proxy settings.
I remember I had a similar problem with the mantis mylyn connector. I don't remember where exactly the entry was, but I think somewhere in the metadata folder of your workspace was an option file for this particualar plugin. Maybe something similar exists for your problem.
On a windows system I've already found eclipse settings in the application folder of the users home directory. Not sure though how this is handled on Ubuntu... it's been a while.
Worst case you could just install another eclipse instance and see if that works. Although if the config file responsible for this problem is not somewhere in the eclipse folder, you'll still have the same problem.
At least you'll have a hint about where it is - eclipse folder, workspace or system setting in home folder.
Greetings and good luck!
Related
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.
Recently I switched to the Java 11 and start to debug my app and saw this message:
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot
loader classes because bootstrap classpath has been appended
Found only this commit and ticket, but it doesn't tell me much.
Do I need to worry about it?
I had this issue too after installing jdk-12.0.1_windows-x64_bin.zip when trying to use the debugger with IntelliJ IDEA. I was getting an error of (Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended). I found, too, going into Setting and search for async and unchecking the Instrumenting agent box. Worked for me!
You can ignore this warning. It just means that class data sharing is disabled for classes not loaded by the bootstrap class loader.
From Improve Launch Times […] With Application Class-Data Sharing:
The JVM loads some of the JDK classes with the bootstrap class loader
and the rest with the system class loader, but includes all of them in
its default archive. When IntelliJ executes your project, it tells the
JVM to load some code with the bootstrap class loader by appending to
that class path (second part of the message). Now, that means that the
portion of the archive that contains classes loaded by the system
class loader is potentially invalidated and so the JVM partially
deactivates sharing (first part of the message).
You could disable class data sharing completely with -Xshare:off, but you would lose some performance.
I had this issue after installing Java12 when trying to use the debugger with Intellij Idea. The solution that I found was to go into Setting and searching for async and unchecking the Instrumenting agent box.
For me, the issue occurred only when I ran in Docker, and when I used a java command line agent like the DataDog APM agent (-javaagent:/dd-java-agent.jar).
When I ran in my JDK11 runtime environment (without the agent) I did not get the warnings.
For Intellij IDE -> Settings/Preferences dialog ( Ctrl+Alt+S ), go to Build | Execution | Deployment | Debugger | Async -> uncheck instrumenting agent
1.Open the Preferences option;
2.Find the Build,Execution,Deployment option;
3.Enter the Debugger --> Async Stack Traces ;
4.Uncheck the Instrumenting agent(requires debugger restart) ;
Please see this for detailed information.
Given this warning in IntelliJ is harmless (see https://stackoverflow.com/a/57957031/779173) you could just hide the line from your Console view by right-clicking on the line and selecting "Fold Lines Like This"
Having done this, you'll just see:
"C:\Program Files\Java\jdk-17.0.2\bin\java.exe" ... <1 internal line>
If it is not critical you can change your jdk version. I've changed from jdk14 to jdk 11. Hope it will work for you.
Got same problem, and tried to solve it as was written above.
But then i got another solution of problem without changing settings.
Press mouse right button on your file where you put break point and want to debug. Then choose "Debug ur file name.method()".
Don't use debug button from tools window. Seems the problem is that Idea can't understand which file u want to debug.
That worked for me without changing async settings.
Screenshot
Got the same problem, and tried to solve it as was written all the above methods.
But still, I wasn't able to debug my file the only reason is that before debugging your program you need to set debug point that till which point we want to debug. So just click on the place shown in the figure and set debug point then our program will debug easily. without doing anything else. enter image description here
Java version must be 9 or higher.
Today I found the same question as you.
Situation: debug while set no breakpoint
Solution: set at least one breakpoint before you click debug button!
You have to put the red dots at the left side of the code line you will make debug .
if not you get this massage on IntelliJ
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.
Im currently developing JavaFX applications. I used Netbeans 7.4 before but now I switch to Netbeans 8.0.2. After running my project with the new IDE, an error occured saying:
C:\projects\client\QueueBoard\nbproject\build-impl.xml:87: The J2SE Platform is not correctly set up.
Your active platform is: default_platform, but the corresponding property "platforms.default_platform.home" is not found in the project's properties files.
Either open the project in the IDE and setup the Platform with the same name or add it manually.
For example like this:
ant -Duser.properties.file=<path_to_property_file> jar (where you put the property "platforms.default_platform.home" in a .properties file)
or ant -Dplatforms.default_platform.home=<path_to_JDK_home> jar (where no properties file is used)
BUILD FAILED (total time: 0 seconds)
How do you resolve this?
The easiest way to resolve this problem is:
open the Project in NetBeans
open Project-Settings for this project
check (and maybe correct/fix) all settings (including Platform-Settings)
click on Save/OK in settings dialog
Clean+Build project
By doing this, project-settings-file will be updated to current settings.
Cheers!
I know this is a very old question, but I encountered this recently. The solution I came up with is to modify the user-editable build.xml file (which is usually one directory up from build-impl.xml) and add the following after the <import> of build-impl.xml:
<property name="platforms.default_platform.home"
location="${java.home}/.."/>
This allows any user/local settings to have precedence, but if not defined, the java used should be the same java that is executing Ant.
This problem still exists in Netbeans 15 and can be solved by updating the nbproject/private/private.properties file and ensure this row exists:
javac.debug=true
We have a Java Spring MVC based project using Eclipse (Juno - the latest build), using the latest JVM 1.7 and Tomcat 7. Eclipse is pretty fast, and everything is set to default settings. Once it is all loaded up, it is lightning fast, which makes a pleasant change.
However, the only gripe is that if I open a project, it begins 'Loading descriptor', which as far as I can tell is our 185-line web.xml file. Sometimes this might take 5 minutes to load, sometimes might just not load at all. This prevents any changes being made, as the system waits for the descriptor to load before anything else happens. Pressing the stop button on this leaves the system 'waiting' for the cancel to go through, and the only way out seems to be to kill the java process is the task manager. If it does by chance load, then the system runs fine (unless you open another project for reference, then the fun begin again).
Is there some configuration that skips the descriptor (e.g. is it something to do with validation that can be skipped) or would there be some reason that the descriptor might not load properly?
This happens when your Project Explorer is open. Uncheck unnecessary options at Project Explorer's "Customize View" dialog. On the top right corner of the Project Explorer panel there is menu called "Customize View", go to the second tab called "Content" and uncheck unwanted options...
That problem occurred because "Project Explorer" performs loading of environment descriptor.
So after the eclipse was loaded, choose "Windows" -> "Open Perspective" -> "Java". It will open the "Package Explorer" instead of "Project Explorer".
You need to be quick and get it done before the eclipse load the descriptor.
As you mentioned you could try disabling all 'xml' based validations like so :
Start by disabling all XML / XSL based validation towards the bottom
in Windows -> Preferences -> Validation :
Type 'Validation' in Eclipse preferences and disable any XML related
validations, like so:
and,
Might be worth to try out the following:
Check your proxy settings. Are they such that if required your Eclipse would be able to connect to the internet ? The reason I ask is, with XML files Eclipse attempts to download the related schema files.
Also, check Eclipse' error log view to see whether there is something specific that it's trying to do when it hangs.
Do you have a source control plugin inside eclipse which is linked to the project containing the web.xml file ? If so, if you disconnect your network does it help ? Infact, I would recommend disconnecting your network connection and try opening the problematic project.
If this is an old workspace from a previous version of Eclipse, try importing this project into a new workspace ?
Hope the above helps.
Yes, the problem is in "Project Explorer". If you like to use the "Java EE" perspective (which by default opens "Project Explorer" view) then close the "Project Explorer" view and open the "Package Explorer" view.
Changed Explorer to Package Explorer
Window->Show View->Other->Java->Package Explorer
It works now.
In my case, renaming the web.xml to web-fail.xml stops the hanging.
At least, I replaced my 2.4 schema definition with the 3.1
`<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
`
and everything works fine again
My way to succes was deleting the project from the eclipse. And removing ".classpath",".settings" and ".project" files(".settings" is a directory). After that importing project into eclipse as existing maven project.