-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jarjar mangles classes even when no meaningful transformation applied #47
Comments
That sounds like a good idea. |
Awesome! I opened a pull request with proposed changes |
eed3si9n
pushed a commit
that referenced
this issue
Feb 5, 2024
…lied (#52) Fixes #47 In case big module and all it dependent jars are going through jarjar shading, there will probably be dependent jars which are not actually modified by shading. However because they go through jarjar, it unpacks, revisits, and repacks the class back resulting a technically different class from before shading (even class size can be different from original). This upsets classpath checkers (i.e. checking that runtime classpath has at most 1 unique class version). I propose to add a change so that jarjar can detect whether the meaningful transformation to class file has happened and if not, the class is unmodified. This pull request introduces following new concepts: - TracingRemapper: extension of Remapper with capability of tracking if the change was applied; - RemappingJarProcessor: extension of JarProcessor focusing on TracingRemapper-based processors. It assumes ownership of TracingRemapper, and will verify if the mentioned remapper did any transformation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey! I have the following problem.
In case big module and all it dependent jars are going through jarjar shading, there will probably be dependent jars which are not actually modified by shading.
However because they go through jarjar, it unpacks, revisits, and repacks the class back resulting a technically different class from before shading (even class size can be different from original). This upsets classpath checkers (i.e. checking that runtime classpath has at most 1 unique class version).
I propose to add a change so that jarjar can detect whether the meaningful transformation to class file has happened and if not, the class is unmodified.
If this aligns with your vision as well, I can share the actual implementation scratch I have. It augments MethodSignatureProcessor and JarTransformerChain so that they track whether the meaningful transformation to class file has happened and if not, the original byte array is returned.
cc @AlessandroPatti
The text was updated successfully, but these errors were encountered: