Major breakage: manifests don't work in certain environments

[Eugene Burmako]

Manifests (not ClassManifests, just Manifests) now use scala.reflect.mirror singleton. This singleton is loaded from scala-compiler.jar using reflection. That reflection uses getClass.getClassLoader of scala-library.jar, and tries to load the mirror from scala.reflect.runtime.package. Breakages might happen even when scalac starts up, because: 1) it uses manifests, 2) in some environments classloader that loads scala-library.jar for scalac doesn't contain scala-compiler.jar.

Status will be tracked here:

https://gist.github.com/2391081

[Eugene Burmako]

@Iulian & Luc, Josh has figured out that setting <fork>false</fork> in
maven-scala configuration fixes problems with compilation. Could you,
please, adjust your scripts and try to build Scala IDE?

[Eugene Burmako]

Hey, would use your help with SBT. Got time today?

[Luc Bourlier]

Adding '<fork>false</fork>' kind of work but is not usable. It generates the classes, but the compiler is calling System.exit() at some point and kill the maven run.

Luc

[Paul Phillips]

https://issues.scala-lang.org/browse/SI-5674

[Eugene Burmako]

I'm glad to announce that manifests don't require a mirror anymore if
you use them solely to create arrays: https://github.com/scala/scala/pull/411.

This means that scala-compiler.jar is now required on the classpath
*of the classloader that loaded scala-library.jar* only if you
explicitly inspect a tpe (or a symbol) of a manifest, or use <:<, >:>
or typeArguments.

Bottom line is that maven should work as it used to, even without
<fork>false</false>.

[Alex Cruise]

On Mon, Apr 16, 2012 at 7:17 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

I'm glad to announce that manifests don't require a mirror anymore if
you use them solely to create arrays: https://github.com/scala/scala/pull/411.

That's good!

 

or use <:<, >:> or typeArguments.

That's bad. :(  

We have eight uses of <:< in our codebase that would be unhappy to have to drag a scala-compiler.jar around with them.  Are there any alternatives?

-0xe1a

[Eugene Burmako]

After having discussed the problem with Paul today, I'm thinking of reverting manifests to their original state, i.e. manifests will remain as they were in 2.9, type tags will remain as they are now, and manifests will become deprecated and subject to being removed in 2.11. I'm not sure of the details (e.g. what if you want to migrate, but you use a 3rd party library, which only accepts manifests), but this looks like the lesser evil.

In the meanwhile, could you please explain your use cases to me? (would be also great if you could post the actual code)