In my project I throw up a JFileChooser from a JDialog to prompt the user to enter the location of the database file when starting the server. The only files valid are the .db files for this assignment. So I copied the ExampleFileFilter available in the SDK under ..SDK\demo\jfc\FileChooserDemo\src\ExampleFileFilter.java. This filter is used to filter file types in JFileChoosers.
It says in the comments of that file that it can be used as long as the required conditions are met - none of which conflict with this project. Do you think this would be acceptable to use? It works fine functionality-wise, but I don't want to get docked points for using something that is not specifically my own.
The ExampleFileFilter seems to be quite heavyweight for what it must do. I implemented a FileFilter in my application using an anonymous inner class that only overruled the accept and getDescription methods. It was not more than a couple of lines of code.
It's probably better that you write your own FileFilter implementation, since it is a requirement that all code yout submit is your own work.
I personally didn't use a FileFilter. First of all, it wasn't in my requirements. In addition, I don't recall seing any specifications about file name. Moreover, imagine the following scenario:
The Examiner (Sun employee testingSCJD projects) is having a bad day. This cranky Examiner has to test your app. Your app shows a file chooser dialog with a filter accepting only ".db" files. The file that Examiner has been normally testings the apps with is called "crash_data.txt". The Examiner is not able to choose this data file through your app. Crankometer arrow jumps into the red zone... Who knows what happens next.
So basically, that's why I didn't do it.
Joined: Dec 29, 2004
The file that Examiner has been normally testings the apps with is called "crash_data.txt".
Yes that is a possibility. For that scenario I included two filters: the *.db filter (default) and the "all files" filter for the cranky assessor