the war on needless AOT begins: http://dev.clojure.org/jira/browse/CLJ-733

[Stuart Halloway]

One goal of CLJ-733 is to get application and library code out of the
exception class business. (E.g. slingshot could drop Stone in favor of
ExceptionInfo and no longer require AOT.)

If this gets added to Clojure, will it eliminate a cause for AOT on
some of your projects? What other causes remain?

Stu

[Sean Corfield]

On Fri, Oct 14, 2011 at 10:57 AM, Stuart Halloway
<stuart....@gmail.com> wrote:
> If this gets added to Clojure, will it eliminate a cause for AOT on
> some of your projects? What other causes remain?

Won't affect AOT for me: I have a log4j appender in Clojure that needs
AOT compilation to be found / loaded by log4j as a Java class.

What would help me: fixing the transitive AOT compilation issue -
http://dev.clojure.org/jira/browse/CLJ-322 :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Nate Young]

On Fri, Oct 14, 2011 at 4:22 PM, Sean Corfield <seanco...@gmail.com> wrote:
> On Fri, Oct 14, 2011 at 10:57 AM, Stuart Halloway
> <stuart....@gmail.com> wrote:
>> If this gets added to Clojure, will it eliminate a cause for AOT on
>> some of your projects? What other causes remain?

From a traipse through our codebase, our AOT cases are all
packaging-driven aside from a couple of custom exceptions, which it
sounds like CLJ-733 is aimed at eliminating. We try to compile all our
source so that we're not distributing our secret sauce to the folks
who would rather buy it from us than write it themselves, and we
generate a main class so that we can make our product executable from
a jar.

Having a large codebase (I'm at Revelytix diagonally opposed to Alex
Miller's desk), we pull in a metric flickton of library code, and like
he alluded to, we don't want our dependencies' class files generated
when we compile our code, so consider this another vote for CLJ-322.

[Phil Hagelberg]

On Fri, Oct 14, 2011 at 4:38 PM, Nate Young <you...@gmail.com> wrote:
> we generate a main class so that we can make our product executable from
> a jar.

Do you know about "java -jar myapp.jar clojure.main -m my.ns"? It
didn't make it into 1.2 unfortunately, but if you're on 1.3 you should
be able to call -main functions from the command-line more easily
without AOT.

-Phil

[Nate Young]

I did not, but will certainly take a gander. Thanks.

--
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.

[Laurent PETIT]

2011/10/14 Stuart Halloway <stuart....@gmail.com>:

CCW is using gen-class for e.g. extending, here and there, abstract
classes provided by Eclipse core plugins.

As time passes, I'm slowly refactoring the code so that instead of
plugging clojure into java via AOT, I write plain old java classes
which act as proxies to clojure code. But I'm not there yet.

Having AOT compile dependencies is also a problem in the Eclipse
Plugins/OSGi bundles world, of course.

-- Laurent

>
> Stu

[Stuart Halloway]

> Having a large codebase (I'm at Revelytix diagonally opposed to Alex
> Miller's desk), we pull in a metric flickton of library code, and like
> he alluded to, we don't want our dependencies' class files generated
> when we compile our code, so consider this another vote for CLJ-322.

+1 on CLJ-322 from me as well.

Now who will bell the cat?

Stu

[Luc Prefontaine]

Leiningen avoids packaging files from dependencies in the target lib.

I wrote a primitive lein plug in last summer to prune alien class files before creating the project target.
After the first Conj Phil added a similar but more fine grained guard to Leiningen to work around the problem (CLJ-322) in the interim.
This is in place since 1.4.x if I recall correctly.

Having a dozen targets to build and seeing dependency classes in every target was a major headache for us.

We have been using AOT to deliver our components for more than a year now.
Note that we did not take the path of rebuilding libs like contrib locally to deliver them AOT with our components.

I understand the concerns about meeting different targets (which JVM, which version, ...) when creating public libs.
AOT may bring its share of problems in this context and shipping source only code is the least expensive alternative.

For us internally, AOT however will not disappear from the horizon any soon given;

a) the number of our own internal targets (around a dozen),

b) the intellectual property protection of our code,

c) the mixed language issue (Clojure,Java, JRuby) which will decrease but it will take us a year
and attain a 95% Clojure/ClojureScript level, we use protocols from Java and until the Java code
chunk vanishes we need AOT,

d) the frequent incremental deliveries which implies incremental replacement of some targets,

e) the cost of finding trivial errors (the ones that the compiler can find) after upgrading a customer's system (24x7 service),

f) we use 75 external dependency jars, this is expected to shrink but not disappear completely, using the compiler
is a safe guard for us against unexpected changes in this mix,

g) our internal work flow which relies heavily on JVM centric build facilities (Maven/Leiningen/Local Maven repo - Archiva).

So far for us the current build process with AOT is satisfactory. It's the last sanity barrier between dev and testing.
Of course if opportunities to improve this pop-up in the future we will have a look at it.

Luc P.

--
Luc P.

================
The rabid Muppet