Bikeshed-ish issue: Optional

[mark.reinhold at oracle.com]

2016/3/11 13:16:17 -0800, david.lloyd at redhat.com:
> On 03/11/2016 11:48 AM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> We recently removed the most confusing use, in the return type of
>> ModuleDescriptor.Exports::targets, which now returns a simple Set<String>
>> of package names rather than an Optional<Set<String>>.
>> 
>> What other specific uses would you suggest to remove?
> 
> I think that all of the getter-style usages are definitely not in line 
> with the original intent of the class.  This would include:
> 
> • java.lang.module.Configuration#parent()
> • java.lang.module.ModuleDescriptor#mainClass()
> • java.lang.module.ModuleDescriptor#osName()
> • java.lang.module.ModuleDescriptor#osArch()
> • java.lang.module.ModuleDescriptor#osVersion()
> • java.lang.module.ModuleReference#location()
> 
> The following usages also seem excessive to me, though they aren't 
> strictly getters.  There's no stream-related use for these methods that 
> I can think of and I can't imagine a case where Optional provides a real 
> benefit, and in some cases there's a precedent for similar methods to 
> return null:
> 
> • java.lang.module.Configuration#findDescriptor()
> • java.lang.module.Configuration#findModule()
> • java.lang.module.ModuleFinder#find()
> • java.lang.module.ModuleReader#find()
> • java.lang.module.ModuleReader#open()
> • java.lang.module.ModuleReader#read()
> 
> By my count there are now more usages of Optional in java.lang.module 
> than in all of the rest of java.base combined.

Well of course not, since Optional was only introduced in Java 8.
That fact, of itself, is not an argument against using Optional in
java.base.

>                                                 It feels like what Brian 
> was referring to as "zealous over-use" to me.

I asked Brian to review the uses of java.util.Optional in the draft API.
He concluded that they were "entirely reasonable."  In response to your
comment about getters he further remarked (quoted with permission):

  This is taking my quote out of context.  By "getter", I didn't mean
  "any non-void method".  The question was in the context of JavaBean
  style classes, whose many getters are simply (usually trivially)
  mediating access to the Bean's state.  Routinely using optional for
  Bean getters (and state) would be overuse.  This is not that.

I see no need for further changes here.

- Mark