Issue2229

When using Java 8, the following code produces a NameError

import jarray
x=jarray.array([1,3,2], 'f')

from java.util import *
Arrays.sort(x)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'Arrays' is not defined


If I do however an explicit import first (i. e. from java.util import Arrays)

things work.

I think this has actually existed for a while, and I believe it is not necessarily related to java 8:

http://bugs.jython.org/issue1383

Dear Brian,

thanks for looking into this. I think, the situations described here and in http://bugs.jython.org/issue1383 are different:

The example provided here works perfectly fine if the JAVA_HOME variable is set to a Java 7 environment, whereas it breaks when JAVA_HOME is set to Java 8.

Most of the reported problems around wild card imports seem to be related to package scanning. If the packages were not scanned, wild card imports did not work at all. 

In this example the import from java.util import * works for some classes (e. g. I can construct a java.util.ArrayList or instantiate a java.util.Date). Just using static methods from the Arrays class does not seem to work.


The article on stack overflow

http://stackoverflow.com/questions/1681849/why-does-jython-refuse-to-find-my-java-package

indicates that not using wild card imports is "the recommended way" of importing classes. Is that the case? Does Jython "explicitly" discourages the use of wildcard imports? If this was the case, we could tell this to our customers in case that they report this type problem ("Why is my Jython script no longer working after switching to Java 8").

Thanks for your help

Best regards



Bernd

So Jython does do package analysis of the JDK, much as for any other jar. So when running Jython for the first time, you should see such output similar to what's below:

...
*sys-package-mgr*: processing new jar, '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/resources.jar'
*sys-package-mgr*: processing new jar, '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/rt.jar'
*sys-package-mgr*: processing new jar, '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/jsse.jar'
*sys-package-mgr*: processing new jar, '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/jce.jar'
*sys-package-mgr*: processing new jar, '/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/charsets.jar'
*
...

Through Java 8, the key package here is rt.jar, which contains core Java packages like java.util.Arrays, as can be readily seen by running the jar tf command:

$ jar tf /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/lib/rt.jar | grep Arrays
java/util/Arrays$LegacyMergeSort.class
java/util/Arrays$ArrayList.class
java/util/Arrays.class

If this package scanning cannot be done, then the problems of #1383 arise, regardless of whether it is builtin or not.

Let's double check this package scanning occurred, in the right place.

Note that Java 9 recently split rt.jar as part of its modularization effort. I don't know its implication yet. But that's about Java 9, not Java 8.

Dear Jim,

thanks for looking into this. Package scanning still happens as before and wild card imports also work when creating new objects. So

from java.util import *
x = ArrayList()

works for Java 7 and Java 8. What does not work is calling a static class method - e. g.

Arrays.sort()

In this case you have to import java.util.Arrays first.

Best regards


Bernd

Bernd, that's an important and subtle distinction. Thanks for the clarification. We will have to investigate!

I have identified a workaround and the likely problem, which is in determining the accessibility of some static classes, like java.util.Arrays, when creating a list of available classes in a given package with PackageManager#doDir. Explicit, nonstarred imports don't go through this directory construction process, so they are not impacted.

The workaround is to set the following in the Jython registry file or on the command line with -D

python.security.respectJavaAccessibility=false

The problem is most likely in PackageManager.checkAccess, which is very old code that attempts to find the access permission of the class. In reviewing
Java 7 (http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.1) vs
Java 8 (http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1) I didn't see any differences that should cause this problem, but there's certainly room for error in how checkAccess is currently implemented.

checkAccess should instead use ASM, specifically http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/ClassVisitor.html#visit(int, int, java.lang.String, java.lang.String, java.lang.String, java.lang.String[]), which provides exactly what we need.

Dear Jim

I wish you a happy new year and would like to thank you for looking into this. 

Your workaround works like a charm!

Best regards


Bernd

Fixed as of https://hg.python.org/jython/rev/cd3fe8336fb2

Note that we are not going to be supporting Jython 2.5 on Java 8, so de-selecting that.

Bernd, sounds great. Also I hope the ASM fix I put in works as well for you. Have a great 2015!