JarMapping now contains the IInheritanceProvider and tryClimb()
instead of JarRemapper, to allow other remappers access to the
same inheritance traversal code.
The trailing slash was being remapped, causing incorrect package names.
Expected format is for example:
org/bukkit/craftbukkit/v1_4_6/ org/bukkit/craftbukkit/v1_4_R1
to replace org/bukkit/craftbukkit/v1_4_6 -> org/bukkit/craftbukkit/v1_4_R1
The trailing slash is only to disambiguate from class remaps in csrg.
Remap through only one inheritance provider, instead of a list of them.
The multiple inheritance provider lookup functionality (check each one,
in order, until one provider responds for the class name) is still
available, but refactored into a new InheritanceProviders class.
Simplifies the common case of only having one inheritance provider, and
also reduces the redundant looping code previously in JarMapper/InheritanceMap.
The inheritance map, as generated with --write-inheritance/-H, can now
be read using --read-inheritance/-H. It will be remapped through the
currently loaded inverse mapping before supplying the inheritance provider.
Example usage:
java -cp target/SpecialSource-1.3-SNAPSHOT-shaded.jar net.md_5.specialsource.SpecialSource --shade-relocation net.minecraft.server=net.minecraft.server.v1_4_R1 --shade-relocation org.bouncycastle=net.minecraft.v1_4_R1.org.bouncycastle --srg-in ../jars/1.4.7/cb2obf.csrg --in-jar ../IncompatiblePlugin/target/bukkit-sample-plugin-0.5.jar --out-jar /tmp/sp/out.jar -h /tmp/h
where the inheritance map was previously generated using:
java -cp target/SpecialSource-1.3-SNAPSHOT-shaded.jar:mcpc-plus-1.4.7-R0.2-SNAPSHOT.jar net.md_5.specialsource.SpecialSource --srg-in ~/minecraft/1.4.x/jars/1.4.7/cb2obf.csrg --live --write-inheritance /tmp/h
Only includes mapped classes in the parents, and only includes entries
for classes which have relevant parents (extends/implements classes).
Shrinks inheritance map on MCPC+ build 73 by 279 lines.
New --write-inheritance/-H command-line option, iterates all classes
in mapping and writes inheritance (interfaces and superclasses) to file.
Example usage, generating inheritance map from MCPC+:
java -cp target/SpecialSource-1.3-SNAPSHOT-shaded.jar:mcpc-plus-1.4.7-R0.2-SNAPSHOT.jar net.md_5.specialsource.SpecialSource --srg-in ~/minecraft/1.4.x/jars/1.4.7/cb2obf.csrg --live --write-inheritance /tmp/h
Used to lookup the inheritance if every single class - now will return
null and allow other inheritance providers to answer instead.
Consequentially mapTypeName() has been enhanced to accept a 'default' type name:
pass the same typeName to 'pass through' unmapped names, or null if you want to
distinguish between unmapped and mapped names, as RemappedRuntimeInheritanceProvider does.
Previously, the runtime inheritance providers would always use the
system classloader. Now you have to explicitly pass the classloader
to use. Also add a 'verbose' flag for debugging.
Although SpecialSource avoids generating unnecessary output where
methods/fields are not renamed, the _absence_ of a class rename is
arguably as important as a class rename, especially when comparing
jars where nearly all classes are renamed.
In the common case of generating Minecraft mappings from an obfuscated
jar and an internally-renamed deobfuscated mc-dev jar, all classes
are renamed, except for one -- the main class:
net/minecraft/server/MinecraftServer net/minecraft/server/MinecraftServer
When the mc-dev server jar is shaded into CraftBukkit, all classes are
relocated under a versioned package. However, the shading relocation
simulator misses MinecraftServer since it is not included in the mappings,
as it isn't renamed.
Always outputting class names, regardless of whether they are renamed,
only increases the mapping file by one line and removes the need to
special-case MinecraftServer.
Allows inheritance to be loaded through URLClassLoader, as an alternative
to JarFile/Jar with JarInheritanceProvider. This is how CB loads plugins, and
it may avoid some of the idiosyncrasies in loading the jar directly as a zip -
for example https://github.com/MinecraftPortCentral/MCPC-Plus/issues/51
java.util.zip.ZipException: duplicate entry (CB can load this plugin just fine)
Also allows more convenient remapping in PluginClassLoader, since the
URLClassLoader object is readily available
The input is now a BufferedReader, so you can read from a file with
new BufferedReader(new FileReader(...)), or from an input stream with
new BufferedReader(new InputStreamReader(...)).
RemappedRuntimeInheritanceProvider is similar to RuntimeInheritanceProvider, providing
access to inheritance information at runtime, but class names are remapped before
looking up, and the inheritance is reverse-remapped before returning.
This allows the inheritance to be provided from an obfuscated jar, via the cb2obf
mappings. For example:
java -cp target/SpecialSource-1.2-SNAPSHOT-shaded.jar:mcpc-plus-1.4.7-R0.2-SNAPSHOT-023.jar net.md_5.specialsource.SpecialSource --shade-relocation net.minecraft.server=net.minecraft.server.v1_4_R1 --shade-relocation org.bouncycastle=net.minecraft.v1_4_R1.org.bouncycastle --srg-in ../jars/1.4.7/cb2obf.csrg --in-jar ../IncompatiblePlugin/IncompatiblePlugin-01.jar --out-jar /tmp/sp/out.jar -L
-L enables remapped runtime inheritance, in order to use the obfuscated MCPC+ jar classes
to lookup the inherited classes for remapping. The same mappings are used as for remapping
the plugin (--srg-in and --shade-relocation take effect).
The original option, -l, in contrast does not remap on class lookup, and can be used to
lookup inheritance from a jar with CraftBukkit mappings, for example:
java -cp target/SpecialSource-1.2-SNAPSHOT-shaded.jar:craftbukkit-1.4.7-R0.1.jar net.md_5.specialsource.SpecialSource --shade-relocation net.minecraft.server=net.minecraft.server.v1_4_R1 --shade-relocation org.bouncycastle=net.minecraft.v1_4_R1.org.bouncycastle --srg-in ../jars/1.4.7/cb2obf.csrg --in-jar ../IncompatiblePlugin/IncompatiblePlugin-01.jar --out-jar /tmp/sp/out.jar -l
Previously, each provider would be consulted until a matching parent is
found. This is incorrect and caused spurious warnings with --live
(jar + runtime inheritance), as unmatched classes in the jar would fall
through to the runtime inheritance provider.
Now once a provider returns non-null, no other providers are checked.
null indicates the provider knows nothing about the class and should
ask elsewhere, non-null indicates a definitive list of inheritance
(extends/implements list) classes. Should be slightly faster, too.
The JarRemapper constructor is now public; you can create a remapper
with a JarMapping and list of IInheritanceProviders, and then use it
to remap an entire jar with remapJar(), or individual classes using
remapClassFile().
If -l is specified, will now traverse the runtime class hierarchy in
tryClimb to determine the method/symbol from the parent to remap, in
addition to the classes in the jar.
This can be used to remap plugins that call into external classes.
For example, with a Bukkit plugin:
java -cp ../jars/craftbukkit-1.4.7-R0.1.jar:target/SpecialSource-1.1-SNAPSHOT.jar net.md_5.specialsource.SpecialSource --shade-relocation net.minecraft.server=net.minecraft.server.v1_4_R1 --shade-relocation org.bouncycastle=net.minecraft.v1_4_R1.org.bouncycastle --srg-in ../jars/1.4.7/cb2obf.csrg --in ../IncompatiblePlugin/IncompatiblePlugin-01.jar --out /tmp/bp/out.jar
using:
https://bitbucket.org/agaricusb/incompatibleplugin/downloads/IncompatiblePlugin-01.jar6d75d94496
agaricus/plugins/IncompatiblePlugin/SamplePosCommand.java will be remapped:
worldServer.q(...)
from worldServer.getTileEntity(). World provides getTileEntity and is remapped in cb2obf;
but WorldServer subclasses World and overrides getTileEntiy.. this information is not
available in the plugin itself and would not be remapped alone. By adding the CB jar to
the classpath and enabling runtime inheritance, the call is correctly remapped.
