tag:blog.danieljanus.pl,2019:category:leiningen 2010-03-31T00:00:00Z Daniel Janus http://danieljanus.pl dj@danieljanus.pl tag:blog.danieljanus.pl,2010-03-31:post:lein-swank 2010-03-31T00:00:00Z <div><p>A couple of weeks ago I finally got around to acquainting myself with [Leiningen][1], one of the most popular build tools for Clojure. The thing that stopped me the most was that Leiningen uses [Maven][2] under the hood, which seemed a scary beast at first sight — but once I’ve overcome the initial fear, it turned out to be a quite simple and useful tool.</p><p>One feature in particular is very useful for Emacs users like me: <code>lein swank</code>. You define all dependencies in <code>project.clj</code> as usual, add a magical line to <code>:dev-dependencies</code>, then say</p><pre><code>$ lein swank </code></pre><p>and lo and behold, you can <code>M-x slime-connect</code> from your Emacs and have all the code at your disposal.</p><p>There is, however, an issue that you must be aware of when using <code>lein swank</code>: Leiningen uses a custom class loader — [AntClassLoader][3] to be more precise — to load the Java classes referenced by the code. Despite being a seemingly irrelevant thing — an implementation detail — this can bite you in a number of most surprising and obscure ways. Try evaluating the following code in a Leiningen REPL:</p><pre><code class="hljs clojure">(<span class="hljs-name"><span class="hljs-built_in">str</span></span> (<span class="hljs-name">.decode</span> (<span class="hljs-name">java.nio.charset.Charset/forName</span> <span class="hljs-string">&quot;ISO-8859-2&quot;</span>) (<span class="hljs-name">java.nio.ByteBuffer/wrap</span> (<span class="hljs-name"><span class="hljs-built_in">into-array</span></span> Byte/TYPE (<span class="hljs-name"><span class="hljs-built_in">map</span></span> byte [<span class="hljs-number">-79</span> <span class="hljs-number">-26</span> <span class="hljs-number">-22</span>]))))) <span class="hljs-comment">;=&gt; &quot;???&quot;</span> </code></pre><p>The same code evaluated in a plain Clojure REPL will give you <code>"ąćę"</code>, which is a string represented in ISO-8859-2 by the three bytes from the above snippet.</p><p>Whence the difference? Internally, each charset is represented as a unique instance of its specific class. These are loaded lazily as needed by the <code>Charset/forName</code> method. Presumably, the system class loader is used for that, and somewhere along the way a <code>SecurityException</code> gets thrown and caught.</p><p>Note also that there are parts of Java API which use the charset lookup under the hood and are thus vulnerable to the same problem, for example <code>Reader</code> constructors taking charset names. If you use <code>clojure.contrib.duck-streams</code>, then rebinding <code>*default-encoding*</code> will not work from a Leiningen REPL. Jars and überjars produced by Leiningen should be fine, though.</p></div>