Primitive Queue<any T> considerations

[Vitaly Davidovich]

If Optional<T> (or some replacement/successor) can be made into a value
type, then it can be used instead.

On Wed, Nov 18, 2015 at 8:27 AM, Dávid Karnok <akarnokd at gmail.com> wrote:

> Hello,
>
> We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> in our library which exploits null as an indicator if the queue is full or
> not. However, this won't work in case of a Queue<any T> because for
> primitives, zero is a valid value.
>
> I see two options:
>
>   - use wider primitive and atomics-acessible types: byte -> int, char ->
> int, short -> int, int -> long, float -> long, double -> 2 slots long and
> long -> 2 slots of long
>   - don't use fast-flow and go back to producer-consumer index comparison.
>
> In either case, the internals and the usage have to be changed drastically,
> i.e., switch to AtomicLongArray, how to indicate the queue is actually
> empty when calling poll(), etc. Perhaps a new queue interface is necessary
> where poll returns a boolean indicator and calls a Consumer if the data is
> there.
>
> The examples I saw regarding valhalla showed List<any T> where I'd guess
> the internals of the ArrayList can be altered in a straightforward manner
> but I don't see how this could happen if the algorithm itself has to change
> based on what primitive T is.
>
> What are the plans for supporting such kind of specializations?
>
> --
> Best regards,
> David Karnok
>