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)
