Issue1127

As discussed on
<http://thread.gmane.org/gmane.comp.lang.jython.user/7156>, configuring
jython on the bootclasspath (as the current launcher script does) is
causing problems when dynamically loading classes which "live" on the
normal CLASSPATH (i.e, when using Class.forName()).

This typically impacts the use of JDBC drivers.

#1096 is clearly related to this issue.

Oh, and for the record, the current workaround is to use the --verify
flag when starting jython.

#1129 is also this problem

So:

>>> Class.forName('com.apple.mrj.MRJPriv')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)

The full stack looks like:

Class<T>.forName(String) line: 169	
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
Method.invoke(Object, Object...) line: 597	
PyReflectedFunction.__call__(PyObject, PyObject[], String[]) line: 162	
PyReflectedFunction.__call__(PyObject[], String[]) line: 170	
PyReflectedFunction(PyObject).__call__(PyObject) line: 273	
_pyx2.f$0(PyFrame) line: not available	
_pyx2.call_function(int, PyFrame) line: not available	
PyTableCode.call(PyFrame, PyObject) line: 187	
PyTableCode(PyCode).call(PyFrame) line: 14	
Py.runCode(PyCode, PyObject, PyObject) line: 1200	
Py.exec(PyObject, PyObject, PyObject) line: 1227	
InteractiveConsole(PythonInterpreter).exec(PyObject) line: 134	
InteractiveConsole(InteractiveInterpreter).runcode(PyObject) line: 90	
InteractiveConsole(InteractiveInterpreter).runsource(String, String, String) line: 71	
InteractiveConsole(InteractiveInterpreter).runsource(String, String) line: 46	
InteractiveConsole.push(String) line: 110	
InteractiveConsole.interact(String, PyObject) line: 90	
jython.run(String[]) line: 294	
jython.main(String[]) line: 114	

So the problem is that Class.forName uses ClassLoader.getCallerClassLoader, whereas we want it to use another 
one.

>>> Thread.currentThread().getContextClassLoader()
sun.misc.Launcher$AppClassLoader@e47858e
>>> Class.forName('com.apple.mrj.MRJPriv', True, Thread.currentThread().getContextClassLoader())
<jclass com.apple.mrj.MRJPriv 1>

At least for cases like #1129 and #1096, we could change Jython's and zxJDBC's Class.forName calls to 
explicitly specify a classloader, as above.

Another issue is people using Class.forName explicitly from Jython.  In general it looks like we need to have 
the invoking class have a "valid" classloader.  From instrumenting ClassLoader.getCallerClassLoader, that 
ends up being PyReflectedFunction.  So, maybe we can load PyReflectedFunction from somewhere else to get 
around this?

Deferred to 2.5.1 (or later)

I think that the machinery needed to workaround the problem and support
using Class.forName from Python code is not worth the effort. 

I propose to explicitely discourage Class.forName('foo.bar.Baz'), since
you can get the desired effect either by doing  "import foo.bar.Baz", if
the class name is known beforehand, or __import__(className), if it's not.

We could even hack PyReflectedFunction to check if it is going to call
Class.forName(String) and print a loud warning.

+1 on discouraging Class.forName, this was my original suggestion before 
we decided to remove it. However if we can hack PyReflectedFunction to 
warn on its call, how much harder would it be really to hack it to call 
another class loader instead?

Maybe best to encourage the use of Py.findClass, which knows about Jython's class loaders. We could also add a function in the new library jythonlib that wraps this.

Changing Class.forName is probably not what we want to do, but we could document the right solution.

Note the use of JDBC drivers will go away with the move to jyjdbc in beta 4.

Bad wording in my previous message:
"Note the use of JDBC drivers will go away with the move to jyjdbc in beta 4."

That should be something like the "problem with the use of JBDC drivers will go away" because jyjdbc is in Python.

Let's revisit Philip's suggestion in msg5243 for 2.7.1