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.

Bug 181989

Summary: User-choosable filter of the "Open" file dialog for the Java Files
Product: utilities Reporter: Victor Vasilyev <vvg>
Component: Open FileAssignee: Jaroslav Havlin <jhavlin>
Severity: normal    
Priority: P3    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 209998    
Bug Blocks:    
Attachments: The patch that removes code of the "Java files" filter from the module "User Utilities" (<hg repo main>/utilities)

Description Victor Vasilyev 2010-03-14 17:00:58 UTC
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].


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?
Comment 1 Victor Vasilyev 2010-03-14 17:06:38 UTC
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.
Comment 2 Victor Vasilyev 2010-03-14 17:14:14 UTC
I just noticed that I forgot to add one comment NOI18N 
            return new String[] {".java"};
            return new String[] {".java"}; // NOI18N

Could you please, do it during transaction.
Comment 3 Jan Lahoda 2010-03-19 11:13:38 UTC
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.
Comment 4 Victor Vasilyev 2010-03-24 05:20:14 UTC

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.
Comment 5 Alexei Mokeev 2010-03-24 05:35:17 UTC
Please use target milestone.
Comment 6 Jaroslav Havlin 2012-08-30 15:03:00 UTC
Fixed, see bug 209998.