|
 |
| Fri, May 16th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 09:16 PDT |
|
|
login « register « recover password « |
|
| [Article] | add comment | [Article] |
|
|
|
Scripting languages are ubiquitous. They are used everywhere: in log parsing, triggering applications, or performing volatile operations which require frequent changes in logic. Shell script was one of the most popular languages through the end of 1980s. Then came Perl, which revolutionized the world of scripting. Later in the day, we have Python and Ruby, both pretty popular. In an organization having primarily Java skills, is it worthwhile to have your developers learn these languages? Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly. It might not be, because it will be a costly affair, with the developers figuring out, "How will I achieve this particular functionality in XXX scripting language?" If there is one thing which the community lacks very badly in documentation, it is cross-language reference documentation. As a developer familiar with the Java language myself, I have often wondered, "Hey, this XXX functionality provided by Java -- how can I achieve it in Python?" For once, Google becomes useless! Why think beyond the shell?If you were living in 1980s, you probably need not have asked this question. These days, we have many scripting jobs that need to access databases, Web services, and content repositories, and, most obviously, parse XML documents. Just imagine parsing XML using sed! Well, we had one of our legacy applications doing exactly this. Suddenly, in the code you would see a call to Oracle's sqlplus, then parsing of XML using sed, then, for more complex parsing of XML, a call to a compiled Java program. It was terribly difficult to understand, and was subsequently redesigned using Groovy.Why not Perl, Python, or Ruby?Why dissipate organizational expertise to new languages? In all Java-based scripting languages, we can use Java classes within the script. What can be done in Java can be done here, too, and much more efficiently! For example, consider this XML snippet:
<buddies>
<buddy>
<name>Shanku Dada</name>
<email>dada@foo.org</email>
</buddy>
<buddy>
<name>Manivannan M</name>
<email>mani@foo.org</email>
</buddy>
</buddies>
To parse this in Java, you would be writing JDOM, DOM4J, SAX, or pure DOM code using JAXP APIs. But scripting languages, being poor cousins of serious languages, cannot afford so much time privilege in terms of organizational priorities. Take the example of Groovy to parse the above XML:
// friends.groovy
doc = new XmlSlurper().parse("friends.xml");
varBuddies = doc.children();
for ( buddy in varBuddies ) {
println("Name: " + buddy.name.text() + " | Email: " +
buddy.email.text());
}
The output:
Name: Shanku Dada | Email: dada@foo.org Name: Manivannan M | Email: mani@foo.org You see the simplicity in parsing XML using Groovy. You show this to the client. He asks you to display only the first name. You use your Java expertise to do the string manipulation:
println "Name: " + buddy.name.text().split(" ")[0] + " | Email: " +
buddy.email.text();
with the output:
Name: Shanku | Email: dada@foo.org Name: Manivannan | Email: mani@foo.org All the valuable investment made in learning Java can be fully utilized in scripting. All Java classes and objects can be accessed from the scripting language, with no need to learn another syntax. Java to script, and vice versaThe examples in this section will compile in Java 6 and above. Java 6 supports JSR 223 Scripting for the Java Platform. Another use case which scripting languages beautifully address is plugin architectures. Many times, applications need to be given plugin architecture for users to extend and customize. All modern text editors and IDEs follow this paradigm. If scripting language support is not provided by an application, extending it means compiling a plugin, packaging it as a Jar, and deploying it in a special directory from which it will be picked by the application. Scripting reduces the compile-and-package step, greatly reducing the development timeline. Generally, the application's plugin module loads/executes the plugins. In this case, the plugin module would need to instantiate some objects and make them available to the script engine, so that the contract between the application and the plugin script could be executed. Consider this Java code:
import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
// Actual code
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEngine se = sem.getEngineByExtension("js");
se.put("myvar", "Hello!");
// this throws javax.script.ScriptException, need to handle that:
se.eval("print(myvar);");
The output would be:
Hello! To dissect this: Java 6 comes bundled with a JavaScript scripting engine (based on Rhino). We get this engine initially in lines:
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEngine se = sem.getEngineByExtension("js");
Once we get the scripting engine, object
se.eval("print(myvar);");
We are calling the ScriptEngine's
print(myvar); , which prints the variable value set in the Java code, "Hello!". We have seen one angle to this plugin paradigm. The next is that Objects instantiated in the script need to be accessed in the Java code. This is also pretty simple:
se.eval("myvar = 'Hello from script!';");
System.out.println(se.get("myvar"));
The output:
Hello from script! Isn't that simple? Some things to consider when using Java-based scripting languages
Author's bio: Subhash Chandran is a Software Engineer at SpikeSource, where his responsibilities include creating various SpikeIgnited stacks. Before joining SpikeSource, he was with Sella Synergy India Ltd., a fully-owned subsidiary of Gruppo Banca Sella. There, he was working in the Java Competence Center and was reporting to Chandrasekar Muralidharan. The experiences discussed in this article are from his work with Muralidharan. T-Shirts and Fame! We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about. [Comments are disabled]
[»]
What, again, is the case? I agree that there are many good reasons for using scripting langauges
within the Java environment. Your Groovy example hints at some of these
reasons. I'd point out the superior enterprise resource management of
JRuby over standard (C) Ruby as another.
[»]
Abuse >is it worthwhile to have your developers learn
[»]
Re: Abuse
[»]
Ugh. Language Chauvinism Why is it that Java programmers (unlike seemingly any other language programmers) want everything to be written in Java?? I so miss the days when people would use whatever language best fit the task at hand. Here's an example of the chauvinism from the ant.apache.org page: 'Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times.' You have to be kidding me! I've had far worse problems writing valid XML than I ever had with Makefiles! Besides, this entire line of argument seems utterly stupid to me. Almost as much as if someone were to complain about 'Java is inherently evil as well. Anybody who has worked on them for any time has run into the dreaded missing paren problem. "Is my program not compiling because I'm missing a paren???"' Syntax is Syntax. Ass. Only a java programmer would ask this question: "Why dissipate organizational expertise to new languages?" Each language has it's pros and cons. Perl might be great for text processing. Ruby's rails might have benefit for some small apps. Why not just use a variety of languages to fit whatever task is at hand? Is it actually painful for Java programmers to know other languages? Unfortunately, I think the answer is that Yes, it probably is, because Java seems designed to be anti-social in that regard. To get perl to talk to the OS (and by extension other programs) is easy. Ditto for C (and by extension C++). But, Java perversely makes talking to any other apps horrendously painful, and perhaps this breeds the attitude of Java programmers. On the side of tasks I like java for, are parsers (I like Jflex/CUP better than lex/yacc, for instance, since I can have multiple parser/lexers within the same program in an easier way than I could with lex/yacc) And, I'm starting to warm to hibernate. But, I wish we would go back to the days when programmers had multiple language expertise. I see too many programmers these days who A. have no idea about other languages, and B. because of their ignorance cast stones at other languages with arguments of this kind: "Perl. Ugh. I hate all those $" That's just brilliant.
[»]
Re: Ugh. Language Chauvinism
[»]
Re: Ugh. Language Chauvinism
|
|
