I'm asking and answering this question to save me from going down this rat hole again in the future.
I'm building a cross platform eclipse IDE based software development environment with about 40 plugins. When I installed the latest nightly build and did some testing on my Linux test system the application started throwing the dreaded java.lang.NoClassDefFoundError when I did a certain action. This was not happening on my Windows installation. It did not happen in my development environments on Linux or Windows. This action and the code behind it is new and so not yet covered in our automated test suite.
The plugin throwing the exception was trying to access a static class method in another plugin, but failing to find the class. Things I tried:
First thought: static initializer fails for some reason! Nope. I can see other plugins access this static class and methods prior to the failure (by attaching my debugger to the installed instance of my product and stepping through the code).
The fact that it works from other plugins eliminate the other usual reason for failure, not properly exporting the package. It was exported correctly.
I poured over my plugin dependency list, comparing them to plugins that were able to access the offending class, but with no success. All dependencies were accounted for.
I did a deep dive into my MANFEST.MF. I switched from using "Required-Bundle" to "Import-Package" in the MANIFEST.MF. That created new problems for me so I reverted that change. Everything looked good.
My build.properties looked good. Not too much in there to go wrong. It was consistent with my MANFIEST.MF where it counts.
I deconstructed my plugin on the installed instance to be sure that the class was indeed present. It was.
Everything was configured correctly. Everything!
I poured over many related SO questions and blog posts but none of them offered a solution that worked or any additional insight into the problem.
The next step was to start iterating over my nightly builds to find the build where the problem first showed up. Once I identify that build, I'd be able to iterate over all the commits from the day before, doing full builds, then installs to find the commit that broke it.
I started 10 days prior and installed every nightly build. All the way up to the build that failed in my test environment. Every single one of them worked. Why?. See my answer below (or submit you own).
When testing a new eclipse IDE build make sure you start with a fresh new non-existent workspace directory and use the "-clean" command line parameter to flush any caches that survive from a previous installation.
The failure was happening because I (1) failed to delete my previous workspace directory before starting the application; and (2) did not use the "-clean" command line parameter to delete related cached information; and (3), even "-clean" may not be enough, I also removed the entire application directory (which, in turn, removed the 'configuration' directory and all cached data within that may not have been "cleaned" by the "-clean" command line argument).
I had been refactoring a few class names to have more meaningful names. When I ran the product with an existing environment the product was using cached data, getting the old name of a class that had been renamed, and failing to resolve it. (You might think that seeing the old name was a good clue, but, unfortunately, one of the first things I tried was undoing the class name refactoring, thus restoring the previous name. So the error reported the correct name, but, I suspect, there is a signature of sorts that did not resolve.)
Of course it is a best practice to always start with a new workspace when testing. I've been doing Eclipse IDE development for years and I know this well. But yesterday I forgot (not helped by the fact that my Windows installation did not suffer the same error for whatever reason). You will forget on occasion...and it will bite you.
Related
I have a scratch file using guava collections, and I get some weird errors that I have to assume is due to the editor and the actual run environment assuming different versions of the guava collections:
Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.common.collect.Range.<init>(Lcom/google/common/collect/Cut;Lcom/google/common/collect/Cut;)V from class
com.google.common.collect.Ranges
at com.google.common.collect.Ranges.create(Ranges.java:80)
at com.google.common.collect.Ranges.closedOpen(Ranges.java:114)
at Scratch.main(scratch_2.java:69)
Not that I can actually know that for sure because I also can't figure out how I'm supposed to see which version the scratch file is pulling in. I've removed guava from my project's deps ENTIRELY and the scratch file still works... WHY? Where is the library coming from??? The scratch run config is completely empty of anything that would dictate this:
And yet it still runs just fine. I discovered that if I delete the guava entries from my local ivy cache, it won't run anymore. If I then add guava back to my project's deps, it ends up in my ivy cache again, and then even if I remove guava from the project deps the scratch file is fine again. So does the scratch file just pick a random version or something? The ivy cache, which is at ~/.ivy2/cache/com.google.guava, looks like this:
But there's also that "jars" folder that has a guava-12.0 for some reason:
And again, I have no idea which version is being used, or why the cache has so many different versions of it. Any ideas?
One way that proved to be the simplest to me was to select "use classpath of an existing project module" (which has dependencies configured) in the run configuration dialog. This is useful if you want to pull out a piece of functionality from your project to play with in isolation but still use the configured dependencies.
I had a similar issue in PyCharm that I just fixed - so your mileage may vary here. It terms out that there was a Python virtual environment attached as the default to the project window (I had had multiple projects open in the same window - but evidently the first one became the default).
I dug into the list of interpreters, found the one I wanted and edited its properties, specifically Associate this virtual environment with current project.
I checked that box for the virtualenv that had the libraries I was looking for and this fixed the compilation errors in the editor itself.
I'm aware several people have asked very similar questions to this one, but I really need help finding the solution to my particular case.
Please read and understand this question before posting an answer :)
I'm using
Eclipse (both Juno and Kepler)
JDK 1.7
Tomcat 7
the Sysdeo Tomcat plugin
and in one particular project (other projects are fine), the following happens:
I set a breakpoint
start Tomcat
execution arrives at that point
I get a message: "Unable to install breakpoint on com.foo.bar.Main.class due to missing line number attributes" Reason: Absent Line Number Information
The thing is, if it can't install a break point - why is it stopping at exactly that point in the code where I set the breakpoint? Also, it says line number information is missing but I've verified all Compiler options and even used javap to confirm that line number information is in the compiled Main class file.
Note:
I am not using Ant to build
I am using the 1.7 JDK in Eclipse (not JRE)
Any guidance or suggestions welcomed.
Edit:
Hmm.. further information that may be important. I'm using Spring, and the actual class that Eclipse tells me has no Line Number Information is actually of the form: 'Main$$EnhancerByCGLIB$$87eae52c'
Could it be that a pre-compilation layer is generating classes without line numbers?
Maybe your class files in Eclipse class path is not matched with the class files you have in Tomcat webapp folder. There are out of synchronization.
You can try to deploy newly built war file again.
Today I came to work, happy. But when I opened my Eclipse, I saw that one of my projects has errors.It's weird because it shows that it has errors only in the window bar, and not in the Navigator. I don't have any Java errors, this is a valid project that was fine all the time:
Some of the errors on the error log of Eclipse:
JavaBuilder handling ImageBuilderInternalException while building: SP_Procedure
Cannot connect to VM
File <SomeFile> has been skipped, problem while reading ('Resource is out of sync with the file system')
Unhandled event loop exception
Internal error
When I run an application from this project, I get a warning message but when I proceed, it works fine, but still. It's very disturbing and I'm not sure if it's harmless.
I tried to:
Restart Eclipse
Restart my machine
Clean projects and recompiling them.
Refresh projects
Pray
Nothing helped. What could be the problem? (I'm using Indigo Service Release 2)
The following nuclear option has desperation written all over it. But I have been where the OP has been with the Juno version of Eclipse.
Run a "Synchronize with Repository" and save all of your local updates to a different directory.
Delete the project. (Check the box to delete the contents on disk. Scary step, but that's OK, because you saved it in a different directory in the previous step, right?)
Read in a fresh project from the repository. It builds happily at this point.
Integrate your local updates.
Keep on praying.
Looks that one unused JAR was deleted, but for some reason, I didn't get errors in any file, even in the files that imports this JAR! So what I did was restoring this JAR, delete unused imports and deleted the JAR again.
I've found this error after two days of navigating on this project on each file.. This is weird that Eclipse didn't recognize that1 this is an error, and throw many unrelated errors such as:
Cannot connect to VM
File has been skipped, problem while reading ('Resource is out of sync with the file system')
Unhandled event loop exception
Is this a bug in Eclipse? (All errors and warnings are enabled!)
1 As seen in the image in the question..
A class from the list of imports for the file seems to have moved out or the jar file containing the class is missing.
Expand the imports section and check if you find some classes that are missing but have been imported.
Though it is a pain, sometimes the easiest solution is to back up all your projects (either in a repository or somewhere else on your computer) then uninstall and reinstall eclipse. No it's not fun, but it should reset eclipse so everything works again. The downfall though is that you have to reconfigure eclipse to any special settings you had/reinatall any extra functionality currently installed (eg. android add-on) and reconnect to any repositories you have. While punting isn't fun, it can be effective... I hope you don't have to resort to this though.
I have went through that problem a lot of times, and tried everything you tried. Rebuild, recompile, refresh, remove and add JDK, remove and reinstall Eclipse... nothing worked
The only thing I concluded is that the workspace metadata was corrupted.
What I did (every time it happened) was
Create an empty workspace
Import -> existing projects into worskpace
Mark the "copy projects" (else it will only link them)
Wait for the copy, and start working with the new workspace
If you work with SCM systems (Git, SVN, etc), making a full checkout will do the trick too, but the worskpace import will let you retrieve those changes you didn't get to commit (if any).
It's a little painful if you have somethings already set (like JDK names, servers, etc), but then I realized it was faster than keep searching how to fix the workspace
Regards!
PS : I've been working with Kepler lately, and everything works fine till now
Click Window -> Show View -> Other -> General -> Problems
This view will show you what is wrong.
Did you, by any chance, update your virtual machine outside of Eclipse? I can't help but feel that we're both missing a finer detail here. I just keep seeing "cannot connect to VM" and thinking that it's a major clue.
Have you tried running anything from the terminal? Does it work there?
If so, do you know where your current edition of Java is located? Is Eclipse looking somewhere else?
Is this exclusive to one project? Do you use any additional libraries to the JDK?
Maybe try this for Resource is out of sync with the file system error:
Right click project in Eclipse Package Explorer
Close Project.
Right click project in Eclipse Package Explorer
Open Project.
Other things not mentioned:
project properties > java build path, see if any of those tabs got changed, local file got moved? read/write permissions on some file you are linking to?
project properties > java compiler, see if workplace settings have changed? maybe under errors/warnings, you can systematically set them to 'ignore' until the error goes away to determine what type of error it is?
maybe update some of the eclipse plugins?
I saw something like this happening for a number of reasons. Mainly because of validation in files other Java source code. See if you are validating XML for instance.
Right click your project and chose Properties (Alt+Enter) and Validation to see the related configuration.
As for the danger, I lived with those marks for ages and nothing wrong ever happened.
I'm trying to help another developer who is using Netbeans. When he runs or debugs some code of his in Netbeans (6.9.1) he gets an "Uncompilable source code" RuntimeException. I'm pretty experienced in Java but am more used to IntelliJ, and haven't used Netbeans at all.
I've done it a bit of googling and it seems Netbeans will compile code even with errors, and then throw the RuntimeException at the errors. (Fairly bad behaviour IMO, but I guess some will find it useful.) I've got him to completely rebuild the project with no compile errors, but the RuntimeException seems to still occur. I assume he's got some bad cached class data somewhere deep within Netbeans.
2 questions:
What is the best way to clear the cache so we can find out where the uncompilable code is?
Is there any way of turning off this behaviour so the code won't run/debug unless everything will compile, so these RuntimeException's won't be injected into the code?
I've googled a fair bit, but haven't found the answer to either of these questions yet.
Update: More information:
Turning off the "compile on save" option makes the problem go away. Turning CoS back on again brings the exception back. Unfortunately this isn't a fix, as CoS is a very useful option.
http://netbeans.org/bugzilla/show_bug.cgi?id=182009 seems the closest bug report, but it has been closed as "RESOLVED INCOMPLETE". Unfortunately the bug is hard to reproduce - the exception is happening in Java library code, when it calls a third-party library, so there isn't anything at the point the exception is thrown we can change. And the code will work for weeks, and then suddenly start throwing this error with no obvious reason why.
We've tried manually deleting the entire build directory - still not a fix.
We finally got a solution, but still don't quite know why the situation occurs. When you have Compile On Save activated, Netbeans generates a second set of class files for debugging etc. These are stored in $USER/.netbeans/var/cache/index/s*/java/*/classes
Somehow (not sure how) this directory can get corrupted or fail to update.
If you close netbeans, delete $USER/.netbeans/var/cache/index and all subdirectories and restart netbeans this clears the cache. If you have no compile errors, your problem ought to go away at this point.
NB: $USER is your user directory - on Windows 7 this is usually c:\Users\username, I guess on Unix it will be ~username.
If you get this problem please vote for, comment on, or add information to: http://netbeans.org/bugzilla/show_bug.cgi?id=182009
I experienced the same wired problem in NB 7.0.1, my hammer-IQ solution was to make a typo in the source code, run NB with this error (despite an error message) and than the cached class was successfully deleted.
I experienced this issue on Linux Mint Nadia with Netbeans 7.2.1, but was stumped as to where the cache location might be - mine was actually located at
/home/USER/.cache/netbeans/7.2.1
rather than in the .netbeans folder.
If you're not sure where the cache is located on your particular setup, just go to the help > about menu in Netbeans and it'll tell you the correct path.
After realising that the cause was a bad cache from the other posted solutions, I solved this problem by copying the file to another directory, deleting it from NetBeans, and then adding it again.
In fact, you neednt delete whole of index folder.
When you open netbeans and your project folder is active. Netbeans starts scanning files and creates temporary project folders (in index folder) for all active projects. If you check index\segments file(its a text file and can be viewed in notepad/(text editor)), you will be able to identify the folders that represent your project. You can then delete those folders and restart netbeans.
*Active project means those projects that were open before Netbeans was shutdown.
Had the same problem on Windows 7 with Netbeans 12.
Cache is here:
C:\Users\<Username>\AppData\Local\NetBeans\Cache
, but the deleting cache is not helpful sometimes. The better solution is to recompile the problematic class i.e. make a minor change (e.g. add space) and save.
Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?
After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.
It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.