Hi Mike: On your suggestion I read JSR 223 again
(http://www.jcp.org/en/jsr/detail?id=223). I have the same concerns as
when I wrote my email yesterday. Maybe I am misunderstanding 223 and I
would appreciate your clarification.
I read 223 to say that there will be a standard way from a servlet
container to run a script. For example, if I am using Tomcat I will be
able to bundle a PHP script into the WAR file, and when the deployed
servlet is called, then Tomcat will execute the PHP script by calling
the PHP interpreter running outside of the Java VM. Is this correct?
How do you see the call being made from Java to the script language
What I would rather see is a JSR that standardizes the use of Java byte
codes in scripting languages. By doing so, the script languages (PHP,
Perl, and all the others) would have a standard way to run as 100% Java
applications and have access to any Java object on the classpath. This
would be a powerful and reliable way to use my existing Java-based
infrastructure and would promote the Java platform.
On Monday, June 16, 2003, at 05:52 PM, Michael Grogan wrote:
> There is a misunderstanding of what the JSR proposes here. See the
> draft at
> The goal of the JSR is to provide a consistent and standard mechanism
> for scripting languages to use to access functionality implemented in
> Java. As the JSR points out, the way that Java objects are
> represented and accessed from a particular scripting language has to
> be specific to that language. A mechanism that required a scripting
> language implemented in Java to access other Java objects using JNI
> wouldn't make sense. The JSR doesn't propose that.
> 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.
> Python/Jython is definitely one of the scripting languages we hope
> will benefit from the JSR. We welcome your input.
> ----- Original Message -----
> From: Frank Cohen <fcohen@...>
> Date: Monday, June 16, 2003 1:27 pm
> Subject: Re: [Jython-users] Scripting Pages in Java Web Applications
>> Hi Guido: It's an honor to write to you. Python is an excellent
>> of work. Thank you for Python.
>> I am using Jython embedded in my TestMaker open-source project as
>> utility and framework for building intelligent test agents to
>> Web-enabled applications for scalability, performance and
>> functionality. I am trying to convince developers, QA technicians
>> IT managers that Python is their lingua-franca to build better
>> software. Details are at http://www.pushtotest.com/ptt.
>> In my opinion JSR 223 is not worthy of support. JSR 223 implements
>> very un-Java like way to bridge Java objects to script language
>> functions. 223 aims to provide a native interface to make calls
>> from a
>> Java object to a limited number of common scripting functions.
>> there may be times when a native interface is useful, I would
>> like to include a native interface in my production-ready code.
>> asking for problems, including:
>> 1) Weak exception handling. If my scripting language interpreter
>> externally to the Java VM then how do I handle recovering from an
>> exception in the interpreter?
>> 2) Slower performance. Native interfaces take processing time and
>> memory to make a call to an external function.
>> 3) Fewer expert resources to help me code. Look at how few
>> there are with production JNI experience.
>> In my view, JSR 223 should be restarted. I believe Jython's use of
>> byte codes is a much better design.
>> Jython compiles Python scripts into Java byte codes. The Python
>> in Jython is 100% Java and runs as native Java code through the
>> Imagine if JSR 223 standardized the way script languages compiled
>> scripts into Java byte-codes. You could have PHP, Python, Ruby,
>> anything else... and they would all be 100% Java.
>> Support for Java byte-codes is important in the middleware space,
>> J2EE and .NET are battling it out for developer mindshare and
>> Microsoft has done an excellent job at building its CLR virtual
>> to support multiple object-oriented languages. The Java platform
>> be so much better with multiple language support... all running on
>> Java VM.
>> -Frank Cohen
>> TestMaker 4.0 now shipping
>> On Thursday, June 12, 2003, at 06:59 AM, Guido van Rossum wrote:
>>> A journalist reporting on JavaOne pointed me to the following Java
>>> standardization effort:
>>> AFAICT (after reading the first two sentences) this is an
>> attempt to
>>> open up room for scripting languages in J2EE environments. Anyone
>>> interested in pursueing this?
>>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>> This SF.NET email is sponsored by: eBay
>>> Great deals on office technology -- on eBay now! Click here:
>>> Jython-users mailing list
>> Frank Cohen, Founder, PushToTest, http://www.PushToTest.com,
>> phone: 408
>> 374 7426
>> Come to PushToTest for free open-source test automation solutions
>> test and monitor
>> Web-enabled applications, especially Web Services for scalability
Frank Cohen, Founder, PushToTest, http://www.PushToTest.com, phone: 408
Come to PushToTest for free open-source test automation solutions that
test and monitor
Web-enabled applications, especially Web Services for scalability and