Bikeshed-ish issue: Optional
David M. Lloyd
david.lloyd at redhat.com
Fri Mar 11 21:16:17 UTC 2016
On 03/11/2016 11:48 AM, mark.reinhold at oracle.com wrote:
> 2016/3/2 19:42 -0800, david.lloyd at redhat.com:
>> I notice that Jigsaw is making arguably excessive use of Optional.
>> Reinier Zwitzerloot [1] quoted Brian Goetz about this topic; the full
>> quote [2] is as follows:
>>
>> ...
>
> 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. It feels like what Brian
was referring to as "zealous over-use" to me.
--
- DML
More information about the jpms-spec-experts
mailing list