JarRemapper can now be configured to "generate an API", as part of
the remapping process. The output classes will only have the symbol names
(remapped, of course), but no executable code. Useful for projects to
build against this generated API.
Adds support for interpreting "CL: xxx/* yyy/*" in .srg for remapping
all class names beginning with xxx/ to yyy/. Previously this functionality
was only programmatically accessible when SpecialSource was used as a
library, but now you can use it from .srg mappings as well.
May be replaced with "PK: xxx yyy" support in .srg files later,
but needs to be first thoroughly tested for full compatibility,
to ensure identical semantics as in MCP (e.g. remapping ".").
Adding CL: /* class name prefix remapping for now, separate from PK:,
which simply remaps class names matching the given prefix substring.
Remaps constant literals passed to Class.forName(""), similar to
the existing class.getDeclaredField("") remapping in RemapperPreprocessor.
Both reflection remappings use the jarMapping, if one is passed in.
Adds new APIs to enable/disable the respective reflection remaps.
If the superclasses cannot be read in ClassLoaderProvider for any reason,
we ignore it and move on. This was the case before but the exception catch
was changed to only include IOError during the 1.5 refactor. This uncovered
an issue where on Java 8 inheritance traversal was hitting the Java 8 classes
in the JRE and throwing IllegalArgumentExceptions from ASM 4.1 since it does
not yet support the 52.0 classfile format.
To restore the previous behavior we change from catching IOException to Throwable,
including IllegalArgumentException. This will prevent correct inheritance trees
to be built on Java 8 classes however this is no worse than before and could be
fixed separately by an ASM 5 or 4.1.1 update once/if it is available.
For background see:
https://github.com/MinecraftPortCentral/MCPC-Plus/issues/841
The interface uses the generic Collection type but the implementation
an ArrayList. Fix by creating an ArrayList from the Collection. Resolves
this crash observed when updating MCPC+'s plugin loader:
https://gist.github.com/agaricusb/5471423
We now use a modified version of RemappingMethodAdaptor that bpasses the superclass LocalVariablesSorter
In addition I added a few more command line options, Most notibly:
kill-source: Removes the 'SourceFile' attribute
kill-lvt: Removes any LocalVariableTable attributes
kill-generics: Remvoes any LocalVariableTypeTable and Signature attributes
identifier: Tags each class with the specified UTF8 string in the constant pool. This is useful for loaders such as FML to know if the class has been obfusicated to SRG names or not.
File.separator is the separator used in subdirectory paths ('/'), whereas
File.pathSeparator is used in $PATH for separating multiple paths (':').
Using the wrong separator worked on OS X since the /var/folders subdir
could be created (":ss-cache") but failed on (Linux?) ci.md-5.net since
/tmp:ss-cache cannot be created (nor it should it be). With this change,
the path should be /tmp/ss-cache, as expected.
Useful since the files can be stored in non-obvious locations (on OS X,
temporary directory is in /var/folders with per-user random subdir) and
may need to be manually removed for testing. Could consider multiple
logging levels instead of always logging these messages.. but they're
more useful to show than most of the other 'verbose' log messages.
File.createTempFile() creates a temporary file, so we instead get
the java.io.tmpdir property and use File mkdirs().
There is a Files.createTempDirectory() method in JDK 7, and
Files.createTempDir() in Guava, could possibly use but for caching
its important to use a consistent path (also the path must be unique,
so the full URI is used, since it could refer to specific commit,
where the path disambiguates the resource, beyond the base filename).
Fixes 'no such file or directory' error building MCPC+ via SpecialSourceMP.
Normally, loadMappingsDir() loads:
obf -> num -> pkgmcp
but with numericSrgNames, it loads:
pkgmcp -> num
where:
obf = obfuscated "notch" names
num = numeric "srg" names
pkgmcp = descriptive "csv" names
This implementation could probably be improved further.
Compatibility Note: --numeric used to load these mappings:
obf -> num
that is, ignoring the fields/methods.csv. But this turned out not to
be too useful. You can still get this mapping with ignoreCsv=true, but
now numericSrgNames and --numeric loads the much more useful mapping:
pkgmcp -> num
Useful for targetting FML runtime deobfuscation.
Not used by CSVMappingTransformer, since the CSVs only contain:
func_###,newname
field_###,newname
with no class name, but it could be used by other load transformers.
Since AccessMap never downgrades visibility, 'private' in AT is
effectively equivalent to 'no change'. Useful in case you want to
change other flags but not the visibility. Accept '*' as private.
In addition to filenames and URLs, loadAccessTransformer(String) now
accepts the literal "pattern:" followed by an access transformer line.
Useful for adding individual transformations without a new _at.cfg.
Now will only upgrade, from private->default->protected->public.
Useful for modifying access with wildcards, e.g. classname.* protected
to change all fields in the class to protected -- except those which
are already public. This matches FML's access transformer behavior.
Allows for easily changing arbitrary symbol access flags. Supports
FML *_at.cfg access transformer file format loading in AccessMap.
Multiple AT's can be merged together and applied simultaneously
from the remapper 'preprocessor' class. Symbol visibility, final,
as well as any Java access flag can be set or cleared with +/-.
The remapped jar is altered and will fail to validate against
the included signatures from the original jar, if any. Normally
not a problem, you can compile against the remapped jar as a library
with no errors. However, when loading the jar from Maven (hit with
the Forge jar), signature validation will fail. Stripping the
signature files fixes this.