[jira] [Created] (MSHADE-391) Do not modify class files, if nothing was relocated

["Alexander Kriegisch (Jira)" <ji...@apache.org>]

Alexander Kriegisch created MSHADE-391:
------------------------------------------

             Summary: Do not modify class files, if nothing was relocated
                 Key: MSHADE-391
                 URL: https://issues.apache.org/jira/browse/MSHADE-391
             Project: Maven Shade Plugin
          Issue Type: Improvement
    Affects Versions: 3.2.4
            Reporter: Alexander Kriegisch


h3. Preface
_This issue relates to my [mailing list question|https://www.mail-archive.com/users@maven.apache.org/msg143192.html] 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. Shortly, I am going to link a GitHub pull request to this question, once I have an issue ID for it._

h3. 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.

h3. 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.

h3. 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)