I have a plain Eclipse installation without much of anything, and a workspace with a Maven (or better yet Tycho) project. Everything worked until I decided to change the JDK (Preferences -> Installed JREs); now whenever I start a Maven build or the plug-in unit tests I get the following error:
Error occurred during initialization of VM
java.lang.UnsatisfiedLinkError: java.lang.Class.getClassLoader0()Ljava/lang/ClassLoader;
<<no stack trace available>>
I have restarted Eclipse and tried a different installation, and since I thought the problem was with the JRE, I changed it back to the original one. Still the same error.
The corresponding 64bit JRE works, but sadly the build has an integration test for 32bit (Cannot load 32-bit SWT libraries on 64-bit JVM), so that's why I need to get 32bit to work again.
How do I fix it?
Deleting all the .metadata folder of the workspace and setting it up again helped.
Related
I am using latest Eclipse version with cmake4eclipse add-on on my Debian machine. I am a noob at using Eclipse and already there is a problem! The very strange problem is that after building a project the explorer tab of IDE shows the built binary but I can not actually find it using my usual file manager. When I try to run the binary from IDE, Eclipse complaints a nullpointer exception has occurred. What is happening here?
I Downloaded Eclipse from-https://eclipse.org/downloads/
From where i got -eclipse-inst-win64.exe
After intalling it,when i launch it, It is throwing me an error
The Eclipse executable launcher was unable to locate its companion shared library.
I am having Windows 8.1-64 bits, Java SE Runtime Environment-Build 1.8.0_77-b03
very simple and easy solution for this problem. This problem occurs only because of versioning of eclipse . so need to clear the versions of jars which are in the eclipse.ini . Easy way to fix this is just remove eclipse.ini and run your eclipse application file it will automatically creates new eclipse.ini as per your environment
I have a web project working in eclipse juno using tomcat 7 on one machine. I exported this project to subversion, and imported it into a fresh workspace of eclipse juno on another machine which also has tomcat 7 installed. To fix errors, I then set up the runtime "Apache Tomcat v7.0" on the second machine, and selected Projects/Clean/Clean all.
Now, my project has a list of libraries that includes "Apache Tomcat v7.0 [Apache Tomcat v7.0]", under which are listed all the jars in my tomcat installation, including servlet-api.jar, which eclipse is able to tell includes the package javax.servlet.http. However, I have hundreds of compiler errors from my source of the form "The import javax.servlet.http cannot be resolved" etc. Short of deleting and recreating the project (which might fix the second machine, but I worry that it will stop the project working on the original machine) what can I do to fix this?
Correction: the machines are running eclipse juno, not indigo as I previously stated.
If you did a refresh on the tree and a clean/build and the errors still exists, it must be the case, that they are not within the build path (check .classpath file).
So even though you may have checked it before, you should go there again and see if they are on the build path and maybe delete it and include them again.
Additionally, maybe this article about the specific problem helps.
Turns out that this is a fairly simple and annoying but otherwise harmless eclipse bug -- it seems as though the list of libraries that constitutes a particular runtime is cached when the project is loaded, and doesn't get updated if the library list changes (e.g. because the runtime didn't exist when the project was imported, but was created afterwards). Restarting eclipse causes it to reload the list, after which a project clean gets rid of the errors.
I'm trying to build a large Open Source project in Eclipse; it uses Maven so I've installed the various plugins (m2eclipse etc) but I'm a little unfamiliar with this setup.
I can build and run the particular JAR I'm interested in with no issues. However, when the newly built JAR tries to open a large ZIP file, I get this:
Exception in thread "main" java.lang.RuntimeException: java.util.zip.ZipException: invalid CEN header (bad sig
nature)
at org.opentripplanner.graph_builder.impl.GtfsGraphBuilderImpl.buildGraph(GtfsGraphBuilderImpl.java:17
9)
at org.opentripplanner.graph_builder.GraphBuilderTask.run(GraphBuilderTask.java:127)
at org.opentripplanner.graph_builder.GraphBuilderMain.main(GraphBuilderMain.java:51)
Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
I did some research and it seems that this error means that java.util.ZipFile can't read the file because it's in ZIP64 format. Apparently this was fixed in Java 1.7, so dutifully I've updated the JDK on OS X, and tried to change the Maven project by right-clicking on it in Eclipse, then altering the Project Facet, which in turns seems to have updated the JRE libraries in that project to 1.7:
However, this doesn't work - I still get the error even having re-built the whole project.
Is it possible that the old java.util.zip is still being pulled in from somewhere? I'm not too familiar with how linking works in Java, can older JDKs be 'embedded' like this within dependencies? Or does the java.util.zip just get used that's on the target machine? (this is definitely JRE 1.7) I know for a fact that the code throwing the exception is actually contained within a separate JAR that's pulled in as a Maven dependency:
Do I need to track down and re-build this external JAR against Java 1.7, is that the issue here? Or is there a concept of a Maven 'parent project' that's regressing my new JRE 1.7 back to 1.6? Sorry if these questions are naive.
I originally thought that it would be as simple as just updated the JRE on the runtime machine, but apparently not. So how do I resolve this error?
Assuming that the problem is really caused by using an older version of Java, then rebuilding is not going to make any difference. The real problem is that your application JAR is running on an older JRE.
In the command shell you are using to run your application, run java -version. That will tell you what JDK / JRE will be used when you then run java -jar yourApp.jar ...
The most important point in relationship with maven is bear in mind that the source of the truth is the pom file in Maven and NOT the IDE anymore. So changing the compiler version must be done in the pom.xml file and NOT in the IDE.
Maven ignores what JRE are you using in eclipse, you have to force it with the maven compile plugin config. Here is how in this link http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html But with version 1.7 instead of 1.3
My eclipse gets stuck when I try building a project, usually at 80%. I also get a heap error, even though I already increased it to 750mb and the same project previously worked with 350mb.
I tried starting up eclipse with the "-clean" command, but according to the log it's not effective:
!MESSAGE The -clean (osgi.clean) option was not successful. Unable to clean the storage area: C:\Program Files\eclipse\configuration\org.eclipse.osgi
Edit:
Okay, the build error seems to be caused by faulty libraries. And -clean did not work because I was starting eclipse without administrator rights (Windows 7).
As stated in the Edit:
The build error seems to be caused by faulty libraries. And -clean did not work because I was starting eclipse without administrator rights (Windows 7).
I had this problem also and it happend after I updated a Jar file.
Turns out the jar I had added was compiled with the wrong version of java.