Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<p>Also known as <a href="http://dev.clojure.org/jira/browse/CLJ-322">CLJ-322</a></p><h2>Why do we AOT compile?</h2><ul><li>Interop<ul><li>To consume a Java API<ul><li>Concrete derivation (gen-class)</li><li>Naming/packaging conventions</li></ul></li><li>To expose an API to Java code<ul><li>deftype/record/protocol/interface</li></ul></li><li>Deployment environments<ul><li>Special classloaders, e.g. OSGi, Eclipse</li></ul></li></ul></li><li>Application delivery<ul><li>Main method (gen-class)<ul><li>Mitigated by &quot;-m&quot; option to clojure.main</li></ul></li><li>Bytecode post-processing<ul><li>Android/Dalvik</li></ul></li><li>Faster startup<ul><li>Only an issue in constrained environments like Android</li></ul></li><li>Hide source code from consumers</li></ul></li><li>Syntax check &amp; reflection warnings<ul><li>Doesn't require writing files to disk</li><li>But still a common use case for invoking the compiler</li><li>Some tools support emitting .class files to temp dir<ul><li>e.g. Mark Derricutt's clojure-maven-plugin</li></ul></li></ul></li></ul><h2>What do we want to AOT-compile?</h2><ul><li>Just a few things<ul><li>For the Interop case</li><li>Or to shorten build times</li><li>Not currently supported</li></ul></li><li>Everything<ul><li>For the &quot;Application delivery&quot;, &quot;Syntax check&quot;, and &quot;reflection warnings&quot; cases</li><li>Currently supported by <code>clojure.core/compile</code></li></ul></li></ul><h2>Current behavior</h2><ul><li>Why is AOT-compilation transitive?<ul><li>Clojure does not support separate compilation<ul><li>All symbols must resolved at compile time</li></ul></li><li><code><strong>compile-files</strong></code> is a boolean</li></ul></li><li>The effects of transitive compilation when AOT-comipiling a namespace &quot;A&quot;<ul><li>When namespace A loads namespace B within the same project<ul><li>Namespace B is AOT-compiled and emitted</li></ul></li><li>When namespace A loads library C from external JAR<ul><li>Library C's namespaces are AOT-compiled and emitted alongside A's</li></ul></li></ul></li><li>Work-arounds<ul><li>Build tools: filter unwanted .class files from JAR<ul><li>Ant, Maven, scripting</li><li>Clojure itself does this, e.g. &quot;slim&quot; JAR</li><li>Tedious</li><li>Not commonly used</li><li>Wastes time during builds to AOT-compile things which will be deleted</li></ul></li><li>Write Java<ul><li>Fairly common</li></ul></li></ul></li></ul><h2>Proposed solutions</h2><h3>Finer-grained control of the compilation process</h3><ul><li>A. Global flag for transitive/non-transitive compilation<ul><li>Chas Emerick's patch<ul><li>New system property &quot;clojure.compiler.transitive&quot;</li><li>When true (default), preserves current behavior</li><li>When false, only namespaces give as arguments to `compile` are emitted</li></ul></li><li>Doesn't handle classes created by deftype/record/etc.</li></ul></li><li>B. Specify exactly which .class files should be emitted<ul><li>Stuart Sierra's patch<ul><li>Specified as a Set of Strings, but could be any function, e.g. regex</li></ul></li></ul></li><li>C. Global flag for compiling &quot;interop&quot; forms<ul><li>Is there a universal definition of what an &quot;interop&quot; form is?<ul><li>gen-class, obviously</li><li>defprotocol?</li><li>deftype/defrecord?</li></ul></li><li>Does not require maintaining list of .class files to emit</li><li>Could provide a convenient defaults for the common case</li><li>Macros like &quot;deftype&quot; can opt in with metadata</li></ul></li><li>D. Metadata to control AOT-compilation</li><ul><li>Permits fine-grained control</li><li>In-line with source code</li><li>How to support multiple AOT-compilation strategies in a single build<ul><li>E.g. dev build only AOT-compiles interop forms, production AOT-compiles everything</li></ul></li></ul></ul><h3>Separate writing class files from compilation</h3><ul><li>E. Compiler holds references to generated bytecode<ul><li>Not currently implemented in any patch</li><li>After compilation, call function to emit .class files</li><li>Will use lots of memory!<ul><li>Or will it? The JVM already has this stuff in memory</li><li>Must disable in production!</li></ul></li><li>Brings us closer to a Smalltalk-like &quot;program image&quot;</li></ul></li></ul>