Oh, you know me: I avoid AOT and gen-class at all costs _if I don’t have to use
them_
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
From:
I got the impression this was the primary reason for Storm’s rewrite:
While Storm's Clojure implementation served it well for many years, it was
often cited as a barrier for entry to new contributors. Storm's codebase is now
more accessible to developers who don't want to learn Clojure in order
Two reasons:
1. When I searched for ‘annotations in Clojure’ I pretty much came up empty
– so I didn’t know you could do that sort of stuff with gen-class
2. I was very focused on adding annotations to specific functions that I
wanted New Relic to trace so I didn’t think much about
Storm recently moved away from Clojure in its core.
https://storm.apache.org/2019/05/30/storm200-released.html
I wonder how much of the legacy Clojure core could be optimised or if they
reached an upper limit imposed by the runtime/architecture. That being said
I suspect for 90% of orgs they'll
In that case, I would try to isolate those gen-classes into as small a box
as possible and make an artifact for just those.
On Fri, Jun 21, 2019 at 4:58 PM Didier wrote:
> Oh, not when you don't have too. I mean, you can always hand write a class
> in Java and have it call into Clojure. That's
Oh, not when you don't have too. I mean, you can always hand write a class in
Java and have it call into Clojure. That's effectively gen-class but done
manually. Otherwise, I favour the Clojure Java API.
But some code base are already using gen-class, and some people do use
gen-class.
I just don’t understand why you would introduce aot or gen-class at all if you
didn’t have to, which is one of the benefits of using the Clojure Java API.
> On Jun 21, 2019, at 2:35 PM, Sean Corfield wrote:
>
> The approach I’ve taken around :gen-class has been to ensure that the
> namespace
Sean,
That is an interesting blog post. Sorry if I am not following everything
but why not use the annotation support in gen-class for those types of
things?
https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34
The approach I’ve taken around :gen-class has been to ensure that the namespace
offering the Java class via :gen-class has no static dependencies at all –
instead it requires/resolves any other namespaces/symbols it needs at run time.
That way AOT creates the .class you need but doesn’t spread
You might be interested in how we provide type-based annotations on Clojure
functions so that tooling (in our case New Relic) sees those annotations:
https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/
I agree that this could be a lot easier.
Sean Corfield --
Interesting about impl-ns, I'll have to look into that. If so, it would greatly
simplify it all.
In my experience, if you only keep the gen-class .class, and delete everything
else, it all works without issues. If you are actually doing AOT, not for the
purpose of gen-class, I wouldn't
With AOT, you generally shouldn't ever exclude part of the AOT'ed code.
Most problems with AOT'ed code stem from having AOT'ed code call into
non-AOT'ed code, so anything "downstream" should also be AOT'ed.
On Fri, Jun 21, 2019 at 10:01 AM eglue wrote:
> This is a good clarification.
>
> I
This is a good clarification.
I found that when I tried to exclude some AOT stuff from the jar you can
get into a situation where Clojure will dynamically produce a class that is
already statically-produced at the root classloader and then you'll hit
ClassPathExceptions when you try to pass
Instead of deleting class files from a jar, you can use the :impl-ns option
on gen-class to stop transitive AOT. (gen-class makes a class file, but
AOT does not reach the impl-ns.) I don't remember seeing this in the
manual, but I don't know why else impl-ns would exist...
On Friday, June
14 matches
Mail list logo
