Message12412

I've mostly fixed these, except for a few I think may be unavoidable, and skipped with a clear conscience.

A lot of it was to do with the treatment of null: many places we have already adapted our coercion of Py.None so we do not ask maps to hold a Java null, but not everywhere. We missed some cases and the improved coverage has found (some of) them for us.

The remaining problem is with the keys() method in mapping types we allow to be treated as equivalent to dict (PyDictionary). The problem is that both ConcurrentHashMap and Hashtable have a keys() method. It returns an Enumerator.

We try to dress up mapping types with the Python mapping API, which includes a keys() method that returns a PyList. Hoever, where there is a clash with a pre-existing method, the Java meaning wins. We have noticed this problem already with LinkedList.pop() in #2645, raised by James. We decided there that letting Java win was the right answer: if an object in Jython claims to be a java.util.Hashtable, its keys() method should return what the Javadoc says.

However, I think these clashes call into question the proxy idea as presently offered. I think there is a case for saying that a java.lang.Hashtable should do exactly and only what it says on the tin, and if you want it to behave like a dict, then there's an explicit wrapper that presents it as exactly a dict, so code that tests for that will find it behaves correctly.