Community
Participate
Working Groups
JDT/Core put code in to support compilation units with extension different than java. JDT/UI should review its code to make sure we don't require .java extensions.
This one got deferred post 3.1
I agree that full fixes can be posponed post 3.1. But it will be more efficient that the changes that Jerome made for JDT Core will go into 3.1 stream. This will allow us to start reporting sooner on problems related to UI and Debug components. Alex.
See comments in bug 71460 why we decided to not do anything in JDT/Core either.
Is this likely to be looked at for 3.2? Are there are known UI problems when the JDT/Core extension point is enabled, or is this bug for investigating the issue? I tried it briefly, and didn't see notice any problems. I'd like to see the extension point enabled, because it could help AJDT, where we have Java-like source (AspectJ code) in .aj files. Let me know if there are any specific tasks I could help with.
Matt, enableing this causes real work on JDT/UI side since we have code that assumes that types and so on always reside in *.java files. For 3.2, this is currently not a committed item.
Hi Dirk, thanks for the response. Although it's not committed, I see it is in the "top items" section of the 3.2 plan, so would it be appropriate for this bug to be reopened? I'd categorise it under the "design for extensibility" theme, which is a big deal for us working on AJDT - extending JDT to support the AspectJ language. I did notice a dependency on .java when excluding source files from the build path. Presumably the solution to issues like that is to change the logic to instead look at the extensions (potentially) defined via the JDT/Core extension point? I could work on a patch if that's an appropriate direction to start on. Do you know which other areas which make the .java assumption, or is that discovery work yet to be done?
I will discuss with the other team leads what the plan is here for 3.2. Besides JDT/UI, JDT/Debug is affected as well. A patch would certainly help to get this addressed for 3.2. When I remember correctly the biggest items in JDT/UI are: - don't assume that CUs end with *.java. This assumption is made in various place when we map types back to the file container - when we map generated class files back to source files this assumption is made as well. - when exporting Jars we assume that code resides in *.java files. And may be more. We only made a quick inventory of our code when looking at this during 3.1.
Hi Dirk, We encountered many of those areas when developing support for AspectJ code in .aj files, so hopefully our experiences there will be helpful. I have my JDT/UI development environment up and running, and I decided to look first at the issues involving including and excluding compilation units with non-.java extensions from the build path. I found the following 3 issues: 1. Build Path > Exclude doesn't work, as the wrong entry is put in the .classpath file, e.g. org/test/MyClass/foo/ instead of org/test/MyClass.foo 2. If MyClass.foo is excluded properly in the .classpath file, it isn't shown with the correct excluded icon (visually it appears to still be included) 3. The excluded MyClass.foo cannot be unexcluded from the context menu, as there is no Build Path > Include menu item for it. I was able to fix all of these with simple changes to use the routines in JDT/Core instead of hardcorded ".java" tests. These routines are in org.eclipse.jdt.internal.core.util.Util, so is it okay for now to use internal API? I guess the routines can be promoted to public API when the JDT/Core extension is enabled? My other question before putting an initial patch together is about testing - I've at least run the AutomatedSuite and that's all okay. Will manual testing and code inspection be sufficient for these changes, or are additional automated tests needed? The org.eclipse.jdt.core.tests.model plugin does define .foo and .bar as additional Java file extensions, so we can use that, but of course the handling of those is disabled in JDT/Core (I enabled it in my workspace to test in order to test it manually).
Created attachment 29182 [details] Make build path support aware of potential non-.java extensions Here's a patch with the above changes, so you can see if this is the right direction to take.
Matt, the patches go into the right directions. The only issue is that they reference internal API in JDT/Core. To avoid this I opened PR 115067 against Core so that we get official API.
reopen
I've now added non-.java support in many more places across JDT/UI. I'll attach a new patch as soon as the API in JDT/Core is added.
Martin, I am assigning this to you and marks it for 3.2 as discussed yesterday. Matt, thanks for working on this issue. We are looking forward to your patch.
Created attachment 30163 [details] Remove hardcoded ".java" dependencies This patch uses the new API in JDT/Core to fix most of the places where units are assumed to have ".java" extensions. This includes the build path actions fixed earlier, exporting of JAR files, refactor > rename actions, and rename quick fixes (the file extension is preserved). There is a second group of issues remaining - when mapping back to a file resource. I can start looking at those next. (plus there is still JDT/Debug to look at too).
patch released > 20051118 Thanks a lot, Matt. I corrected some more references to 'java'. Filed bug 117015 and bug 117016 against refactorings: We should always preserve existing file extensions. Can you explain what is the issue when mapping back to a file resource?
Martin, I was referring to those places in the code which convert a compilation unit to a path by adding ".java". I believe this is the same issue Dirk mentioned in comment #7. The additional changes you made, and the two refactoring bugs you raised have covered most of these places. I could find only one remaining place: getPathToCompilationUnit() in Bindings.java (line 1113). I'm not sure the best way to address this one. We could iterate over the file extensions in turn, until we get a path which corresponds to a file which exists. Or if possible it would be better to refactor so as to have access to the type, to avoid having to construct the path element from the name + ".java". Also, there are still a number of places which hardcode the string ".java". I believe these are valid for various reasons, such as being the default for new compilation units. But wouldn't it be cleaner to define a constant for this, like JavaContextType.NAME does for the string "java"?
getPathToCompilationUnit() is code that will go away (it is currently still there for debugging reasons, but not called). Good idea with the constant, something like DEFAULT_COMPILATIONUNIT_NAME_SUFFIX?
That name is okay. Alternatively DEFAULT_CU_SUFFIX is a little shorter. I can take a look at JDT/Debug next.
Created attachment 30385 [details] Remove ".java" dependencies in JDT/Debug I have completed my investigations of JDT/Debug. The following list shows the relevant places and indicates whether they are a) fixed by this patch, b) no fix is necessary, or in one case, c) I'm not certain, so hopefully someone more familiar with JDT/Debug can comment: JDT/Debug UI BreakpointRenameTypeParticipant line 52, fixed in this patch by using same extension as original BreakpointLocationVerifierJob line 137, fixed in this patch by using JavaCore.isJavaLikeFileName line 147: OK, as .java is only used in a name given to the parser JavaStackTraceHyperlink line 171, fixed in this patch by using JavaCore.removeJavaLikeExtension OpenTypeAction, line 162 AppletLaunchConfiguarionUtils, line 92 OK, as javaProject.findElement(IPath) still finds compilation unit JDT/Debug EvaluationSourceGenerator, line 226 LocalEvaluationEngine, lines 1199, 1282 JavaHotCodeReplaceManager, line 1126 OK, as javaProject.findElement(IPath) still finds compilation unit JavaDebugUtils line 175 - this may be ok if the returned string is used with findElement, as in the above places, but I couldn't be certain this would always in the case - it wasn't clear to me exactly when this code was called. If required, we'd need to iterate over the registered Java source extensions until finding a name which maps to a resource which exists.
Filed bug 117516 against jdt.debug. We keep this bug to track JDT.UI issues.
I fixed bug 117015 and some more references, introduced constant JavaModelUtil#DEFAULT_CU_SUFFIX, and filed bug 117696 for the only remaining issue in jdt.ui (extract interface).
I made another pass over our code to make sure that JavaCore.removeJavaLikeExtension is used instead of Signature.getQualifier(cu.getElementName()) JDT.UI is ready and suggests that jdt.core turns the switch for the Java-like extensions so we can get more experience. I think it's not a problem if not everything (e.g. debug) is ready yet, as the new funtionality only comes into the play if the user explicilty adds a new extension to the Java content type.
Bug 118617 has been filed against compare: Comparing compilation units with new file extensions don't show the structural compare view yet.
I made some testing with the switch enabled and it looks good. Setting this PR to fixed. Please continue to annotate this bug if you find issues (or file new bug reports!). > 20050112
Verifying...
Verified in I20051213-0010.
*** Bug 122487 has been marked as a duplicate of this bug. ***
I am using M20060629-1905. It seems that compilation errors are not reported on files associated with the Java editor with an extension different from ".java". Code completion and syntax highlighting sometimes fail. Some Java-specific elements in right-click menus are not shown (References, Declarations, Refactor, ...).
How did you associate the files with the editor? It only works if those files have the 'java' content type.
I forgot to set the content type, now the edition works well. But can something be done to avoid the weird behavior when the content type is not set? (or should the content type be set automatically?)
