Compilation Exception due to ASM?

[clojure-emacs]

Compilation Exception due to ASM?

[gtrak]

project$ lein deps :tree |grep asm

[org.ow2.asm/asm-commons "5.0.2"]
[org.ow2.asm/asm-tree "5.0.2"]
[org.ow2.asm/asm "5.0.2"]
[org.datanucleus/datanucleus-enhancer "2.0.3" :exclusions [[asm]]]
[asm "3.2"]

[gtrak]

asm 3.2's coming in through hadoop-core.. eww. I'm guessing it gets classloaded first.. gross.

We might consider a re-rooted ASM like what clojure itself uses.

[gtrak]

Is it possible to write this in terms of clojure's built-in re-rooted ASM impl? It's guaranteed to be there and not conflict with other versions of ASM. Clojure 1.6 has support for ASM 4.1, and earlier versions support 3.3.

Here's where they flipped versions: http://dev.clojure.org/jira/browse/CLJ-713

Can we re-write this to handle both cases?.

[gtrak]

@bbatsov we need to be very careful about project deps going forward.

I'd prefer pure-clojure and only-standard-lib impls where possible, plus we can rely on whatever's getting pulled in by tools.nrepl.

For instance, I don't have an explicit dep for cemerick/piggieback in my cljs impl, I resolve the vars dynamically.

In the future, we might consider splitting off chunks of middlewares into separate projects.

But, ASM and friends like CGLIB are especially problematic.

Or, heh, classloader isolation.

[jeffvalk]

Well that's a bummer of a stacktrace!

So I did originally look at using the bundled clojure.asm classes, but unfortunately this isn't a ideal option either. There are breaking API changes between ASM 3.x that Clojure 1.5 uses and ASM 4.x in Clojure 1.6. Supporting both <=1.5 and 1.6+ would require hacks. Hence the dependency on a single (external) version.

WRT to dependency minimization, I agree with you in principle -- fewer is better. In the case of host interop, though, building all the pieces from scratch isn't very attractive.

I will take another look at this and see if there's a reasonable way to eliminate the external ASM dependency. Reasonable is the key word here: I did hack up a macro that bridged the API incompatibility between ASM 3 and 4, but it seemed too clever by half. And that aside, we could always borrow Clojure's re-rooting trick like you mentioned. I'll have another look.

[gtrak]

Hacks wouldn't be so bad, I imagine we just have two quoted forms and eval
the right one at runtime.

Clojure.tools.logging already does this:
https://github.com/clojure/tools.logging/blob/master/src/main/clojure/clojure/tools/logging/impl.clj#L35

It's only a problem for AOT, which shouldn't be a problem here.

On Mon, Apr 28, 2014 at 6:58 PM, Jeff [email protected] wrote:

Well that's a bummer of a stacktrace!

So I did originally look at using the bundled clojure.asm classes, but
unfortunately this isn't a ideal option either. There are breaking API
changes between ASM 3.x that Clojure 1.5 uses and ASM 4.x in Clojure 1.6.
Supporting both <=1.5 and 1.6+ would require hacks. Hence the dependency on
a single (external) version.

WRT to dependency minimization, I agree with you in principle -- fewer is
better. In the case of host interop, though, building all the pieces from
scratch isn't very attractive.

I will take another look at this and see if there's a reasonable way to
eliminate the external ASM dependency. Reasonable is the key word here: I
did hack up a macro that bridged the API incompatibility between ASM 3 and
4, but it seemed too clever by half. And that aside, we could always borrow
Clojure's re-rooting trick like you mentioned. I'll have another look.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-41624648
.

[bbatsov]

@gtrak Ah, the dark side of the Java dep management. I haven't done much "enterprise" Java lately and had forgotten about such problems (which are extremely common in JEE). We should be more careful with the deps moving forward indeed.

[hugoduncan]

Ritz tried hard to use no external dependencies, in order to minimize potential conflicts with user code.

[bbatsov]

I think it is OK to use various tooling libs as users are extremely unlikely to be using them directly in their projects. We should just be careful about libs that are likely to affect an application.

[jeffvalk]

Agreed. I didn't think libraries other than dev tooling would have any reason to use ASM.

Anyway, the external dependency is removed in #45. And since the code is now (slightly) Clojure version dependent, I added profiles to the CI tests. Everything passes for 1.5, 1.6, and 1.7 snapshot.

[bbatsov]

Great! I've just pushed an updated snapshot to clojars.

[gtrak]

@jeff, lots of things use ASM and CGLIB, for instance AOP implementations
like Spring (this is where I've seen this before, built-in java stuff only
supports AOP across interfaces, not concrete/abstract classes). I can
certainly believe hadoop has a use for it. It's massively over-engineered
:-).

On Tue, Apr 29, 2014 at 10:57 AM, Bozhidar Batsov
[email protected]:

Closed #44 #44 via
#45 #45.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/44
.

[jeffvalk]

@gtrak Good idea to beware the dragons there. :-)

[bbatsov]

We no longer use asm. Guess you're not on the latest snapshot.

On Sunday, June 8, 2014, Matt DeBoard [email protected] wrote:

It looks as though Titanium also uses this, as I am being bitten by this
bug right now sigh

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

Best Regards,
Bozhidar Batsov

http://www.batsov.com

[mattdeboard]

I deleted my comment, but you're right :) I was on 0.6.1 in profiles.clj, but in project.clj I was specifying 0.7.0