[MSHADE-105] Classes processed by the relocator still have references to the original classes in their constant pools

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 1.4
• Fix Version/s: 1.6
• Flags: Patch
• Assignee: Olivier Lamy
• Reporter: Andreas Veithen
• Created: 05/Oct/11 14:50
• Updated: 16/May/22 17:58
• Resolved: 10/Mar/12 16:12

Description

DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of ClassWriter(int). According to the ASM Javadoc, this has the following effects:

"- The constant pool from the original class is copied as is in the new class, which saves time. New constant pool entries will be added at the end if necessary, but unused constant pool entries won't be removed.

• Methods that are not transformed are copied as is in the new class, directly from the original class bytecode (i.e. without emitting visit events for all the method instructions), which saves a lot of time. Untransformed methods are detected by the fact that the ClassReader receives MethodVisitor objects that come from a ClassWriter (and not from a custom ClassAdapter or any other ClassVisitor instance)."

The second item is actually not applicable in the case of DefaultShader because the entire class needs to be transformed anyway. On the other hand, the first item implies that the constant pool of the transformed class will still have references to the original classes. This can be seen from the attached "javap.txt" file (produced by javap on a class relocated by maven-shade-plugin): the relocation adds new entries at the end of the constant pool, but the original entries are still present.

Since the original entries are no longer referenced anywhere in the class, this has no consequences at runtime. However, some tools such as Felix' maven-bundle-plugin use the constant pool to determine the dependencies of a class. The effect is that if such a shaded JAR is embedded into a bundle using maven-bundle-plugin, it will generate spurious Import-Package instructions referring to the original package names. An example of this is described in AXIS2-5145.

The solution to this problem is simply not to pass the ClassReader object to the ClassWriter constructor. With this change, the constant pool is properly cleaned up (see the attached "javap2.txt" file).

Issue Links

• links to: GitHub Pull Request #136