Daniel Lemire
Daniel Lemire
I agree 100%.
That’s to be expected since the interoperability guarantee only applies to the Roaring format which is 32-bit. Contributions are invited.
So we do not delete but deprecate, correct?
Do you have a specific proposal regarding how we should rename the package?
Ok. What do people think of `org.roaringbitmap1`? @blacelle ?
@richardstartin What do you think of `org.roaringbitmap.v2`?
I have changed the base for this PR to https://github.com/RoaringBitmap/RoaringBitmap/tree/1.0-SNAPSHOT I suggest that once @blacelle approves it, we merge it to 1.0-SNAPSHOT then proceed, separately, with a package renaming.
Ping @Maithem : This PR still has requested changes... Can you check?
This fellow seems to report that Java will use conditional moves just fine on its own... https://ivansmirnov.wordpress.com/2015/06/14/confirmed-openjdk-jit-compiler-emits-efficient-conditional-move-machine-codes/
Note that the evaluation of both paths is without side-effect so I do not expect that conditional moves break the specification.