David, Yes they could be combined. However, the one in Java is a proxy for the actual implementation in Memory, except for one method, which is a real fast, trimmed-down version of XxHash for just a single long. The proxy does not use Unsafe or anything like that. I can't remember why I added the single long method except that somebody must have asked for it. It is not used in DS-java.
By the way, I think we should consider getting ready for a Memory release. I also looked at the effective pom length -- the PR you submitted reduced the length by 149 lines, from 7215 to 7086 ! I did scan it a bit, and it turns out all of the boiler-plate is duplicated multiple times. And, come to think about it, perhaps that is what the effective pom is -- it resolves all properties and inheritance down into one big file, so in operation, there are no lookups (or lookbacks). So, I'm not sure that creating an intermediate parent would change the length of the effective pom. I just don't know. Perhaps some research will tell us. Having an intermediate parent would simplify the human readable poms for sure. :) Lee. On Mon, Jul 19, 2021 at 2:21 PM David Cromberge < [email protected]> wrote: > Hi Lee, > > These changes make sense, and will simplify the migration effort to > support the JPMS and later versions of Java as you mentioned. > > Whilst testing the new datasketches-memory changes currently in master > (v2.0.0-SNAPSHOT), I also identified XxHash64 in datasketches-java as a > candidate for migration to the DS-memory package. This is because it uses > numerous fields from the org.apache.datasketches.memory.internal package. > Since there is already an XxHash implementation in dataskethes-memory, the > two could probably be consolidated. I’ve just noted it here in case you > missed it in changes. > > David > > > On 19 Jul 2021, at 17:02, leerho <[email protected]> wrote: > > > > David, > > > > Last night I moved DS-java/datasketches.hash/MurmurHash3v2 to > datasketches-memory, which caused an interesting problem. > > > > When I tried moving the corresponding test file from -java to -memory it > revealed that the test file is actually doing comparison testing against > the DS-java/datasketches.hash/MurmurHash3, which is a reverse dependency -- > not a good idea! So I moved the test class back. This means that while > the main MMH3v2 is in DS-memory, the exhaustive testing of MMH3v2 vs MMH3 > is in the DS-java repo. I will add a much simpler test of MMH3v2 in > DS-memory to keep the coverage high. > > > > Also, I want to clean up the remaining uses of DS-memory/UnsafeUtil in > DS-java, which are just a few uses of the static checkBounds(). This tiny > method can be easily duplicated in DS-java. Once this is done, DS-java > will not have any dependencies on DS-memory other than strictly public API > in DS-memory -- and no dependency on DS-memory/internal either. This will > pave the way for simpler modularization of DS-java and compatibility of the > DS-java component well past JDK-13. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
