Upgrading ASM (CLJ-713)

[Paul Stadig]

CLJ-713 (http://dev.clojure.org/jira/browse/CLJ-713) is about
upgrading the ASM library that is bundled with Clojure. I've done some
tests, and it doesn't seem to be a big deal to do so. There is one
change necessary in clojure.reflect.java because ASM moved from
interfaces to abstract classes (changing a reify to proxy).

I've done it with re-rooting ASM and with adding it as a dependency,
and the only additional issue is that when ASM is a dependency the
build.xml and pom.xml need to be modified to pass along the
maven.compile.classpath property to the compile-tests task. The ticket
and the design page (http://dev.clojure.org/display/design/ASM) both
mention "no longer sub-setting" ASM. I'm not sure what this means.
There are some namespaces that are not re-rooted in Clojure right now,
but they are also not used, so I'm not sure what the value would be in
pulling them in.

Also, the design page says that a future direction would be to split
out the still re-rooted ASM lib into a separate jar that can be left
out on delivery targets where dynamic code gen is not needed. What
would be the value in doing that over just depending on the plain old
ASM lib? Unless there are other implications we would worry about, the
changes to go ahead and depend on ASM now are about the same as
re-rooting it, so I would think we could just go ahead with an
external jar now.

I'm interested in this because I'd like to experiment with modifying
the compiler to emit invokedynamic call sites when reflection is used.
I thought I could go ahead and submit the ASM change even though the
ticket is in currently in the "Approved Backlog."

Any thoughts/concerns about this?


Paul

[Rich Hickey]

Definitely interested in this. It's not exactly clear to me what you are saying with your questions.

The problem with straight ASM jar dependency is conflicts with others using ASM (other langs, Hibernate etc).

Ideally we would:

Only use as much ASM as we need.
Reroot it
Put it in an external jar

It would be good to survey what others (JRuby, Groovy) et al are doing these days, but I think you'll find there are always conflict issues with ASM.

> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>

[Paul Stadig]

On Oct 13, 2012 2:04 PM, "Rich Hickey" <richh...@gmail.com> wrote:
>
> Definitely interested in this. It's not exactly clear to me what you are saying with your questions.

My understanding of the ticket and design was:
1. We want to re-root all of ASM, even the parts we do not currently use.
2. We want to distribute a jar of the whole ASM re-rooted, instead of
just using the official ASM jar.

I was curious if this was still the desired plan, and what the
rationale was. What I hear you saying is, we want to re-root only what
we use, and we do want to distribute a jar of that re-rooted ASM
instead of using the official ASM jar, because of conflict issues
mentioned below.

> The problem with straight ASM jar dependency is conflicts with others using ASM (other langs, Hibernate etc).

This makes sense, though JRuby and Groovy seem to not be concerned about this?

> Ideally we would:
>
> Only use as much ASM as we need.
> Reroot it
> Put it in an external jar
>
> It would be good to survey what others (JRuby, Groovy) et al are doing these days, but I think you'll find there are always conflict issues with ASM.

It looks to me like both JRuby[1] and Groovy[2] use the official ASM
jar. Though with JRuby it pulls the classes into its jruby-core.jar
instead of establishing a dependency[3].

Does that change any of your thoughts about upgrading? If not, should
we create a contrib project to import ASM?


Paul

[1] https://github.com/jruby/jruby/tree/master/build_lib
[2] http://mvnrepository.com/artifact/org.codehaus.groovy/groovy/2.0.4
[3] https://github.com/jruby/jruby/blob/master/maven/jruby-core/pom.xml#L92