{ "version": "https://jsonfeed.org/version/1", "title": "Ash's Workshop Debrief Blog", "home_page_url": "https://blog.ashwork.net/minecraft", "description": "Ash's Workshop Debrief Blog", "items": [ { "id": "https://blog.ashwork.net/minecraft/2026/06/07/obfuscation-addition", "content_html": "

Large language models like to lie, a lot.

\n

I don't try to ask it tricky questions. If anything, I want to eventually integrate large language models into my workflow, well, once they stop hallucinating on any problem outside their dataset. It doesn't matter how good a word predictor is if it can't admit that it doesn't know the answer.

\n

For example, when was the Minecraft source code first obfuscated?

\n

We know for a fact that the codebase hasn't been obfuscated since it's inception, especially with the recently popularity spike of people making mods for rd-132211. It's also not an easy question given the number of versions that we don't have archives for (according to the Minecraft wiki). So I threw the question over to Gemini:

\n

'When was Minecraft first obfuscated?'

\n
\n

\"Minecraft: Java Edition was first obfuscated alongside its initial public release in 2009. To protect their proprietary code, Mojang used scrambled variable and class names, a practice that continued for over a decade.\"

\n
\n

...well, that's not true. Though, Gemini could be assuming only releases from 1.0 onwards So let's rephrase the question.

\n

'What was the first version of Minecraft (any build) that was obfuscated?'

\n
\n

\"The first obfuscated build (2009): The very initial pre-Classic and Classic versions (like rd-131655) were obfuscated with ProGuard.\"

\n
\n

...that's even worse. We already know the next version wasn't obfuscated, so what's the likelihood that a prior one, a version with no archive, was? Maybe I phrased the question wrong. Let's try once more:

\n

'Including all pre-release builds, when was Minecraft first obfuscated?'

\n
\n

\"Minecraft’s Java code was first scrambled (obfuscated) with ProGuard in the pre-Classic version 0.0.15a in May 2009. Mojang applied this code scrambling to its very earliest multiplayer tests to protect proprietary algorithms and prevent hacked clients.\"

\n
\n

Well now, that seems a lot more reasonable, and only after three attempts!

\n

But is it true?

\n

Well, if we track down the source, it leads to a single comment from a reddit post by 'iProgramMC' on December 21st, 2023.

\n
\n

\"I mentioned this in several replies to comments. I believe that the original reason for obfuscation was to try to prevent the creation of hacked clients and client-based cheats. You see, Classic builds before 0.0.15a (when the first multiplayer tests were being performed), are not obfuscated at all - you can throw them into any Java decompiler and they will show it all; this leads me to believe that's the original reason. It probably has changed over time.\"

\n
\n

I couldn't really find any proof to this claim, but on its face, it seems reasonable. However, I can do one better.

\n

Let's verify it!

\n

Modifying the previous gradle buildscript once again:

\n
plugins {
    id(\"fabric-loom\") version \"1.10-SNAPSHOT\"
}
\n
group = \"net.ashwork.mc\"
version = \"0.0.0\"
base.archivesName = \"legacy\"
\n
loom {
    noIntermediateMappings()
    clientOnlyMinecraftJar()
}
\n
dependencies {
    minecraft(\"com.mojang:minecraft:<minecraft_version>\")
    mappings(loom.layered {
        // No mappings required
    })
    modImplementation(\"net.fabricmc:fabric-loader:0.16.14\")
}
\n
tasks.withType<JavaCompile> {
    options.release = 8
    options.encoding = \"UTF-8\"
}
\n
java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}
\n

All we need to do is check the downloaded source and see if it was obfuscated or not.

\n

And running through all the versions in the manifest from oldest to newest, the first obfuscated version is c0.0.13a_03 (or 0.0.13a_03). And since the version prior to that, c0.0.13a (or 0.0.13a), isn't obfuscated, we have our answer!

\n

Well, sort of. There's a slight hiccup to this reasoning. According to the Minecraft Wiki:

\n
\n

\"An early development version of 0.0.13a, mislabelled as its released counterpart, is available in the launcher. It was used for testing the world size, and can only generate flat terrain, instead of the actual terrain used in the full release. Many features from 0.0.12a are still present, such as using the \"generating level\" screen from that version instead of the one from 0.0.13a.\"

\n
\n

This means that we could potentially be dealing with some kind of mislabeling. Of course, there is some evidence that 0.0.13a_03 can be the first obfuscated version. Looking through the channel logs from the #minecraft IRC server by Testvan, we can see some supporting conversation from May 25th, 2009:

\n
\n\n
\n

This conversation, from taodih_away \"[maybe] an extra payment for the developers as the get the sourcecode\" and @Notch \"I'm not going to opensource it or sell the source code' / 'if people reverse-engineer and so on, I can't (and won't! especially if they've paid me :D) stop them\" indicate that, at this point in time, the Minecraft source code was already obfuscated. There's even further proof from May 29th, 2009:

\n
\n\n
\n

@Notch \"but I forgot that I obfuscate the game before uploading it, and that broke serialization between versions\" indicates that the game was obfuscated prior to May 29th, 2009.

\n

So, I guess this is it, 0.0.13a_03 is the first obfuscated Minecraft version.

\n

...well, maybe we can dig up a bit more proof.

\n

There are two nearby versions that are archived somewhere else, and therefore not in the version manifest: 0.0.12a_03 and 0.0.14a_08. If we decompile the JAR of these versions, we should be able to, at least, definitively prove to the best to our knowledge that 0.0.13a_03 is the first obfuscated Minecraft version.

\n

Luckily for us, Omniarchive provides a link to these versions. For brevity, I downloaded all versions from 0.0.11a to 0.0.14a_08 just to verify our findings. For those curious:

\n\n

And for whether they were obfuscated:

\n
JARObfuscated
c0.0.11a-launcher.jarNo
c0.0.12a_03-200018.jarYes
c0.0.13a-launcher.jarNo
c0.0.13a_03.jarYes
c0.0.13a_03-launcher.jarYes
c0.0.14a_08.jarPartial
\n

...huh. Well that's a problem. Let's expand our version range a bit more just to verify:

\n
JARObfuscated
c0.0.15a-05311904.jarPartial
c0.0.16a_02-081047.jarPartial
c0.0.17a-2014.jarPartial
c0.0.18a_02.jarPartial
c0.0.19a_04.jarPartial
c0.0.19a_06-0137.jarPartial
c0.0.20a_01.jarPartial
c0.0.20a_02.jarPartial
\n

...hmm. Yeah. Still weird. First of all, c0.0.12a_03 (or 0.0.12a_03) is obfuscated, which is earlier than the c0.0.13a_03 release. Meanwhile, JARs from c0.0.14a_08 have some unobfuscated classes.

\n

For the latter, Minecraft originally used Java's Serializable class to handle saving data to disk. Serializable, along with its associated ObjectInputStream and ObjectOutputStream used reflection to read a class's fields by their name to write them to some file. Naturally, if a field's or class's name changes, for example due to obfuscation, the game may be unable to read or write the data deterministically. As such, the easiest way to handle this was to leave it deobfuscated. (Credit to Celeste for the accurate deduction)

\n

As for the former, the obfuscated existence of 0.0.12a_03 while 0.0.13a being unobfuscated in the launcher provides two potential conclusions:

\n

One, 0.0.13a is mislabelled in the Minecraft launcher and actually represents a previous version. The Omniarchive version spreadsheet mentions that a lot of the versions in the launcher are either incorrectly labelled or 'developer builds', meaning not the ones that were actually released to players, but the raw compiled JAR.

\n

Two, the versions in the Minecraft launcher are not the \"true\" versions, and are instead re-releases. The spreadsheet also notes that the versions released in the launcher were from 2013, compared to the archived versions from 2009. Going off that logic, c0.0.11a might have originally been obfuscated, but was later released in the launcher unobfuscated.

\n

Unfortunately, there's not much evidence supporting either claim enough to make any definitive statements. It's all guesswork as all other versions are lost as far as we know. Of course this may change in the future, so who knows?

\n

But for right now, the first version Minecraft was obfuscated is Classic 0.0.12a_03 (or c0.0.12a_03), with one big asterisk.

", "url": "https://blog.ashwork.net/minecraft/2026/06/07/obfuscation-addition", "title": "When was Minecraft obfuscated?", "summary": "Large language models like to lie, a lot.", "date_modified": "2026-06-07T19:01:01.000Z", "author": { "name": "ChampionAsh5357", "url": "https://github.com/ChampionAsh5357" }, "tags": [] }, { "id": "https://blog.ashwork.net/minecraft/2026/05/23/menu-stack-move", "content_html": "

Did you know that when shift-clicking a stack within a GUI like a chest or dispenser, the stack will move from one inventory to the other? It's a feature that's been in the game since b1.5 and hasn't really changed much.

\n

The method that manages this shift-clicking behavior is AbstractContainerMenu.quickMoveStack(), as internally, shift-clicking performs the ContainerInput.QUICK_MOVE action. The logic for this is rather simple:

\n
// From Minecraft 26.1.2 `CraftingMenu`
// Comments added to understand how the method works
@Override
public ItemStack quickMoveStack(Player player, int slotIndex) {
    // Setup variables
    ItemStack clicked = ItemStack.EMPTY;
    Slot slot = this.slots.get(slotIndex);
\n
    // If the clicked slot has an item to move...
    if (slot != null && slot.hasItem()) {
        // Get the stack to move
        ItemStack stack = slot.getItem();
        // Keep track of the original stack
        clicked = stack.copy();
\n
        // If the clicked slot is the crafting result...
        if (slotIndex == RESULT_SLOT) {
            // On stack crafted
            stack.getItem().onCraftedBy(stack, player);
\n
            // Try to move stack into the player slots, starting from the hotbar
            if (!this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, true)) {
                // Return if the stack can't be moved into the player slots
                return ItemStack.EMPTY;
            }
\n
            // Slot behavior on moving the crafting result
            slot.onQuickCraft(stack, clicked);
        }
        // Otherwise, if the clicked slot is in the player slots...
        else if (slotIndex >= INV_SLOT_START && slotIndex < USE_ROW_SLOT_END) {
            // Try to move stack into the crafting inventory
            if (!this.moveItemStackTo(stack, CRAFT_SLOT_START, CRAFT_SLOT_END, false)) {
                // If the stack can't be moved into the crafting inventory...
\n
                // If the clicked slot is in the player inventory
                if (slotIndex < INV_SLOT_END) {
                    // Try to move stack into the player hotbar
                    if (!this.moveItemStackTo(stack, USE_ROW_SLOT_START, USE_ROW_SLOT_END, false)) {
                        // Return if the stack can't be moved into the player hotbar
                        return ItemStack.EMPTY;
                    }
                }
                // Otherwise, since the clicked slot is in the player hotbar
                // Try to move stack into the player inventory
                else if (!this.moveItemStackTo(stack, INV_SLOT_START, INV_SLOT_END, false)) {
                    // Return if the stack can't be moved into the player inventory
                    return ItemStack.EMPTY;
                }
            }
        }
        // Otherwise try to move stack into the player slots
        else if (!this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, false)) {
            // Return if the stack can't be moved into the player slots
            return ItemStack.EMPTY;
        }
\n
        // If all items in the stack was successfully moved...
        if (stack.isEmpty()) {
            // Clear the original slot the stack was in
            slot.setByPlayer(ItemStack.EMPTY);
        }
        else {
            // Otherwise, mark that the contents of the slot have changed
            slot.setChanged();
        }
\n
        // If the slot's contents haven't changed
        if (stack.getCount() == clicked.getCount()) {
            return ItemStack.EMPTY;
        }
\n
        // Slot behavior on stack move
        slot.onTake(player, stack);
\n
        // If the clicked slot is the crafting result
        if (slotIndex == RESULT_SLOT) {
            // Drop the remaining stack into the level
            player.drop(stack, false);
        }
    }
\n
    // Return the original clicked stack
    return clicked;
}
\n

This was my original understanding of how quickMoveStack worked. There were some differences depending on the backing inventory and menu, but the structure remained more or less the same. I didn't really think more about it at the time, and it was sitting that way across docs and other mod projects for a decade.

\n

Well, until two days ago.

\n

On March 21 2026, Celeste made a comment on the Fabric Discord on one particular part on the quickMoveStack logic saying that the following didn't make much sense.

\n
if (stack.getCount() == clicked.getCount()) {
    return ItemStack.EMPTY;
}
\n

I responded with, \"Why not? The original stack can be modified in moveItemStackTo right? I'm pretty sure it's to prevent onTake from being called if nothing was taken\" since that was how I understood the method to work. I would've stopped thinking about it right there, but then, Celeste responded with something interesting:

\n
though honestly, I can't seem to find a way to reach that case at all
\n

...well, that's strange.

\n

So, I tried to trigger it myself. Normal quick move, moving with multiple stacks, modifying the stack size in the player data, etc. However, no matter what I did, nothing worked, the same as Celeste. At this point, there was only one reasonable thing to do:

\n

Backtrace the addition through previous Minecraft versions to find why it was added.

\n

So modifying an old gradle workspace with the following buildscript:

\n
plugins {
    id(\"fabric-loom\") version \"1.10-SNAPSHOT\"
}
\n
group = \"net.ashwork.mc\"
version = \"0.0.0\"
base.archivesName = \"legacy\"
\n
loom {
    noIntermediateMappings()
    clientOnlyMinecraftJar()
}
\n
dependencies {
    minecraft(\"com.mojang:minecraft:<minecraft_version>\")
    mappings(loom.layered {
        // No mappings required
    })
    modImplementation(\"net.fabricmc:fabric-loader:0.16.14\")
}
\n
tasks.withType<JavaCompile> {
    options.release = 8
    options.encoding = \"UTF-8\"
}
\n
java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}
\n

Let's look at the original code added in b1.5:

\n
// From Minecraft b1.5 `do`
public ii a(int i) {
    ge var2 = (ge) this.e.get(i);
    return var2 != null ? var2.a() : null;
}
\n

...well that's not clear whatsoever. Which makes sense -- the Minecraft codebase was still obfuscated during the period. There are some mappings through the Feather project, but I ended up going with the old 'translate it myself' approach. A bit of nostalgia from the SRG and Parchment mapping days.

\n

For ease of understanding, I'll be translating the codebase into its modern Mojang mapping equivalent along with providing the original signature if you want to look up the methods yourself.

\n

So, let's take another look at the b1.5 method:

\n
// From Minecraft b1.5 `AbstractContainerMenu`
// Comments added to understand how the method works
// Translated with their equivalent Mojang mappings
// Original signature: `do a(I)Lii;`
public ItemStack quickMoveStack(int slotIndex) {
    // Setup variables
    Slot slot = (Slot) this.slots.get(slotIndex);
\n
    // If the slot exists, get the item in the slot
    // Otherwise, return an empty stack
    return slot != null ? slot.getItem() : null;
}
\n
\n

Some IDEs may fail to open the file as the obfuscated name of the class do is a keyword. I got around this in IntelliJ IDEA by right-clicking the class and selecting 'Open in Right Split'.

\n
\n

Now you might be wondering why I'm showing the AbstractContainerMenu method instead of the CraftingMenu override. Well, it's because CraftingMenu (or ie obfuscated) didn't override quickMoveStack when it was first implemented. Nowadays, all menus have to implement quickMoveStack as an abstract method, much different than before.

\n

Well, regardless, what we're looking for hasn't been implemented yet, so let's jump up a version:

\n
// From Minecraft b1.6 `CraftingMenu`
// Translated with their equivalent Mojang mappings
// Original signature: `iq a(I)Liw;`
public ItemStack quickMoveStack(int slotIndex) {
    // Setup variables
    ItemStack clicked = null;
    Slot slot = (Slot) this.slots.get(slotIndex);
\n
    // If the clicked slot has an item to move...
    if (slot != null && slot.hasItem()) {
        // Get the stack to move
        ItemStack stack = slot.getItem();
        // Keep track of the original stack
        clicked = stack.copy();
\n
        // If the clicked slot is the crafting result...
        if (slotIndex == RESULT_SLOT) {
            // Try to move stack into the player slots, starting from the hotbar
            this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, true);
        }
        // Otherwise, if the clicked slot is in the player inventory...
        else if (slotIndex >= INV_SLOT_START && slotIndex < INV_SLOT_END) {
            // Try to move stack into the player hotbar
            this.moveItemStackTo(stack, USE_ROW_SLOT_START, USE_ROW_SLOT_END, false);
        }
        // Otherwise, if the clicked slot is in the player hotbar...
        else if (slotIndex >= USE_ROW_SLOT_START && slotIndex < USE_ROW_SLOT_END) {
            // Try to move stack into the player inventory
            this.moveItemStackTo(stack, INV_SLOT_START, INV_SLOT_END, false);
        }
        // Otherwise try to move stack into the player slots
        else {
            this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, false);
        }
\n
        // If all items in the stack was successfully moved...
        if (stack.count == 0) {
            // Clear the original slot the stack was in
            slot.setByPlayer((ItemStack) null);
        } else {
            // Otherwise, mark that the contents of the slot have changed
            slot.setChanged();
        }
\n
        // If the slot's contents haven't changed
        if (stack.count == clicked.count) {
            return null;
        }
\n
        // Slot behavior on stack move
        slot.onTake(stack);
    }
\n
    // Return the original clicked stack
    return clicked;
}
\n

Now, this is looking much closer to the current CraftingMenu. There are, of course, a few things missing. For example, you can't move quick move items from the player slots to the crafting inventory. Or, if you're able to quick move from the crafting result that fills up the entire inventory, any items left in the crafting result will disappear into the aether.

\n

But with this, we can now see the original purpose of that count comparison: to prevent onTake from being called if the slot's contents haven't changed. In b1.6, AbstractContainerMenu.moveItemStackTo() didn't originally have a return result indicating if some of the stack was moved successfully. As such, if the player tried to quick move from the with a full inventory, onTake would still be called, which depending on the Slot, could perform behavior it wasn't yet supposed to. So the count comparison acted as a gate to prevent the method from being called if nothing changed about the contents.

\n

Later on in b1.8.1, the implementation was changed to:

\n
// From Minecraft b1.8.1 `CraftingMenu`
// Translated with their equivalent Mojang mappings
// Original signature: `uf a(I)Lul;`
public ItemStack quickMoveStack(int slotIndex) {
    // Setup variables
    ItemStack clicked = null;
    Slot slot = (Slot) this.slots.get(slotIndex);
\n
    // If the clicked slot has an item to move...
    if (slot != null && slot.hasItem()) {
        // Get the stack to move
        ItemStack stack = slot.getItem();
        // Keep track of the original stack
        clicked = stack.copy();
\n
        // If the clicked slot is the crafting result...
        if (slotIndex == RESULT_SLOT) {
            // Try to move stack into the player slots, starting from the hotbar
            if (!this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, true)) {
                // Return if the stack can't be moved into the player slots
                return null;
            }
        }
        // Otherwise, if the clicked slot is in the player inventory...
        else if (slotIndex >= INV_SLOT_START && slotIndex < INV_SLOT_END) {
            // Try to move stack into the player hotbar
            if (!this.moveItemStackTo(stack, USE_ROW_SLOT_START, USE_ROW_SLOT_END, false)) {
                // Return if the stack can't be moved into the player hotbar
                return null;
            }
        }
        // Otherwise, if the clicked slot is in the player hotbar...
        else if (slotIndex >= USE_ROW_SLOT_START && slotIndex < USE_ROW_SLOT_END) {
            // Try to move stack into the player inventory
            if (!this.moveItemStackTo(stack, INV_SLOT_START, INV_SLOT_END, false)) {
                // Return if the stack can't be moved into the player inventory
                return null;
            }
        }
        // Otherwise try to move stack into the player slots
        else if (this.moveItemStackTo(stack, INV_SLOT_START, USE_ROW_SLOT_END, false)) {
            // Return if the stack can't be moved into the player slots
            return null;
        }
\n
        // If all items in the stack was successfully moved...
        if (stack.count == 0) {
            // Clear the original slot the stack was in
            slot.setByPlayer((ItemStack) null);
        } else {
            // Otherwise, mark that the contents of the slot have changed
            slot.setChanged();
        }
\n
        // If the slot's contents haven't changed
        if (stack.count == clicked.count) {
            return null;
        }
\n
        // Slot behavior on stack move
        slot.onTake(stack);
    }
\n
    // Return the original clicked stack
    return clicked;
}
\n

moveItemStackTo now returned if the stack was successfully moved. quickMoveStack then checked that result and, if the stack wasn't moved, exited early with the empty stack. This change functionally made the count comparison pointless as what it was checking for happened much earlier in the method. From there, the count comparison was copy-pasta-ed throughout different menus across the versions until the quickMoveStack we have today. Since the comparison always returns false, it doesn't affect game behavior whatsoever, and if it works, then who cares.

\n

With this discovery, I removed it from the NeoForged docs. After all, what's the point in having something that will never do anything?

\n

A very worthwhile four hour rabbit hole.

\n

Thanks again to Celeste for the initial discovery and investigation work.

", "url": "https://blog.ashwork.net/minecraft/2026/05/23/menu-stack-move", "title": "A Redundant Count Comparison in AbstractContainerMenu", "summary": "Did you know that when shift-clicking a stack within a GUI like a chest or dispenser, the stack will move from one inventory to the other? It's a feature that's been in the game since b1.5 and hasn't really changed much.", "date_modified": "2026-05-23T19:59:03.000Z", "author": { "name": "ChampionAsh5357", "url": "https://github.com/ChampionAsh5357" }, "tags": [] } ] }