Primitive Queue<any T> considerations

[Brian Goetz]

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 
forthcoming.