<!--
RSS generated by JIRA (4.4#649-r158309) at Thu May 23 06:50:16 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+10010+AND+labels+%3D+bug&tempMax=1000&field=key&field=summary
-->
<!-- If you wish to do custom client-side styling of RSS, uncomment this:
<?xml-stylesheet href="http://dev.clojure.org/jira/styles/jiraxml2html.xsl" type="text/xsl"?>
-->
<rss version="0.92">
    <channel>
        <title>Clojure JIRA</title>
        <link>http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+10010+AND+labels+%3D+bug</link>
        <description>An XML representation of a search request</description>
                <language>en-us</language>
                        <issue start="0" end="15" total="15"/>
                <build-info>
            <version>4.4</version>
            <build-number>649</build-number>
            <build-date>25-07-2011</build-date>
        </build-info>
<item>
            <title>[CLJ-1184] Evaling #{do ...} or [do ...] is treated as the do special form</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1184</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Evaluating a persistent collection for which the function &apos;first&apos; returns the symbol &apos;do&apos; leads to that collection being treated as the do special form, even though it may be a vector or even a set. IMHO, the expected result would be to report that &apos;do&apos; cannot be resolved. For the cause, see the if condition on line 6604 of Compiler.java in clojure-1.5.1.&lt;/p&gt;

&lt;p&gt;E.g.:&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;do 1 2&amp;#93;&lt;/span&gt;&lt;br/&gt;
;=&amp;gt; 2&lt;/p&gt;

&lt;p&gt;#{&quot;hello&quot; &quot;goodbye&quot; do}&lt;br/&gt;
;=&amp;gt; &quot;hello&quot;&lt;br/&gt;
; Wat?&lt;/p&gt;</description>
                <environment></environment>
            <key id="16093">CLJ-1184</key>
            <summary>Evaling #{do ...} or [do ...] is treated as the do special form</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jirkamarsik">Ji&#345;&#237; Mar&#353;&#237;k</reporter>
                        <labels>
                        <label>Compiler</label>
                        <label>bug</label>
                    </labels>
                <created>Sat, 16 Mar 2013 08:56:32 -0500</created>
                <updated>Fri, 12 Apr 2013 09:42:02 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1182] Regexp are never equal</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1182</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The following (= #&quot;asd&quot; #&quot;asd&quot;) will return false in CLJ, even if they are the same.&lt;/p&gt;

&lt;p&gt;Consequently, everything with a regexp in it (lists, vectors, maps...) will never be equal.&lt;/p&gt;

&lt;p&gt;It seems to have been fixed for CLJS, but not for CLJ.&lt;br/&gt;
&lt;a href=&quot;https://github.com/clojure/clojurescript/commit/e35c3a57472fa62ae41591418a73794dc8ac6dde&quot;&gt;https://github.com/clojure/clojurescript/commit/e35c3a57472fa62ae41591418a73794dc8ac6dde&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16083">CLJ-1182</key>
            <summary>Regexp are never equal</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="olenhad">Omer Iqbal</assignee>
                                <reporter username="frozenlock">Christian Fortin</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 12 Mar 2013 13:28:59 -0500</created>
                <updated>Sat, 13 Apr 2013 21:13:52 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="30746" author="olenhad" created="Tue, 12 Mar 2013 16:08:55 -0500"  >&lt;p&gt;added an implementation for the equiv method if both args are java.util.regex.Pattern&lt;/p&gt;</comment>
                    <comment id="30749" author="jafingerhut" created="Tue, 12 Mar 2013 17:54:40 -0500"  >&lt;p&gt;Omer, could you also include in your patch a few test cases?  At least one that validates that two regex&apos;s that should be equal, are equal, and another that two regex&apos;s that should be different, are non-equal.  Preferably the first of those tests should fail with the existing Clojure code, and pass with your changes.&lt;/p&gt;</comment>
                    <comment id="30754" author="olenhad" created="Wed, 13 Mar 2013 05:39:13 -0500"  >&lt;p&gt;I updated the patch with some tests. Hope I added them in the correct file. I also changed the implementation a bit, by instead of adding another implementation of equiv with a different signature, checking the type of the Object in the equiv method with signature (Object k1, Object k2).&lt;br/&gt;
For the sake of consistency I also added an EquivPred implementation, though I&apos;m not entirely sure when its used.&lt;/p&gt;</comment>
                    <comment id="30757" author="jafingerhut" created="Wed, 13 Mar 2013 13:04:58 -0500"  >&lt;p&gt;All comments here refer to the patch named fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1182&quot; title=&quot;Regexp are never equal&quot;&gt;CLJ-1182&lt;/a&gt;.diff dated Mar 13, 2013.&lt;/p&gt;

&lt;p&gt;The location for the new tests looks reasonable.  However, note that your new patch has your old changes plus some new ones, not just the new ones.  In particular, the new signature for equiv is still in your latest patch.  You should start from a clean pull of the latest Clojure master and make only the changes you want when creating a patch, not build on top of previous changes you have made.&lt;/p&gt;

&lt;p&gt;Also, there are several whitespace-only changes in your patch that should not be included.&lt;/p&gt;</comment>
                    <comment id="30758" author="olenhad" created="Wed, 13 Mar 2013 13:39:09 -0500"  >&lt;p&gt;I uploaded a clean patch, removing the whitespace diff and only adding the latest changes. Thanks for clarifying the workflow!&lt;br/&gt;
Just to clarify, this refers to the patch named fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1182&quot; title=&quot;Regexp are never equal&quot;&gt;CLJ-1182&lt;/a&gt;.diff dated Mar 13 1:34 PM&lt;/p&gt;</comment>
                    <comment id="30835" author="stu" created="Fri, 29 Mar 2013 05:46:25 -0500"  >&lt;p&gt;I am recategorizing this as an enhancement, because if this is a bug it is a bug in Java &amp;#8211; the Java Patterns class documents being immutable, but apparently does not implement .equals.&lt;/p&gt;

&lt;p&gt;Other recent &quot;make Clojure more complicated to work around problems in Java&quot; patches have been rejected, and I suspect this one will be too, because it might impact the performance of equality everywhere.&lt;/p&gt;</comment>
                    <comment id="30940" author="stu" created="Fri, 12 Apr 2013 09:04:57 -0500"  >&lt;p&gt;At first pass, Rich and I both believe that, as regex equality is undecidable, that Java made the right choice in using identity for equality, that this ticket should be declined, and the ClojureScript should revert to match.&lt;/p&gt;

&lt;p&gt;But leaving this ticket open for now so that ClojureScript dev can weigh in.&lt;/p&gt;</comment>
                    <comment id="30941" author="michael-drogalis" created="Fri, 12 Apr 2013 09:32:14 -0500"  >&lt;p&gt;What do you mean when you say &quot;undecidable&quot;?&lt;/p&gt;</comment>
                    <comment id="30942" author="aredington" created="Fri, 12 Apr 2013 10:03:45 -0500"  >&lt;p&gt;If Regex instances were interned by the reader, but still used identity for equality, then code like&lt;/p&gt;

&lt;p&gt;(= #&quot;abc&quot; #&quot;abc&quot;)&lt;/p&gt;

&lt;p&gt;would return true, but it wouldn&apos;t diverge in the definition of equality for regular expressions between Java and Clojure.&lt;/p&gt;</comment>
                    <comment id="30943" author="fogus" created="Fri, 12 Apr 2013 10:13:02 -0500"  >&lt;p&gt;Undecidable means that for any given regular expression, there is no single way to write it.  For example #&quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;a&amp;#93;&lt;/span&gt;&quot; #&quot;a&quot; both match the same strings, but are they the same?  Maybe.  But how can we decide if /any/ given regular expression matches all of the same strings as any other?  The answer is, you can&apos;t.  Java does provide a Pattern#pattern method that returns the string that was used to build it, but I&apos;m not sure if that could/should be used as a basis for equality given the potential perf hit.&lt;/p&gt;</comment>
                    <comment id="30944" author="bendlas" created="Fri, 12 Apr 2013 10:31:54 -0500"  >&lt;p&gt;I posted in Stu&apos;s thread: &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/OTPNJQbPtds/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/OTPNJQbPtds/discussion&lt;/a&gt;&lt;br/&gt;
TL;DR: Disagree with undecidability, agree with reverting to identity based equality&lt;/p&gt;</comment>
                    <comment id="30945" author="michael-drogalis" created="Fri, 12 Apr 2013 10:32:49 -0500"  >&lt;p&gt;That makes sense to me. Thanks Fogus.&lt;/p&gt;</comment>
                    <comment id="30947" author="bendlas" created="Fri, 12 Apr 2013 21:42:19 -0500"  >&lt;p&gt;From my post to the ml thread, it might not be entirely clear, why I don&apos;t think we should implement equality for host regexes:&lt;/p&gt;

&lt;p&gt;It would involve parsing and would leave a lot of room for errors and platform-idiosycracies to leak. And it would be different for every platform.&lt;/p&gt;

&lt;p&gt;As Alexander said, I also think this ticket could be resolved by interning regex literals, akin to keywords. That, however, would warrant a design page first, because there are tradeoffs to be made about how far the interning should go.&lt;/p&gt;</comment>
                    <comment id="30948" author="richhickey" created="Sat, 13 Apr 2013 08:51:17 -0500"  >&lt;p&gt;Why are we spending time on this? Where is the problem statement? Does someone actually need this for a real world purpose not solved by using regex strings as keys?&lt;/p&gt;</comment>
                    <comment id="30957" author="michael-drogalis" created="Sat, 13 Apr 2013 21:13:52 -0500"  >&lt;p&gt;It was prompted as a matter of consistency, which I think is valid. I can&apos;t think of a good reason to use regex&apos;s as keys though.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11913" name="fix-CLJ-1182.diff" size="2628" author="olenhad" created="Wed, 13 Mar 2013 13:34:11 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10120">Triaged</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1179] distinct? does not accept zero arguments</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1179</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;tt&gt;distinct?&lt;/tt&gt; cannot be invoked with zero arguments. When using the pattern &lt;tt&gt;(apply distinct? x)&lt;/tt&gt;, this is bothersome as you have to check whether x is empty or not. It is also logical that &lt;tt&gt;distinct?&lt;/tt&gt; should return &lt;tt&gt;true&lt;/tt&gt; if no arguments are given, since there are no duplicates.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;What%28smallsetof%29stepswillreproducetheproblem%3F&quot;&gt;&lt;/a&gt;What (small set of) steps will reproduce the problem?&lt;/h3&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (apply distinct? [])
ArityException Wrong number of args (0) passed to: core$distinct-QMARK-  clojure.lang.AFn.throwArity (AFn.java:437)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h3&gt;&lt;a name=&quot;Whatistheexpectedoutput%3FWhatdoyouseeinstead%3F&quot;&gt;&lt;/a&gt;What is the expected output? What do you see instead?&lt;/h3&gt;
&lt;p&gt;I would expect &lt;tt&gt;distinct?&lt;/tt&gt; to return true whenever given zero arguments.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;Whatversionareyouusing%3F&quot;&gt;&lt;/a&gt;What version are you using?&lt;/h3&gt;
&lt;p&gt;This was tested under Clojure 1.4 and Clojure 1.5.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16068">CLJ-1179</key>
            <summary>distinct? does not accept zero arguments</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hypirion">Jean Niklas L&apos;orange</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Sat, 9 Mar 2013 05:46:03 -0600</created>
                <updated>Fri, 12 Apr 2013 09:12:55 -0500</updated>
                    <resolved>Fri, 12 Apr 2013 09:12:55 -0500</resolved>
                            <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30719" author="hypirion" created="Sat, 9 Mar 2013 06:08:41 -0600"  >&lt;p&gt;Attached the straightforward patch which solves this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11902" name="clj-1179-distinct-zero-arguments.txt" size="603" author="hypirion" created="Sat, 9 Mar 2013 06:08:41 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10008">Not Approved</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1177] clojure.java.io/resource and non-ASCII characters</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1177</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.java.io/resource corrupts path containing UTF-8 characters without issuing warning.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/getProperty &lt;span class=&quot;code-quote&quot;&gt;&quot;java.runtime.version&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;1.8.0-ea-b79&quot;&lt;/span&gt;
user=&amp;gt; (clojure-version)
&lt;span class=&quot;code-quote&quot;&gt;&quot;1.5.0&quot;&lt;/span&gt;
user=&amp;gt; (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/getProperty &lt;span class=&quot;code-quote&quot;&gt;&quot;user.dir&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;
user=&amp;gt; (clojure.java.io/resource &lt;span class=&quot;code-quote&quot;&gt;&quot;myfile.txt&quot;&lt;/span&gt;)
#&amp;lt;URL file:/dir/d%c3%a9f/resources/myfile.txt&amp;gt;
user=&amp;gt; (slurp (clojure.java.io/resource &lt;span class=&quot;code-quote&quot;&gt;&quot;myfile.txt&quot;&lt;/span&gt;) :encoding &lt;span class=&quot;code-quote&quot;&gt;&quot;UTF-8&quot;&lt;/span&gt;)
FileNotFoundException /dir/d&#195;&#169;f/resources/myfile.txt (No such file or directory)  java.io.FileInputStream.open (FileInputStream.java:-2)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="16062">CLJ-1177</key>
            <summary>clojure.java.io/resource and non-ASCII characters</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="trevor">Trevor Wennblom</reporter>
                        <labels>
                        <label>bug</label>
                        <label>enhancement</label>
                    </labels>
                <created>Thu, 7 Mar 2013 16:54:43 -0600</created>
                <updated>Sun, 10 Mar 2013 17:56:52 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30713" author="jafingerhut" created="Fri, 8 Mar 2013 00:10:22 -0600"  >&lt;p&gt;Below is a workaround, at least.  I don&apos;t know, but perhaps the as-file method for URLs in io.clj of Clojure, the part that converts %hh sequences to a character with code point in the range 0 through 255, is at least partly at fault here.  I don&apos;t know right now if it is possible to modify that code to handle the general case of whatever character encoding munging is going on here to when .getResource creates the URL object.&lt;/p&gt;


&lt;p&gt;clojure.java.io/resource is documented to return a Java object of type java.net.URL, which seems like it does %hh escaping of many characters.  Reference &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; to a Java bug from 2001 where a Java user was surprised by the then-recent change in behavior of the getResource method &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;Doing a little searching I found this StackOverflow question &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;, which has what might be a workaround.  I tried it on my Mac OS X 10.6 system running JDK 1.6 and it seemed to work:&lt;/p&gt;

&lt;p&gt;(slurp (.getContent (clojure.java.io/resource &quot;abc&#237;d/foo.txt&quot;)))&lt;/p&gt;

&lt;p&gt;That getContent is a method for class java.net.URL &lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485&quot;&gt;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29&quot;&gt;http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource&quot;&gt;http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29&quot;&gt;http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30716" author="trevor" created="Fri, 8 Mar 2013 09:56:22 -0600"  >&lt;p&gt;Hi Andy,&lt;/p&gt;

&lt;p&gt;Thanks for the background and suggestions, that&apos;s very helpful.&lt;/p&gt;

&lt;p&gt;I&apos;m gradually learning Clojure with no Java experience. In this case I was searching for the preferred Clojure way to access items in directories declared under :resource-paths in a Leiningen project.clj file. Perhaps clojure.java.io/resource isn&apos;t the best way to do this as it&apos;s possibly too tied to the expectation for a URI instead of a more general IRI.&lt;/p&gt;

&lt;p&gt;You&apos;re suggested workaround did work for my use case:&lt;/p&gt;

&lt;p&gt;(slurp (.getContent (clojure.java.io/resource &quot;abc&#237;d/foo.txt&quot;)))&lt;/p&gt;

&lt;p&gt;but hopefully there would be more native/direct Clojure way to accomplish the same eventually.&lt;/p&gt;

&lt;p&gt;I don&apos;t know if java.net.IDN would be useful internally as a fix in clojure.java.io/resource &#8212; I&apos;m assuming not since it wasn&apos;t added until Java 6.&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; &apos;java.net.IDN)
java.net.IDN
user=&amp;gt; (java.net.IDN/toASCII &lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;xn--/dir/df-gya&quot;&lt;/span&gt;
user=&amp;gt; (java.net.IDN/toUnicode &lt;span class=&quot;code-quote&quot;&gt;&quot;xn--/dir/df-gya&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;: &lt;a href=&quot;http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html&quot;&gt;http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30717" author="jafingerhut" created="Fri, 8 Mar 2013 13:30:05 -0600"  >&lt;p&gt;Patch clj-1177-patch-v1.txt dated Mar 8 2013 is an attempt to solve this issue, in what I think may be a correct way.  As specified in RFC 3986, when taking a Unicode string and making a URL of it, it should be encoded in UTF-8 and then each individual byte is subject to the %HH hex encoding.  This patch reverses that to turn URLs into file names.&lt;/p&gt;

&lt;p&gt;Tested on Mac OS X 10.6 with a command line like this (it doesn&apos;t work without the -Dfile.encoding=UTF-8 option on my Mac, probably because the default encoding is MacRoman):&lt;/p&gt;

&lt;p&gt;% java -cp clojure.jar:path/to/resource -Dfile.encoding=UTF-8 clojure.main&lt;br/&gt;
user=&amp;gt; (require &apos;&lt;span class=&quot;error&quot;&gt;&amp;#91;clojure.java.io :as io&amp;#93;&lt;/span&gt;)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (io/resource &quot;abc&#237;d/foo.txt&quot;)&lt;br/&gt;
#&amp;lt;URL &lt;a href=&quot;file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt&quot;&gt;file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt&lt;/a&gt;&amp;gt;&lt;br/&gt;
user=&amp;gt; (slurp (io/resource &quot;abc&#237;d/foo.txt&quot;))&lt;br/&gt;
&quot;The quick brown fox jumped over the l&#225;zy d&#246;g!\n&quot;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11900" name="clj-1177-patch-v1.txt" size="2673" author="jafingerhut" created="Fri, 8 Mar 2013 13:30:05 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1136] Type hinting for array classes does not work in binding forms</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1136</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Type hints don&apos;t work as expected in binding forms. &lt;/p&gt;

&lt;p&gt;The following form results in a reflection warning:&lt;/p&gt;

&lt;p&gt;    (let [^{:tag (Class/forName &quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;Ljava.lang.Object;&amp;quot;)} a (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
      (aget a 0))&lt;/p&gt;

&lt;p&gt;However, hinting does appear to work correctly on vars:&lt;/p&gt;

&lt;p&gt;    (def ^{:tag (Class/forName &quot;[Ljava.lang.Object;&quot;)} a (make-array Object 2))&lt;br/&gt;
    (aget a 0) ;; no reflection warning&lt;/p&gt;</description>
                <environment>replicated on OpenJDK 7u9 on Ubuntu 12.04, and Hotspot 1.6.0_37 on OSX Lion</environment>
            <key id="15911">CLJ-1136</key>
            <summary>Type hinting for array classes does not work in binding forms</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="lvanderhart">Luke VanderHart</reporter>
                        <labels>
                        <label>Compiler</label>
                        <label>bug</label>
                    </labels>
                <created>Thu, 20 Dec 2012 14:59:58 -0600</created>
                <updated>Fri, 21 Dec 2012 11:09:56 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30272" author="gshayban" created="Thu, 20 Dec 2012 22:51:22 -0600"  >&lt;p&gt;It&apos;s a little more insidious than type hinting: the compiler doesn&apos;t evaluate metadata in the binding vec.&lt;/p&gt;

&lt;p&gt;This doesn&apos;t throw the necessary exception...&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^{:foo (Class/forName &amp;quot;not real&amp;quot;)} bar 42&amp;#93;&lt;/span&gt;&lt;br/&gt;
  bar)&lt;/p&gt;

&lt;p&gt;neither this...&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^{gyorgy ligeti} a 42&amp;#93;&lt;/span&gt;&lt;br/&gt;
  a)&lt;/p&gt;

&lt;p&gt;Gyorgy Ligeti never resolves.&lt;/p&gt;

&lt;p&gt;These two equivalent examples don&apos;t reflect: &lt;br/&gt;
(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^objects a (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (aget a 0))&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;a ^objects (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (aget a 0))&lt;/p&gt;
</comment>
                    <comment id="30275" author="gshayban" created="Fri, 21 Dec 2012 11:09:56 -0600"  >&lt;p&gt;On only the left-hand side of a local binding, metadata on a symbol is not analyzed or evaluated.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1134] star-directive in clojure.pprint/cl-format with an at-prefix (&quot;~n@*&quot;) do not obey its specifications</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1134</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The star-directive in &lt;tt&gt;clojure.pprint/cl-format&lt;/tt&gt; with an at-prefix (&lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt;) does not obey its specifications according to &lt;a href=&quot;http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/clm/node200.html#SECTION002633000000000000000&quot;&gt;Common Lisp the Language, 2nd Edition&lt;/a&gt;. There are two bugs within &lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt; as of right now:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;When &lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt; is supposed to jump forward over more than one argument, it jumps one step backward as if it had seen &lt;tt&gt;&amp;#126;:&amp;#42;&lt;/tt&gt;. For instance, &lt;tt&gt;(cl-format nil &quot;~D ~3@*~D&quot; 0 1 2 3)&lt;/tt&gt; will return &lt;tt&gt;&quot;0 0&quot;&lt;/tt&gt; and not &lt;tt&gt;&quot;0 3&quot;&lt;/tt&gt; as expected.&lt;/li&gt;
	&lt;li&gt;When &lt;tt&gt;&amp;#126;@&amp;#42;&lt;/tt&gt; is seen, the formatter is supposed to jump to the first argument (as &lt;tt&gt;n&lt;/tt&gt; defaults to &lt;tt&gt;0&lt;/tt&gt;, see specification linked above). However, whenever a &lt;tt&gt;&amp;#126;@&amp;#42;&lt;/tt&gt;-directive is seen, the formatter jumps to the second argument instead.&lt;/li&gt;
&lt;/ol&gt;


&lt;h4&gt;&lt;a name=&quot;What%28smallsetof%29stepswillreproducetheproblem%3F&quot;&gt;&lt;/a&gt;What (small set of) steps will reproduce the problem?&lt;/h4&gt;

&lt;p&gt;Inside a clean Clojure repl, perform these steps:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (require &apos;[clojure.pprint :refer [cl-format]])
nil
user=&amp;gt; (cl-format nil &quot;~D ~3@*~D&quot; 0 1 2 3)
&quot;0 0&quot;                                           ;; Expected: &quot;0 3&quot;
user=&amp;gt; (cl-format nil &quot;~D~D~D~D ~@*~D&quot; 0 1 2 3)
&quot;0123 1&quot;                                        ;; Expected: &quot;0123 0&quot;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h4&gt;&lt;a name=&quot;Whatistheexpectedoutput%3FWhatdoyouseeinstead%3F&quot;&gt;&lt;/a&gt;What is the expected output? What do you see instead?&lt;/h4&gt;

&lt;p&gt;The expected output is &lt;tt&gt;&quot;0 3&quot;&lt;/tt&gt; and &lt;tt&gt;&quot;0123 0&quot;&lt;/tt&gt;, but is &lt;tt&gt;&quot;0 0&quot;&lt;/tt&gt; and &lt;tt&gt;&quot;0123 1&quot;&lt;/tt&gt; as shown above.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;Whatversionareyouusing%3F&quot;&gt;&lt;/a&gt;What version are you using?&lt;/h4&gt;

&lt;p&gt;Tested on both &lt;tt&gt;1.4.0&lt;/tt&gt; and &lt;tt&gt;1.5.0-beta2&lt;/tt&gt;, both have the defect described.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;Pleaseprovideanyadditionalinformationbelow.&quot;&gt;&lt;/a&gt;Please provide any additional information below.&lt;/h4&gt;

&lt;p&gt;The format strings which reproduces the problem has been compared with the &lt;tt&gt;format&lt;/tt&gt; function from the Common Lisp implementations SBCL, CLisp and Clozure. All of them print the expected output.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15907">CLJ-1134</key>
            <summary>star-directive in clojure.pprint/cl-format with an at-prefix (&quot;~n@*&quot;) do not obey its specifications</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hypirion">Jean Niklas L&apos;orange</reporter>
                        <labels>
                        <label>bug</label>
                        <label>pprint</label>
                    </labels>
                <created>Tue, 18 Dec 2012 20:34:25 -0600</created>
                <updated>Wed, 26 Dec 2012 19:57:30 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30261" author="hypirion" created="Tue, 18 Dec 2012 21:28:03 -0600"  >&lt;p&gt;Patch attached.&lt;/p&gt;

&lt;p&gt;It may be easier to read the changes the patch does from within JIRA instead from the commit message, so I&apos;ve added it here:&lt;/p&gt;

&lt;p&gt;This solves two issues as specified by #&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1134&quot; title=&quot;star-directive in clojure.pprint/cl-format with an at-prefix (&amp;quot;~n@*&amp;quot;) do not obey its specifications&quot;&gt;CLJ-1134&lt;/a&gt;. Issue #1 is solved by doing a&lt;br/&gt;
relative jump forward within &lt;tt&gt;absolute-reposition&lt;/tt&gt; in &lt;tt&gt;cl_format.clj&lt;/tt&gt;, line 114 by&lt;br/&gt;
switching &lt;tt&gt;(- (:pos navigator) position)&lt;/tt&gt; with &lt;tt&gt;(- position (:pos navigator))&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;Issue #2 is handled by changing the default &lt;tt&gt;n&lt;/tt&gt;-parameter to &lt;tt&gt;*&lt;/tt&gt; depending on&lt;br/&gt;
whether the &lt;tt&gt;@&lt;/tt&gt;-prefix is placed or not. If it is placed, then &lt;tt&gt;n&lt;/tt&gt; defaults to&lt;br/&gt;
0, otherwise it defaults to 1.&lt;/p&gt;

&lt;p&gt;In addition, new tests have been appended to &lt;tt&gt;test_cl_format.clj&lt;/tt&gt; to ensure the&lt;br/&gt;
correctness of this patch. The tests have been tested on the Common Lisp&lt;br/&gt;
implementation GNU CLISP 2.49, which presumably handle the &lt;tt&gt;~n@*&lt;/tt&gt;&lt;br/&gt;
correctly. This patch and GNU CLISP returns the same output for each format&lt;br/&gt;
call, sans case for printed symbols; Common Lisp has case-insensitive symbols,&lt;br/&gt;
whereas Clojure has not.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11767" name="clj-1134-star-directive-in-cl-format.txt" size="4067" author="hypirion" created="Tue, 18 Dec 2012 21:28:03 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1087] clojure.data/diff uses set union on key seqs</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1087</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;tt&gt;clojure.data/diff&lt;/tt&gt;, on line 118, defines:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java.util.Map
(diff-similar [a b]
  (diff-associative a b (set/union (keys a) (keys b))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Since &lt;tt&gt;keys&lt;/tt&gt; returns a key seq, this seems like an error. &lt;tt&gt;clojure.set/union&lt;/tt&gt; has strange and inconsistent behavior with regard to non-sets, and in this case the two key seqs are concatenated. Based on a cursory benchmark, it seems that this bug &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/help_16.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; is a slight performance gain when the maps have no common keys, and a significant performance loss when the maps have the same keys. The results are still correct because of the merging reduce in &lt;tt&gt;diff-associative&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;The patch is easy (just call set on each key seq).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15753">CLJ-1087</key>
            <summary>clojure.data/diff uses set union on key seqs</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tomoj">Tom Jack</reporter>
                        <labels>
                        <label>bug</label>
                        <label>performance</label>
                    </labels>
                <created>Mon, 15 Oct 2012 03:59:52 -0500</created>
                <updated>Mon, 15 Oct 2012 14:52:42 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29650" author="jafingerhut" created="Mon, 15 Oct 2012 14:52:04 -0500"  >&lt;p&gt;clj-1087-diff-perf-enhance-patch-v1.txt dated Oct 15 2012 implements Tom&apos;s suggested performance enhancement, although not exactly in the way he suggested.  It does calculate the union of the two key sequences.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11562" name="clj-1087-diff-perf-enhance-patch-v1.txt" size="760" author="jafingerhut" created="Mon, 15 Oct 2012 14:52:04 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1030] Misleading ClassCastException when coercing a String to int</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1030</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Observed behaviour&lt;/p&gt;

&lt;p&gt;(int &quot;0&quot;) =&amp;gt;&lt;br/&gt;
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Character&lt;/p&gt;

&lt;p&gt;Expected behaviour&lt;br/&gt;
(int &quot;0&quot;) =&amp;gt;&lt;br/&gt;
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer&lt;br/&gt;
or &lt;br/&gt;
IllegalArgumentException&lt;/p&gt;</description>
                <environment></environment>
            <key id="15591">CLJ-1030</key>
            <summary>Misleading ClassCastException when coercing a String to int</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ordnungswidrig">Philipp Meier</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Wed, 25 Jul 2012 06:13:21 -0500</created>
                <updated>Sun, 6 Jan 2013 20:52:40 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29532" author="jafingerhut" created="Mon, 24 Sep 2012 11:20:07 -0500"  >&lt;p&gt;If someone wants to improve the behavior of int in this case, they should also consider similar improvements to the error messages for unchecked-int, char, and unchecked-char.&lt;/p&gt;</comment>
                    <comment id="30383" author="michael-drogalis" created="Sun, 6 Jan 2013 20:45:00 -0600"  >&lt;p&gt;Patch improved-int-char-casting-error-messages.diff on January 6, 2013.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11793" name="improved-int-char-casting-error-messages.diff" size="3855" author="michael-drogalis" created="Sun, 6 Jan 2013 20:45:00 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1028] (compile) crashes with NullPointerException if public function &apos;load&apos; is defined</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1028</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When performing AOT compilation, if the namespace being compiled or one of the namespaces :required by it defines a public function named &apos;load&apos;, the compiler will crash with a NullPointerException.&lt;/p&gt;

&lt;p&gt;The following code demonstrates this:&lt;/p&gt;

&lt;p&gt;(ns ca.ancilla.kessler.core (:gen-class)) (defn load &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x) (defn -main &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt; 0)&lt;/p&gt;

&lt;p&gt;When run directly, with &apos;clojure -m ca.ancilla.kessler.core&apos; or &apos;clojure ca/ancilla/kessler/core.clj&apos;, it runs as expected. When loaded with &apos;clojure -i&apos; and (compile)d, however, or when automatically compiled by &apos;lein run&apos;, it results in a NullPointerException (the complete stack trace is attached).&lt;/p&gt;

&lt;p&gt;This occurs whether or not &apos;load&apos; or actually called. It does not, however, occur if &apos;load&apos; is private.&lt;/p&gt;</description>
                <environment>Linux, OpenJDK 1.6.0 64bit</environment>
            <key id="15584">CLJ-1028</key>
            <summary>(compile) crashes with NullPointerException if public function &apos;load&apos; is defined</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="toxicfrog">Ben Kelly</reporter>
                        <labels>
                        <label>Compiler</label>
                        <label>bug</label>
                    </labels>
                <created>Fri, 20 Jul 2012 12:40:30 -0500</created>
                <updated>Fri, 20 Jul 2012 22:06:22 -0500</updated>
                    <resolved>Fri, 20 Jul 2012 16:35:47 -0500</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29007" author="toxicfrog" created="Fri, 20 Jul 2012 12:43:33 -0500"  >&lt;p&gt;If you add (:refer-clojure :exclude &lt;span class=&quot;error&quot;&gt;&amp;#91;load&amp;#93;&lt;/span&gt;) to the (ns), it works fine:&lt;/p&gt;

&lt;p&gt;(ns ca.ancilla.kessler.core (:refer-clojure :exclude &lt;span class=&quot;error&quot;&gt;&amp;#91;load&amp;#93;&lt;/span&gt;) (:gen-class))&lt;br/&gt;
(defn load &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x)&lt;br/&gt;
(defn -main &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt; 0)&lt;/p&gt;

&lt;p&gt;Thanks to llasram on IRC for discovering this.&lt;/p&gt;</comment>
                    <comment id="29010" author="stu" created="Fri, 20 Jul 2012 16:35:38 -0500"  >&lt;p&gt;You should not replace functions in clojure.core.  This is left legal (with a loud CONSOLE warning) for compatibility, but programs that do it are in error.&lt;/p&gt;</comment>
                    <comment id="29015" author="toxicfrog" created="Fri, 20 Jul 2012 22:06:22 -0500"  >&lt;p&gt;So, just to make sure that I have this right, then...&lt;/p&gt;

&lt;p&gt;If I want to create a namespace with a public function that shares a name with a function in clojure.core, the only supported way of doing this is to (:refer-clojure :exclude &lt;span class=&quot;error&quot;&gt;&amp;#91;list of all such functions&amp;#93;&lt;/span&gt;)?&lt;/p&gt;

&lt;p&gt;If so, it would be nice if the warning were replaced with an error, rather than having the compiler emit an error and then &lt;b&gt;crash&lt;/b&gt;.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11391" name="stack-trace" size="1541" author="toxicfrog" created="Fri, 20 Jul 2012 12:40:30 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1022] gen-class destroys method annotations</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1022</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When extending a class gen-class doesn&apos;t preserve method annotations.&lt;/p&gt;

&lt;p&gt;If class com.bar.Foo has annotated methods  then in MyClass all annotations are gone.&lt;/p&gt;


&lt;p&gt;(gen-class&lt;br/&gt;
   :name com.my.MyClass&lt;br/&gt;
   :extends com.bar.Foo&lt;br/&gt;
   :implements &lt;span class=&quot;error&quot;&gt;&amp;#91;com.google.common.base.Supplier&amp;#93;&lt;/span&gt;&lt;br/&gt;
   :prefix demo-&lt;br/&gt;
   :post-init post-init)&lt;/p&gt;

&lt;p&gt;(defn demo-post-init &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (info &quot;initialized&quot;)&lt;br/&gt;
  (swank.swank/start-server :port 68478))&lt;/p&gt;

&lt;p&gt;(defn demo-get &lt;span class=&quot;error&quot;&gt;&amp;#91;_&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (get-msg))&lt;/p&gt;



&lt;p&gt;            Class&amp;lt;?&amp;gt; aClass = Class.forName(&quot;com.my.MyClass&quot;);&lt;br/&gt;
            Method[] methods = aClass.getMethods();&lt;/p&gt;

&lt;p&gt;            for (Method m : methods) {&lt;br/&gt;
                Annotation[] annotations = m.getAnnotations();&lt;br/&gt;
                System.out.println(m.getName()+&quot; &quot;+annotations.length);&lt;br/&gt;
                for (Annotation a : annotations) {
                    System.out.println(a.annotationType().getClass().getName());
                }&lt;br/&gt;
            }&lt;/p&gt;</description>
                <environment></environment>
            <key id="15566">CLJ-1022</key>
            <summary>gen-class destroys method annotations</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="maris">Maris Orbidans</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 3 Jul 2012 06:19:26 -0500</created>
                <updated>Tue, 3 Jul 2012 06:19:26 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1021] (let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1021</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;i 5&amp;#93;&lt;/span&gt; (defmacro m &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt; args) (def x (m (inc 5) (inc 6) (inc 7))) &lt;a href=&quot;#&amp;#39;m)&quot;&gt;x m (meta #&apos;m)&lt;/a&gt;)&lt;br/&gt;
is&lt;br/&gt;
[(8) #&amp;lt;user$eval522$m_&lt;em&gt;523 user$eval522$m&lt;/em&gt;_523@11a74355&amp;gt; {:macro true, :ns #&amp;lt;Namespace user&amp;gt;, :name m, :arglists (&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt;), :line 1, :file &quot;NO_SOURCE_PATH&quot;}]&lt;/p&gt;

&lt;p&gt;It appears to be interpreting m as a function despite the metadata. This behavior only shows up inside the (let ...).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15565">CLJ-1021</key>
            <summary>(let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zii-prime">Zii Prime</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Mon, 2 Jul 2012 23:32:22 -0500</created>
                <updated>Thu, 13 Sep 2012 14:29:20 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29222" author="bronsa" created="Sat, 18 Aug 2012 11:43:42 -0500"  >&lt;p&gt;The problem is the same as the one for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-918&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-918&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The patch linked there was mine but i had no CA signed at that time, and no account on jira.&lt;/p&gt;

&lt;p&gt;Here is the same patch in the correct format.&lt;/p&gt;

&lt;p&gt;Bug #918 should be closed as this is a duplicate&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11443" name="001-propagate-on-macro-meta.diff" size="1018" author="bronsa" created="Sat, 18 Aug 2012 11:43:42 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1006] Quotient on bigdec may produce wrong result</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1006</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;As discussed on the mailing list in the message &quot;When arithmetic on a computer bite back&quot; (01/jun)&lt;/p&gt;

&lt;p&gt;There may be bug in the way quotient is implemented for bigdec.&lt;/p&gt;

&lt;p&gt;user&amp;gt; (quot 1.4411518807585587E17 2)   ;; correct with doubles&lt;br/&gt;
7.2057594037927936E16&lt;br/&gt;
user&amp;gt; (quot 1.4411518807585587E+17M 2) ;; wrong with BigDecs&lt;br/&gt;
72057594037927935M &lt;/p&gt;

&lt;p&gt;&amp;#8211;&lt;br/&gt;
Laurent&lt;/p&gt;</description>
                <environment>Linux 3.2.0-24-generic #39-Ubuntu SMP i686 GNU/Linux</environment>
            <key id="15500">CLJ-1006</key>
            <summary>Quotient on bigdec may produce wrong result</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="laurentj">laurent joigny</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Fri, 1 Jun 2012 16:12:34 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Fri, 9 Nov 2012 08:49:48 -0600</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28677" author="laurentj" created="Fri, 1 Jun 2012 17:48:24 -0500"  >&lt;p&gt;I can reproduce the bug when using BigDecimal constructor on String.&lt;br/&gt;
See attached file for a test class.&lt;/p&gt;

&lt;p&gt;More infos :&lt;br/&gt;
java version &quot;1.6.0_24&quot;&lt;br/&gt;
OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)&lt;br/&gt;
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)&lt;/p&gt;</comment>
                    <comment id="28678" author="laurentj" created="Fri, 1 Jun 2012 17:49:50 -0500"  >&lt;p&gt;A simple test file, that you can drop in Clojure sources and execute to reproduce the bug on BigDecimal constructor using String as argument.&lt;/p&gt;</comment>
                    <comment id="28687" author="tsdh" created="Sun, 3 Jun 2012 04:30:44 -0500"  >&lt;p&gt;Seems to be a general precision problem.  Note that in&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user&amp;gt; (quot 1.4411518807585587E17 2) ;; correct with doubles
7.2057594037927936E16
user&amp;gt; (quot 1.4411518807585587E+17M 2) ;; wrong with BigDecs
72057594037927935M
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;the double result is actually wrong and the bigdec one is correct.  The problem which lead to the wrong conclusion is that in your calculation the input number is already wrong.&lt;/p&gt;

&lt;p&gt;So the moral is: don&apos;t use any floating points (neither doubles nor bigdecs) for computations involving divisibility tests.&lt;/p&gt;

&lt;p&gt;For bigdecs, you can set the math context for making computations throw exceptions if they lose precision, though:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user&amp;gt; (binding [*math-context* (java.math.MathContext. 1 java.math.RoundingMode/UNNECESSARY)]
	       (quot (bigdec (Math/pow 2 58)) 2))
;Division impossible
;  [Thrown class java.lang.ArithmeticException]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="29920" author="stuart.sierra" created="Fri, 9 Nov 2012 08:49:48 -0600"  >&lt;p&gt;Not a bug. Just floating-point arithmetic.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11282" name="TestBigDecimalQuotient.java" size="782" author="laurentj" created="Fri, 1 Jun 2012 17:49:50 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-988] the locking in MultiFn.java (synchronized methods) can cause lots of contention in multithreaded programs</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-988</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;if you call a single multimethod a lot in multithreaded code you get lots of contention for the lock on the multimethod. this contention slows things down a lot.&lt;/p&gt;

&lt;p&gt;this is due to getMethod being synchronized. it would be great if there was some fast non-locking path through the multimethod.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15419">CLJ-988</key>
            <summary>the locking in MultiFn.java (synchronized methods) can cause lots of contention in multithreaded programs</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                        <label>bug</label>
                        <label>performance</label>
                    </labels>
                <created>Tue, 8 May 2012 11:14:53 -0500</created>
                <updated>Fri, 21 Sep 2012 14:21:33 -0500</updated>
                    <resolved>Fri, 21 Sep 2012 14:21:33 -0500</resolved>
                                            <fixVersion>Release 1.5</fixVersion>
                                        <due></due>
                    <votes>10</votes>
                        <watches>9</watches>
                        <comments>
                    <comment id="28411" author="hiredman" created="Tue, 8 May 2012 11:30:00 -0500"  >&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/6a8219ae3d4cd0ae?hl=en&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/6a8219ae3d4cd0ae?hl=en&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="28446" author="santiago" created="Fri, 11 May 2012 06:38:34 -0500"  >&lt;p&gt;Here&apos;s a stab in the dark attempt at rewriting MultiFn to use atoms to swap between immutable copies of its otherwise mutable state. &lt;/p&gt;

&lt;p&gt;The four pieces of the MultiFn&apos;s state that are mutable and protected by locks are now contained in the MultiFn.State class, which is immutable and contains convenience functions for creating a new one with one field changed. An instance of this class is now held in an atom in the MultiFn called state. Changes to any of these four members are now done with an atomic swap of these State objects. &lt;/p&gt;

&lt;p&gt;The getMethod/findAndCacheBestMethod complex was rewritten to better enable the atomic logic. findAndCacheBestMethod was replaced with findBestMethod, which merely looks up the method; the caching logic was moved to getMethod so that it can be retried easily as part of the work that method does. &lt;/p&gt;

&lt;p&gt;As it was findAndCacheBestMethod seemingly had the potential to cause a stack overflow in a perfect storm of heavy concurrent modification, since it calls itself recursively if it finds that the hierarchy has changed while it has done its work. This logic is now done in the CAS looping of getMethod, so hopefully that is not even an unlikely possibility anymore.&lt;/p&gt;

&lt;p&gt;There is still seemingly a small race here, since the check is done of a regular variable against the value in a ref. Now as before, the ref could be updated just after you do the check, but before the MultiFn&apos;s state is updated. Of course, only the method lookup part of a MultiFn call was synchronized before; it could already change after the lookup but before the method itself executed, having a stale method finish seemingly after the method had been changed. Things are no different now in general, with the atom-based approach, so perhaps this race is not a big deal, as a stale value can&apos;t persist for long.&lt;/p&gt;

&lt;p&gt;The patch passes the tests and Clojure and multimethods seems to work.&lt;/p&gt;</comment>
                    <comment id="28482" author="hiredman" created="Sat, 12 May 2012 20:59:45 -0500"  >&lt;p&gt;this patch gets rid of the ugly lock contention issues. I have not been able to benchmark it vs. the old multimethod implementation, but looking at it, I would not be surprised if it is faster when the system is in a steady state.&lt;/p&gt;</comment>
                    <comment id="28747" author="stu" created="Fri, 8 Jun 2012 12:11:51 -0500"  >&lt;p&gt;This looks straightforward, except for getMethod. Can somebody with context add more discussion of how method caching works?&lt;/p&gt;

&lt;p&gt;Also, it would be great to have tests with this one.&lt;/p&gt;</comment>
                    <comment id="28810" author="santiago" created="Fri, 15 Jun 2012 04:44:53 -0500"  >&lt;p&gt;Obviously I didn&apos;t write the original code, so I&apos;m not the ideal&lt;br/&gt;
person to explain this stuff. But I did work with it a bit recently,&lt;br/&gt;
so in the hopes that I can be helpful, I&apos;m writing down my&lt;br/&gt;
understanding of the code as I worked with it. Since I came to the&lt;br/&gt;
code and sort of reverse engineered my way to this understanding,&lt;br/&gt;
hopefully laying this all out will make any mistakes or&lt;br/&gt;
misunderstandings I may have made easier to catch and correct. To&lt;br/&gt;
ensure some stability, I&apos;ll talk about the original MultiFn code as it&lt;br/&gt;
stands at this commit:&lt;br/&gt;
&lt;a href=&quot;https://github.com/clojure/clojure/blob/8fda34e4c77cac079b711da59d5fe49b74605553/src/jvm/clojure/lang/MultiFn.java&quot;&gt;https://github.com/clojure/clojure/blob/8fda34e4c77cac079b711da59d5fe49b74605553/src/jvm/clojure/lang/MultiFn.java&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;There are four pieces of state that change as the multimethod is either&lt;br/&gt;
populated with methods or called.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;methodTable: A persistent map from a dispatch value (Object) to&lt;br/&gt;
    a function (IFn). This is the obvious thing you think it is,&lt;br/&gt;
    determining which dispatch values call which function.&lt;/li&gt;
	&lt;li&gt;preferTable: A persistent map from a dispatch value (Object) to&lt;br/&gt;
    another value (Object), where the key &quot;is preferred&quot; to the value.&lt;/li&gt;
	&lt;li&gt;methodCache: A persistent map from a dispatch value (Object) to&lt;br/&gt;
    function (IFn). By default, the methodCache is assigned the same&lt;br/&gt;
    map value as the methodTable. If values are calculated out of the&lt;br/&gt;
    hierarchy during a dispatch, the originating value and the&lt;br/&gt;
    ultimate method it resolves to are inserted as additional items in&lt;br/&gt;
    the methodCache so that subsequent calls can jump right to the&lt;br/&gt;
    method without recursing down the hierarchy and preference table.&lt;/li&gt;
	&lt;li&gt;cachedHierarchy: An Object that refers to the hierarchy that is&lt;br/&gt;
    reflected in the latest cached values. It is used to check if the&lt;br/&gt;
    hierarchy has been updated since we last updated the cache. If it&lt;br/&gt;
    has been updated, then the cache is flushed.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I think reset(), addMethod(), removeMethod(), preferMethod(),&lt;br/&gt;
prefers(), isA(), dominates(), and resetCache() are extremely&lt;br/&gt;
straightforward in both the original code and the patch. In the&lt;br/&gt;
original code, the first four of those are synchronized, and the other&lt;br/&gt;
four are only called from methods that are synchronized (or from&lt;br/&gt;
methods only called from methods that are synchronized).&lt;/p&gt;

&lt;p&gt;Invoking a multimethod through its invoke() function will call&lt;br/&gt;
getFn(). getFn() will call the getMethod() function, which is&lt;br/&gt;
synchronized. This means any call of the multimethod will wait for and&lt;br/&gt;
take a lock as part of method invocation. The goal of the patch in&lt;br/&gt;
this issue is to remove this lock on calls into the multimethod. It in&lt;br/&gt;
fact removes the locks on all operations, and instead keeps its&lt;br/&gt;
internal mutable state by atomically swapping a private immutable&lt;br/&gt;
State object held in an Atom called state.&lt;/p&gt;

&lt;p&gt;The biggest change in the patch is to the&lt;br/&gt;
getFn()&lt;del&gt;&amp;gt;getMethod()&lt;/del&gt;&amp;gt;findAndCacheBestMethod() complex from the&lt;br/&gt;
original code. I&apos;ll describe how that code works first. &lt;/p&gt;

&lt;p&gt;In the original code, getFn() does nothing but bounce through&lt;br/&gt;
getMethod(). getMethod() tries three times to find a method to call,&lt;br/&gt;
after checking that the cache is up to date and flushing it if it&lt;br/&gt;
isn&apos;t:&lt;/p&gt;

&lt;p&gt;    1. It checks if there&apos;s a method for the dispatch value in the&lt;br/&gt;
    methodCache. &lt;/p&gt;

&lt;p&gt;    2. If not, it calls findAndCacheBestMethod() on the&lt;br/&gt;
    dispatch value. findAndCacheBestMethod() does the following:&lt;/p&gt;

&lt;p&gt;        1. It iterates through every map entry in the method table,&lt;br/&gt;
        keeping at each step the best entry it has found so far&lt;br/&gt;
        (according to the hierarchy and preference tables).  &lt;/p&gt;

&lt;p&gt;        2. If it did not find a suitable entry, it returns null.  &lt;/p&gt;

&lt;p&gt;        3. Otherwise, it checks if the hierarchy has been changed since the cache&lt;br/&gt;
        was last updated. If it has not changed, it inserts the method&lt;br/&gt;
        into the cache and returns it. If it has been changed, it&lt;br/&gt;
        resets the cache and calls itself recursively to repeat the process.&lt;/p&gt;

&lt;p&gt;    3. Failing all else, it will return the method for the default&lt;br/&gt;
    dispatch value.&lt;/p&gt;

&lt;p&gt;Again, remember everything in the list above happens in a call to a&lt;br/&gt;
synchronized function. Also note that as it is currently written,&lt;br/&gt;
findAndCacheBestMethod() uses recursion for iteration in a way that&lt;br/&gt;
grows the stack. This seems unlikely to cause a stack overflow unless&lt;br/&gt;
the multimethod is getting its hierarchy updated very rapidly for a&lt;br/&gt;
sustained period while someone else tries to call it. Nonetheless, the&lt;br/&gt;
hierarchy is held in an IRef that is updated independently of the&lt;br/&gt;
locking of the MultiFn. Finally, note that the multimethod is locked&lt;br/&gt;
only while the method is being found. Once it is found, the lock is&lt;br/&gt;
released and the method actually gets called afterwards without any&lt;br/&gt;
synchronization, meaning that by the time the method actually&lt;br/&gt;
executes, the multimethod may have already been modified in a way that&lt;br/&gt;
suggests a different method should have been called. Presumably this&lt;br/&gt;
is intended, understood, and not a big deal.&lt;/p&gt;

&lt;p&gt;Moving on now to the patch in this issue. As mentioned, the main&lt;br/&gt;
change is updating this entire apparatus to work with a single atomic&lt;br/&gt;
swap to control concurrency. This means that all updates to the&lt;br/&gt;
multimethod&apos;s state have to happen at one instant in time. Where the&lt;br/&gt;
original code could make multiple changes to the state at different&lt;br/&gt;
times, knowing it was safely protected by an exclusive lock, rewriting&lt;br/&gt;
for atom swaps requires us to reorganize the code so that all updates&lt;br/&gt;
to the state happen at the same time with a single CAS.&lt;/p&gt;

&lt;p&gt;To implement this change, I pulled the implicit looping logic from&lt;br/&gt;
findAndCacheBestMethod() up into getMethod() itself, and broke the&lt;br/&gt;
&quot;findBestMethod&quot; part into its own function, findBestMethod(), which&lt;br/&gt;
makes no update to any state while implementing the same&lt;br/&gt;
logic. getMethod() now has an explicit loop to avoid stack-consuming&lt;br/&gt;
recursion on retries. This infinite for loop covers all of the logic&lt;br/&gt;
in getMethod() and retries until a method is successfully found and a&lt;br/&gt;
CAS operation succeeds, or we determine that the method cannot be&lt;br/&gt;
found and we return the default dispatch value&apos;s implementation.&lt;/p&gt;

&lt;p&gt;I&apos;ll now describe the operation of the logic in the for loop. The&lt;br/&gt;
first two steps in the loop correspond to things getMethod() does&lt;br/&gt;
&quot;before&quot; its looping construct in the original code, but we have to do&lt;br/&gt;
in the loop to get the latest values.&lt;/p&gt;

&lt;p&gt;    1. First we dereference our state, and assign this value to both&lt;br/&gt;
    oldState and newState. We also set a variable called needWrite to&lt;br/&gt;
    false; this is so we can avoid doing a CAS (they&apos;re not free) when&lt;br/&gt;
    we have not actually updated the state.  &lt;/p&gt;

&lt;p&gt;    2. Check if the cache is stale, and flush it if so. If the cache&lt;br/&gt;
    gets flushed, set needWrite to true, as the state has changed.&lt;/p&gt;

&lt;p&gt;    3. Check if the methodCache has an entry for this dispatch&lt;br/&gt;
    value. If so, we are &quot;finished&quot; in the sense that we found the&lt;br/&gt;
    value we wanted. However, we may need to update the state. So, &lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;If needWrite is false, we can return without a CAS, so just&lt;br/&gt;
          break out of the loop and return the method.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Otherwise, we need to update the state object with a CAS. If&lt;br/&gt;
          the CAS is successful, break out of the loop and return the&lt;br/&gt;
          target function. Otherwise, continue on the next iteration&lt;br/&gt;
          of the loop, skipping any other attempts to fetch the method&lt;br/&gt;
          later in the loop (useless work, at this point).&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;    4. The value was not in the methodCache, so call the function&lt;br/&gt;
    findBestMethod() to attempt to find a suitable method based on the&lt;br/&gt;
    hierarchy and preferences. If it does find us a suitable method,&lt;br/&gt;
    we now need to cache it ourselves. We create a new state object&lt;br/&gt;
    with the new method cache and attempt to update the state atom&lt;br/&gt;
    with a CAS (we definitely need a write here, so no need to check&lt;br/&gt;
    needWrite at this point).&lt;/p&gt;

&lt;p&gt;    The one thing that is possibly questionable is the check at this&lt;br/&gt;
    point to make sure the hierarchy has not been updated since the&lt;br/&gt;
    beginning of this method. I inserted this here to match the&lt;br/&gt;
    identical check at the corresponding point in&lt;br/&gt;
    findAndCacheBestMethod() in the original code. That is also a&lt;br/&gt;
    second check, since the cache is originally checked for freshness&lt;br/&gt;
    at the very beginning of getMethod() in the original code. That&lt;br/&gt;
    initial check happens at the beginning of the loop in the&lt;br/&gt;
    patch. Given that there is no synchronization with the method&lt;br/&gt;
    hierarchy, it is not clear to me that this second check is needed,&lt;br/&gt;
    since we are already proceeding with a snapshot from the beginning&lt;br/&gt;
    of the loop. Nonetheless, it can&apos;t hurt as far as I can tell, it&lt;br/&gt;
    is how the original code worked, and I assume there was some&lt;br/&gt;
    reason for that, so I kept the second check.&lt;/p&gt;

&lt;p&gt;    5. Finally, if findBestMethod() failed to find us a method for the&lt;br/&gt;
    dispatch value, find the method for the default dispatch value and&lt;br/&gt;
    return that by breaking out of the loop.&lt;/p&gt;

&lt;p&gt;So the organization of getMethod() in the patch is complicated by two&lt;br/&gt;
factors: (1) making the retry looping explicit and stackless, (2)&lt;br/&gt;
skipping the CAS when we don&apos;t need to update state, and (3) skipping&lt;br/&gt;
needless work later in the retry loop if we find a value but are&lt;br/&gt;
unable to succeed in our attempt to CAS. Invoking a multimethod that&lt;br/&gt;
has a stable hierarchy and a populated cache should not even have a&lt;br/&gt;
CAS operation (or memory allocation) on this code path, just a cache&lt;br/&gt;
lookup after the dispatch value is calculated.&lt;/p&gt;</comment>
                    <comment id="28811" author="santiago" created="Fri, 15 Jun 2012 04:45:58 -0500"  >&lt;p&gt;I&apos;ve updated this patch (removing the old version, which is entirely superseded by this one). The actual changes to MultiFn.java are identical (modulo any thing that came through in the rebase), but this newer patch has tests of basic multimethod usage, including defmulti, defmethod, remove-method, prefer-method and usage of these in a hierarchy that updates in a way interleaved with calls. &lt;/p&gt;</comment>
                    <comment id="28812" author="santiago" created="Fri, 15 Jun 2012 06:38:27 -0500"  >&lt;p&gt;I created a really, really simple benchmark to make sure this was an improvement. The following tests were on a quad-core hyper-threaded 2012 MBP. &lt;/p&gt;

&lt;p&gt;With two threads contending for a simple multimethod: &lt;br/&gt;
The lock-based multifns run at an average of 606ms, with about 12% user, 15% system CPU at around 150%. &lt;br/&gt;
The lockless multifns run at an average of 159ms, with about 25% user, 3% system CPU at around 195%.&lt;/p&gt;

&lt;p&gt;With four threads contending for a simple multimethod:&lt;br/&gt;
The lock-based multifns run at an average of 1.2s, with about 12% user, 15% system, CPU at around 150%.&lt;br/&gt;
The lockless multifns run at an average of 219ms, with about 50% user, 4% system, CPU at around 330%.&lt;/p&gt;

&lt;p&gt;You can get the code at &lt;a href=&quot;https://github.com/davidsantiago/multifn-perf&quot;&gt;https://github.com/davidsantiago/multifn-perf&lt;/a&gt; &lt;/p&gt;</comment>
                    <comment id="29159" author="santiago" created="Tue, 14 Aug 2012 22:02:00 -0500"  >&lt;p&gt;It&apos;s been a couple of months, and so I just wanted to check in and see if there was anything else needed to move this along. &lt;/p&gt;

&lt;p&gt;Also, Alan Malloy pointed out to me that my benchmarks above did not mention single-threaded performance. I actually wrote this into the tests above, but I neglected to report them at the time. Here are the results on the same machine as above (multithreaded versions are basically the same as the previous comment). &lt;/p&gt;

&lt;p&gt;With a single thread performing the same work:&lt;br/&gt;
The lock-based multifns run at an average of 142ms. &lt;br/&gt;
The lockless multifns run at an average of 115ms. &lt;/p&gt;

&lt;p&gt;So the lockless multimethods are still faster even in a single-threaded case, although the speedup is more modest compared to the speedups in the multithreaded cases above. This is not surprising, but it is good to know.&lt;/p&gt;</comment>
                    <comment id="29213" author="stuart.sierra" created="Fri, 17 Aug 2012 14:58:06 -0500"  >&lt;p&gt;Screened. The approach is sound. &lt;/p&gt;

&lt;p&gt;I can confirm similar performance measurements using David Santiago&apos;s benchmark, compared with Clojure 1.5 master as of commit f5f4faf.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;Mean runtime (ms) of a multimethod when called repeatedly from N threads:

|            | N=1 | N=2 | N=4 |
|------------+-----+-----+-----|
| 1.5 master |  80 | 302 | 765 |
| lockless   |  63 |  88 | 125 |&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;My only concern is that the extra allocations of the &lt;tt&gt;State&lt;/tt&gt; class will create more garbage, but this is probably not significant if we are already using persistent maps. It would be interesting to compare this implementation with one using thread-safe mutable data structures (e.g. ConcurrentHashMap) for the cache.&lt;/p&gt;</comment>
                    <comment id="29216" author="santiago" created="Fri, 17 Aug 2012 19:05:54 -0500"  >&lt;p&gt;I think your assessment that it&apos;s not significant compared to the current implementation using persistent maps is correct. Regarding the extra garbage, note that the new State is only created when the hierarchy has changed or there&apos;s a cache miss (related, obviously)... situations where you&apos;re already screwed. Then it won&apos;t have to happen again for the same method (until another change to the multimethod). So for most code, it won&apos;t happen very often. &lt;/p&gt;

&lt;p&gt;ConcurrentHashMap might be faster, it&apos;d be interesting to see. My instinct is to keep it as close to being &quot;made out of Clojure&quot; as possible. In fact, it&apos;s hard to see why this couldn&apos;t be rewritten in Clojure itself some day, as I believe Chas Emerick has suggested. Also, I would point out that two of the three maps are used from the Clojure side in core.clj. I assume they would be happier if they were persistent maps. &lt;/p&gt;

&lt;p&gt;Funny story: I was going to point out the parts of the code that were called from the clojure side just now, and alarmingly cannot find two of the functions. I think I must have misplaced them while rewriting the state into an immutable object. Going to attach a new patch with the fix and some tests for it in a few minutes.&lt;/p&gt;</comment>
                    <comment id="29218" author="santiago" created="Fri, 17 Aug 2012 19:44:54 -0500"  >&lt;p&gt;Latest patch for this issue. Supersedes issue988-lockless-multifn+tests.diff as of 08/17/2012.&lt;/p&gt;</comment>
                    <comment id="29219" author="santiago" created="Fri, 17 Aug 2012 19:49:13 -0500"  >&lt;p&gt;As promised, I reimplemented those two functions. I also added more multimethod tests to the test suite. The new tests should definitely prevent a similar mistake. While I was at it, I went through core.clj and found all the multimethod API functions I could and ensured that there were at least some basic functionality tests for all of them. The ones I found were: defmulti, defmethod, remove-all-methods, remove-method, prefer-method, methods, get-method, prefers (Some of those already had tests from the earlier version of the patch). &lt;/p&gt;

&lt;p&gt;Really sorry about catching this right after you vetted the patch. 12771 test assertions were apparently not affected by prefers and methods ceasing to function, but now there are 12780 to help prevent a similar error. Since you just went through it, I&apos;m leaving the older version of the patch up so you can easily see the difference to what I&apos;ve added. &lt;/p&gt;</comment>
                    <comment id="29448" author="richhickey" created="Sat, 15 Sep 2012 09:05:46 -0500"  >&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/commit/83ebf814d5d6663c49c1b2d0d076b57638bff673&quot;&gt;https://github.com/clojure/clojure/commit/83ebf814d5d6663c49c1b2d0d076b57638bff673&lt;/a&gt; should fix these issues. The patch here was too much of a change to properly vet.&lt;/p&gt;

&lt;p&gt;If you could though, I&apos;d appreciate a patch with just the multimethod tests.&lt;/p&gt;</comment>
                    <comment id="29449" author="jafingerhut" created="Sat, 15 Sep 2012 10:59:01 -0500"  >&lt;p&gt;Patch clj-988-tests-only-patch-v1.txt dated Sep 15 2012 is a subset of David Santiago&apos;s &lt;br/&gt;
patch issue988-lockless-multifn+tests-120817.diff dated Aug 17 2012.  It includes only the tests from that patch.  Applies cleanly and passes tests with latest master after Rich&apos;s read/write lock change for multimethods was committed.&lt;/p&gt;</comment>
                    <comment id="29463" author="richhickey" created="Mon, 17 Sep 2012 09:20:43 -0500"  >&lt;p&gt;tests-only patch ok&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11498" name="clj-988-tests-only-patch-v1.txt" size="3569" author="jafingerhut" created="Sat, 15 Sep 2012 10:59:01 -0500" />
                    <attachment id="11441" name="issue988-lockless-multifn+tests-120817.diff" size="15875" author="santiago" created="Fri, 17 Aug 2012 19:44:54 -0500" />
                    <attachment id="11321" name="issue988-lockless-multifn+tests.diff" size="12422" author="santiago" created="Fri, 15 Jun 2012 04:45:58 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-983] proxy-super does not restore original binding if call throws exception</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-983</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The code for proxy-call-with-super internally used by proxy-super does not handle exceptions from the call method:&lt;/p&gt;

&lt;p&gt;(defn proxy-call-with-super &lt;span class=&quot;error&quot;&gt;&amp;#91;call this meth&amp;#93;&lt;/span&gt;&lt;br/&gt;
 (let &lt;span class=&quot;error&quot;&gt;&amp;#91;m (proxy-mappings this)&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (update-proxy this (assoc m meth nil))&lt;br/&gt;
    (let &lt;span class=&quot;error&quot;&gt;&amp;#91;ret (call)&amp;#93;&lt;/span&gt;&lt;br/&gt;
      (update-proxy this m)&lt;br/&gt;
      ret)))&lt;/p&gt;

&lt;p&gt;As a result the following sequence behaves unexpectedly:&lt;br/&gt;
(def obj (proxy &lt;span class=&quot;error&quot;&gt;&amp;#91;java.lang.ClassLoader&amp;#93;&lt;/span&gt; []&lt;br/&gt;
		      (loadClass &lt;span class=&quot;error&quot;&gt;&amp;#91;cl&amp;#93;&lt;/span&gt; (println &quot;enter&quot;)&lt;br/&gt;
				 (proxy-super loadClass cl))))&lt;br/&gt;
(.loadClass obj &quot;nonexistent&quot;)&lt;br/&gt;
;; prints enter, then throws ClassNotFoundException&lt;br/&gt;
(.loadClass obj &quot;nonexistent&quot;)&lt;br/&gt;
;; does not print anything before throwing cnfe&lt;/p&gt;


&lt;p&gt;A try-finally block around the invocation would solve this particular issue.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15409">CLJ-983</key>
            <summary>proxy-super does not restore original binding if call throws exception</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tuor713">Valentin Mahrwald</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Sat, 5 May 2012 03:36:15 -0500</created>
                <updated>Sat, 5 May 2012 09:04:26 -0500</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28392" author="tuor713" created="Sat, 5 May 2012 09:04:26 -0500"  >&lt;p&gt;Test &amp;amp; fix patch on latest Clojure github branch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11171" name="proxy_super.patch" size="1867" author="tuor713" created="Sat, 5 May 2012 09:04:26 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-971] Jar within a jar throws a runtime error</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-971</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;ve created two jar files in my multi-project Maven setup.  The first jar is the &quot;engine&quot;, and it includes the clojure jar in it.  The other jar is the &quot;application&quot;.  It includes the engine and then packages itself into a one-jar jar file.  This means we have a jar within a jar: The &quot;onejar&quot; contains the engine jar, which in turn contains that clojure jar.&lt;/p&gt;

&lt;p&gt;I then get an error in the runtime:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.reflect.InvocationTargetException&lt;br/&gt;
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)&lt;br/&gt;
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)&lt;br/&gt;
    at java.lang.reflect.Method.invoke(Method.java:616)&lt;br/&gt;
    at com.simontuffs.onejar.Boot.run(Boot.java:340)&lt;br/&gt;
    at com.simontuffs.onejar.Boot.main(Boot.java:166)&lt;br/&gt;
Caused by: java.lang.ExceptionInInitializerError&lt;br/&gt;
    at com.ziroby.clojure.App.main(App.java:14)&lt;br/&gt;
    ... 6 more&lt;br/&gt;
Caused by: java.lang.NullPointerException&lt;br/&gt;
    at clojure.lang.RT.lastModified(RT.java:374)&lt;br/&gt;
    at clojure.lang.RT.load(RT.java:408)&lt;br/&gt;
    at clojure.lang.RT.load(RT.java:398)&lt;br/&gt;
    at clojure.lang.RT.doInit(RT.java:434)&lt;br/&gt;
    at clojure.lang.RT.&amp;lt;clinit&amp;gt;(RT.java:316)&lt;br/&gt;
... 7 more&lt;/p&gt;

&lt;p&gt;See also my Stack Overflow question on this at &lt;a href=&quot;http://stackoverflow.com/questions/7763480/making-an-executable-jar-that-evals-clojure-strings&quot;&gt;http://stackoverflow.com/questions/7763480/making-an-executable-jar-that-evals-clojure-strings&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In researching it, I&apos;ve found the problem lies in RT.lastModified, where it tries to determine last modified time by looking at the modified time on the jar file for Clojure.  But there&apos;s not actually a jar file, since it&apos;s embedded in another.&lt;/p&gt;

&lt;p&gt;I&apos;ve found that adding a null check solves the problem.  My lastModified looks like this now:&lt;/p&gt;

&lt;p&gt;static public long lastModified(URL url, String libfile) throws Exception{&lt;br/&gt;
	if(url.getProtocol().equals(&quot;jar&quot;)) {
		ZipEntry entry = ((JarURLConnection) url.openConnection()).getJarFile().getEntry(libfile);
		if (entry != null)
			return entry.getTime();
	}&lt;/p&gt;

&lt;p&gt;	return url.openConnection().getLastModified();&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;This runs successfully.&lt;/p&gt;

&lt;p&gt;If you&apos;d prefer, I can submit a patch, or commit directly.    &lt;/p&gt;
</description>
                <environment>Maven using the one-jar plugin</environment>
            <key id="15326">CLJ-971</key>
            <summary>Jar within a jar throws a runtime error</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ziroby">Ron Romero</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 10 Apr 2012 22:39:36 -0500</created>
                <updated>Tue, 10 Apr 2012 22:39:36 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>
</channel>
</rss>