Clojure

Clojure master fails on JDK 11 EA builds due to overloaded toArray in gvec.clj

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: Release 1.10
  • Component/s: None
  • Labels:
  • Environment:
    java version "11-ea" 2018-09-25
    Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
    Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
    OS : Ubuntu
  • Patch:
    Code
  • Approval:
    Ok

Description

The java.util.Collection interface has long had the methods:

Object[] toArray()
<T> T[] toArray​(T[] a)

JDK 11 adds a new method with default impl:

default <T> T[] toArray​(IntFunction<T[]> generator)

For cases of a deftype implementing java.util.Collection, this makes existing implementations of the 1-arity toArray ambiguous. In Java, static typing means that existing implementors are not broken, but in our dynamic typing world, we now have ambiguity. *shakes fist at Java*

In Clojure itself, this comes up in gvec in the primitive vector implementation, which is done with deftype. This breaks the compilation of Clojure on JDK 11. This has also come up in some external projects that do the same thing (like core.rrbvector). See CRRBV-18.

Proposed: Add a type hint to disambiguate in JDK 11+.

This breaks our compilation of deftype implementation of java.util.Collection, which includes primitive vector in gvec, but also many external Clojure implementors.

Patch: clj-2374-2.patch

  1. clj-2374.patch
    21/Sep/18 8:33 AM
    1 kB
    Alex Miller
  2. clj-2374-2.patch
    01/Oct/18 9:30 AM
    1.0 kB
    Alex Miller

Activity

Alex Miller made changes -
Field Original Value New Value
Approval Vetted [ 10003 ]
Affects Version/s Release 1.10 [ 11451 ]
Fix Version/s Release 1.10 [ 11451 ]
Alex Miller made changes -
Patch Code [ 10001 ]
Attachment clj-2374.patch [ 18496 ]
Alex Miller made changes -
Description I was trying to build Clojure master on Travis against JDK 11 EA builds and got the below error . This is caused due to overloaded toArray and a similar [issue](https://dev.clojure.org/jira/browse/CRRBV-18) has been found at core.rrb-vector. The applied patch fixes the issue there and it seems that the change was introduced recently. Please refer to the [comment](https://dev.clojure.org/jira/browse/CRRBV-18?focusedCommentId=49545&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49545) for the change.

Travis log : https://travis-ci.org/tirkarthi/clojure/jobs/402132377

I searched for JIRA using JDK 11 and Java 11 and couldn't come up with anything similar to this. Since this is an EA build I don't know if it will be added in the final release. Also if this going to be fixed will this mean that versions below master won't run on JDK 11 and above?

Thanks
The java.util.Collection interface has long had the methods:

{code}
Object[] toArray()
<T> T[] toArray​(T[] a)
{code}

JDK 11 adds a new method with default impl:

{code}
default <T> T[] toArray​(IntFunction<T[]> generator)
{code}

For cases of a deftype implementing java.util.Collection, this makes existing implementations of the 1-arity toArray ambiguous. In Java, static typing means that existing implementors are not broken, but in our dynamic typing world, we now have ambiguity. \*shakes fist at Java\*

In Clojure itself, this comes up in gvec in the primitive vector implementation, which is done with deftype. This breaks the compilation of Clojure on JDK 11. This has also come up in some external projects that do the same thing (like core.rrbvector). See CRRBV-18.

*Proposed:* Add a type hint to disambiguate in JDK 11+.
 
This breaks our compilation of deftype implementation of java.util.Collection, which includes primitive vector in gvec, but also many external Clojure implementors.

*Patch:* clj-2374.patch
Alex Miller made changes -
Priority Major [ 3 ] Critical [ 2 ]
Alex Miller made changes -
Description The java.util.Collection interface has long had the methods:

{code}
Object[] toArray()
<T> T[] toArray​(T[] a)
{code}

JDK 11 adds a new method with default impl:

{code}
default <T> T[] toArray​(IntFunction<T[]> generator)
{code}

For cases of a deftype implementing java.util.Collection, this makes existing implementations of the 1-arity toArray ambiguous. In Java, static typing means that existing implementors are not broken, but in our dynamic typing world, we now have ambiguity. \*shakes fist at Java\*

In Clojure itself, this comes up in gvec in the primitive vector implementation, which is done with deftype. This breaks the compilation of Clojure on JDK 11. This has also come up in some external projects that do the same thing (like core.rrbvector). See CRRBV-18.

*Proposed:* Add a type hint to disambiguate in JDK 11+.
 
This breaks our compilation of deftype implementation of java.util.Collection, which includes primitive vector in gvec, but also many external Clojure implementors.

*Patch:* clj-2374.patch
The java.util.Collection interface has long had the methods:

{code}
Object[] toArray()
<T> T[] toArray​(T[] a)
{code}

JDK 11 adds a new method with default impl:

{code}
default <T> T[] toArray​(IntFunction<T[]> generator)
{code}

For cases of a deftype implementing java.util.Collection, this makes existing implementations of the 1-arity toArray ambiguous. In Java, static typing means that existing implementors are not broken, but in our dynamic typing world, we now have ambiguity. \*shakes fist at Java\*

In Clojure itself, this comes up in gvec in the primitive vector implementation, which is done with deftype. This breaks the compilation of Clojure on JDK 11. This has also come up in some external projects that do the same thing (like core.rrbvector). See CRRBV-18.

*Proposed:* Add a type hint to disambiguate in JDK 11+.
 
This breaks our compilation of deftype implementation of java.util.Collection, which includes primitive vector in gvec, but also many external Clojure implementors.

*Patch:* clj-2374-2.patch
Attachment clj-2374-2.patch [ 18522 ]
Stuart Halloway made changes -
Approval Vetted [ 10003 ] Screened [ 10004 ]
Rich Hickey made changes -
Approval Screened [ 10004 ] Ok [ 10007 ]
Stuart Halloway made changes -
Resolution Completed [ 1 ]
Status Open [ 1 ] Closed [ 6 ]

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: