Issue1181

This is an svn diff against trunk (Nov 24, 2008) to make Jython work in
an applet context. The patch reads .py source and/or precompiled .py
classes from the applet jar using getResourceAsStream.

Accidentally included a debugging change to Py.java in the last patch.
Use the later patch.

Just to expand on the purpose of this patch, in case it's unclear: this
makes Jython work from within the applet context without jythonc. You
just need to make a signed jar containing the contents of jython.jar and
the Lib directory. The code will automagically determine that it's
running as an applet and use getResourceAsStream to load .py source and
class files rather than file I/O.

I've been working more on this to fix a few problems and clean it up a
bit. I would really like to see something along these lines integrated
into the mainline Jython code so that I don't have to keep patching the
sources every time a new release comes out. So if any of the maintainers
are interested in helping me check this in to the trunk, pls let me
know. I still have few questions about this, as well: for example, what
exactly the relationship between core/imp.java and module/imp.java
should be, and what to set __file__ to for module imports.

Finally, it would be nice to further extend this so that reading a file
from path __appletjar__/... using Python file I/O would magically try to
load the file from the applet jar. (I.e., make the same change for
read-only data as for code.)

This seems like the same thing as issue1747126 unless I'm missing
something.  It's adding the ability to read py and py$class files
through the classpath in addition to the filesystem, right? That's
something I've wanted for years, so I'm glad to see someone working on it.

As for the implementation in the patch, is there any reason it couldn't
work as a PEP 302 import path hook?  That's how I'd envisioned this
functionality implemented up until now.  Java class and package import
is handled by an import hook, JavaImporter, that keys off the
__classpath__ entry in sys.path.  I could see the same thing working for
this keying off something like __pyclasspath__ or some better name.  I
prefer that to modifying imp.java and Py.java as it goes through the
extension mechanism we already have.

As far as getting this patch or one along the lines I outlined accepted,
you should make sure to use spaces instead of tabs in your java code,
and this will definitely need some test cases to run as part of
regrtest. imp stuff is always fragile, so if we're not exercising it as
part of the build, it's bound to break.

Thanks for the comments. The primary difference between this and what
you describe is the necessity to use getResourceAsStream() in the applet
context. My patch doesn't actually change the behavior with regard to
__classpath__: that still works as usual (in that it will still be
searched for .class files but not .py files).

What I changed is the behavior of the importer when Jython is being
hosted by an applet. In such a case you want to be able to read .py and
py$class files from your *applet jar* rather than from the filesystem.
This allows you to distribute a complete, self-contained jar file for
the applet to use so that end users don't need anything installed on
their local machines (except, of course, a browser supporting Java applets).

In terms of PEP302, that does sound like a good model to consider.
However, there will have to be at least a minor change to imp.java to
support creating the input stream using getResourceAsStream rather than
using file I/O. Unfortunately, this is one area where applets really are
just different from and incompatible with their application
counterparts. Part of the patch I wrote just involves cutting and
pasting the loadFromSource method; that should ideally be refactored
anyway, to allow the caller to ask for the stream to come from the
applet rather than the file system.

The ultimate goal of all this is to allow Jython users to distribute the
same code as either an applet or application. That means that finding
.py files at run-time has to work in both contexts and -- in the applet
case -- without relying on particular files being on the end user's
local file system.

However, I will look into the PEP302 approach and see if that simplifies
things.

I implemented this as a PEP 302 hook in r5816 on trunk. It uses
getResourceAsStream on the classloader on sys or on the context class
loader if that one doesn't find anything. Instead of using a jar: prefix
to find things, it picks up on __pyclasspath__ entries in sys.path to
decide what level to import from in the classpath, like the
__classpath__ entry used by the Java importer. I think this should do
what you want and get your applets going, but I'd appreciate it if you'd
check.

By default __pyclasspath__ is added to sys.path, so .py and $py.class
files directly on the classpath will be loaded.  If you have them in a
Lib directory in your jar, you'll want to replace __pyclasspath__ with
__pyclasspath__/Lib.

This does address my need -- thanks! I was inspired by your work on this
to write my own Java PEP-302 importer, modeled after yours. I ran into
one minor issue: the loadBuiltins method of core.imp is private, so I
couldn't call it from my own importer. (What I was trying to do was
handle *all* the importing from my importer, including builtins, for
security reasons in the applet context.) Should I open an RFE issue for
this?