https://github.com/lucacicada/VanillaSort
Minecraft chest sorting is a problem as old as the game itself. For fifteen years, players have been manually organizing storage rooms, building elaborate hopper systems, memorizing which chest holds which materials, and occasionally just giving up and throwing everything into a single double-chest until the chaos becomes unbearable. The server plugin ecosystem responded with sorting plugins that all work the same way: they require configuration files, category definitions, item-to-label mappings, signs, commands, and a plugin-specific rule language. After setup, the system sorts items according to the rules you wrote, not according to where you actually put things.
Luca approached this problem differently. The question he asked was not "how do I sort items efficiently?" The question was: "how does a player already organize their storage naturally, and how do I reinforce that behaviour instead of replacing it?"
The answer became VanillaSort.
One trapped chest. One name in an anvil: Sorter. That is the entire setup.
Place the trapped chest anywhere in your storage room. Name it. Now whenever you close it, every item you put in gets automatically moved to whichever chest in the surrounding 15-block radius already holds the most of that item type.
That is all. No config. No commands. No categories. No signs. No learning curve.
The plugin works with your memory. You already know where your logs are; you put them there. You already know where your stone is. The next time you dump a mining haul into the Sorter chest, every oak log goes to the chest that already has oak logs, every cobblestone goes to the chest that already has cobblestone, every iron ore goes where your iron ore lives. The organization you built over hours of play is exactly the organization the plugin reinforces.
This is the insight. Not clever algorithms. Not config files. Not a smart system that decides where things should go. A system that observes where things already are and honours that.
The core logic lives in a single file: Plugin.java at 299 lines. The entire sorting mechanism is driven by a single InventoryCloseEvent listener that fires when a player closes the Sorter chest.
The event handler first validates the trigger: is this a trapped chest? Is its custom name Sorter? If not, return immediately. The plugin is completely invisible to every other inventory interaction in the game.
// Only allow trapped chests
if (chest.getBlock().getType() != Material.TRAPPED_CHEST) {
return;
}
// Only allow chests with a special custom name
if (!CUSTOM_SORTER_NAME.equals(chest.getCustomName())) {
return;
}
Then it scans the surrounding area for valid target containers (regular chests and barrels within 15 blocks) using BlockFinder.java, a generic 3D block space iterator that walks a cubic bounding box and yields each block in sequence. It uses no Bukkit API overhead for iterating nearby entities and no reflection; it is a straightforward custom iterator that scans X, Y, Z in nested order.
For each item in the Sorter chest, the target container list is sorted using a four-level comparator:
Collections.sort(targetContainers, (TargetContainer a, TargetContainer b) -> {
int materialAmountComparison = Long.compare(
b.getMaterialAmount(itemType),
a.getMaterialAmount(itemType)
);
// Get the one that has the most of this item type
if (materialAmountComparison != 0) {
return materialAmountComparison;
}
int occupiedSlotsComparison = Long.compare(
b.getOccupiedSlots(),
a.getOccupiedSlots()
);
// Get the one that has the most occupied slots
if (occupiedSlotsComparison != 0) {
return occupiedSlotsComparison;
}
int itemsAmountCountComparison = Long.compare(
b.getItemsAmountCount(),
a.getItemsAmountCount()
);
// Get the one that has the most item amount count
if (itemsAmountCountComparison != 0) {
return itemsAmountCountComparison;
}
// Get the closest one to the sorter chest
return Double.compare(
a.getContainer().getLocation().distanceSquared(chestLocation),
b.getContainer().getLocation().distanceSquared(chestLocation)
);
});
Once the best target is found, the item is added to that container's inventory using Bukkit's addItem() method, which handles partial stacks and overflow correctly. If the target is full, the comparator cascades to the next best option. If nowhere can accept the item, it stays in the Sorter chest.
The entire sorting pass for all items happens in a single synchronous tick, triggered by the close event. The player closes the chest and the items are gone; moved silently, without animation, without sound, without any feedback that software was involved.
The implementation succeeds because it does exactly one thing: listen to the close event, identify the Sorter chest, perform the sort, then stop.
Most Minecraft plugins that touch inventories register listeners on InventoryClickEvent, InventoryDragEvent, and several other events that fire constantly as players interact with any container anywhere on the server. VanillaSort listens to exactly one event: InventoryCloseEvent, and immediately discards every invocation that is not from its specific trapped chest. The performance footprint is negligible.
The BlockFinder class separates concerns. It knows nothing about sorting, nothing about Minecraft items, nothing about the plugin's purpose. It is a reusable 3D space iterator that takes a location, a radius, and an optional predicate, and yields blocks. The sorting logic in Plugin.java uses it without caring how the iteration works. There is a clear boundary between "find blocks in space" and "decide what to do with them."
private void findNext() {
nextBlock = null;
while (currentX <= maxX) {
while (currentY <= maxY) {
while (currentZ <= maxZ) {
Block block = world.getBlockAt(currentX, currentY, currentZ);
currentZ++;
if (predicate == null || predicate.test(block)) {
nextBlock = block;
return;
}
}
currentZ = minZ;
currentY++;
}
currentY = minY;
currentX++;
}
}
The four-level comparator encodes human behaviour rather than abstract sorting rules. Humans who play Minecraft organize storage by item type; the comparator's first level captures this directly. The remaining levels are tiebreakers that produce sensible outcomes in edge cases without explicit specification.
Rich Hickey distinguishes between simple and easy in Simple Made Easy: easy means familiar, not far from what you know; simple means not interleaved, not complex in structure. Most Minecraft sorting plugins are familiar software that interleaves their logic with gameplay. VanillaSort does not interleave with play. It has one job, does that job at exactly one moment, and then stops.
VanillaSort has one block type (trapped chest), one custom name (Sorter), one event (close), one algorithm (four-level sort). Players who use it do not think about it. They do not configure it. They do not learn its rules. They dump items in, close the chest, and the sort happens silently.
The design uses only vanilla Minecraft objects. A trapped chest has in-game meaning (it triggers redstone). The anvil renaming system already exists. The 15-block radius is a natural spatial concept. Nothing requires knowledge that a modded server exists.
Other sorting plugins use commands as the interface, chat messages as feedback, and YAML files for configuration that lives outside the game. VanillaSort has no interface, no feedback, and no configuration. The only artifact it leaves is a trapped chest with a custom name, both placed and named using vanilla Minecraft mechanics. Most sorting mods require learning their rules; VanillaSort requires none.
The source is at github.com/lucacicada/VanillaSort. Three Java files. 299 lines for the main plugin logic, 133 lines for the block iterator, and a small WorldAreaBlockIterator utility. The entire plugin compiles to a single JAR that any Spigot server can drop into its plugins folder.
The project was later renamed EasySort internally, reflecting the experience it creates.