Recaf
Recaf copied to clipboard
Col-E
Add Krakatau decompiler
Would love to see this implemented!
We would like to add Krakatau, however, we don't have any good solution (at least, right now) about how we want to deal with the fact that Krakatau is written in Python If you have any ideas, we might look into that
One can do it by adding a gui with a list of library jars where you can add, edit, delete the paths.
Then one needs an option to set pypy2/python2 executable path.
You need a directory to unpack Krakatau.
Create a new jar file with just the class to decompile in it.
Build path with libraries from user settings + original jar file. Paths separated with ;.
Specify some unique output.zip
Then you execute python in krakatau dir. And grab decompiled java file from output zip.
For user easyness (I don't need that):
- autodownload of pypy2
- locate rt.jar when running on java 8 or create rt.jar for java9+ with https://github.com/Storyyeller/jrt-extractor
One can do it by adding a gui with a list of library jars where you can add, edit, delete the paths. Then one needs an option to set pypy2/python2 executable path. You need a directory to unpack Krakatau. Create a new jar file with just the class to decompile in it. Build path with libraries from user settings + original jar file. Paths separated with
;. Specify some unique output.zip Then you execute python in krakatau dir. And grab decompiled java file from output zip.For user easyness (I don't need that):
* autodownload of pypy2 * locate rt.jar when running on java 8 or create rt.jar for java9+ with https://github.com/Storyyeller/jrt-extractor
The problem and why we don't want to take this approach is:
- We would have to spawn new processes to let Krakatau do it's job and thus, maintain whether the process dies, kill processes when Recaf dies and bunch of other corner cases
- Exporting JAR files is expensive, that's why we are not keeping any thing on file system, instead, everything uses in-memory representation which is already there
- Save as 2, but to clarify: exporting large JARs is bad, and we are avoiding that by any means
- To support JDK 9 and newer, as you already mentioned, we would have to dump modules file content for Krakatau to locate bootstrap classes. Again, Recaf already has in-memory support for that, and that would require ugly hacks. Recaf 3.x does not work on Java 8, so, 8 is not a problem
As one of the users in our Discord mentioned, there is appears to be Krakatau 2 being written in Rust (? https://github.com/Storyyeller/Krakatau/issues/185), so me personally would suggest to wait until there is some light on the situation with it. I'm not saying that adding Krakatau is a bad idea, I'm saying that it would require even more hacks to make it work. I can add support for Krakatau, but that's up to @Col-E or to someone who is willing to do this and submit PR, so we can review it
If you don't want to create a new process, you could embed the Python interpreter that runs Krakatau in Recaf with something like https://github.com/ninia/jep. However, you would need Python installed (with the required libraries) for this to work, but you could have a prompt, or something of the sort saying that Python is required? Additionally, Krakatau's decompiler is Python 2, and you'd probably have to upgrade it to Python 3 (which isn't too bad to do). Just a consideration for a "cleaner" approach to implementing this, there are probably better ways though.
Krakatau dev said its hard to update it to python 3. Also krakatau benefits from pypy quite well. So maybe this should wait for krakatau 2 where you don't need libraries and the cli will be a little easier to use with class file in, class file out option.
FYI, I'm also planning to remove the decompiler JRE/path requirement thing during the rewrite. I think that experience has shown that the benefits of having class hierarchies available during decompilation is nowhere near the cost of the hassle involved, and Java 9+ makes it very difficult anyway.
