Re: [Jython-dev] MINI-PEP: Alternative to jar scanning.

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

[Samuele]

> I'm a bit unhappy with the actual form of the proposal.
> It seems more a mixture/mismatch beetween things that are
> good for jython -jar and some that are good for java -jar ...

> > The RunJar startup utility shows how /applications/ can be deployed
> > using the "java -jar" syntax. An index is generated of all the java
> > packages in the java system and stored in the main jar file together
> > with manifest file like this:
> >
> >     Name: python.main
> >     Main-Script: mytest.py
> >
> >     Name: python.options
> >     python-security-respectJavaAccessibility: true
> >     python-skipcachedir: true
> >     python-prepath:
> >     python-path: mytest.jar
> >
> > (notice that the jar file that includes the $py.class files must be
> > available on sys.path.
> That's the critical part. It seems that the CWD should be
> the directory with the jar otherwise java -jar will fail ... or
> I'm mislooking something.

No, you are right.

> > We can't load python modules from resources yet
> I don't even know if that would be a good idea, maybe we should just load
> them through the Java system classloader as happen with jythonc-ed code.

Agreed. Eventually we have to find a way of adding this feature.

> >
> > Problems:
> >
> > - Because the JYTHON-PACKAGE-* files is found as resources, only one
> > version of a package index can be loaded. If the classes in a
> > javapackage is split over more than one jar file, only the class files
> > in the first jar will be loaded with "import *" and show up in
> > dir(javapackage).
> That's not a big problem,
> if you're using java -jar there is just one jar up to java extensions...

Yeah, but since the manifest can have a Class-Path entry that lists
other .jar files I think it would be common to include libraries like
xerces.jar and jython.jar in this way.

  http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Main Attributes

These jar files doesn't show up in the java.class.path property but the
classes in them are of course available.

> > - Python module can not be loaded as resources, so none of this helps
> > with the applet situation.
> But IMHO the solution for applets should be the same for java -jar
> vs. the solution for jython -jar ...

I agree. 

Lets forget about RunJar for now. Remaining is (I hope) yet another way
to support import of java packages in the situation where we can't scan
the jar file.


I have also considered a scheme where the indexer tool writes a resource
file named after the jar file:

   /META-INF/JYTHON-PACKAGES-jython

which contains a complete list of all java packages and the classes in
each package:

   org.python.core : ArgParser,AutoInternalTables,BytecodeLoader,...
   org.python.compilers : ...

An deployed application that knows about the jars it depends on, can
make sure that the java packages are totally initialized by calling a
new sys.addXXX method for each jar file:

   sys.add_jar("jython")

This idea demands more of the application, but avoids the problem where
a java package is split over multiple jar files.

regards,
finn