This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This bug is about the files filter for the Java Files that is appeared in the list "Files of type:" of the "Open" dialog that is accessible via the menu item Main Menu ► File ► Open File... "Traditionally", a user-choosable filter for the Java Files is declared in the module utilities ("User Utilities") where functionality of the "Open" dialog is implemented. I guess, it is wrong location for implementation of the filter, because it is always appeared in the list independently the Java support is installed/activated on the NetBeans platform or not. I've implemented the class OpenFileDialogFilter that lets to declare the filter via a service provider. So the "Java Files" filter can be easily declared in a module that is responsible to open standalone Java files, and it will appear in the "Open" dialog only if the module is active in the NetBeans IDE. See examples in the javadoc of the class OpenFileDialogFilter [1]. [1] http://hg.netbeans.org/main/file/4124d2acbfb1/utilities/src/org/netbeans/modules/openfile/OpenFileDialogFilter.java An issue is that I'm not owning the Java support modules, and I don't know where the code of the filter should be placed, but the functionality must not be lost, and we should move the code (i.e delete and add) in a common set of changes. To simplify this transaction I've prepared a patch (it will be attached) that removes the service provider and a property from the utilities module. So, please, extend the patch by adding the deleted code in a desired module, and apply the common changes to the hg repository. BTW there is another filter for text files, but I have no any ideas where the filter should be located instead of the utilities module. What a module is responsible for opening standalone *.txt files?
Created attachment 95138 [details] The patch that removes code of the "Java files" filter from the module "User Utilities" (<hg repo main>/utilities) See the comments about applying the patch above.
I just noticed that I forgot to add one comment NOI18N NOW: return new String[] {".java"}; SHOULD BE: return new String[] {".java"}; // NOI18N Could you please, do it during transaction.
Sorry, but I am not sure if this is the most appropriate solution - should Java (and C/C++ and all other language supports) really be friends of the User Utilities module and have dependency on it? In the current situation, I would have to create a brand new bridge module, just to hold the one implementation class that would provide the filter (making java.source or java.editor depend on User Utilities does not seem feasible to me). Could you please consider some alternative approaches before we create such a module? For example, the filter could be specified declarativelly in the layer, binding a name to a list of mime types and these mime types would be used to recognize file types (would require FileObjects, but is the most precise way). Thanks.
Jan, I agree it is not the best solution. Seems requirements against an implementation should be collected and refined before to have clear constraints and criteria of quality. Probably, we also need examine a variant of extracting of the Open File functionality into a separate module to have it as an optional functionality of the NetBeans platform. Let we to suspend discussions and activities in this area until the NB6.9 release. To track this issue I'll reassign it to myself.
Please use target milestone.
Fixed, see bug 209998.