Common superclass for Optional<T> and primitive variants?

[Paul Benedict]

I think Optional would be useful for data providers that contain nullable
types. There are lots of frameworks out there (like Spring JDBC) that
provide simple query operations and return a flat collection of values.
Right now, all those values are boxed -- the specific OptionalXXX variants
could be useful to prevent that boxing.

Furthermore, if Optional was also an interface, JDBC could take advantage
of implementing the interface. Maybe Optional::isPresent() could delegate
to ResultSet::wasNull()? There would also be the opportunity for new
ResultSet methods that return a List<Optional<?>> objects.

Paul

On Mon, Mar 4, 2013 at 3:26 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Can you explain what you see as the benefit (to offset the cost of an
> additional public type)?  Where would the supertype show up in APIs?
>
>
> On 3/4/2013 3:47 PM, Paul Benedict wrote:
>
>> I think it would be a good idea to give the four Optional classes a common
>> super class. This would allow heterogeneous collections of OptionalXXX
>> objects to be returned.
>>
>> I can understand why Optional<T> is NOT the superclass so that unnecessary
>> boxing is avoided. That's not what I'm suggesting. It could simply be a
>> marker interface, if necessary, but I think equals/hashCode/toString could
>> be shared code.
>>
>> If the current Optional<T> was renamed to OptionalObj, then the name
>> Optional would free up for the common superclass.
>>
>> Paul
>>
>>