Re: [Jython-users] RE: Classpath problem?

[Finn B. <bc...@wo...>]

[dave]

> Hi Ed,
> 
> Not so much a bug as a way of doing things? :-)
> 
> It does seem to me that jython's built on the assumption that
 > it will run on a desktop PC, with access to the hard drive etc.

To some extend that description is correct.

 > I'm interested in deploying jython within mobile code that
 > won't necessarily have those privileges. There are several
 > situations where this could occur:
> 
> - an app that is downloaded via JNLP and embeds a jython interpreter
> - a piece of code invoked from a remote process, such as an attribute 
 >   of a jini service
> - an app that runs from inside a jar file, and ought to be completely 
 >   portable as a single jar file (allowing 'java -jar' invocation, or
 >   double-clicking on the icon in Win Explorer, etc.)

These are all usefull and valuable use cases, I'm sure there are many 
others cases which are suffering from jython's current limitation.

> IMHO, this is where java is heading - on to mobile devices, running 
 > across networks, etc.
> It would be a great shame if jython remained stuck on the desktop,
 > as it offers better capabilities than any of the other java
 > scripting engines I've come across.
> 
> I guess this question is aimed at the folk who develop jython, or know 
 > its internals well. Am I right in what I've said above? If so, is
 > it a major job to modify the internals, or just a matter of replacing
 > a few FileInputStreams with URLs that can then be configured to point
 > to web resources, jar contents, etc.?

It goes quite a lot deeper than that. First the problem that jython 
faces can be described with "no reflection info available from 
classloaders (CL)". Since the only part of the external world that 
jython can see when embedded in a .jar or JNLP is the CL, jython can not 
know what java packages there exists and can not know which java classes 
to import with wildcard import. As an example, what should en embedded 
jython do when faced with and no "dk.py" module and python package exists?

    import dk

We can't ask the CL if a "dk" java package exists, we can only ask if a 
"dk.bckfnn.Main" java class exist. In the desktop situation, we know 
that a "dk" java package exists because we have scanned all the 
available .jar files and discovered that a "dk.bckfnn.Main" class existed.

Similar when facing

    from dk.bckfnn import *

The CL can't tell us the name and accessibility of all the java classes 
that have "dk.bckfnn" as package.

There are some patches in the jython patch manager that in different 
ways try to help with this "package indexing" problem. One of the 
patches require that an indexing command is run on the .jar file(s), the 
other depends on somewhat underdocumented features of the JDK1.2 CL 
(that CL.getResource() works on a java package).

Neither solution is perfect, but I don't think that the perfect solution 
is possible.

I would further like to split the CL cases up into two different types.

A) Single classloader case. From jython's POV there is only one CL which 
also was the CL that loaded jython. Both .jar-MainClass and JNLP are of 
this type.

B) Multiple classloaders case. Jython is ofcourse still loaded by a 
single CL, but the python scripts or the PythonInterpreter user wants 
jython to search for java package/classes in other unreleated classloaders.

In imp.java there exists some unused code in loadFromClassLoader that on 
first impression would help in case A) but don't get your hopes up, the 
unused code does not play nice with python modules from the disk and it 
gets the loading priority slightly wrong (IIRC).

A solution for the CL loading issue also have to handle B) type cases.

And a solution will probably also involve some restructuring of the 
existing loadFromXXX methods in imp.java. The 3 methods are too similar 
for comfort and really should be merged somehow.

 > Does anyone else on the list see
 > the merit of what I'm saying? I've tentatively raised this issue a
 > couple of times before, and received little response.

It is just a difficult issue. Fixing it will require a deep and solid 
understanding on how jython does its importing and of all the very 
different situations where importing must work.

> I owe the jython community a lot, and I'm very grateful for what you've 
 > created. I've spent a fair bit of time recently working on a resource
 > loader system (for config files and yes, jython scripts) for a
 > Open Source project that I run, and would be happy to see this code
 > in use in jython, if it allows the language to have greater portability.
 > I don't have a great deal of time to contribute (yeah, I know, none
 > of us do...), but if anyone would like to show me around the jython
 > source and point me to the right places, I'm willing to have a first
 > look and see if it's feasible. Anyone else care to join me?

Maybe a simple solution is just laying there, ready to be picked up, but 
I haven't found it myself <wink>.

Please don't think that we don't recoqnize that the CL loaded applications
likes .jar and JNLP are important, it is just a feature that hasn't been 
implemented yet.

regards,
finn