From: Guido v. R. <gu...@py...> - 2003-06-12 14:00:00
|
A journalist reporting on JavaOne pointed me to the following Java standardization effort: http://www.jcp.org/en/jsr/detail?id=223 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 C. <fc...@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 Java VM. -Frank Cohen http://www.pushtotest.com/ptt 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: > > http://www.jcp.org/en/jsr/detail?id=223 > > 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: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > > -- Frank Cohen, Founder, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Come to PushToTest for free open-source test automation solutions that test and monitor Web-enabled applications, especially Web Services for scalability and reliability. |