Issue1867

C:\jython-2.5.2-standalone>java -jar jython.jar
Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_02
Type "help", "copyright", "credits" or "license" for more information.
>>> import java
>>> import java.security
>>> import java.security.spec
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named spec

-----

This problem doesn't exist with normal Jython, i.e. the non-standalone.
The used OS is Windows 7, 64bit.

I can reproduce that issue, but only by using the -server option to java

C:\>C:\jdk1.7.0_02\bin\java -jar C:\jython252_standalone\jython.jar
Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Client VM (Oracle Corporation)] on java1.7.0_02-ea
Type "help", "copyright", "credits" or "license" for more information.
>>> import java
>>> import java.security
>>> import java.security.spec
>>> import java.math
>>> java.security.spec.ECFieldFp(java.math.BigInteger("5"))
java.security.spec.ECFieldFp@5


X:\>C:\jdk1.7.0_02\bin\java -server -jar C:\jython252_standalone\jython.jar
Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Server VM (Oracle Corporation)] on java1.7.0_02-ea
Type "help", "copyright", "credits" or "license" for more information.
>>> import java
>>> import java.security
>>> import java.security.spec
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named spec
>>>

It doesn't appear to be a java bug necessarily either. When I compile and run the following code, it runs OK with both client and server VMs.

// --------------------------------------------------------

import java.security.spec.ECFieldFp;
import java.math.BigInteger;

public class JSSTest
{
  public static void main (String[] args)
  {
    System.out.println(new ECFieldFp(new BigInteger("5")));
  }
}

// --------------------------------------------------------

C:\jython\bug1867>C:\jdk1.7.0_02\bin\javac JSSTest.java

C:\jython\bug1867>C:\jdk1.7.0_02\bin\java -server -cp . JSSTest
java.security.spec.ECFieldFp@5

C:\jython\bug1867>C:\jdk1.7.0_02\bin\java -client -cp . JSSTest
java.security.spec.ECFieldFp@5

I have found that this issue affects from-import-* statements. When working with my own codebase, from-import-* statements fail to import contents when trying to load from class files within the file system, or from within a jar.

Using Tomas' example of java.security.spec, we can see that standard Jython imports the classes properly:

Using normal Jython:
C:\jython2.7a1>jython
Jython 2.7a1 (default:4f5e3c12edc0, May 16 2012, 13:40:33)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.security.spec import *
>>> dir()
['AlgorithmParameterSpec', 'DSAParameterSpec', 'DSAPrivateKeySpec', 'DSAPublicKeySpec', 'ECField', 'ECFieldF2m', 'ECFiel
dFp', 'ECGenParameterSpec', 'ECParameterSpec', 'ECPoint', 'ECPrivateKeySpec', 'ECPublicKeySpec', 'EllipticCurve', 'Encod
edKeySpec', 'InvalidKeySpecException', 'InvalidParameterSpecException', 'KeySpec', 'MGF1ParameterSpec', 'PKCS8EncodedKey
Spec', 'PSSParameterSpec', 'RSAKeyGenParameterSpec', 'RSAMultiPrimePrivateCrtKeySpec', 'RSAOtherPrimeInfo', 'RSAPrivateC
rtKeySpec', 'RSAPrivateKeySpec', 'RSAPublicKeySpec', 'X509EncodedKeySpec', '__doc__', '__name__', '__package__']
>>>


Standalune Jython imports nothing:

Using Jython standalone:
C:\jython2.7a1_s>java -jar jython.jar
Jython 2.7a1 (default:4f5e3c12edc0, May 16 2012, 13:40:33)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.security.spec import *
>>> dir()
['__doc__', '__name__', '__package__']
>>>


If anyone is interested, I did some digging through the Jython codebase yesterday. I get the impression that org.python.code.JavaImportHelper is being used when the standard caching import system cannot be used, as is the case with the standalone. JavaImportHelper will handle import statements of the form 'import java.net.URL' and 'from java.net import URL' but not of the form 'from java.net import *'. In these cases, a representation of the Java package is created, but not populated.

This problem is not related only to from-import but also to regular import. It's interesting that some imports work, some don't. Look:

Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_04
Type "help", "copyright", "credits" or "license" for more information.

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

>>> import java
>>> dir(java)
['__name__', 'io']

>>> import java.security
>>> dir(java.security)
['__name__']
>>> import java.security.spec
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named spec

In general, it is always better to import Java classes directly and avoid depending on importing packages, so for example:

from java.security.spec import DSAPrivateKeySpec

should work much better. Our package caching mechanism has limits - there is no real way to ask a JVM: what classes does this package contain? Instead we walk through the jars and keep notes ourselves with the package caching mechanism. I'm tempted to turn it off by default in 3.x.

Closing this out, however it is something we should be able to support in Clamp - https://github.com/jythontools/clamp/#todo