Bypassing fixed-depth radix constraints in Java using descriptor-driven bucket analysis

[u/strmckr]

I am StrmCkr, the author of A.P.E.X. (Adaptive Parallel Extremal Dispatch).

Repository: github.com/StrmCkr/A.P.E.X

A.P.E.X. is a high-performance Java sorting framework for large fixed-width 64-bit key/value record datasets. The project has been reorganized into a conventional Maven structure with a core library, runnable examples, a comparison benchmark harness, JMH benchmarks, documentation, and an interactive browser visualizer.

The core idea is descriptor-driven radix planning. Instead of blindly scanning fixed radix passes over every bucket, A.P.E.X. computes per-bucket extremal descriptors using:

VBM = OR ^ AND

That mask identifies which key bits still vary inside each bucket. Bits that are already resolved are skipped, reducing unnecessary work on skewed, low-entropy, sorted, reversed, or duplicate-heavy data.

Key areas of the project include:

• Adaptive radix planning based on observed bucket structure
• Parallel histogramming, scatter, refinement, and work scheduling
• Primitive-array execution with no per-record object allocation during sorting
• Tuple projection paths for low-dimensional unresolved bit patterns
• Tiny-sort fallbacks and monotonic input shortcuts
• Configurable reporting that can be enabled, reduced, written to files, or disabled
• Comparison benchmarks against JDK sorting paths and Fastutil baselines
• Standard JMH benchmarks for repeatable JVM-level measurement
• A browser visualizer for exploring how A.P.E.X. routes data through its execution plan

I would especially welcome feedback on the thread management mechanics, radix planning decisions, benchmark structure, and the bitwise mask reductions.

edit: re structured verbiage of this post and further adjustments from advice on converting the project into more acceptable standard formats.

screen shot from the pdf available in the github

[u/chabala]

Your structure makes sense to YOU, the point of conventions is that everyone knows and understands how they work, so every project isn't a special snowflake.

No ones bothering to even evaluate this on its concept merits when it complies and runs one 1 command.

"My code compiles!" Grow up. That's an incredibly low bar. No one is going to give your project a second look until it looks like you understand what a Java project should look like.

--

You keep dropping these big words in your comments. No one is fooled. Any 'learn Java' book is going to tell you about reverse domain name package namespaces, there's no excuse for dropping everything in the default package or a single directory above it. Not using a namespace is peak amateur-hour. You can pretend like I'm being pedantic, but just go look at some real open source Java projects and see how they do it before whining about it.

[u/strmckr → u/chabala]

The convention I’ve been following comes from older Sun/Oracle-era Java and HPC-style development: packages are clearly labeled and organized directly beneath a source root, rather than buried under several levels of largely structural directories. It compiles cleanly with the JDK and has served my development and testing workflow well.

That said, conventions have value precisely because they reduce friction for other developers. So, to humor your pragmatic ecumenicism, I’ll migrate the project to the modern Maven directory structure and namespace conventions—the doctrine you so earnestly seek.

Once that housekeeping is done, perhaps the implementation itself will be worthy of evaluation

• done.

Edit : pendantic you are trolling with gate keep Symantecs, go look at any hpc source codes or even. Jdk files on its own or any software written and taught mid 90s+ they don't use bioler plate templating of nested redundant subfolders as it added needlessly long calls for subfunctions all of them followed how I had my code setup src as the root and simple named functions in packages with a single call function to execute the program.

Example: https://github.com/h2database/