Intrusive trees are great for specialized use cases, but not for a general-purpose Java Collection. If the payload owns the left/right pointers, the same object can't cleanly participate in multiple Maps/Sets.
ChaosTree keeps the tree topology separate from the domain objects, which is necessary for a NavigableMap-style collection.
You can have both! You can of course implement the non-intrusive case on top of the intrusive one. I think that opens up interesting use cases with Valhalla.
If you need, you can trivially backport the code to JDK 11. All new Java features are essentially syntax sugar and trivial to rewrite with early Java code. Just ask LLM, they're really good and mundane and trivial rewrites.
Upgrading JDK versions isn't all that much work, and it offers very significant benefits especially when it comes to performance. Applications that don't upgrade don't have the resources to do even that; they're in minimal maintenance mode. Does it make sense, then, for a library that offers some new feature that requires at least some code changes in the application to use, to target users who don't have the resources even for a runtime upgrade?
Applications that don't upgrade their runtime are usually not in the market for new libraries (or even new features in old libraries).
You should add an intrusive variant of all the trees.
Intrusive trees are great for specialized use cases, but not for a general-purpose Java Collection. If the payload owns the left/right pointers, the same object can't cleanly participate in multiple Maps/Sets.
ChaosTree keeps the tree topology separate from the domain objects, which is necessary for a NavigableMap-style collection.
You can have both! You can of course implement the non-intrusive case on top of the intrusive one. I think that opens up interesting use cases with Valhalla.
Does this really need to be JDK 21 ?
I personally require libs that are JDK 11.
If you need, you can trivially backport the code to JDK 11. All new Java features are essentially syntax sugar and trivial to rewrite with early Java code. Just ask LLM, they're really good and mundane and trivial rewrites.
Upgrading JDK versions isn't all that much work, and it offers very significant benefits especially when it comes to performance. Applications that don't upgrade don't have the resources to do even that; they're in minimal maintenance mode. Does it make sense, then, for a library that offers some new feature that requires at least some code changes in the application to use, to target users who don't have the resources even for a runtime upgrade?
Applications that don't upgrade their runtime are usually not in the market for new libraries (or even new features in old libraries).
It uses sealed classes, JDK21 SequencedSet and SequencedMap implementation, Math.clamp(), and get benifit from modern JIT optimization.
That not much to jump all the way to jdk21.
Math.clamp is literally 2 / 3 lines.
The Tree Supports JEP431(Sequenced Collection) and my whole node structure is based on pattern match and sealed classes.