I think we have the correct behaviour in all cases now: fields will
never override fields. Only non-static methods may override other
methods.
Signed-off-by: Graham <gpe@openrs2.dev>
A static member should not override an equivalent member in a superclass
or superinterface. This commit makes us skip the union() calls for
static methods, such that the two disjoint sets are not incorrectly
joined together.
Signed-off-by: Graham <gpe@openrs2.dev>
This allows us to avoid needing to worry about manipulating stack frames
in individual transformers, which adds lots of complexity. It's much
easier to just make ASM generate them for us.
Signed-off-by: Graham <gpe@openrs2.dev>
This is necessary for a future commit that will track the original
indexes of AbstractInsnNodes throughout the deobfuscator, with the aim
of using this information to track local variables in the decompiled
code.
I suspect this will also improve performance, as we don't need to
re-allocate all of the tree objects.
This isn't ideal as it's deprecated. However, while Apache Harmony's
unpack200 implementation seems fine, its pack200 implementation doesn't
work with the client and produces invalid output.
I've fixed some of the easy to fix bugs, but tracking down any remaining
bugs will be difficult - it'll involve tracing through the native
unpack200 code.
When Pack200 is removed from the JDK, hopefully someone will take up the
mantle of maintaining it outside of the JDK. If that doesn't happen,
we'll have to consider writing our own Pack200 implementation,
extracting OpenJDK's implementation out of the tree or fixing the bugs
in Apache Harmony.
The dependency/interface properties are translated to getDependency and
getInterface. I don't know if it is possible to fix this, but it won't matter
when the rest of the codebase is converted to Kotlin.
This commit stops ClassForNameTransformer from extending Transformer and
renames it. I think this makes sense, as we don't use it like a normal
Transformer.
This is a prerequisite for removing dummy arguments - before the methods
are remapped, removing an argument might cause the method to conflict
with another method with the same name and descriptor as the replacement
descriptor.
This is in preparation for Transformers taking an entire ClassPath
instead of a single Library at a time, which is in turn required for
dummy argument removal (a whole program analysis).
