|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
How to choose a Java scripting language
If you are considering hooking a scripting interpreter into your Java application, the hardest part is choosing which one to use. David Kearns describes some of the issues that come with supporting a scripting language in your Java application and compares Groovy, JudoScript, Pnuts, JRuby, Jacl, Jython, Rhino, and BeanShell in a variety of ways to help you make the right choice.
Read Choosing a Java Scripting language.
In related news, on February 10th, JSR 223: Scripting for the Java Platform Released a Public Draft. The JSR is concerned with how to write and package Java classes that will be accessible from different scripting engines, which should make the integration effort easier.
|
|
|
Message #161554
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
parsing/compilation times
The Groovy times include the parsing/compilation overhead, which can be optimized away for scripts that are rerun often.
|
|
|
Message #161579
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
steady state performance
The tests also do not reflect the performance characteristics of the bytecode based scripting languages, which can take advantage of the JIT and hotspot compilation available in the JVM. If Groovy and BeanShell compile into reasonable bytecode that is anywhere close to javac, I don't see why the steady state performance of these languages would not be equivalent to Java code, when parsing/compilation time is factored out.
|
|
|
Message #161594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jelly
We tried to use Jelly as the template engine for a webapp 2 years ago. The component architecture for defining new tags was simplier than JSP tags, that's the primiary reason we want to try it.
Sadly, we had to move away from Jelly after a while because it had a very bad memory leak problem when parsing scripts. It seems the problem has been fixed now, but we are not going to move back to Jelly because we are now happy Tapestry users.
|
|
|
Message #161598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How to choose a Java scripting language
Nice article!!! Great job by the author.
Looks like pNuts is very nice, I downloaded their docs.zip based on this write up.
.V
|
|
|
Message #161603
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Excellent article, wonder if Sun gets it
I wish this article existed some years ago when I was looking at Jython as an embedded script interpreter for my Web test tool. The article covers the important parts of an architect's decision points. It wasn't mentioned in the article but it's worth pointing out that these Java Byte Code based languages are very stable. I've had a Jython test script monitoring a Web site for 6 months or longer without fail.
Now for my gripe: Why doesn't Sun get the benefits of multiple languages running on the JVM? It's a clear way to even the playing field with .NET, and it helps attract the attention of all those PHP and Perl scripters.
Tim Bray at Sun has been trying for the past year to get Sun to at least endorse the idea of dynamic scripting languages on Java. But he's getting little support.
And then there's the inevitable disappointments on dynamic scripting from Sun. For example:
Dear Frank Cohen,
Sun Microsystems, Inc. and the JavaOne(sm) Conference Content Team are grateful for your proposal to present at the 2005 JavaOne conference. The high quality of submissions made the selection process extremely difficult. We regret to inform you that we will be unable to accept your proposal entitled ' Dynamic scripting languages BOF (Jython, Groovy, Perl, and many more) '.
Thank you very much for your submission. We appreciate your continued support of the JavaOne conference.
Sincerely,
JavaOne Conference Content Tea
Oh well.
-Frank Cohen
http://www.pushtotest.com
|
|
|
Message #161673
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why no Jython update??
Well, the entire Java world combined with the entire Python world of 2-3 years ago. I'll be much more excited when I see Jython updated to the current Python version.
|
|
|
Message #161686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Worthless article
There are several things I could mention but I'll just point out the most glaring one:
you can not learn anything about the performance of a language by using micro benchmarks!!!
Do we need to keep providing links to this excellent IBM article that explains why?
http://www-128.ibm.com/developerworks/java/library/j-jtp02225.html
This article is about Java but reading you'll understand it applies to other languages as well.
Knowing how to make and read graphs seems to be difficult as well because with cummulative measurements it's impossible to see if there's only one benchmark that makes up for 99% of the time taken while the others might be blindingly fast.
The article also says "Rhino, Pnuts, and Jython were consistently the fastest, followed closely by Groovy, then JudoScript". What? Groovy is almost 3 times as slow as Rhino! And Judoscript is even 7 times slower! How on earth can this be "closely followed"?
|
|
|
Message #161692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jython 2.1 works for me
I've heard this complaint about Jython not being up-to-date enough for some developers. From my experience, most of Python's advancements over the past 2 years have been to add libraries that wrap-around the core language. I haven't seen the core Python language change in a long while. Many of Python 2.2, 2.3, and 2.4's changes are extensions to make it easy to use Python to manipulate XML, to implement Web services, to implement collections support, and to work with Windows. As a Java developer none of these interests me because anything that's on the classpath is available to my Jython scripts as an object. And I mean everything, all of the J2SE, J2EE and J2ME objects. So I can use the JAX pack for XML, Apache Axis for Web Servivces, real Java collections, and JNI if I need to deal with Windows. I'm happy with Jython 2.1.
-Frank
|
|
|
Message #161718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No mention of BSF and JSR-223?
How you can write an article on Java scripting without mentioning either BSF or JSR-223, both of which make the choice of scripting language somewhat moot, is beyond me.
|
|
|
Message #161790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes Sun Gets It - announcing Coyote
Now for my gripe: Why doesn't Sun get the benefits of multiple languages running on the JVM?
Funny you should ask. See what I just wrote on my blog.
Tim Bray at Sun has been trying for the past year to get Sun to at least endorse the idea of dynamic scripting languages on Java. But he's getting little support.
Again, funny you should mention that, have you seen what Tim wrote today (no, not the 'boring' thing)? I don't think he would agree with you.
I'm sorry your session wasn't accepted, neither was mine. It has nothing to do with not liking scripting languages though. It would be great to have your help with Coyote ...
S.
|
|
|
Message #161812
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR 223 should be stopped
Here's my blog on JSR 223 from last year. -Frank
Sun is promoting a new openness to support scripting languages in the Java platform. See details at http://www.jcp.org/en/jsr/detail?id=223 .
Frank Cohen recently wrote an open-letter to the Jython community urging Sun to rewrite JSR 223.
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
|
|
|
Message #161817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Coyote news - excellent
Thanks for pointing me to Tim's blog on the news that Coyote - a Groovy and Jython module for NetBeans - is available. I'm downloading it now.
-Frank
|
|
|
Message #161835
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Read it
I read the article. I wrote a similar set of article covering Jython (JPython at the time), BeanShell, Rhino, and NetRexx for the JDJ. Pnuts was mentioned but not highlighted.
The piece that is really missing is the tool support (code completion, debugging, integration as Java classes). I understand that Coyote provides tools support, but it does it on the NetBeans IDE platform.
Nearly all of my clients are using (in order): Eclipse (80%), IBM WSAD (Rational Rad) (10%), IntelliJ (5%), and then Borland (2%). I used NetBean before I started using Eclipse, and I liked it.
There is an Eclipse plugin for Jython, and a Eclipse plugin for Groovy.
Excerpt from my blog on Dion talk about Groovy....
Dion felt JSR-241 should not exist because Groovy is still rapidly evolving. I agree to a point. Dion also felt that debugging Groovy was hell. Dion also felt that for some tasks Java does not make as much sense as a higher level language like Groovy.
There are some benefits of Ruby over Java, but Groovy and Ruby seem to be on par for language features.
"When will I use Groovy? I will use Groovy when my IDE provides good support for Groovy. I want code completion, break points, refactoring, and easy integration with the rest of my Java classes. Then I will use Groovy. I am assuming of course that Groovy matures and can be used in production applications."
http://www.jroller.com/page/RickHigh/20050315#is_the_groovy_language_groovy
"Dion had an intersting idea. I think it was Dion. Why doesn't IBM, Sun or Oracle hire James Strachan and let him work on Groovy full time?
It looks like the Java platform is winning the war against the .Net onslaught. Groovy could help beat back the M$ hordes even further. Groovy needs some full time love and affection to help it mature and grow."
If Groovy lives up to its promise, I think I would prefer it to Jython. Dion did an excellent job promoting Groovy. It got me interested again.
|
|
|
Message #161837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
More to it than that
Actually, I think Python changed quite a bit. It is my understandign that they added block closures and continuation to Python to compete with Ruby. Thus, Jython does not have this language support.
This seems like a pretty major change to the core. I hope this is something that gets added to Jython.
It looks like Groovy has this support already. This makes Groovy very Rubyesque.
The more I learn about Groovy... the more I hope it takes off.
Disclaimer: It has been a while since I followed Python closely. I am not a Ruby expert.
Here are some thoughts and comparisons of Jython and Groovy:
http://www.jroller.com/page/RickHigh/20050315#is_the_groovy_language_groovy
|
|
|
Message #161838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jelly Blues
I had to use Jelly on one project. I wrote some closed-source Maven plugins.
I tried to avoid Jelly as much as possible, and put most of my code into the Jelly tag object (written in Java).
Jelly seemed a bit unpleasant to me. (It just never seemed quite baked.)
Also, I heard that Maven 2.0 rewrote most of the plugins in BeanShell. A lot of the plugins were written in Jelly.
|
|
|
Message #161839
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Vic Pnuts
Vic,
I read the article as well. Nothing in the article seemed to make Pnuts all that interesting to me.
What in the article made Pnuts so appealing to you?
Did I miss something? Care to share?
.R
|
|
|
Message #161864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
steady state performance of compiled scripts
If Groovy and BeanShell compile into reasonable bytecode that is anywhere close to javac, I don't see why the steady state performance of these languages would not be equivalent to Java code, when parsing/compilation time is factored out.
Ben,
I can't speak for groovy or beanshell, but I know that the compile-to-bytecode option for jython generates a class file that requires the jython interpreter classes in order to run. So it optimises away the overhead of parsing the script text, but every variable in the script is still wrapped as a PyObject, so performance and footprint will still be slower.
Take a simple example in python (the exact details may be inaccurate here, as I'm writing off the top of my head, but the general principles are true)
a=b+c
Jython will create three PyObjects for a,b, c and then evaluate a by calling the _add_() method (I think I've got that name right) of b with c as an argument. _add_() will figure out that c is wrapping an integer, and then call the inbuilt add operator of the VM.
In java, compiling the code
int a=b+c
will cut straight to the inbuilt add operator without faffing about with PyObjects or anything else.
Needless to say, your performance will benefit. The trade-off is the longer development cycle if using java rather than jython or similar.
Implementing the type of compilation that jython does support is relatively straightforward, because it reuses the existing interpreter workflow, but spits the bytecode out to a .class file instead of into the JVM. Implementing a compiler that strips out the PyObjects (or equivalent in any other scripting engine) would require a lot of new code, and a lot of effort!
Dave
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
