Common superclass for Optional<T> and primitive variants?

Paul Benedict pbenedict at
Mon Mar 4 14:04:40 PST 2013

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.


On Mon, Mar 4, 2013 at 3:26 PM, Brian Goetz <brian.goetz at> 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

More information about the lambda-dev mailing list