More user friendly API

[sirinath]

Can some helper API be added so the end user can be insulated from lower level details like: ([Ljava/lang/String;)V, Ljava/io/PrintStream; where one writes in more families code constructors which is converted to the current lower level API calls.

Similarly one can search and replace byte-code slightly more higher level and close to source code.

[EricLafortune]

Thanks for your note. Java bytecode indeed has its own format and structures, which are close to but different from Java/Kotlin/etc source code. Being insulated is not the intention at this level, but ProGuardCORE has classes to work with these structures and to go back and forth between more readable notations. Notably:

• proguard.classfile.util.ClassUtil with conversion methods
• proguard.classfile.util.InternalTypeEnumeration to extract types from a bytecode type descriptor
• proguard.classfile.util.ExternalTypeEnumeration to extract types from a Java-style type descriptor
• proguard.classfile.util.DescriptorClassEnumeration to extract class names from a bytecode type descriptor
• proguard.classfile.ClassConstants, etc. with bytecode constants
• proguard.classfile.Java*Constants with Java-style constants

At the code level, Java bytecode looks even more different from Java source code indeed. ProGuardCORE does not intend to be a compiler. For that purpose, you can use a standard compiler, but you still need to understand the resulting bytecode to manipulate it.

[sirinath]

As a side note Spoon has reverse engineering to get back to a more high level view which is closer to the source.

[EricLafortune]

Spoon looks nice indeed and is definitely better suited if you prefer working with Java source code. Decompilation may then be the weakest link, since not all Java bytecode can be easily/successfully/completely reverted to Java source code.

[sirinath]

It would be great if something can be done to bridge the gap. Not fully Java but high level and not too low level.