From: Sean M. <sea...@pr...> - 2003-06-14 07:36:50
|
[Guido van Rossum] >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 i>nterested in pursueing this? Absolutely. I think an excellent opportunity has befallen us with this. I have been putting stuff on my blog about this since I heard that a Jython meme was spotted weaving through Java One. regards, Sean http://seanmcgrath.blogspot.com |
From: Michael G. <Mike.Grogan@Sun.COM> - 2003-06-17 00:53:15
|
Hi There is a misunderstanding of what the JSR proposes here. See the draft at http://www.jcp.org/en/jsr/detail?id=223. 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. //mike ----- Original Message ----- From: Frank Cohen <fc...@pu...> 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 > 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. > > > |
From: Frank C. <fc...@pu...> - 2003-06-17 13:23:36
|
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 interpreter? 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. -Frank On Monday, June 16, 2003, at 05:52 PM, Michael Grogan wrote: > Hi > > There is a misunderstanding of what the JSR proposes here. See the > draft at > > http://www.jcp.org/en/jsr/detail?id=223. > > 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. > > //mike > > > ----- Original Message ----- > From: Frank Cohen <fc...@pu...> > 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 >> 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. >> >> >> > > -- 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. |
From: Michel P. <mi...@di...> - 2003-06-17 19:57:45
|
On Tuesday 17 June 2003 08:23, Frank Cohen wrote: > Hi Mike: On your suggestion I read JSR 223 again > (http://www.jcp.org/en/jsr/detail?id=3D223). I have the same concerns a= s > 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? As I read it, not necessarily. The draft proposes an API be created that= =20 *may* be used through JNI, or may not. Jython could significantly drive = this=20 API enough to possibly remove or simplify some parts of the Jython core c= ode;=20 or at least remove any magic to be replaced with a standard API. > How do you see the call being made from Java to the script language > interpreter? Using the proposed standard API, whether through JNI or not. > What I would rather see is a JSR that standardizes the use of Java byte > codes in scripting languages. While a noble effort and definately something worth exploring, this=20 unreasonable to ask of many scripting languages. A bridge through JNI is= =20 perfectly reasonable for *most* (including CPython). > By doing so, the script languages (PHP, > Perl, and all the others) would have a standard way to run as 100% Java > applications granted a great benefit of Jython > and have access to any Java object on the classpath. Does the JSR propose that any object on the classpath will not be availab= le? > This > would be a powerful and reliable way to use my existing Java-based > infrastructure and would promote the Java platform. Agreed that Jython is superior integration to a JNI bridge; but I think t= his=20 JSR is very reasonable and necessary. It does not seem invalidate any 10= 0%=20 Java scripting solutions or push them aside for a different purpose and c= ould=20 propose an API that is very useful to us. -Michel |
From: Anthony E. <ae...@si...> - 2003-06-17 20:23:37
|
Call me crazy but isn't JSR 223 the same thing as what the Bean Scripting Framework ( http://jakarta.apache.org/bsf ) does already? Additionally, why such strong ties to the Servlet API? Or is that what differentiates 223 from BSF, the fact that it is tied to the servlet API? Sincerely, Anthony Eden |
From: Don C. <dco...@ch...> - 2003-06-18 02:29:59
|
I think the difference between Bean Scripting Framework and JSR-223 is that JSR-223 wants to support non-java based scripting languages like PHP and Perl. I don't think BSF can do that. On Tue, 2003-06-17 at 16:23, Anthony Eden wrote: > Call me crazy but isn't JSR 223 the same thing as what the Bean > Scripting Framework ( http://jakarta.apache.org/bsf ) does already? > Additionally, why such strong ties to the Servlet API? Or is that what > differentiates 223 from BSF, the fact that it is tied to the servlet API? > > Sincerely, > Anthony Eden > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users |
From: Samuele P. <ped...@bl...> - 2003-06-17 21:58:26
|
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. |
From: Michel P. <mi...@di...> - 2003-06-18 00:20:50
|
I've read: http://www.jcp.org/en/jsr/detail?id=3D223 and would like to provide my opinion on the document from a Java and Pyth= on=20 programmers perspective. For background to those unfamiliar with Python/Jython: Python is a high-level, object-oriented scripting language whose interpre= ter=20 and many core modules are written in C. From the perspetive of JSR 223, = it=20 is very much like any other scripting language like PHP or Perl. Jython is an implementation of the Python language written in 100% Java. = =20 Jython compiles Python code directly into Java bytecode .class files that= are=20 indestinguishable to the JVM from .java compiled files. For distinction,= =20 Jython programmers call the Python implementation written in C "CPython".= =20 JSR 223 does not really specify much about scripting languages implemente= d in=20 Java itself. Both CPython and Jython can benefit from something like JSR 223, but I th= ink=20 the scope of the JSR is too narrow and slightly off target. The JSR focuses on web scripting, but this leaves out a huge amount of=20 scripting language use cases. Scripting languages are not just about web= =20 pages. Much more often they are used as "rapid" application development=20 languages, "simple" configuration files, high level application glue, a = tool=20 for users to extend any kind of program, a tool for users to automate cer= tain=20 common tasks ("macro" uses) and many others. The thought and effort that goes into this JSR will need to be duplicated= ,=20 bacwarded against, or replaced by something new when the Java developers=20 realize (and they *will* realize) that they need a general, non-web speci= fic,=20 standard API for other languages to BOTH interface the Java runtime (like= =20 CPython or Perl) and be implemented entirely in Java (like Jython). I'm sure I'm repeating something you've heard over and over, because if y= ou do=20 a Google search for JSR 223, you will not find a link to the document on = the=20 first page. You will instead get links to many different discussion boar= ds=20 and sites of various open source scripting languages; and almost all mess= ages=20 and articles on the subject say close to the same thing: JSR 223 is too w= eb=20 specific and ignores some very real issues of scripting language and Java= =20 integration; and I agree. But JSR 223 can easily broaden its scope to include all genearl scripting= use=20 cases. It could also easily focus on a standard, core API for languages = to=20 access all Java services, not just servlets through a narrow interface. = It's=20 a step in the right direction but it's timid step in my opinion and needs= to=20 go farther. Thanks for your time, -Michel |
From: Dennis <mai...@ya...> - 2003-06-19 13:00:37
|
Can anyone tell me who leads in performance for string manipulations, Jython or PERL??? I have to call scripts thru Java, a Jython script can be called directly but PERL script can be called thru some JNI interfacing. Does anyone have idea which way to go??? Thanks Dennis __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |