Community
Participate
Working Groups
My Java project contains a folder with java files and their class files. This folder is not a source folder of the project but it is included as class folder on the Libraries tab on Java Build Path page on the project properties dialog. After a while of editing a java file from this folder, when I try to save the file, I get an error message saying that the file could not be saved because there was a NullPointerException thrown.
Created attachment 7424 [details] Log file for the NullPointerException
Could you please try to start your Eclipse workspace disabling the JIT? -vmargs -Djava.compiler=NONE If this doesn't fix it, please provide a reproducable test case.
I have removed the folder containing the java files I edit from project's libraries and I was able to edit the files fine. Then I had to edit a file that is in the source folder for the project and after few changes, I got the NullPointerException. I will attach another log file I got after that.
Created attachment 7426 [details] Another log for the NullPointerException problem
I'm now running the Eclipse with JIT disabled, I will provide log as soon as the NullPointerException shows up again. As to the testcase, it is contained in the bug description. It didn't take more than 10 minutes to get the exception.
I've been running the Eclipse for about an hour with JIT disabled and the exception hasn't been thrown. However, in my opinion, disabling JIT can not be considered a fix for the problem because it makes Eclipse very slow. If after your tests with the scenario I've described, you conclude that there is nothing to fix in Eclipse code and the problem is being caused by JVM, I hope you can provide IBM Java team with a test scenario to have the JVM fixed. The JVM I'm using is (fullversion) : J2RE 1.4.1 IBM Windows 32 build cn1411-20031011
Can you provide sources or even your workspace so we can reproduce it ?
Actually, you should report this to the VM vendor directly with steps to reproduce. Eclipse is VM agnostic.
To clarify. Olivier asked you to turn the JIT off, so as to disable the VM optimizer which has some bugs (and we saw a couple of these hurting us). By doing so, it proved that the Java compiler is innocent and that the VM is guilty. You don't want to run with JIT off in production mode of course. Either you should report this to the VM vendor, or switch to another VM. I would strongly recommend the first one, as this is the only way you'll get the VM improved in the future. Closing as VM bug.
This is not the first time I have experienced problems with Eclipse that were caused by JVM. However, EVERY TIME, the only thing the Eclipse team has done was blame JVM, close the bug and asked the end user to report to JVM vendor... Eclipse team, closing this bug might help you lower the number of bugs, but did you help me, YOUR CUSTOMER ??? NOT AT ALL !!! I'm reopening the bug in order to see something being done with regards to this issue, be it either a report to JVM vendor or at least a few lines put into documentation to warn the users that this problem might occur.
This bug database is reserved to Eclipse bugs. This issue is a VM JIT bug and has nothing to do with Eclipse codebase. Also note that the VM you are using isn't a final version. In order for anything to occur, input has to come from *you* to VM vendor with reproducing steps. Closing as invalid.
I agree that this bug was not an Eclipse bug, however, it is a problem that the Eclipse user's might run into. Something has to be done... At the moment, the problem is still there, so the bug can not have status of "resolved". Also, the problem is real and occurs in a valid scenario, so this bug can not have a resolution of "invalid". I'm reopening the bug again for above reasons.
Bug isn't receivable from Eclipse standpoint. See comment #11. Please rather report this to VM vendor directly rather than harassing us to get it done for you.
Sorry, I was under the impression that the Eclipse has been created FOR US, the USERS, and you will do as much as possible to make it a usable tool, even if all you can do is put something into the documentation... As to the informing the JVM Vendor, I would have done it if the problem was causing problems in my product, however, it is Eclipse that is crashing...
So we would have to document that using an intermediate drop of some VM did make Eclipse crash ? Big deal. What is important for the company you work for is that this bug is resolved. Given you seem to have reproduceable steps, you should be realizing that you are in a good position to help the VM team to solve this issue. We simply cannot solve this problem for them, neither for you.
I have first found the issue with following JVM : J2RE 1.4.1 IBM Windows 32 build cn1411-20030930 What is the JVM that you have tested this scenario with and got no exception ?
Other vendor VMs do not expose this issue. Also note that the code you have in your workspace is directly creating the error scenario.
I've been running Eclipse on another machine with latest JVM from Sun for a while now and I have to admit that I had no NullPointerException as I reported earlier. As to my code creating the error scenario, I'm not sure what exactly you meant by that statement. If you have time to explain, I would appreciate it.
Compiling your source code causes the VM running underneath to crash.
In the original scenario I was editing a file that was not in the source folder so I'm not sure why it would be compiled.
FYI - when using IBM JREs, you should also specify the command line option "- Xj9" which will likely make these JIT bug go away.
Interesting info, thanks.
