Community
Participate
Working Groups
While working on a Java project, sometimes I need to upgrade one of the JARs in the build path. This may bring change to some of the exposed interfaces, for instance, a new member in a class, or change of signature in an interface method. Eclipse 3.1.2 would pick up these changes after having Eclipse re-read the JAR, either by re-compiling a class that referred it or by refreshing the file-system information in the project (the Refresh action in the context menu). Now enters the regression: Eclipse 3.2M5a does not seem to pick up these changes properly. Neither plainly re-compiling or forcing it to re-read the JAR help. Even browsing the JAR from Eclipse does not show the newly introduced method, whereas running javap on the same JAR show the method, as expected. Not even Build Path -> Replace JAR seems to trigger an update. Finally, restarting the workspace causes the changes to be picked up.
Javier - this is still supposed to work, and we do have some regression tests for this which look ok. You may have uncovered some bug, can you pls provide exact steps to reproduce ?
Philippe, I've found a way to reproduce this bug. See the following instructions: $ eclipse -data wsa New Java Project "A" with default settings New Java Class "B" in package jkohen. Add method "void m1()" to class B. Export Project A to "lib.jar" JAR File with default settings. Put this workbench aside for now. $ eclipse -data wsb New Java Project "B" with default settings Add lib.jar to Project B's Build Path. New Java Class "C" in package jkohen.impl extending class B. Create method "f" and add an invocation to B.m1. Put this workbench aside for now and go back to wsa. Modify method's m1 signature to take a String. Re-export Project A to "lib.jar" JAR File with default settings. This workspace can be closed now. Refresh Project A from the Package Explorer. The call to method m1 will be marked with an error, because the caller is not pasing a String argument. Add a String argument to m1 in order to fix the error. Once class C is re-compiled, no more errors will be shown in the Problems view, but the error mark in the file buffer will be kept. The mark persists after closing and opening C.java again. Note that the code seems to be compiled properly, but having the error marks around is misleading and annoying.
Reproduced. This is not a build problem as the errors are correctly created/removed. It appears to be a problem with the Reconciler's cached view of the jar file. Jerome can you have a look at this please.
I cannot reproduce with 3.2 RC1. (Kent reproduced it only if not refreshing project B). 2 points to clarify: - when you say: "Refresh Project A from the Package Explorer." you meant "Refresh Project B from the Package Explorer.", right ? - when you export lib.jar, where exactly do you export it ? inside project A ? or to another location ? Please reopen once requested information is available.
(In reply to comment #4) > I cannot reproduce with 3.2 RC1. (Kent reproduced it only if not refreshing > project B). > > 2 points to clarify: > - when you say: "Refresh Project A from the Package Explorer." you meant > "Refresh Project B from the Package Explorer.", right ? Yes, I believe you are right. > - when you export lib.jar, where exactly do you export it ? inside project A ? > or to another location ? To another location such as /tmp/lib.jar. When added to Project B's classpath, it should be added as an external JAR, and not imported into the project.
Thanks for the clarification. I was able to reproduce and I'm investigating.
Created attachment 38599 [details] Proposed patch and regression test
+1 for 3.2RC2
Released fix and regression test
Verified with I20060427-1600 for 3.2RC2. Could not reproduce original problem, but open bug 139279.
