From: Guido van Rossum <guido@py...> - 2003-06-12 14:00:00
A journalist reporting on JavaOne pointed me to the following Java
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/)
From: Frank Cohen <fcohen@pu...> - 2003-06-16 20:27:17
Hi Guido: It's an honor to write to you. Python is an excellent piece
of work. Thank you for Python.
I am using Jython embedded in my TestMaker open-source project as a
utility and framework for building intelligent test agents to check
Web-enabled applications for scalability, performance and
functionality. I am trying to convince developers, QA technicians and
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 a
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. While
there may be times when a native interface is useful, I would never
like to include a native interface in my production-ready code. It's
asking for problems, including:
1) Weak exception handling. If my scripting language interpreter runs
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 engineers
there are with production JNI experience.
In my view, JSR 223 should be restarted. I believe Jython's use of Java
byte codes is a much better design.
Jython compiles Python scripts into Java byte codes. The Python script
in Jython is 100% Java and runs as native Java code through the VM.
Imagine if JSR 223 standardized the way script languages compiled
scripts into Java byte-codes. You could have PHP, Python, Ruby, and
anything else... and they would all be 100% Java.
Support for Java byte-codes is important in the middleware space, where
J2EE and .NET are battling it out for developer mindshare and support.
Microsoft has done an excellent job at building its CLR virtual machine
to support multiple object-oriented languages. The Java platform would
be so much better with multiple language support... all running on the
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
Come to PushToTest for free open-source test automation solutions that
test and monitor
Web-enabled applications, especially Web Services for scalability and