Community
Participate
Working Groups
Using 3.0 RC1. I have following project setup: P src a b c A.java classpath is: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> I have also open class A for editing (it's important). Its content is: package src.a.b.c1; public class A { } I build my project. Everything is fine and I have no error neither in Problems view nor in editor... Now, I change the classpath to make src folder a source folder instead of project. Classpath becomes: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> I build my project and now get an error both in editor and Problems view that "The declared package does not match the expected package a.b.c1". Of course this sounds normal, so I go in the editor and remove the leading src. in the package declaration, save the change and build the project... Here's the problem, error is correctly removed from Problems view but not from editor: now it warns me that package does not match expected package src.a.b.c1!
Suspecting stale working copy handle to be used and reconciled. Jerome - pls confirm whether this occurs, and whether UI has sufficient info in delta to figure information, and properly discard/acquire a new working copy handle in this scenario.
Created attachment 11455 [details] Trace javadelta+javamodel Following steps have been executed while tracing: 1- modify classpath to set "src" source folder instead of project 2- build 3- modify file A.java and save 4- build Note that project name is "Reconciler".
The working copy handle used by UI is bogus on the last reconcile: [Working copy] A.java [in src.a.b.c1 [in <project root> [in Reconciler]]] UI should discard the primary working copy and create a new one when the classpath change notification happens: Java Model[*]: {CHILDREN} Reconciler[*]: {CHILDREN | CLASSPATH CHANGED} <project root>[*]: {REMOVED FROM CLASSPATH} src[*]: {ADDED TO CLASSPATH} ResourceDelta(/Reconciler/.classpath)[*] Moving to JDT Text for comments.
to be investigated
There's an error in my scenario, project setup should read: P src a b c1 A.java and then there's effectively no error at the start of it... Sorry for the confusion
The CompilationUnitDocumentProvider does not listen to JavaModel delta and hence does not recognized the build path change. The workaround is to open and close the editor. We will fix this post 3.0. Note: see also bug 19012
*** Bug 51709 has been marked as a duplicate of this bug. ***
*** Bug 73653 has been marked as a duplicate of this bug. ***
Deferred.
*** Bug 100588 has been marked as a duplicate of this bug. ***
I have a similar? issue that is very straight-forward to describe. All of the java code for a specific package lives in an appropriately named directory structure, e.g. com/mycorp/util. Let's say one .java file in this directory does NOT have any package statement. I get the error on that file: "The declared package does not match the expected package com.mycorp.util" on Line 1 where a package statement would normally be. The file compiles fine, and assumes the package statement for the directory structure that it lives in and puts the resulting .class file in the target com/mycorp/util output folder. Using Sun's javac, there is NO error generated from the compiler AND the .class file is located at the same level as the target com folder. This is what I expect.
Franklin, this has nothing to do with this bug. Please file a separate bug against JDT Core.
Franklin, to be more clear: the error that gets reported in this bugs scenario is the same that you see but this bug is not about the compile error itself but about JDT Text is handling build path changes.
*** Bug 123408 has been marked as a duplicate of this bug. ***
Sorry, not for 3.2.
Before attacking this I need advice from JDT Core: what happens to a Java Element (handle) if the build path changes? Will it be discarded? Will the buffer be closed? In other words what are the actions that a client like the Java editor who works on such a stale working copy with non-saved changes has to do? Wouldn't it eventually be more natural if JDT Core updated those elements upon build path changes?
I would assume that I have to 1. discard the old working copy 2. create a new one 3. if dirty, transfer the source from the stale one to the old one
(In reply to comment #16) > Before attacking this I need advice from JDT Core: what happens to a Java > Element (handle) if the build path changes? Will it be discarded? No, the working coyy won't be discarded. > Will the buffer be closed? No, the buffer won't be closed. > In other words what are the actions that a client like the > Java editor who works on such a stale working copy with non-saved changes has > to do? It should create a new working copy, transfer the buffer content to this new working copy, and discard the old one. > Wouldn't it eventually be more natural if JDT Core updated those > elements upon build path changes? A handle is immutable. I'm not sure how we can achieve what you are suggesting.
This is not as simply as it looks: we cannot just change the working copy underneath the editor because the editor acts differently for working copies that are on the build path than for wcs that aren't on the build path, e.g. the editor tab icon is different and action availability and enablement is different. So, we either have to reset the editor's input which causes trouble (dialog) if the editor is already dirty, or we need to be able to adjust all editor state that depends on whether the wc is on the build path. At this point this is too much work for this corner case. I have to defer this to 3.4.
*** Bug 49458 has been marked as a duplicate of this bug. ***
*** Bug 264488 has been marked as a duplicate of this bug. ***
*** Bug 310957 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
