Want a better Minecraft server? Read about SpigotMC here!
Separate names with a comma.
Discussion in 'Spigot Discussion' started by Adamt605, May 18, 2017.
What is the best Decompiler for 2017.
Krakatau and Procyon are good, though I'm no expert in this topic.
I do not decompile, but a few months ago I only used JDGui xd
I was going to try that how is it?
Jd-gui is known to be one of the worst decompilers out there ;P
fernflower, developed by jetbrains as part of their intellij idea is good. its integrated in the ide so its easy to look at nms code for example.
for standalone stuff, I use luyten (https://github.com/deathmarine/Luyten) which is a gui for procyon, just like jd-gui is for jd.
I really wouln't recommend jd, its extremely outdated.
Why all of them are read only 0.0
You already have to source code, what is the problem to recompile...
because its not as easy as that, lol.
first of all: decompilers not always produce valid java code. they could have a bug, a missing feature or the input bytecode was obfuscated which may lead to ambiguous method names.
then, even if you had valid java source, you would still not be able to compile it. you are missing the dependencies. how should your decompiler know that you need bukkit to recompile? or even worse, 3rd party plugins, like worldedit. you can't compile if you have missing dependencies.
so yeah, it will not work.
Dependencies that get exported with the jar is easy to add, all of the other are "provided", you are telling me there is NO WAY to tell the compilter to ignore dependencies?
yes, there is nothing the decompiler would need to do to recompile it if everything is in the jar
yes, provided at runtime. you have no way to know about them (as a decompiler). you need them at compile time. a human and guess by the imports, search google and add them to the buildpath. a programm can't do that.
yes, you can't compile a class that uses class B if your compiler doesn't even know wtf B is.
What exactly are you looking to decompile that you cant use API for ?
I use the same thing, and i also use this https://github.com/java-deobfuscator/deobfuscator and this https://github.com/contra/JMD for deobfuscation
That's impossible. You need to have the library available and compile-time and at runtime so that you can have some compile time validation of fairly important things, like you're calling a real method, that class exists, or you aren't passing a String to an int field.
( It was a joke )
I'm just looking to read code of plugins that i use. And maybe change some of it up as i learn. Like add more commands to one command, and other cool stuff as i learn. Because I'm only learning the basics of spigot coding as of right now. Like teleportation and all of that. Also I have no idea what an API is. I have heard of it, but i don't know a lot about it. If you don't mind explaining a little bit about them, like what they do and how to use them ect. That would be gratefully appreciated.
Procryon and JD-GUI both last recieved updates around the same time, and Procryon admittedly has issues with anything not compiled with javac. Where JD has less issues. It does have serious main class issues with Java 8 though.
I honestly use multiple online cores which are based on the same decompilers, to often get the best and quickest results form each one. For instance, when one fails, it's easy to tick a box for another decompiler.
you are comparing a decompiler to a gui. that doesn't work. also, just take a look at jds known limitations lists on their homepage. just that alone should scream don't use me.
the online things then to be much slower than decompiling it yourself, as there are multiple ppl using it.
What? JD is not JD-GUI. What is with you and assumptions or is it just misunderstanding? We were talking about GUI implementations of the decompilers though, or did you forget that immediately after posting a GUI for Procryon (Luyten)?
Less issues in context of the statement about Eclipse.
And continued on to mention it has it's limitations, but for what I also mentioned about Procryon's limitation which covers half, if not more (As Intellij has only really recently gaining momentum) of compiled programs since Eclipse's initial release in 2001. It has it's uses.
I further continue on mentioning alternatives which use all known decompiling methods, including Procryon and JD.