Scala compilation fails when it includes a Java source with an inner class depending on an third-party dependency

[stephenjudkins]

Here's a failing test in a PR: https://github.com/higherkindness/rules_scala/pull/172

What appears to be going on: ClassToApi is using Java reflection to determine the structure of generated Java sources. [https://github.com/sbt/zinc/blob/develop/internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala#L158]. However, this appears to cause the classloader to attempt to transitively load a class that's defined only in an ijar in this phase; it then blows up because these files are apparently malformed for this purpose.

I'm not sure if this is an upstream Zinc bug that's merely being exercised here or there's something that this project can change directly. Happy to talk through possible resolutions.

[andyscott]

Thanks for the report, and the PR for the failing case!

I'll take a look this weekend. This might be the kick I needed to implement the pure scalac (a per target option, compatible with zinc targets) worker since it probably won't suffer from the same problem.

[pauldraper]

:/

Zinc was never made to use ijar, though javac works fine with ijra. And ijar is supposed to basically be a canonicalized form of the interface, but still otherwise "correct".

So I'm not sure what to put the blame on :/

As a workaround, if you use scala_import or mark the library as a macro in scala_library, then it will not use the ijar for scalac.