Community
Participate
Working Groups
To be able open a Java editor on a Java file outside of a build path JDT/Core creates a working copy / compilation unit which isn't connected to a real Java project. As a result all our actions have to contain some check code if the CU we have in hand is a real or a fake CU. Since calling most of the API on a fake CU ends in a JavaModelException. And as usual this check code is sometimes forgotten. Is there a change to get a different type for this kind of files in 3.0. This woulld really ease our code.
I don't see how it would make any difference on your end.
If we have a separate type then the action would be disabled since it wouldn't be a compilation unit. And this is something we can currently spec in XML and in code. Having the same type enables the action even if it should be disabled. So we have some check code in run to test if it is a fake or a real CU.
A .java file outside the classpath isn't a compilation unit, however we tolerate opening a working copy on it, so that editors can be opened onto them. This was a special request from JDT/UI which induces rather inelegant hacks on our end to support. Now, are you asking back that we shouldn't support this any longer for you ? Legitimally, we shouldn't allow you to create working copies on them, period.
FYI these are already of different type, since they are listed amongst non-java resources.
I know that we have asked for this support and at that point in time it was the right thing to do. I am not asking back to not support this anymore. Since the current solution seems to be a hack on your and on our side I am asking for a better solution than the one we have right now. I thought about something like a IJavaFile which isn't a ICompilationUnit ?
How do you expect all Java tooling to function on these entities ? We would pretty much have to provide new elements for these, and new support accordingly. Maybe we could reuse working copies under the cover, but this feels a nasty request since all resolution should step back from the working copies back to this IJavaFile element... Very unlikely to occur. Why aren't your actions registered onto a different object than the fake unit ? It seems to me you are missing a generic 'enable' check for actions (they would all check whether or not the unit is on a classpath).
Currently our actions do exactly this. They check if the element they try to working on is on the class path and if not the pop-up a dialog. But since this is something the developer has to do manually it gets forgotten.
I think this is an implementation detail on your end. You should better structure these actions so that you implicitly get this behavior (by inheritance or whatever suits the best your needs).
Yes and No, since another plug-in can contribute action to a compilation unit as well. So all plug-ins have to be aware of that issue as well. But I agree that doubling the Java element tree isn't an option either.
As an end user I don't care if I have a Java editor when I open a file (ending with .java) that is located in a simple project (not a java project). All actions like Open on selection won't work anyway. So why would this be a fake compilation unit? Open it as a text file and this is good enough. Then I won't be tempted to use action that will fail. See bug 38853. Note that I am not talking about a compilation unit outside of the classpath, but about a file (name ending with .java) located in a simple project.
We had PRs that users wanted to get an Outline for normal *.java files even if they don't reside in a Java Project.
Enabling the outliner should not interfere with different actions like open on selection. The actual behavior is not acceptable. The check has to be done on the UI side.
I am not saying that we don't intend to fix 38853. It is already assigned to me. I justed wanted to find a better solution than always putting the "is a fake" check into all our actions.
