Spliterator flags as enum (was Initial java.util.Spliterator putback)

Joshua Bloch josh at bloch.us
Thu Mar 28 12:14:54 PDT 2013


On Thu, Mar 28, 2013 at 12:06 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 03/28/13 14:52, Joshua Bloch wrote:
>> Doug,
>> I don't get it. You can set and unset flags on your own EnumSet.  Why
>> isn't that
>> sufficient?
> There are a lot of problems. First, even
> though most spliterators will return the same set of
> characteristics each time, you can't just create one static one:
> class MySpliterator { ...
>   static final EnumSet<Characteristics>  cs = EnumSet.of(...);
>   EnumSet<Characteristics>  characteristics() return cs; }
> }
> ... because you cannot risk that no one will modify.

Sounds like a perfect opportunity to put in immutableEnumSet, which is
trivial to implement and generally useful. Alternatively, don't share, and
see if the performance it good enough.  (I suspect it will be.)

Second, when inside streams, you'd have to create a new EnumSet
> Object across each stage, that somehow secretly extends the
> public Characteristics with non-public internal control flags.
> Which means either some slow conversion table or grabbing
> private EnumSet internals.

Or having two EnumSets: one public, consisting of public constants, and one
private, consisting of private constants. Again, doesn't sound like a big

So it is both slow and painful.

You haven't convinced me of either (yet).  Did you measure the performance?

> I tried to make it less so,
> knowing that people sometimes react hostilely to plain bit
> sets. But I'm sure that the current scheme is better than all
> I tried. (Ditto for Brian Goetz and Paul Sandoz).
> In fact, I think the current scheme is sorta nice in
> an absolute sense.

Could be.  I haven't seen it. That said, I find that bit fields are usually
not a good idea in the post-enum age.


More information about the lambda-dev mailing list