Eugene Burmako | 1 May 23:07 2012
Picon
Picon

classloader problem #1

=== Given ===
* A singleton scala.reflect.mirror in scala-library.jar (it's a
singleton, because manifests/tags need a mirror that's accessible from
anywhere)
* An implementation of mirror in scala-reflect.jar (because it's 2 mb
of compressed classes, which is too much to put into scala-
library.jar)

=== Problem ===

We are essentially forced to reflectively load (Class.forName) from
scala-library.jar. But what classloader do we use for that?

1) getClass.getClassLoader is a wrong answer, because scala-reflect
might be loaded by a classloader down the chain w.r.t scala-library
(e.g. scala-library is in boot classpath, scala-reflect is in app
classpath).

2) ClassLoader.getSystemClassLoader? Not necessarily, due to the same
reason.

3) Thread.getContextClassLoader? Might be a good idea, but it might be
sabotaged by careless environment.

4) Classloader from stack trace, like it's done in
http://docs.oracle.com/javase/6/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass)?
No idea, tbh, looks very hacky to me.

=== Supposed solution ===

How about trying 1, 2, 3, maybe 4, and bailing (i.e. switching to a
fallback mirror) if none of these classloaders contains an
implementation of mirror?


Gmane