Problems with custom editing bukkit/craftbukkit/mc-dev

I've googled and haven't found a fix for this. I'm trying to edit craftbukkit/bukkit to add some edits/play around with it. https://github.com/Bukkit/Bukkit, I have that all good. No errors a few warnings. I have this. https://github.com/Bukkit/CraftBukkit partly good, I exported mc-dev with a few errors and then craftbukkit project gives no errors. just a few warnings. But when I try to put mc-dev into my eclipse from here https://github.com/Bukkit/mc-dev it creates 700+ errors prob around 400+ IOExceptions. I don't think these should be here, So I don't want to try and fix them. Does anyone know why? Am I doing the wrong mc server from github? If anyone can pitch any ideas it would be great. If someone figures this out it would help future people who want to edit craftbukkit/bukkit like me.


Btw, I don't know if this is proper place. Its about bukkit so I'm just guessing

 

I know for certain there will be a lot of warnings saying it needs to be parameterized.

For example:
How Mc-dev is coded

PHP:

Hashmap m = new Hashmap();

What eclipse wants you to do

PHP:

Hashmap<Block> m = new Hashmap<Block>();

Could things like that be part of it?

 

idc about warnings atm. I care about the errors.

 

RealmsofValendor You shouldn't be editing mc-dev directly, you should be copying the file over to CraftBukkit and modifying it there. When we're making modifications to CB we often have to modify the file a bit so that it'll compile.

 

This type information is not usually necessary at runtime so it is not present in the Minecraft jars shipped by Mojang (mc-dev is decompiled from this binary so it does not have it either).

Would be an interesting challenge to re-add this generic type info (the "Signature" attribute in bytecode, accessible at runtime with getGenericReturnType, getGenericParameterTypes etc. using reflection). I suspect most (all?) of the types can be inferred, and it would lead to a cleaner decompile.

The IOException errors you see are a result of a limitation of the fernflower decompiler. Java bytecode does not always clearly correspond to Java source code; in this case the 'throws' clauses are missing/problematic. There are a couple ways to solve this problem. MCP solves it by an "exceptor" tool, which adds the necessary missing exceptions from a known list of mappings (stored in an .exc file), for example:

says to add 'throws IOException' to the function in the MinecraftServer class internally known as 'func_71197_b' and with a ()Z type signature. CraftBukkit fixes these cases manually as needed, search for "// CraftBukkit - throws IOException" or "// CraftBukkit - added throws".

There are many other types of fernflower decompile errors you may run into. If you really want to compile entirely from source, you have to fix all the 700+ compile errors. MCP actually does fix the compile errors, so it can completely build Minecraft from source, but it is not a trivial effort. Patches have to be written by hand to fix each of the errors.

Fortunately there is a better way. CraftBukkit does not require decompiling everything, instead, it builds against a "minecraft-server" jar as a dependency. This jar is almost identical to the minecraft_server.jar you get from Mojang, except it is deobfuscated to the familiar symbol names used in mc-dev ('net/minecraft/server/World.class' instead of 'aab.class', and so on). The unmodified classes from minecraft-server are shaded into the final craftbukkit.jar, including Mojang bytecode without passing through the lossy decompile/recompile cycle.

Only NMS classes that CB edits have to have their decompile-errors fixed. This is a much more manageable subset of classes. Check the contributing guidelines at https://github.com/Bukkit/CraftBukkit/blob/master/CONTRIBUTING.md for how classes from mc-dev are 'imported':

when the classes are imported, any decompile fixes should also be developed. There's only a handful in CraftBukkit besides the exception fixes, if you are curious:

So you may be wondering, is it possible to develop a 100% perfect decompiler, able to transform bytecode to source which compiles to byte-for-byte identical bytecode as the input? Not quite, because the JVM bytecode and Java source have different specifications, and do not map onto each other 1:1. The JVM actually supports features not in the Java language (for example, you can overload methods based on return type: a quite handy feature at times, CraftBukkit recently started using via post-compilation binary processing, the Overmapped tool written by Wolvereness), and they have different models. However, it is possible to roundtrip binary->source->binary 100% perfectly using a disassembler, such as Krakatau, but the downside is much less readable source. Perhaps an intermediate language could be developed for decompilation offering similar readability to Java but with perfect lossless recompilation, could be an interesting project.

Anyways, a final note, decompile errors can be more insidious than failures to recompile. A real-world example I've seen (twice): RCON, the Remote Control protocol for Minecraft servers - it can be broken by an improper decompile, even though it may recompile just fine. The affected class is net/minecraft/server/RemoteControlSession (aka net/minecraft/network/rcon/RConThreadClient), and apparently the nested exception handlers confuse fernflower and it decompiles the loop incorrectly, causing an infinite loop when you try to use RCON. JD-GUI correctly decompiles this class, unlike fernflower, but fortunately it is not a class patched by CraftBukkit so this bug/limitation in the decompiler does not matter in CraftBukkit.