search

neva-dev / felix-search-webconsole-plugin

Search Web Console Plugin for Apache Felix
https://bintray.com/neva-dev/maven-public/felix-search-webconsole-plugin
Apache License 2.0
94 stars 21 forks source link

Support jd-core decompiler with partial line number output #23

Closed ielali closed 1 year ago

ielali commented 3 years ago

jd-core seems to be a much more stable project with lots of unit testing. I added support for output line numbers (can be disabled via configuration of class printer)

All in all I'd say it's better option than cfr, ideally we'd have a dropdown to choose the compiler...

pun-ky commented 3 years ago

yep, dropdown could be also cool ;)

yep, we are thinking the same. the more stable project the better.

pun-ky commented 3 years ago

now is the question... which one is better? :)

ielali commented 3 years ago

now is the question... which one is better? :)

If I were to choose one or the other I'd say definitely jd-core. But why choose? I'm confident I can make at least 3 available. The idea would be to add two more entries in settings, a dropdown to choose the decompiler and an option to include line numbers when available. The only drawback would be the size of the jar. Let me know what you decide.

pun-ky commented 3 years ago

is jd-core decompiling also code written in Scala and Kotlin? did you try to use Fernflower? 

IMO the decompiler select option may be accurate if decompilers will have exclusive features. if rather not, then the most feature-rich and stable decompiler should be only in use.

pun-ky commented 3 years ago

size of jar is rather not a problem as this tool is rather installed on development environments. however, installation of that tool should not break instances so... the less code the better / I am thinking about some compatibility issues. Potentially something could break on OSGi runtime unexpectedly. So this is the advantage of a battle-tested procyon. I have never seen an error related to that lib.