Cf. issue #44731. Seems it is quite common for
different pieces of code (in different modules) to
want to share the last file selection (or
containing directory?) in a JFileChooser, so that
the user does not have to keep on hunting around
for the right location. Probably needs to be based
on several keys, e.g.
- project type (for New Project wizards)
- project (for customizers of various sorts)
- misc. constants (for Open File etc.)
And the selections should be persistent.
Suggest something like
public class Utilities/* ? */ {
// ...
public static File getLastFileSelection(Object key);
public static void putLastFileSelection(Object
key, File file);
}

I'd suggest something somewhat simpler - don't try to listen to the filechooser
or anything, just something like:
private String pathFromLastPut = null;
private static final String DEFAULT_TOKEN = "default";
public File getLastFolder (String token) {
String name = token == null ? pathFromLastPut :
Preferences.getUserNodeForPackage (FileUtil.class).get(token);
if (file == null) {
file = pathFromLastPut;
}
if (!File.exists()) {
file = System.getProperty("user.home");
}
return file;
}
public void putLastFolder (String token, File file) {
if (file.isDirectory()) file = file.getParentFile();
pathFromLastPut = file.getPath();
Preferences.getUserNodeForPackage(FileUtil.class).put (token, file.getPath());
}
Modules can then have whatever contract they want to have for sharing tokens. I
suppose it would be a little bit nicer to be able to listen to the file chooser
and make it all nice and transparent, but the above solves a lot of it and I
can't imagine it being a big deal to implement.
Re using Preferences, this seems like exactly the sort of thing where it's
perfectly safe to do - trivial data that's never going to break anything by
being global.
Even doing the listening would be pretty painless - have a createFileChooser
method, pass it a token, and attach a weak listener that caches the file path
but can lose the file chooser, and some kind of timer to check if the file
chooser is gone, and if so store the value by the token. A little more
complicated to do right though - do you want to store the selection even if the
user cancelled the file chooser? You won't necessarily know. Rather than a
lengthy debate, the above approach would allow us to solve the major problem
quickly, and give code a choice about whether it really wants to save the value
or not.

See the patch attached to duplicate issue 152750 - I've been using a version of this in another application for some time.
The basic pattern is
JFileChooser createFileChooser (String adHocKey);
to handle the current directory on initialization.
It also handles the case of needing badging in file choosers - both the platform and project file choosers do this, and
AFAIK all of the above contain copies of the same code. It also generally makes working with file choosers easier than
remembering abstruse JFileChooser.* constants for most uses in NetBeans.

http://www.netbeans.org/nonav/issues/showattachment.cgi/73522/FileChooserBuilder.java
in other words.
[JG01] I want to see a complete patch that includes various clients - say, three or more - using the new API with all or
most of its features, and being significantly simplified or functionally improved as a result. (The dozen or so
duplicate issues were filed just for the ability to remember a default CWD by key, but I have not heard requests for the
other features of this API.)
[JG02] Your @see tag on BadgeProvider is incorrect. Try just "@see FileChooserBuilder#setBadgeProvider".
[JG03] Who is going to use BadgeProvider? Not the project chooser, which implements its own highly tuned icon badging
which cannot be accommodated by this interface. Perhaps the platform choosers?
[JG04] preventFileChooserSymlinkTraversal should probably be on by default, maybe even with no option to disable it. It
anyway only applies to Unixy platforms running JDK 5 - the default behavior on JDK 6 is correct.
[JG05] Is issue #82427 still considered important? If so, shouldn't that be covered by FileChooserBuilder as an
implementation detail?
[JG06] Utilities.showJFileChooser should refer the reader to FileChooserBuilder. (BTW you need to use the syntax
@org-openide-filesystems@ to link to a downstream API in Javadoc.)

[JG01] I want to see a complete patch that includes various clients
Easy enough.
[JG02] Your @see tag on BadgeProvider is incorrect. Try just "@see FileChooserBuilder#setBadgeProvider".
Thx.
[JG03] Who is going to use BadgeProvider? Not the project chooser, which implements its own highly tuned icon badging
which cannot be accommodated by this interface. Perhaps the platform choosers?
I just copied the code in java.platform to achieve this for CLDC, and it needs to be done for CDC and others as well;
anybody implementing something platform-like will need it as well. Would much prefer the code for this to be in one place.
[JG04] preventFileChooserSymlinkTraversal should probably be on by default, maybe even with no option to disable it. It
anyway only applies to Unixy platforms running JDK 5 - the default behavior on JDK 6 is correct.
If we can be sure there will never be a case where the default behavior is desirable, that sounds good to me.
[JG05] Is issue #82427 still considered important? If so, shouldn't that be covered by FileChooserBuilder as an
implementation detail?
Yes, it should. I'd rather get the API in place, and then if we want to do that (it sounds like maybe Dafe already did
for some file choosers), do that after some people are using it - i.e. debug one thing at a time.
[JG06] Utilities.showJFileChooser should refer the reader to FileChooserBuilder. (BTW you need to use the syntax
@org-openide-filesystems@ to link to a downstream API in Javadoc.)
Ok.
> There should be some ability for users to completely turn this off
We can provide a system property to disable it, e.g. -J-Ddisable.filechooser.history=true

"hg doesn't include things added with 'hg addremove' in a diff" - uh, yes it does. Make sure you have
[diff]
git = 1
in your ~/.hgrc (though you should not need that just to get added/removed files displayed). For more, see
http://wiki.netbeans.org/HgHowTos#section-HgHowTos-DevelopAPIReviewPatchesUsingMQ
JG06 - The syntax in Utilities.java is wrong. @org-openide-filesystems@ refers to the root of the foreign Javadoc. You
still need to interject a path and manually construct the hyperlink. Something like
@see <a href="@org-openide-filesystems@/org/openide/filesystems/FileChooserBuilder.html"><code>FileChooserBuilder</code></a>
but try actually building Javadoc and verifying that the link works.
[JG07] Do not use new FileChooserBuilder(getClass()). Use new FileChooserBuilder(ThisClass.class). Otherwise the key
will silently change when the method is ever called on a subclass. (We have the same rule for NbBundle.)

All comments addressed, tests added and documentation improved; committed in changeset f989a1086333
Notes:
- System property allow.filechooser.symlink.traversal can be used to disable preventing symlink traversal; it is on by
default, this is just in case there is some weird corner case in the future
- System property forget.recent.dirs will disable collecting of directory history (but not delete anything already
written to NbPreferences)