Allow traversal to home directory with single button click - p4

[ghost]

When opening a file, it's convenient to have a single button that may be clicked to navigate to the user's home directory. For example:

1. File chooser opens
2. Click "Home" icon
   • File chooser navigates to System.getProperty( "user.home" ); value

Optionally, a button to navigate to the "user.dir" directory (user working directory) may be useful.

[io7m]

Yep, sounds good. I'd like to pass both of those values in via the immutable configuration value (as Optional<Path> values), and then only show the buttons if those values have been provided.

[ghost]

For what it's worth, see https://rules.sonarsource.com/java/RSPEC-3553 :

The Java language authors have been quite frank that Optional was intended for use only as a return type, as a way to convey that a method may or may not return a value.

[io7m]

And for that, it's valuable but using Optional on the input side increases the work you have to do in the
method without really increasing the value. With an Optional parameter, you go from having 2 possible inputs:
null and not-null, to three: null, non-null-without-value, and non-null-with-value. Add to that the fact that
overloading has long been available to convey that some parameters are optional, and there's really no reason
to have Optional parameters.

I completely disagree with their assessment, and their complaints actually don't apply in this particular case.

With an Optional parameter, you go from having 2 possible inputs...

Nope. Sensible codebases reject null as a value anywhere. It was a language design mistake to have pervasive nullable references everywhere, and it's a mistake that hasn't been repeated in modern languages that have more sensible type systems. null is never an acceptable value in the jwheatsheaf codebase.

Additionally, immutables.org generated types include the following methods for a property x of type Optional<T>:

Builder setX(T x);
Builder setX(Optional<T> x);

So the "it's inconvenient to wrap values in Optional" criticism doesn't apply. Both methods reject null values immediately.

A key point that everyone misses is that in null-hostile codebases, Optional is the one and only technique by which we indicate that a value may not be present at the type level. A nullable reference T communicates absolutely nothing; it might be safe to dereference, it might not - at least with Optional<T>, the mere presence of the Optional type indicates to you that you should be checking first.

When Project Valhalla is completed, we'll have a way to express truly non-null values at the type level. As the next stages of Project Amber are completed, we'll gain the ability to pattern match on Optional values and I suspect some of the unsafe methods on Optional (such as get) will be deprecated...

if (x instanceof Optional.of(y)) {
  // safely use the guaranteed-non-null y value here
}