Community
Participate
Working Groups
Enhancement request for 3.1 stream. Files with non *.java extension, but with normal Java contents should also be treated as normal Java code, when associated with Java type editor. All core functionality (like code outline, automated builds, code completion, etc.) should also be available, not only source syntax highlight. I'm trying to make Eclipse based project with Apache Beehive. All JPF, JCS, JCX, etc. files are normal Java files with JSR 175 annotations. I would like to preserve the compatability with Beehive defined extensions for the future, while working normally on Java code. Thanks, Alex.
see newsgroup: Re: Any idea about feature request id=71460 http://www.eclipse.org/newsportal/article.php?id=11919&group=eclipse.tools.jdt
Will conduct preliminary investigations before committing.
I can't wait for this enhancement ...
I'm trying to reuse org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor using editor extension like but to set different file extension: <extension point="org.eclipse.ui.editors"> <editor name="Java Editor" default="true" icon="icons/full/etool16/beehive.gif" extensions="jcs,jcx,jws" contributorClass="org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditorActionContributor" class="org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor" symbolicFontName="org.eclipse.jdt.ui.editors.textfont" id="org.eclipse.pollinate.editors.CompilationUnitEditor" /> </extension> But with no much luck: only coloring scheme is working fine. Is there any hack I may use to make this extension work more like a Java Editor? What is the status of this bug? Any tip will be appreciated. Thanks, Alex.
I tried to make very obvious/naive hack to allow non .java extensions files with Java content to be treated as normal Java files and I was partially succeeded. The idea was to set public static org.eclipse.jdt.internal.core.util.Util.JAVA_LIKE_EXTENSIONS array to desired extensions. I've created a startup extension to do the work: public class ChangeExtensions implements IStartup { public final static char[] SUFFIX_jcs = ".jcs".toCharArray(); public final static char[] SUFFIX_jcx = ".jcx".toCharArray(); public final static char[] SUFFIX_jws = ".jws".toCharArray(); /* (non-Javadoc) * @see org.eclipse.ui.IStartup#earlyStartup() */ public void earlyStartup() { Util.JAVA_LIKE_EXTENSIONS = new char[][] { SuffixConstants.SUFFIX_java, SUFFIX_jcs, SUFFIX_jcx, SUFFIX_jws }; } } And I've used simple file to test (Test1.jcs): package pkg; public class Test1 { public static void main(String[] args) { System.out.println("Hello"); } } The hack was working with this code: I was able to get most of actions that were missing before and even the builder was able to compile it into class file. However, there was a problem report in the editor (if I've tried to change something) saying that Test1 class must be defined in it's own file (there was no such problem report in the problems view and no problem marker in package explorer, only editor). Also the editor lost most of the syntax highlight and package explorer changed the icon to Java default icon. I've looked back into the Util class and found the "defaultJavaExtension" method. This method obviously a source for trouble in this case. I don't know if there are any hardcoded dependencies on java file extension... I hope this helps. -alex
Created attachment 17658 [details] Patch fixes some hardcoded dependency on *.java extension Continuing my hacking effort to support non *.java extensions with JavaEditors this patch provide some tiny, but healthy fix in CompilationUnit class.
Created attachment 17686 [details] Another patch to fix hardcoded dependecy on java extension This tiny patch supplement the fix of hardcoded dependency on ".java" extension in JDT Core. In fact I've made brutal text search on ".java" and find out *a lot* of hardcoded ".java" constants in UI, debug, and other non-core plugins. It looks like it will be not that simple to make this enhancement...
Thanks Alex for your effort. I just committed changes that remove all hardcoded dependency on .java extension in org.eclipse.jdt.core. You should enter separate bugs against the other plugins that hardcode this dependency.
Jerome, Is Util.JAVA_LIKE_EXTENSIONS a correct way to contribute new extesions to the model? There would be a need to define the contribution pattern somewhere. Thanks, Alex.
No, Util.JAVA_LIKE_EXTENSIONS is not the correct way to contribute new file extensions. I changed it to private and added an extension point (extraJavaLikeFileExtensions) to add other Java-like file extensions to JDT Core. The schema of this extension point is defined in schema/extraJavaLikeFileExtensions.exsd. An example is as follows: <extension point="org.eclipse.jdt.core.extraJavaLikeFileExtensions"> <extraJavaLikeFile extension="foo"/> <extraJavaLikeFile extension="bar"/> </extension>
I've re-opened, just to request reasoning be documented, if not changed. Why provide a new extension point for this, instead of using platform's contentType extension point? Whouldn't the contentType allow more consistent treatment (consistent accross platform, that is, for example, if/when there was a mechanism for users to influence the defintion of a contentType, associate an editor with it, etc).?
Interesting idea, how would you imagine clients to contribute their custom Java-like extensions ? for instance, this is our contribution for "java" files. <content-type id="javaSource" name="%javaSourceName" base-type="org.eclipse.core.runtime.text" priority="high" file-extensions="java"/> Do you imagine some extra attribute, where clients would specify they want it contributed as a java-like contents as well ?
Part One: the easiest way If clients just wanted to add a file extension to what's considered 'java', the following should work: <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.jdt.core.javaSource" file-extensions="jav,javaAlso"/> </extension> The implementations that currently look for java file extension would have to be changed to look at the resource's contentType (id.equals("org.eclipse.jdt.core.javaSource") the contentType framework accumulates contributed file extensions (doesn't replace them)
Part Two: slightly more sophisticated If the implementation was changed to instead of looking for literal java content type id, it got the java contentType object (from content type manager) and then got the resource's content type, it could use 'isKindOf' to see if the resource was extending java -- the assumptioning being that all the base java stuff should still work, but client's code might do something special (like aspect J looks into comments to get special info). Clients would then indicate this extended java file type using following type of extension, indicating that files with "javaPlus" extension should be treated as java (but their own add-on function could detect 'javaPlus' specifically to do its special thing). <extension point="org.eclipse.core.runtime.contentTypes"> <content-type priority="medium" name="Java Plus Content" id="javaPlusSource" base-type="org.eclipse.jdt.core.javaSource" file-extensions="javaPlus"/> </extension>
I could add ... at one time it was suggested the Eclipse 3.1 theme of "Design for extensibility: Be a Better Platform" explicitly mentioned that "content types should be implemented consistently through out the base" but seems it was omitted in final version -- probably because writers didn't know know what it meant :)
I've added bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=89266 for UI plugin.
Re: comment 14 - what David suggests would be the recommended approach for supporting *regular* Java source files with file names different than *.java. Clients interested in Java source files could then obtain the corresponding content type (org.eclipse.jdt.core.javaSource) and for every file of interest do: if (!javaSourceFile.isAssociatedWith(fileName)) //ignore, name does not match Java source file return; // do Java-only related work That would allow Java source files to have any name, and does very little work (file name matching only).
Re: comment 15 Making a content type B derived from an existing content type A only makes sense if: i) all occurrences of the derived content type (B) are valid occurrences of the base content type (A), and ii) not all occurrences of the base type (A) are valid occurrences of the derived type (b). If only i) is true, B is actually A, so no need for another content type, just add new file patterns to A. If only ii) is true, then B should not be derived from A. It may be similar but is actually an unrelated content type (for example - AspectJ is not an eligible derived type of Java source - it is actually the other way around). If both are true, Dave's suggestion is correct. Clients looking for Java source files could do: IContentType javaSource = Platform.getContentTypeManager() .getContentType("org.eclipse.jdt.core.javaSource"); IFile file = ...; IContentDescription description = file.getContentDescription(); if (description == null || !description.getContentType().isKindOf(javaSource)) // not a valid Java file return; // process Java and special (but backward compatible) Java files That being said, if all that is wanted here is a common way of handling the Java family (AspectJ, SQLJ, Java, JSP), then I would say you do need an extension point for that, but would strongly recommend basing such extension point on content type ids, instead of file names. This exactly what we are trying to avoid with the content type framework. All file associations should occur through content type assocations. Sorry for talking about so many options, but I do not know what the exact requirements are here, so I thought I should at least be as informative as possible.
*** Bug 89266 has been marked as a duplicate of this bug. ***
Thanks David and Rafael for the explanation. I confirm that we want to solve the problem described in comment #14 (i.e. supporting *regular* Java source files with file names different than *.java). The other problem described in comment #15 is not part of the original request. Moreoever JDT Core is not ready to support files with contents other than pure Java. So David please feel free to add a bug report requesting that, since it is a much harder problem, we won't be able to do it soon.
Thanks for the comments. Actually, I don't have a specific need at the moment, I was just trying to highlight the advantages of moving to 'contentType' based approach. You could evolve in future. Do your remarks mean you'll provide the solution suggested in #14, instead of introducing a new file extension based extension point. (If so, great, and thanks).
You guessed right :-) Removed the extraJavaLikeFileExtensions extension point. Changed Util.getJavaLikeExtensions() to use the content type manager and retrieve the file extensions for the "org.eclipse.jdt.core.javaSource" content type. Updated the tests to use the "org.eclipse.core.runtime.contentTypes" extension.
Verified in I20050330-0500
I20050330 I was expecting the Java builder to honor the Java source file content type settings, but that does not seem to work, no class files are generated for a Java source file having a non .java extension. Am I missing something?
Rafael, I just noticed that you could dynamicaly update the content-type through the preferences page (hidden in the editor preferences (bug 89787)). Is it the way you added a Java file extension ? My understanding was that content-types were statically set. It looks like I was wrong. The current implementation caches the Java file extensions on start up. (I'm not sure we can afford to dynamically look them up).
JDT UI is not ready for this feature yet: they hardcode the .java file extension in many places, they need more time to remove this dependency and test it. So this feature cannot go into 3.1 M6. Reopening and disabling the support in JDT Core for now. Changed org.eclipse.jdt.internal.core.Util#getJavaLikeExtensions() to just return the ".java" extension and disabled JavaProjectTests#testExtraJavaLikeExtension1() and testExtraJavaLikeExtension2().
Rafael, looking at IContentTypeChangeListener, I noticed the following note: * Clients who reference the <code>org.eclipse.core.resources</code> * bundle are encouraged <em>not</em> to use this listener mechanism to * listen to content type changes. The Core Resources bundle will * propagate changes to content types and notify clients appropriately * via the resource change mechanism. However, looking at IResourceDelta, I don't see any flag indicating that the content-type has changed. How am I supposed to know that an .abc file is now a Java source file ?
Re: comment 26 - yes, they can be changed by the user. >The current implementation caches the Java file extensions on start up. >(I'm not sure we can afford to dynamically look them up). I am not aware of all your requirements, but couldn't you cache for a file scan operation only? In what scenarios are you concerned about the performance of matching a file name against the Java content type?
Re: comment 28 - please disregard that blurb, it is bogus. I am going to fix that. Anyway, what it should be saying is "Clients who reference the org.eclipse.core.resources bundle are encouraged not to use this listener mechanism to detect encoding changes. The Core Resources bundle will detect changes to content types and notify clients appropriately of potential changes to the encoding of files in the workspace via the resource change mechanism."
So ... (If I may request elaboration), IContentTypeChangeListener is the way to detect changes in content type itself? (Just not encoding).
Yes. That API was added late during the 3.0 cycle in the context of bug 59899. The event itself does not tell you about what exactly changed, only that user settings for that content type changed. Dynamic addition/removal of content types (by adding/removing plug-ins dinamically) are *not* reported.
Jerome, Can you enable the fixes for JDT Core before 3.1 ships. As of my understanding this should not brake other functionality (that based on *.java extensions). But this will allows us start testing and reporting problems for non-java part sooner. Thanks, Alex.
We have been debating whether we should include into M7 timeframe some support for non-"java" file extensions. In brief, given this item is not committed and in agreement with PMC, we are proposing to defer it post 3.1. We believe it could jeopardize our 3.1 schedule, since it is quite a big piece of work to complete. As of today, JDT/Core has (disabled) support for non-"java" file extensions, in a static way (i.e. relying on content type extensions in plugin.xml). We don't support dynamically changing them (this is quite a big amount of work to get there, since we need to broadcast changes to clients when tons of resources are suddenly changing their Java nature. And we get no support from platform there). On JDT/UI & Debug, there is no support at all implemented today; and there are significant algorithms to rework in order to get there. Also testing will be involving, since we have no client for it either. We want to keep room for addressing issues near 1.5 support, access restrictions and performance (plus normal bug fixing activity).
Just to clarify: the code can't only be enabled in JDT/Core. This would face the UI with elements it currently can't deal with asking for lot of trouble.
As this was deferred to post-3.1, can it now be reopened? I think it would be a good idea to re-enable the extension point, to help flush out the remaining problems during 3.2 development.
Sorry we must ensure that UI and Debug behave correctly (see bug 89977) before we can enable this extension point.
Reopening since UI and Debug are now ready
Changed org.eclipse.jdt.internal.core.util.Util#ENABLE_JAVA_LIKE_EXTENSIONS to true. Also added constant JavaCore#JAVA_SOURCE_CONTENT_TYPE to retrieve the Java source content type from the content type manager (see org.eclipse.core.runtime.content.IContentTypeManager#getContentType(String))
For those trying this support, be aware of the following limitation: Due to bug 118619, it is not possible to update the Java model when a file extension is added to the Java source content-type through the UI. One has to either exit/restart Eclipse, or close/reopen the affected projects.
Verified for 3.2 M4 using build I20051212-0010
