switch form v1.1.5 to v1.1.6 on java-9 produces java.util.ConcurrentModificationException

[Andrei-Pozolotin]

project:
https://github.com/random-maven/scalor-maven-plugin

after switch switch form zinc v1.1.5 to zinc v1.1.6:

builds fine on java-8:
https://travis-ci.org/random-maven/scalor-maven-plugin/builds/375394197

build fails on java-9, trace:
https://travis-ci.org/random-maven/scalor-maven-plugin/jobs/375394199#L2269

[INFO] java.util.ConcurrentModificationException
[INFO]     at java.util.HashMap.computeIfAbsent (HashMap.java:1139)
[INFO]     at xsbt.ExtractAPI.processType (ExtractAPI.scala:504)
[INFO]     at xsbt.ExtractAPI.$anonfun$types$1 (ExtractAPI.scala:185)
[INFO]     at scala.collection.TraversableLike.$anonfun$map$1 (TraversableLike.scala:234)
[INFO]     at scala.collection.IndexedSeqOptimized.foreach (IndexedSeqOptimized.scala:32)
[INFO]     at scala.collection.IndexedSeqOptimized.foreach$ (IndexedSeqOptimized.scala:29)
[INFO]     at scala.collection.mutable.ArrayOps$ofRef.foreach (ArrayOps.scala:191)
[INFO]     at scala.collection.TraversableLike.map (TraversableLike.scala:234)
[INFO]     at scala.collection.TraversableLike.map$ (TraversableLike.scala:227)
[INFO]     at scala.collection.mutable.ArrayOps$ofRef.map (ArrayOps.scala:191)
[INFO]     at xsbt.ExtractAPI.types (ExtractAPI.scala:185)

[eed3si9n]

Thanks for the report @Andrei-Pozolotin!

I suspect the direct cause might be 52959c9 but I am not sure if it somehow introduced a concurrency issue, just happened to uncover an existing one.
Ping @retronym.

[eed3si9n]

processType looks like this:

  private def processType(in: Symbol, t: Type): xsbti.api.Type = {
    typeCache.computeIfAbsent((in, t),
                              new java.util.function.Function[(Symbol, Type), xsbti.api.Type] {
                                def apply(key: (Symbol, Type)) = makeType(in, t)
                              })
  }

It checks if (in, t) pair is in typeCache, and calls makeType(in, t), and modifies typeCache.
Inside of def makeType(...) there are multiple calls to processType(...). Is that enough to cause ConcurrentModificationException single-threadedly?

[eed3si9n]

Thankfully the unit test is able to reproduce java.util.ConcurrentModificationException running on OracleJDK 10.

steps

1. jenv shell 10

2. Comment out inlining flags in build.sbt:

    scalaBinaryVersion.value match {
      case "2.12" => old // ++ List("-opt-inline-from:<sources>", "-opt:l:inline", "-Yopt-inline-heuristics:at-inline-annotated")

3. From sbt:

sbt:zinc Root> compilerBridgeTest/testOnly xsbt.ExtractAPISpecification

problems

[info] ExtractAPISpecification:
[info] ExtractAPI
[info] - should give stable names to members of existential types in method signatures *** FAILED ***
[info]   java.util.ConcurrentModificationException:
[info]   at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1139)
[info]   at xsbt.ExtractAPI.processType(ExtractAPI.scala:504)
[info]   at xsbt.ExtractAPI.typeParameter(ExtractAPI.scala:609)
[info]   at xsbt.ExtractAPI.$anonfun$typeParameters$1(ExtractAPI.scala:596)
[info]   at scala.collection.immutable.List.map(List.scala:283)
[info]   at xsbt.ExtractAPI.typeParameters(ExtractAPI.scala:596)
[info]   at xsbt.ExtractAPI.typeParameters(ExtractAPI.scala:594)
[info]   at xsbt.ExtractAPI.xsbt$ExtractAPI$$mkClassLike(ExtractAPI.scala:680)
[info]   at xsbt.ExtractAPI$$anon$5.apply(ExtractAPI.scala:661)
[info]   at xsbt.ExtractAPI$$anon$5.apply(ExtractAPI.scala:660)
[info]   ...

[eed3si9n]

Fixed in #539

[Andrei-Pozolotin]

1.1.7 works, thank you

[eed3si9n]

@Andrei-Pozolotin Awesome. Thanks for the confirmation.