http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-944 Clojure <p>Patch clj944-plus-tests does three things:</p> <ul> <li>includes the previous "0002" patch which has the compiler emit map types consistent with the reader</li> <li>adds tests</li> <li>removes tests that were broken all along and now symptomatic</li> </ul> <p>Hi guys, I am getting the following exception:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(.containsKey {:one 1} :one) ;=&gt; ClassCastException clojure.lang.PersistentArrayMap cannot be <span class="code-keyword">cast</span> to clojure.lang.PersistentHashMap</pre> </div></div> <p>The map is a clojure.lang.PersistentArrayMap, which obviously has a containsKey method (<a href="https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentArrayMap.java#L95">https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentArrayMap.java#L95</a>). </p> <p>Casting it works fine though:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(.containsKey ^clojure.lang.PersistentArrayMap {:one 1} :one) ;=&gt; <span class="code-keyword">true</span></pre> </div></div> <p>The mailing list suggest that the compiler injects an incorrect cast to clojure.lang.PersistentHashMap. In this case it should probably be cast to a clojure.lang.Associative, the highest common interface having the .containsKey method.</p> <p>The problem is not present in Clojure 1.2.1.</p> Clojure 1.3 om Mac OS 10.7, Clojure 1.5.0 alpha1 on Linux x86_64 (OpenJDK 1.7.0 b147) CLJ-944

(.containsKey {:one 1} :one) throws Exception

Defect Major Open Unresolved Unassigned Alf Kristian Støyle Sun, 4 Mar 2012 02:45:09 -0600 Sat, 13 Apr 2013 12:06:35 -0500 Release 1.3 Release 1.4 Release 1.5 Release 1.5 Release 1.6 2 3 <p>The attached patch fixes the issue, by emitting IPersistentMap instead of Persistent{Hash|Array}Map as class type for maps literals</p> <p>I uploaded another patch fixing the same problem in a different way.<br/> While 0001-Fix-for-<a href="http://dev.clojure.org/jira/browse/CLJ-944" title="(.containsKey {:one 1} :one) throws Exception">CLJ-944</a>.patch makes clojure.lang.Complier.ConstantExpr#getJavaClass return clojure.lang.IPersistentMap for both clojure.lang.PersistentHashMap and clojure.lang.PersistentArrayMap, 0002-Fix-for-<a href="http://dev.clojure.org/jira/browse/CLJ-944" title="(.containsKey {:one 1} :one) throws Exception">CLJ-944</a>.patch makes clojure.lang.Compiler.MapExpr#parse return a PersistentArrayMap if the length is &lt;= HASHTABLE_THRESHOLD, instead of always returning a PersistentHashMap.</p> <p>This approach is more consistent, making the type of the compiler's internal representation of a map literal equal to the one of the reader.</p> <p>Note that this second approach while being more consistent, breaks some tests that assume some operations on maps (specifically `seq` and `print`) to be order dependent, and written with the hash-map return order implementation in mind.</p> <p>That should not be the case and if the second patch is preferred over the first one, I'll gladly fix those tests.</p> <p>Approach #2, relying on consistent choice of concrete map class by size throughout, feels quite fragile.</p> <p>Approach #1 seems to abuse the method name getJavaClass(), now having it return "get the base type I would need for cast".</p> <p>Maybe there needs to be a different thing entirely?</p> <p>Patch #2 should get merged (IMHO) regardless of the fragility of its approach to fixing this ticket's bug, since it fixes another bug:</p> <p>prior to the patch:</p> <p>user=&gt; (class {:a 1})<br/> clojure.lang.PersistentArrayMap<br/> user=&gt; (def a {:a 1})<br/> #'user/a<br/> user=&gt; (class a)<br/> clojure.lang.PersistentHashMap</p> <p>after the patch:</p> <p>user=&gt; (class {:a 1})<br/> clojure.lang.PersistentArrayMap<br/> user=&gt; (def a {:a 1})<br/> #'user/a<br/> user=&gt; (class a)<br/> clojure.lang.PersistentArrayMap</p> <p>This should also lead to some <b>minor</b> performance enhancement since prior to this moment, every map def'ed would be a HashMap instead of an ArrayMap</p> <p>So, I think patch #2 should be applied if not for this ticket's bug, at least for the reason stated above.<br/> If somebody has any proposal for making this patch more solid regarding this ticket's bug, any help is welcome</p> <p>This should not have passed screening. There are two issues, should be separate. I have no idea what has been screened nor what will be applied should it be approved. There's contention in the discussion but no resolution.</p> <p>I don't think that there are two issues here.<br/> The issue is only one: the compiler doesn't emit maps in a way consistent with what the reader returns and with how the compiler itself uses maps.<br/> The symptoms are two: some interop calls fail, and def'ed vars with a literal map as value never use a PersistentArrayMap.</p> <p>The underlying cause of those two symtoms is fixed by the patch 002 that i submitted (incorporated in Stu's clj944-plus-tests patch.</p> <p>Stuart said that this approach feels fragile but the bug is caused by the fact that everywhere else clojure returns a PersistentArrayMap when the element count is &lt;= than the PersistentHashMap threshold, and when emitting maps, it doesn't.</p> <p>Making clojure emit maps consistently with how clojure does internally everywhere else looks to me like the only solution, and I don't really see how making clojure consistent is a fragile approach.</p> <p>But again, if somebody can suggest a better solution to this problem, I'll gladly submit another patch.</p> Approval Vetted Global Rank Patch Code