Hi, Storyyeller. I actually just have a couple of questions, not really issues, but I couldn't find any contact information here or on your Antimony account on stackoverflow from where I was linked to here. Sorry if this isn't an appropriate place to ask, but I couldn't think of anywhere else.
I am very interested in this project, as it's the only one I've found which seems to have the potential to support decompilation of arbitrary bytecode generated from languages other than Java or from obfuscators. (The obfuscation part isn't actually important to me personally, but it would be a nice display of robustness ;).) It's also nice to see a useful looking project and to not discover it's been unmaintained for a decade!
Your approach to the problem as a 'backwards compiler' sounds exactly like what I was looking for, as 'good quality' and readable Java isn't something I care about, I just need would like something which works consistently. If you are interested in the application, I'm trying to put together a toolchain for helping convert Java applications to Objective-C.
Currently https://code.google.com/p/j2objc/ exists to help convert Java source to Objective-C, but it occurred to me that Android apps can be written in something like Scala also, since Davlik bytecode is generated from Java bytecode. This means that to leverage the power of the j2objc library we need an extra decompilation step from bytecode to Objective-C to support all possibilities.
Since I've found no decompilers which look massively dependable it has started to feel like this technique might actually be a step backwards, since it adds steps which are often unnecessary and so may fail in cases where j2objc would have been successful by itself. I suppose those extra steps could be skipped in those cases where the original source is actually Java, but that would add extra complexity to an otherwise more generally applicable toolchain.
On the other hand, j2objc doesn't appear to be fully matured, and I have a feeling that code generated by Krakatau might actually be more consistently understandable by j2objc than arbitrary Java, so it could be more reliable in every case if the decompilation step is robust enough.
So, how well tested is your code? Have you tested with different obfuscaters or with bytecode compiled from different languages etc? I will be happy to perform a whole bunch of tests myself, of course, I'm only asking you this here in case you can give me a good idea from what you have done already :).
Sorry for the long message, I ended up with more to say than I thought I did. Please feel free to delete this issue and reply by email to eliasv at hotmail.co.uk if that would be better.
Hi, Storyyeller. I actually just have a couple of questions, not really issues, but I couldn't find any contact information here or on your Antimony account on stackoverflow from where I was linked to here. Sorry if this isn't an appropriate place to ask, but I couldn't think of anywhere else.
I am very interested in this project, as it's the only one I've found which seems to have the potential to support decompilation of arbitrary bytecode generated from languages other than Java or from obfuscators. (The obfuscation part isn't actually important to me personally, but it would be a nice display of robustness ;).) It's also nice to see a useful looking project and to not discover it's been unmaintained for a decade!
Your approach to the problem as a 'backwards compiler' sounds exactly like what I was looking for, as 'good quality' and readable Java isn't something I care about, I just need would like something which works consistently. If you are interested in the application, I'm trying to put together a toolchain for helping convert Java applications to Objective-C.
Currently https://code.google.com/p/j2objc/ exists to help convert Java source to Objective-C, but it occurred to me that Android apps can be written in something like Scala also, since Davlik bytecode is generated from Java bytecode. This means that to leverage the power of the j2objc library we need an extra decompilation step from bytecode to Objective-C to support all possibilities.
Since I've found no decompilers which look massively dependable it has started to feel like this technique might actually be a step backwards, since it adds steps which are often unnecessary and so may fail in cases where j2objc would have been successful by itself. I suppose those extra steps could be skipped in those cases where the original source is actually Java, but that would add extra complexity to an otherwise more generally applicable toolchain.
On the other hand, j2objc doesn't appear to be fully matured, and I have a feeling that code generated by Krakatau might actually be more consistently understandable by j2objc than arbitrary Java, so it could be more reliable in every case if the decompilation step is robust enough.
So, how well tested is your code? Have you tested with different obfuscaters or with bytecode compiled from different languages etc? I will be happy to perform a whole bunch of tests myself, of course, I'm only asking you this here in case you can give me a good idea from what you have done already :).
Sorry for the long message, I ended up with more to say than I thought I did. Please feel free to delete this issue and reply by email to eliasv at hotmail.co.uk if that would be better.
Thanks for your help.