Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.2.4
-
None
Description
Preface
This issue relates to my mailing list question and the subsequent, fruitless meta discussion there, where nobody actually said anything about the problem at hand. So just like in the case of MSHADE-252, I fixed the problem by myself. Please see the attached pull request.
Problem description
When running Maven Shade with relocation, it works nicely.
When comparing JARs before and after relocation, I was surprised to see that Shade not just modifies the relocated classes and classes referencing them, but also a bunch of completely unrelated classes. Their byte code is slightly different, probably still does the same thing, but it makes comparisons and sanity checks or automatic verification steps harder than necessary.
BTW, the same Shade execution also relocates the sources (running my version with fixed MSHADE-252). In this case, only changed source files referencing the relocated classes are being changed, just like I would have expected.
Problem analysis
Maven Shade internally uses ASM's ClassRemapper and defines a custom Remapper subclass, which takes care of relocation, partially doing the work by itself and partially delegating to the ASM parent class. An ASM ClassReader reads each class file from the original JAR and unconditionally writes it into a ClassWriter, plugging in the transformer.
This transformation, even if not a single relocation (package name mapping) takes place, often leads to binary differences between original class and transformed class, because constant pool or stack map frames have been adjusted, not changing the functionality of the class, but making it look like something changed when comparing class files before and after the relocation process.
Solution / improvement
When reading each class file from the original JAR, we can store a copy in a byte array. We also need to adjust the relocation process such that a flag is set whenever anything is being relocated (package name change, textual or binary references to other relocated classes). After the transformation is done, Maven Shade can decide whether to write the original class file or the transformed one. This avoids writing transformed class files, even though no relocation has taken place for those files.
Attachments
Issue Links
- links to