Re: [Jython-dev] Enhancement Applet ClassLoader

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

[Sells, Fred]

>I am using jython to customize the behavior of an applet written in Java.
>
>I am loading jython source from a URL and use that source to define 90% of
>the appearance of the applet.
>
>I decided to load the source (rather than go the jythonc route) because the
>file is much smaller and I have the pazazz (sp?) of being able to modify
>applet appearance on the fly.  The speed and capability is a big hit with
>management.
>
>I read several Jython files and .exec() them in the same instance of the
>Interpreter.  these files are jython source but the files the client edits
>hide that fact.  They contain no "class" or "def" statements, nor do they
>import anything.
>
>In order to make this work I had to grant permissions to the applet that It
>would not normally (default) need. 

Right, you will need to do that.

>Not a politically acceptable thing to do in today's world.
>
>I do not know the internals of Jython or Java  enough to know if there is a
>potential solution for a future release.  Things I would consider as a
>solution, include:
>     the ability to "exec()" without requiring a change to applet security
>     or
>     the abiltiy to execute conventional C-python (.pyc) byte-code in the
>Java environment.

The solution is to make an engine in jython which performs a traditional
interpretation of bytecodes. It could be .pyc byte-codes or it could be
a homebrew set of byte-codes. Running python fully interpreted would:

- be very slow. Obviously I don't know how slow, but I guess at least
  10 times slower than current execution.
- not allow any subclassing of java classes or interfaces. 

>The "big picture" reason to consider such a chage to the core product 

It will *never* be a change. It might be an *addition*.

>is
>that applets (and webstart) applications can then extend their features with
>jython; allowing the core product to be very generic in Java and the
>deployed implementation to be customized in Jython.

For application where the restrictions above isn't a problem, a fully
interpreted engine would be valuable. It is a big task to begin, so
please don't hold your breath.

>That's just my opinion, I could be wrong.

But you are not.

regards,
finn