Community
Participate
Working Groups
Eclipse 3.2 M5, M6 (cant say if in previous milestones it worked or not) Used to work in Eclipse 2 up to 3.1.2 I have a project that uses a project builder that enhances persistent classes (JDO), adding the implementation of PersistenceCapable interface to these classes. After compilation and enhancement, you are able to run the application. The problem starts when we change one class that has a reference to these enhanced classes. You edit the source of the class and save it. After saving the class you get "The type org.jpox.samples.city.Country cannot be resolved. It is indirectly referenced from required .class files". "org.jpox.samples.city.Country" was enhanced in a previous compile step. To reproduce: class A { String a; } class B { A a; } 1) Compile A and B classes. 2) Enhance class A (you can use JPOX if you like, or some other tool to modify the bytecode). 3) Optional: Run B 4) Edit B and save. The issue should show up now. Workaround: Rebuild the project
Feels related to bug 129082, which should have been corrected in 3.2M6.
Yes it looks like bug 12908. I opened A.class using an hex editor and saved it. That was enough for reproducing the issue. The Class A is still a valid class since I run "javap A" and it worked. I'm using Version: 3.2.0 Build id: N20060408-0010
To correct the above comment: It looks like bug 129082.
Tried to reproduce but it works fine for me. So do you have the new option enabled to recreate modified class files? I assume not. And does A.class still exist in the same place in the directory structure after you've saved it?
To reproduce it 1) Downloaded Eclipse Build id: N20060408-0010 or any latest version 2) Create a new java project 3) Create A and B classes. 4) Compile A and B classes. 5) Open and save in an external editor the file A.class 6) Edit in eclipse B and save. The issue should show up now.
Those are the same steps as before and it works fine for me. Can you please try it again and tell me if A.class is still in the same place (by looking at it on disk).
Yes the file is still there. I was trying to find the "option enabled to recreate modified class file", but could't, everything is set to default
I'm wondering whether your changes to A.class are corrupting it so we think its not there anymore. Instead of changing it in an editor, what happens if you replace it with a previous copy that had a different method in it?
As I told before javap works, but this is not the issue because if I just open the file with an hex editor and save with no changes, the issue is the same. Also, In my real work, I use a bytecode enhancer which is very stable and generates fine bytecode, and the issue is the same. In any case, I just did what you asked and the issue is still the same The only thing that can be different is the environment so here is mine: - Windows XP Professional - Java 1.5.0 06
Reproduced. This is a consequence of our change to have ClassFileReaders get the contents of a file using the Core resource API, which checks to see if the file is out of sync. In the past, we got the contents by reading from the raw IO file. As a workaround, you need to refresh your project after changing the .class files externally. Philippe - we can force a refresh of the output folder when we detect that the class file is no longer in sync.
Glad to see that you were able to reproduce, but refreshing the project is not a good workaround in long term because it recompiles the files again which means that I have to re-enhance the changed files.
The refresh does not recompile the files again unless the source files have been changed.
+1 for 3.2RC2
See also bug 131791 which seems like the same issue
*** Bug 131791 has been marked as a duplicate of this bug. ***
This is a straight forward 1 line change to create ClassFileReaders even when the .class file is out of sync by using the force flag on the call to getContents(). See org.eclipse.jdt.internal.core.util.Util.newClassFileReader(), changed: in = ((IFile) resource).getContents(); to in = ((IFile) resource).getContents(true);
*** Bug 138361 has been marked as a duplicate of this bug. ***
Verified with I20060427-1600 for 3.2RC2 (looking at the source code).
