EsotericSoftware / reflectasm

High performance Java reflection
BSD 3-Clause "New" or "Revised" License
1.53k stars 222 forks source link

Repackage asm #54

Closed greenlaw110 closed 6 years ago

greenlaw110 commented 7 years ago

This library use asm 5.1 (at the moment) direclty. However as per http://asm.ow2.org/doc/faq.html#Q15, it suggest that

Tools and frameworks that are using ASM for bytecode processing (e.g. Hibernate, CGLIB, AspectWerkz) should repackage ASM code within their own name space. This can be automated with Jar Jar Links tool.

Here is a real issue caused by ASM library version conflict between sun's jersey and ReflectASM

NathanSweet commented 7 years ago

I tried, jar jar links appears to be broken.

greenlaw110 commented 7 years ago

@NathanSweet

Well IDE is your friend, it's very simple to load all ASM code into your ide and run a code refactory to change the package name. You don't really need jarjar to work.

NathanSweet commented 7 years ago

I'd rather modify the built artifact provided by ObjectWeb than repackage it from source each time it needs updating. As you can see in the jarjar issue, I got it to work. Their docs were outdated and their launcher code half wrong.

greenlaw110 commented 7 years ago

My approach is to create a separate project that package the asm, and maintain that project including release it as a separate jar in the maven repository.

But anyway it's your call

magro commented 7 years ago

@NathanSweet I guess pom.xml still has to be adjusted to make this work for other users and in the context of releasing to maven, right?!

NathanSweet commented 7 years ago

@magro Yes.

magro commented 7 years ago

We're already building/releasing a shaded jar, creating an additional artifact with a classifier attached. We could use the shading approach and just release the shaded jar instead of using jarjar (not sure how this would be integrated via maven).

NathanSweet commented 7 years ago

Normally I would leave shading to whoever is cobbling together conflicting dependencies, but if the ASM people are saying we should shade their lib and distribute that, then I guess we don't need a non-shaded JAR.

Maven doesn't have to use jar jar, though it's possible. Can we shade it to "com.esotericsoftware.asm"?

Is it a problem for Maven that I use a shaded ASM JAR as a dependency? That means the ReflectASM source is using shaded imports.

magro commented 7 years ago

Can we shade it to "com.esotericsoftware.asm"?

Yes we can. In the PR (#57) I left it unchanged to keep changes as small as possible, but I don't think that changing to "com.esotericsoftware.asm" would break anything (assuming nobody uses the shaded classes of course). What's your motivation btw?

Is it a problem for Maven that I use a shaded ASM JAR as a dependency? That means the ReflectASM source is using shaded imports.

That's the problem, because maven doesn't use the patched asm jar, but the original one as declared as dependency. Therefore compilation fails.

NathanSweet commented 7 years ago

The long package name was just very long. :)

I'm fine with shading it after building the ReflectASM JAR. Next time I want to do a release for GitHub I'll probably make scar/jarjar do it.

magro commented 7 years ago

Next time I want to do a release for GitHub I'll probably make scar/jarjar do it.

So you're not going to use mvn package for this? Shall we set up the maven/sonatype push-to-maven-central stuff for you? It's not that much...

He-Pin commented 7 years ago
Caused by: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.<init>(I)V
  at com.esotericsoftware.reflectasm.MethodAccess.get(MethodAccess.java:120)
  at com.taobao.xgraphql.annotation.AnnotationToAST.getGraphQLObjectType(AnnotationToAST.java:451)

the packed version is not released,so ....

He-Pin commented 7 years ago

I have done a shade in my local code:)

NathanSweet commented 6 years ago

So you're not going to use mvn package for this?

@magro Since I'm not a Maven user, doing releases that way is asking for trouble. If it's OK with you, you can be the Maven master.

Does anything more need to be done for this isssue? Currently the ReflectASM source is using an ASM JAR repacked to com.esotericsoftware.asm. We need a new 1.11.6 Maven release (#60), so once that is done I think we can close this.

NathanSweet commented 6 years ago

Somewhat OT for RefelctASM but, @magro since ReflectASM uses a repacked ASM, maybe we don't need to provided a shaded Kryo any more? If we do, the use case would not be about ASM, but that you had two libraries that use different versions of Kryo. In that case we would want to shade the entire Kryo lib and its dependencies.

magro commented 6 years ago

@NathanSweet Your commit ade0542 broke the mvn build, i.e. right now it's not possible anymore for me to publish the library to maven central. I don't have the time to check out other ways of building / publishing. If you want me to publish this thing to maven central so that kryo can use a new version I see nothing else than reverting the mentioned commit and merge #57 instead (of course there we can change the package name to com.esotericsoftware.asm).

NathanSweet commented 6 years ago

Yep, reverting and doing the repack with Maven is fine.