[jdom-interest] Re: [Jython-users] Scripting Pages in Java Web Applications

[Samuele Pedroni]

At 14:56 17.06.2003 -0500, Michel Pelletier wrote:
>As I read it, not necessarily.  The draft proposes an API be created that
>*may* be used through JNI, or may not.  Jython could significantly drive this
>API enough to possibly remove or simplify some parts of the Jython core code;
>or at least remove any magic to be replaced with a standard API.

like a standard way to dynamically dispatch on a set of overloaded method 
signatures
while considering programmatically defined language specifics conversions 
with their precedence and method overriding, like in:

public class A {

   public void method(String[] s) {
     System.out.println("strings");

   }

   public void method(boolean b) {
     System.out.println("boolean");
   }

}

Jython 2.1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
 >>> import A
 >>> a=A()
 >>> a.method(["a"])
strings
 >>> a.method(0)
boolean
 >>> ^Z

I could go on with things needed to remove "magic". <wink>

At 17:52 16.06.2003 -0700, Michael Grogan wrote:
>The focus of the JSR is on web scripting.  A major goal is to allow 
>developers to bundle script pages in Java Web applications and provide a 
>mechanism for those pages to access the standard Java web abstractions 
>(request, response, context etc.) in a way that is consistent with the way 
>they are accessed from Servlets and JSPs.

but it seems that the JSR has a narrower scope.

At a minimum it seems it needs a way to startup and run in parallel to the 
JVM the (C) execution engine of a scripting language.

Then there's the need for communication between the two, likely in terms of 
proxied Java objects, maybe out of a limited set of classes or through some 
general proxying approach.

Generally proxying Java objects for a dynamically typed language (as the 
above shows), is not completely trival both technically and from a language 
design decisions POV.

[Aside Jython allows also to subclass Java classes on the fly at runtime,

related to that one nice-to-have Java platform feature would be the ability 
to dynamically load bytecode from memory even under security restrictions. 
Now Classloader creation is a privileged operation... but discussing this - 
I fear - is also outside the scope of the JSR]

regards.