Might need to move to the bytecode deobfuscator if public boxed type
constructors are removed from future JDKs, but for now it's easier to do
this on the AST level.
It is an LTS release that will remain supported for a while. It is also
supported by Quasar 0.8.x, but JDK 13 is not (and JDK 12 will not be
supported for much longer).
This is a little bit grim and probably not completely safe in all cases,
but it works well enough on the client.
Ideally I think I'd do it with a dominator tree calculated from a call
graph aware of integer constants and conditional calls, but that's quite
complicated (especially given how the existing code in the
DummyArgTransformer works).
This commit makes two changes:
- Renames libjaggl.jnilib to libjaggl.dylib, to reflect the more modern
convention on OS X.
- Removes the distinction between jaggl.dll and jaggl64.dll. The
loadLibrary() code only attempts to use jaggl.dll now, with the
correct architecture being selected by the loader.
This fixes a problem where dummy arguments that already had more than 8
possible values in their set (because the dummy argument is used in a
greater or less than condition) were not removed, as we'd replace the
IntValue with an unknown value when two branches (where the dummy
argument is not modified) are merged back together.
It should also improve performance, as we'll be doing less memory
allocation.
This is for several reasons:
* It makes building the main OpenRS2 repository easier, as it no longer
requires a C compiler.
* Pre-built versions for all platforms will be available in the Maven
repository. Many versions might not have access to build environments
for all of the supported operating systems and architectures.
* The bundler module should be able to depend on the pre-built versions
in the Maven repository. The Maven reactor isn't quite clever enough
for this to work, especially when depending on .nar artifacts with a
different operating system or architecture.
