Primitive Queue<any T> considerations
brian.goetz at oracle.com
Wed Nov 18 20:52:52 UTC 2015
On 11/18/2015 3:38 PM, Dávid Karnok wrote:
> To be clear, I don't want to use nullable primitive long, this is what
> Long is for.
There's a big difference between these two ... a Long will entail an
indirection (as well as 2x as much memory), an Optional<long> will not.
If boxes were good enough here, we'd not need to do values...
> My problem is that the j.u.Queue.poll() relies on the ability to
> return null indicating an empty queue which when primitivized is
> likely to return zero which is also a valid value.
Ah, now I get it -- you're talking about APIs, not implementation.
Since null is not a member of all types, then methods like Queue.poll()
(and Map.get() !) are not candidates for naive any-fication. We have a
story here for binary- and source-compatible migration of such APIs to
new Optional-bearing methods while leaving the old "broken" methods in
place for compatibility with existing erased ref instantiations. We've
alluded to this briefly in State of the Specialization. Details to be
More information about the valhalla-dev