Community
Participate
Working Groups
Please provide Java class content type. I will attach a patch for org.eclipse.jdt.core that does that. This will enable the Java class file viewer to be bound to the content type instead of to the file name. See bug 89232 and bug 89240 for more details.
Created attachment 19296 [details] patch for org.eclipse.jdt.core The only changes required are in plugin.xml and plugin.properties.
Is it making the classfile viewer any slower ?
Yes. For class files as files in the workspace, there will be an additional (partial) file read (should be a one-time only hit though). For class files in JAR files, it depends on how the client is implemented. I am not sure if the regular editor association mechanism is used. Daniel, do you know how this is done?
For stuff in JARs we use IDE.getEditorDescriptor(input.getName()), e.g. IDE.getEditorDescriptor("Test.class"). Will this still work if we (JDT UI) only contribute the class file editor to the new Java class content type? As you suggested we should remove the file-based contributions.
My reading of related issues is that this extension point is only meant to provide hints to editors. Then its name sounds confusing as it is fairly generic, and suggests all tools would use it over the file extensions. If so, and it is slower as you said, this might be deadly for JDT/Core, and simply prove inadequate.
DM: Just talked to Kim Horne about this and she confirmed it should work. Note though that since contents are not being taken into account, you might end up with an editor that is not the most appropriate. This would not be an issue for class files though. PM: the content type extension point *is* meant to be the single file name based registry in Eclipse. See the summary for bug 37668. It is currently used for encoding determination, compare merger/viewer selection, content-sensitive object contributions, document setup participants (filebuffers) and recently editor selection. "If so, and it is slower as you said, this might be deadly for JDT/Core, and simply prove inadequate." I am not sure you are talking about issues in the context of of editor selection, or you have other use cases in mind. For editor selection, it should not be a big deal. Re: my own comment 3 - since class files are frequently rewritten, the caching scheme for files in the workspace would actually not be very helpful.
Note that JDT Core will never rely on the content-type to find out if a file is a Java class file. This would mean that every single .class file in the workspace would need to be opened, and this would slow us down to a crawl. We currently rely on the file extension and we have no plan to change this. Now it might still make sense to have the Java class content-type defined in JDT Core, as dependent plugins could benefit from this content-type. First I would need to understand the implications. Since I'm not familiar with this content-type notion, can you please tell me which Platform APIs use/return the content-type ? TIA.
We did not expect JDT/Core to use the content type. Still, as you mention, jdt.core is the best place for defining any content types supported by the JDT feature, because it is the only essential plug-in. IContentTypeManager/IContentTypeMatcher in org.eclipse.core.runtime.content and org.eclipse.core.resources.IFile.getContentDescription() are good starting points. From there, you can find all clients. Also, in comment 6 I mention what use cases are based on content types so far (you can add Team binary vs text determination). Maybe if I knew what kind of implications you are looking for, I may be able to be more helpful.
Thanks Rafael. I just wanted to make sure that we don't use any of the methods that are affected by this change. So it looks like we're okay. I released your patch.
Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD.
