No it's not true, Java is always going to have support for mods.
There was a thing recently where Minecraft bedrock edition had a part of its code removed to stop players from using it to make addons for that version of the game as players were also using it to use cheats on servers. It caused a lot of controversy as most players that were using it were simply using it to make addons and do some admin work on their private servers.
Rollback Post to RevisionRollBack
The Wanderer Of The Stars - Mapper Of Worlds - Forever Alone
Technically, the only "mods" that Java Edition officially supports are data packs and resource packs - everything else is unofficial; people actually have to decompile and hack into the game's code in order to modify it, which had led to a lot of misunderstandings on whether modding is legal or not (it is, Mojang simply forbids distributing the complete game / "a substantial part of" (with no specifics on what this means) or making money off of mods):
This is what the EULA says about mods (I'll note that many mods break the "don't make money" rule, and I'm not including ads/donations but actually charging for them, or giving you something in return, like Optifine's capes, which are only supposed to be a special gift from Mojang):
If you've bought Minecraft: Java Edition, you may play around with it and modify it by adding modifications, tools, or plugins, which we will refer to collectively as "Mods." By "Mods," we mean something original that you or someone else created that doesn't contain a substantial part of our copyrightable code or content. When you combine your Mod with Minecraft: Java Edition, we will call that combination a "Modded Version" of the game. We have the final say on what constitutes a Mod and what doesn't. You may not distribute any Modded Versions of our game or software, and we’d appreciate it if you didn’t use Mods for griefing. Basically, Mods are okay to distribute; hacked versions or Modded Versions of the game client or server software are not okay to distribute.
Any Mods you create for Minecraft: Java Edition from scratch belong to you (including pre-run Mods and in-memory Mods) and you can do whatever you want with them, as long as you don't sell them for money / try to make money from them and so long as you don’t distribute Modded Versions of the game. Remember that a Mod means something that is your original work and that does not contain a substantial part of our code or content. You only own what you created; you do not own our code or content.
Also, modding exists in the form it does because of how easy it is to decompile Java, it isn't compiled to machine code but "Java bytecode", which is only fully compiled once loaded by a Java runtime, and a "Java jar file" is simply a collection of Java class files and other assets, as opposed to a monolithic executable or its associated libraries (you can even open them with any tool that can open zip files, including the ones built into operating systems if you change the extension to .zip); Java itself even provides ways to indirectly modify and access code (possibly one reason why it had long been considered insecure, the way modloaders work is by injecting a mod's code into the game at runtime, exactly what malware might also do).
Not only that, Mojang had long attempted to "obfuscate" the game to try to prevent tampering but modders were able to figure out how to reverse-engineer the code, since again, it didn't really change much from the original source:
Example of "source" code, as decompiled and deobfuscated by Mod Coder Pack:
public static final Block stone = (new BlockStone(1)).setHardness(1.5F).setResistance(10.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("stone").setTextureName("stone");
public static final BlockGrass grass = (BlockGrass)(new BlockGrass(2)).setHardness(0.6F).setStepSound(soundGrassFootstep).setUnlocalizedName("grass").setTextureName("grass");
public static final Block dirt = (new BlockDirt(3)).setHardness(0.5F).setStepSound(soundGravelFootstep).setUnlocalizedName("dirt").setTextureName("dirt");
public static final Block cobblestone = (new Block(4, Material.rock)).setHardness(2.0F).setResistance(10.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("stonebrick").setCreativeTab(CreativeTabs.tabBlock).setTextureName("cobblestone");
public static final Block planks = (new BlockWood(5)).setHardness(2.0F).setResistance(5.0F).setStepSound(soundWoodFootstep).setUnlocalizedName("wood").setTextureName("planks");
public static final Block sapling = (new BlockSapling(6)).setHardness(0.0F).setStepSound(soundGrassFootstep).setUnlocalizedName("sapling").setTextureName("sapling");
public static final Block bedrock = (new Block(7, Material.rock)).setBlockUnbreakable().setResistance(6000000.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("bedrock").disableStats().setCreativeTab(CreativeTabs.tabBlock).setTextureName("bedrock");
public static final BlockFluid waterMoving = (BlockFluid)(new BlockFlowing(8, Material.water)).setHardness(100.0F).setLightOpacity(3).setUnlocalizedName("water").disableStats().setTextureName("water_flow");
public static final Block waterStill = (new BlockStationary(9, Material.water)).setHardness(100.0F).setLightOpacity(3).setUnlocalizedName("water").disableStats().setTextureName("water_still");
public static final BlockFluid lavaMoving = (BlockFluid)(new BlockFlowing(10, Material.lava)).setHardness(0.0F).setLightValue(1.0F).setUnlocalizedName("lava").disableStats().setTextureName("lava_flow");
The same lines of code as seen with a decompiler; even with no knowledge of the game you can see the names of the blocks since strings aren't obfuscated, and apply these changes to every instance of their associated fields and variables (e.g. "aqz.y" becomes "Block.stone"):
public static final aqz y = new aqu(1).c(1.5F).b(10.0F).a(k).c("stone").d("stone");
public static final aon z = (aon)new aon(2).c(0.6F).a(j).c("grass").d("grass");
public static final aqz A = new anx(3).c(0.5F).a(i).c("dirt").d("dirt");
public static final aqz B = new aqz(4, akc.e).c(2.0F).b(10.0F).a(k).c("stonebrick").a(ww.b).d("cobblestone");
public static final aqz C = new art(5).c(2.0F).b(5.0F).a(h).c("wood").d("planks");
public static final aqz D = new aqi(6).c(0.0F).a(j).c("sapling").d("sapling");
public static final aqz E = new aqz(7, akc.e).r().b(6000000.0F).a(k).c("bedrock").C().a(ww.b).d("bedrock");
public static final apc F = (apc)new apd(8, akc.h).c(100.0F).k(3).c("water").C().d("water_flow");
public static final aqz G = new ape(9, akc.h).c(100.0F).k(3).c("water").C().d("water_still");
public static final apc H = (apc)new apd(10, akc.i).c(0.0F).a(1.0F).c("lava").C().d("lava_flow");
For comparison, this is part of one of my own mod's classes and what it looks like in a decompiler; only references to the original code are obfuscated, as well as constants like the "BlockState" constants since the compiler inlines them (you could still figure them out thanks to my "BlockStates" class retaining the original field names; they are not block IDs but a block ID + data value * 256, hence "stone_granite" is 1 + 256). The constants like -999 turning into values like 64537 is an issue with the decompiler I used (I assume they are stored as "shorts" in bytecode to reduce its size; the decompiler simply treats them as integers / unsigned values. This can also explain why the MCP source often uses shorts/bytes in places where one would just use ints):
private static final WorldGeneratorTMCW cherryTreeGenerator = new WorldGenCherryTree();
private static final WorldGenDoublePlant pinkFlowerGenerator = new WorldGenDoublePlant(WorldGenDoublePlant.PINK_FLOWERS);
protected BiomeGenCherryGrove(int par1)
{
super(par1);
this.theBiomeDecoratorTMCW.treesPerChunk = -999;
this.theBiomeDecoratorTMCW.flowersPerChunk = -999;
this.theBiomeDecoratorTMCW.grassPerChunk = 8;
this.setTreeRestrictionRadius(6);
}
// Set to true to modify light opacity of leaves in biomes with big trees so they are not too dark
public boolean isMegaTreeBiome()
{
return true;
}
// Returns block used for bedrock layer
public short getBedrockBlock()
{
return BlockStates.bedrock_granite;
}
// Returns block used as stone block and its depth
public short getBiomeStoneBlock()
{
return BlockStates.stone_granite;
}
// Called by ChunkProviderTMCW to replace blocks for biomes with special requirements
public int replaceBlocksForBiome_generate(ChunkProviderTMCW chunkGenerator, short[] terrainData, int chunkX_16, int chunkZ_16, int blockX, int blockZ, int minHeight, int maxHeight)
{
this.biomeBlockReplacer.replaceBiomeBlocks_generate(terrainData, blockX << 12 | blockZ << 8, maxHeight, this.getBiomeStoneBlock());
return maxHeight;
}
private static final WorldGeneratorTMCW cherryTreeGenerator = new WorldGenCherryTree();
private static final WorldGenDoublePlant pinkFlowerGenerator = new WorldGenDoublePlant(-1);
protected BiomeGenCherryGrove(int par1)
{
super(par1);
this.theBiomeDecoratorTMCW.treesPerChunk = 64537;
this.theBiomeDecoratorTMCW.flowersPerChunk = 64537;
this.theBiomeDecoratorTMCW.grassPerChunk = 8;
setTreeRestrictionRadius(6);
}
public boolean isMegaTreeBiome()
{
return true;
}
public short getBedrockBlock()
{
return 2823;
}
public short getBiomeStoneBlock()
{
return 257;
}
public int replaceBlocksForBiome_generate(ChunkProviderTMCW chunkGenerator, short[] terrainData, int chunkX_16, int chunkZ_16, int blockX, int blockZ, int minHeight, int maxHeight)
{
biomeBlockReplacer.replaceBiomeBlocks_generate(terrainData, blockX << 12 | blockZ << 8, maxHeight, getBiomeStoneBlock());
return maxHeight;
}
An example of a decompiled class which shows that the names of static final fields are still retained even if they are inlined when used elsewhere; while comments are missing you can deduce that positive values for "plantMetadata" will cause that specific variant to exclusively generate:
public static final int FLOWERS = -3;
public static final int AUTUMNAL_FLOWERS = -2;
public static final int PINK_FLOWERS = -1;
private final int plantMetadata;
private final boolean isGrass;
public WorldGenDoublePlant(int meta)
{
this.plantMetadata = meta;
this.isGrass = BlockDoublePlant.isGrass(this.plantMetadata);
}
This is a case where the decompiled code varies a bit from the original (nesting subsequent else-ifs and multiple variable declarations, the latter would cause a compile-time error, an issue handled by modding tools like MCP after the initial decompilation has been done, or again, because I'm using a decompiler that is so old it it officially only supports Java 5 (which is still what 1.6.4 and my mod mostly/entirely are, the game only updated to Java 6 in 1.6 to use a newer LWJGL library and I've only used/learned the Java syntax that 1.6.4 uses). Otherwise, it still does the same thing):
// Original
int meta;
if (this.plantMetadata == FLOWERS)
{
meta = BlockDoublePlant.getRandomFlower(this.nextInt(), false); // excludes blue orchids
}
else if (this.plantMetadata == AUTUMNAL_FLOWERS)
{
meta = BlockDoublePlant.getRandomAutumnalFlower(this.nextInt());
}
else if (this.plantMetadata == PINK_FLOWERS)
{
meta = BlockDoublePlant.getRandomPinkFlower(this.nextInt());
}
else
{
meta = this.plantMetadata;
}
// Decompiled
int meta;
int meta;
if (this.plantMetadata == -3)
{
meta = BlockDoublePlant.getRandomFlower(nextInt(), false);
}
else
{
int meta;
if (this.plantMetadata == -2)
{
meta = BlockDoublePlant.getRandomAutumnalFlower(nextInt());
}
else
{
int meta;
if (this.plantMetadata == -1)
{
meta = BlockDoublePlant.getRandomPinkFlower(nextInt());
}
else
{
meta = this.plantMetadata;
}
}
}
The Meaning of Life, the Universe, and Everything.
Join Date:
8/20/2011
Posts:
235
Member Details
If mod support for Minecraft Java was stopped, I would no longer play Minecraft. Period. Java mods are much easier to install and run, more varied, and more interesting than most of the stuff that's available for Bedrock. I hardly play Bedrock at all, even though the game runs slightly faster and smoother than Java.
The main consideration for me is the *content* of the game, and Java MInecraft is so much better on that score than Bedrock.
hey I heard from a couple friends that minecraft java might lose support for mods soon and in a couple countries it already happened. is it true?
No it's not true, Java is always going to have support for mods.
There was a thing recently where Minecraft bedrock edition had a part of its code removed to stop players from using it to make addons for that version of the game as players were also using it to use cheats on servers. It caused a lot of controversy as most players that were using it were simply using it to make addons and do some admin work on their private servers.
The Wanderer Of The Stars - Mapper Of Worlds - Forever Alone
Many Minecraft mods illegally redistribute Mojang assets.
Is Et futurum illegal
Modification Legality
This is what the EULA says about mods (I'll note that many mods break the "don't make money" rule, and I'm not including ads/donations but actually charging for them, or giving you something in return, like Optifine's capes, which are only supposed to be a special gift from Mojang):
Also, modding exists in the form it does because of how easy it is to decompile Java, it isn't compiled to machine code but "Java bytecode", which is only fully compiled once loaded by a Java runtime, and a "Java jar file" is simply a collection of Java class files and other assets, as opposed to a monolithic executable or its associated libraries (you can even open them with any tool that can open zip files, including the ones built into operating systems if you change the extension to .zip); Java itself even provides ways to indirectly modify and access code (possibly one reason why it had long been considered insecure, the way modloaders work is by injecting a mod's code into the game at runtime, exactly what malware might also do).
Not only that, Mojang had long attempted to "obfuscate" the game to try to prevent tampering but modders were able to figure out how to reverse-engineer the code, since again, it didn't really change much from the original source:
The same lines of code as seen with a decompiler; even with no knowledge of the game you can see the names of the blocks since strings aren't obfuscated, and apply these changes to every instance of their associated fields and variables (e.g. "aqz.y" becomes "Block.stone"):
For comparison, this is part of one of my own mod's classes and what it looks like in a decompiler; only references to the original code are obfuscated, as well as constants like the "BlockState" constants since the compiler inlines them (you could still figure them out thanks to my "BlockStates" class retaining the original field names; they are not block IDs but a block ID + data value * 256, hence "stone_granite" is 1 + 256). The constants like -999 turning into values like 64537 is an issue with the decompiler I used (I assume they are stored as "shorts" in bytecode to reduce its size; the decompiler simply treats them as integers / unsigned values. This can also explain why the MCP source often uses shorts/bytes in places where one would just use ints):
An example of a decompiled class which shows that the names of static final fields are still retained even if they are inlined when used elsewhere; while comments are missing you can deduce that positive values for "plantMetadata" will cause that specific variant to exclusively generate:
This is a case where the decompiled code varies a bit from the original (nesting subsequent else-ifs and multiple variable declarations, the latter would cause a compile-time error, an issue handled by modding tools like MCP after the initial decompilation has been done, or again, because I'm using a decompiler that is so old it it officially only supports Java 5 (which is still what 1.6.4 and my mod mostly/entirely are, the game only updated to Java 6 in 1.6 to use a newer LWJGL library and I've only used/learned the Java syntax that 1.6.4 uses). Otherwise, it still does the same thing):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
If mod support for Minecraft Java was stopped, I would no longer play Minecraft. Period. Java mods are much easier to install and run, more varied, and more interesting than most of the stuff that's available for Bedrock. I hardly play Bedrock at all, even though the game runs slightly faster and smoother than Java.
The main consideration for me is the *content* of the game, and Java MInecraft is so much better on that score than Bedrock.
I believe that Minecraft will always have mods and will continue to do so that's how Minecraft makes its money people buy Minecraft to get mods