1.0.4 "Bats and Hats"

This release only updates some dependencies and moves the com.github.tommyettinger.ds.support.function package to com.github.tommyettinger.function, in the new funderby library that is now a dependency. There are many more functional interfaces supported by funderby than ever were supported by jdkgdxds, though probably not too many, because each one is so small. Most code that uses functional interfaces via lambdas won't need any changes.

1.0.3 "Finger Food"

This release removes the required dependency on juniper (it is still recommended if you use any randomized methods, though) and improves the behavior of the hash multiplier changes to work a little better with problematic Strings. Now jdkgdxds only depends on digital 0.0.3 at runtime, plus jsr305 3.0.2 (for common annotations). There aren't many other changes here, though there is one breaking change as a result of not depending on juniper -- Arrangeable.rearrange(EnhancedRandom) is now Arrangeable.rearrange(long), and it doesn't need to attempt to reset the state of an EnhancedRandom now that it can simply generate random numbers from a long seed. Other breaking changes happened earlier; if you rely on EnhancedRandom being an interface (which is a property from before 1.0.1), then you may need to change to using the java.util.Random class instead, or the EnhancedRandom abstract class from juniper.

The map and set methods may be a little slower on average, but should be drastically faster in the worst-case. You can always override the place() method and replace it with a hash mixer of your choice, such as the older place() method from jdkgdxds 1.0.1 .

1.0.2 "Scrambling To Freedom"

This release has virtually no public API changes, but instead is meant to protect maps and sets against some uncommon (but severe) cases that could make normally-quick operations take hours. It changes the Fibonacci hashing to use a different multiplier after each time resize() is called. That's about it! The actual change to each affected class is quite small, and there will actually be no change for maps and sets that are created with enough capacity that they don't need to resize(). Performance should be about the same; because the different multiplier chosen on each resize could be better or worse for any particular data, it's hard to generalize how much the change in multiplier will affect most maps and sets. We do know that this helps prevent a specific DoS vector, so it's probably worthwhile to update.

Note that this depends on the same versions of juniper and digital as release 1.0.1 did.

1.0.1 "Zero To Hero"

It's the first[citation needed] 1.x release of jdkgdxds! Ignore that the version number isn't 1.0.0, but pay attention to the several small breaking changes! Now jdkgdxds depends on digital and juniper, two other libraries by the same author (tommyettinger), so external code can depend on just common math code in digital or just that and random number generators with juniper. You will likely need to change some import statements; see README.md for more. Other changes aren't especially likely; other than one method which moved from EnhancedRandom to Arrangeable, there aren't any other known breaking changes here. There aren't many new features here, though there are in the new libraries. Arrangeable has a rearrange(EnhancedRandom) method, I guess. But hey, go wild, it's 1.0.1! Any additional major breaking changes will go into another major version increase.

0.2.8 "Yes, All of Them!"

This release adds a few new random number generators (including one optimized for GWT performance, ChopRandom), adds some more API to QuickSelect and NumberedSet, and most importantly, makes removeAll() act the same for ObjectList and the various primitive lists, such as IntList and DoubleList. The problem before was that the JDK List method removeAll() removes any occurrences of any items that appear in the Collection parameter, while IntList matched libGDX's IntArray behavior and would only remove occurrences on a one-for-one basis with the parameter. That is, if an item occurred once, it would only be removed once from the IntList, and if it occurred twice, it would be removed twice. The old removeAll() behavior (matching libGDX to at least version 1.10.0) is still available as removeEach(), and removeAll() should act like the JDK version everywhere here now.

0.2.7 "Tiny Trim"

This release fixes the shrink() method in maps and sets when the shrink would have reduced the table's capacity to less than what it needed to hold its current items. Because some usage may want to indiscriminately (or by iteration order, from the end, for ordered maps and sets) remove items until a specific size has been reached, there is now a truncate() method on all maps and sets. There was already a very similar truncate() on lists.

There are some fixes and additions to the random number generator code. To help ease conversion between the similar codebases of ShaiRandom and jdkgdxds, MizuchiRandom was added here. Mizuchi is similar to LaserRandom in that it has two states, but has less correlation between initial seeds and the resulting sequence; it is, however, slightly slower than LaserRandom usually, and does not allow skip(long). TrimRandom changed slightly in what constants it uses and has become much more robust as a result; it is now considered stable. FourWheelRandom.previousLong() was badly broken before and is now fixed.

If you're looking in the tests, there is an actually-working map that uses Cuckoo Hashing with a Stash (ObjectObjectCuckooMap), and it can take 500,000 keys with identical hashes but different equality (albeit slowly). This was something that everyone tried to find and no one fully solved before I decided to bite the bullet and reimplement all of libGDX's hash-based data structures. Now it is solved, but because insertion into a cuckoo-hashed map is just generally several times slower than the style jdkgdxds uses, without any operations being drastically faster, it's best that jdkgdxds sticks with what it has already.

0.2.6 "Ordered Disorder"

This release rolls back a change in 0.2.4 and 0.2.5, where addAll() methods were defined for both the current data structure type's parent when passed as an argument (such as ObjectOrderedSet.addAll(ObjectSet<T>)) and for the more general case taking an Ordered implementation (such as ObjectOrderedSet.addAll(Ordered<T>). This caused a conflict when passing an ObjectOrderedSet to addAll(), because it satisfies both types. The same was true for enough other types that this newly-added Ordered overload caused pretty severe problems in the largest project that uses jdkgdxds, to my knowledge (SquidSquad), so a new release was in order. No other changes are present.

0.2.5 "Ranger Danger/Wrapper Zapper"

This is a bit of a hasty release to fix the entirely broken WrapperRandom in 0.2.4, and realign some documentation and implementations so they all match regarding removeRange(). Now all removeRange() methods follow the behavior of ArrayList, where start is inclusive and end is exclusive. About WrapperRandom, it wasn't tested before and is now. There was a severe problem in how its constructor called Random's super-constructor, and though it is resolved now, in 0.2.4 constructing a WrapperRandom would have resulted in an exception.

Here's to a more stable release next time.

0.2.4 "By Bow And By Blades"

This release adds a bit of support for ranges in addAll(), putAll(), to some extent removeRange(), and copy constructors in most of the ordered data structures. Some example usage is described in the README.md. There's also the new (but not yet stable) TrimRandom, and WrapperRandom for making EnhancedRandom implementations act like Random subclasses. Some bugs were fixed in ensureCapacity(), which didn't act as its docs described in some classes. In the tests (not actually part of this release), there's some experiments that might actually fix the Cuckoo Hashing based maps used by libGDX 1.9.10 and sometimes by Kryo still. This library exists because I was familiar with the libGDX data structures when I replaced the 1.9.10 maps and sets and wrote the versions that went into 1.9.11, so having finally come closer to fixing the original Cuckoo-based maps/sets is a nice feeling. It's entirely possible the fixed version still crashes and burns with an OutOfMemoryError in some cases, which is part of why it isn't used in the regular library (the other part being that insertions are very slow compared to what we have now).

Note: The removeRange() methods are a work in progress, and may change names, semantics, return types, etc. in future versions. The other new constructors, methods, and overloads should be considered more stable and usable.

0.2.3 "Gotta Keep Em Iterated"

This release mostly contains fixes for the iteration through int- and long-keyed maps, as well as fixing two-argument nextInt() and nextSignedInt() for EnhancedRandom, adding BooleanDeque, and some miscellaneous other improvements. The iteration fixes are the most important of these to have in a stable release, though it's also nice to have rand.nextInt(low, high) not return some large, out-of-range value.

I also was able to finally fix the issue that precipitated jdkgdxds existing: libGDX 1.9.10's cuckoo-hashed maps would produce OutOfMemoryErrors in some situations (that could be exploited easily by unskilled malicious actors). Now there's a ObjectObjectCuckooMap in the tests that includes a fix for that... but benchmarks showed that even with cuckoo's supposedly better algorithm that guarantees constant-time containsKey(), if the cuckoo-map can't fail, it can't have constant-time operations as a tradeoff. They also showed that it's significantly slower at insertions (0.5x throughput) and not significantly faster at anything (nothing over 1.1x throughput). So, we can be fully satisfied with the algorithm used currently in jdkgdxds (and libGDX).