Message12800

It's an interesting problem.

In general, we have had this implicit magic of semantic equivalence of Python and Java for a while, going back to the beginning of the project. It usually works well, until we further fix things by making the semantic equivalence ore regular, as we see in this bug report.

(See https://hg.python.org/jython/rev/ae2a1efe4192 for when this regularization fix was introduced.)

However, Jython also implements a number of hooks to control such magic more precisely. So for example, we have the ability to register the java2py adapter (use a custom one based on ExtensiblePyObjectAdapter per sys instance instead of ClassicPyObjectAdapter, or use its pre/post adapter scheme), manage ClassDict initialization, and in jythonlib, the ability to directly use a constructed Java ConcurrentMap for initializing a PyDictionary.

I can see the possibility of using the object adapter support to restore older usage. But it might be complicated in practice - now we have this per PySystemState setup, etc.

One thought I had is to make *explicit* (sorry!!!!) when we don't want the implicit magic, similar to what was done with jythonlib (see its usage in Lib/weakref.py, Lib/threading.py, and a few other libraries, 
https://bugs.jython.org/issue1631).

So this is the current behavior, which we can continue to support:

from java.util import LinkedList

x = LinkedList([1, 2, 3, 4, 5])
assert x.pop() == 1 

However we could instead do the following with an alternative wrapper class:

from jythonlib import RawJavaObject

y = RawJavaObject(LinkedList([1, 2, 3, 4, 5]))
assert y.pop() == 5

The RawJavaObject support would expose an alternative implementation of the underlying Java type with minimal wrapping, and would instead pass through all calls to the underlying object. Also, much like some other jythonlib functionality, there could be a factory function to control exactly what is done. Example: what happens when comparing the types of x and y?