That's the lazy way out. Even with the source code released, people will have to poke at the jar the same old fashioned way.
I disagree. The basic problem with mods keeping up with new versions has been the
obfuscation that Mojang applies. As a side effect, it makes even the slightest change to the source code (e.g. removing the April Fools chest block) propagate through the entire binary, changing classnames and function names through the whole thing.
It is not guaranteed, but is logical, that with the planned (limited) release of the source code, Mojang will stop obfuscating the binaries.
As such, mods would only need to be updated when the exact part of vanilla Minecraft that they modify was changed by Mojang.
At the very least, he needs a small API to load mod jars, so users can go through a menu to pick which mods to use instead of having to mess with your .jar
You can't really do this inside a Java program.
(Modulo reflection onto specially-prepared functions, or runtime-created functions. (Functors?) Not sure if Java can do compile-at-runtime. I know Java doesn't have anonymous functions.) If a mod needs to override or hook into a base class, it can't be loaded at runtime. ModLoader gets away with loading MODS\*.JAR only because nothing in those jars actually replaces or overrides vanilla Minecraft functions.
So what would have to be done is a separate program that merges together the vanilla jar with whatever mods the user wants.
And we already have those. They're called mod managers.
Mojang could integrate a mod manager into Minecraft.exe or its equivalent for other OSes. But they can't make one that will suit all tastes.
And, looka that! Those wacky modders are already solving the problem! Without obfuscated classfiles, they can solve it
better!
Mojang can just be lazy. Strange but true, being lazy is often the best solution. Seriously. Laziness is one of the
Three Virtues of a programmer.
Second problem is, with all the updates, no API means the modders will still have to update like crazy. With an API, you can maintain the API and only update it as necessary. So there's a whole level of backwards compatibility where modders only have to update the mods for minecraft versions -when needed- instead of every single version.
Well, yeah, an API is a guarantee of compatibility.
But APIs don't just happen. They have to be specified, formalized, documented, published,
maintained. And, most notably, each and every part of Minecraft that a modder might possibly want to hook into would need to have its own agreement. Specifications, documentation, callbacks or hooks, code verification, sandboxing… it would be a lot of work. A
lot of work. And it would be never ending. There would always be some code, somewhere, that a modder might be interested in tweaking.
I think it would be objectively better in the long run to take the lazy way out and shove off all that work to the modders themselves. ModLoader has paved the way, showing that it can be done. It'll be easier when (if) the obfuscation is no longer applied.
Remember that there are 6 (?) coders at Mojang. Yet there are hundreds of coders already modding Minecraft, under very difficult conditions. 100 > 6. Make them do the work.