Clojure master fails on JDK 11 EA builds due to overloaded toArray in gvec.clj
Description
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
Attachments
- 01 Oct 2018, 03:30 PM
- 21 Sep 2018, 02:33 PM
Activity
Ghadi ShaybanSeptember 28, 2018 at 8:37 PM
RRB vector has a new release you can pull and override your transitive dependency.
importSeptember 28, 2018 at 7:00 PM
Comment made by: pmonks
Andy ah ok that makes more sense. It looks like midje (which I'm using for unit testing) has a dependency on core.rrb-vector.
[edit following your edit] Yes I can confirm that the issue is with midje (see https://github.com/marick/lein-midje/issues/66), and yes I am using midje for unit testing as part of the CI process on Travis, so it's not as trivial as simply removing midje from the dependencies and/or Travis script. I'll probably just bite the bullet and port to clojure.test.
Andy FingerhutSeptember 28, 2018 at 6:54 PM
@Peter That looks like an issue when compiling the core.rrb-vector library, which despite its name is a library separate from Clojure, and has an open ticket for its own independent issue that has the same JDK 11 based root cause as this ticket: https://dev.clojure.org/jira/browse/CRRBV-18
It looks like in your multigrep project, you have a test dependency on midje, which through one or two other deps (including fipp) depends upon core.rrb-vector. I did not dig into your travis build to check, but if that step is not doing any testing, but only building multigrep code, there should be no need to pull in midje in that step. For any midge-based testing, it will have that problem until core.rrb-vector, then fipp, etc. then midje have their dependencies updated and released to avoid this problem.
importSeptember 28, 2018 at 6:50 PM
Comment made by: pmonks
Andy the build I referenced above is using those published JARs - I am not attempting to compile Clojure from source - and yet I'm seeing this exception (and hence believe I'm seeing the issue described here). Any ideas why?
Andy FingerhutSeptember 28, 2018 at 6:47 PM
I think Ghadi's comment may be intended to mean: "there are JARs for earlier Clojure releases published already, and most people use those rather than compiling Clojure from source code themselves". The only people that will ever see this error are a few developers wanting to build old versions of Clojure from source code.
That said, for those few it might be convenient for them if they didn't have to hunt down this patch and apply it themselves, I guess, but I would understand if the Clojure core team would rather document this for developers, rather than put out ".1" releases of older Clojure versions for a Clojure-build-time-with-latest-JDK issue.
Details
Assignee
UnassignedUnassignedReporter
KarthikeyanKarthikeyanLabels
Approval
OkPatch
CodePriority
CriticalFix versions
Details
Details
Assignee
Reporter
Labels
Approval
Patch
Priority
Critical
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