JavaWorld.com has an article by Chaur Wu entitled "Build your own scripting language for Java," which shows "how to program to the Scripting API, how to package and deploy a language implementation in accordance with the script engine discovery mechanism, and how to make your script engine compilable as well as invocable the JSR 223 way."
- Posted by: Joseph Ottinger
- Posted on: April 25 2006 12:36 EDT
The article implements a "BoolScript" language - a language that evaluates boolean expressions - as a JSR-223 scripting language, including the autodiscovery mechanism. BoolScript doesn't have any means by which to assign values to variables, which offers Mr. Wu the chance to show how Java code can put things into a scripting context.
He also shows how to make the BoolScript compileable - by translating it into Java code and then compiling it into bytecode.
While he doesn't show external bindings to languages like Ruby or Perl, Mr. Wu is showing the basics of using JSR-223 to bind external languages to the Java runtime, which offers Java the chance to be somewhat of a "glue language" itself, an odd reversal considering that most of the scripting languages are characterized as "glue languages" themselves.
- Build your own scripting language for Java by Race Condition on April 25 2006 16:04 EDT
- Isn't it at JavaWorld.com? by Trustin Heuiseung Lee on April 25 2006 19:15 EDT
- JSR 223 and Patriots by Frank Cohen on April 25 2006 23:42 EDT
- What a great idea by Ethan Allen on April 26 2006 13:56 EDT
Build your own scripting language for Java
I'll get right on that.
FYI: I'm hosting a Birds-Of-A-Feather session on Dynamic Scripting languages at JavaOne.
Session Id: BOF-0554
Session Title: Dynamic Scripting Languages BOF
Track: Core Platform
Room: Hall E 133
Start Time: 22:30
At the Dynamic Scripting BOF-0554 you will hear the latest updates on Jython, Groovy, Ruby, BeanShell and the new JSR 292 efforts to make scripting on Java easier, more available, and fun. Representatives from the dynamic scripting language projects will give you the latest news and answer your questions.
Chaur Wu's article on Java SE 6 beta's implementation of JSR 223 is well written. I understand 223 in technical terms now from the article.
I do not agree with the article's assumption that JSR 223 is a good thing. For example the article says...
"Creating a script engine directly might be okay for testing a script engine, but for a real usage scenario, it violates the principle that a client Java program should always interact with a script engine indirectly via a JSR 223 framework."
This reminds me of the rhetoric in late 2003 that the time to argue over the US invasion of Iraq was over and that every patriot should fall in line with the decision. I didn't agree with JSR 223 when it was started.
And I still think it is a poor idea.
On the otherhand, dynamic scripting on the JVM is an excellent idea. Dynamic scripting languages compile into Java Byte Code so they help the Java platform overall. They bring people into the Java camp. They provide needed alternatives to Object Oriented programming. And in some cases they bring scalability and performance solutions that are just not available to developers working with Java objects.
I also like Jython compiler but I would love to have it supporting Jython modules. I mean, to compile my Jython classes into plain Java classes I need to follow the Java convention of having one public class per source file.
Instead, I wish jythonc could extract classes from a Jython module and then create a file for each class within the module when transforming it into Java source.
Beside being closer to Python style of organizing source files, this would also keep me free from the Java way of change-compile-test/run and keeping with the Python way of change-test/run more agile process.
For a while I have been worried about too much standardization of languages. I mean, if everyone uses a standard language, it makes it easy for competitors to learn that language and that is bad - right ? Software should be as obscure as possible, ideally created on a purely personal basis so that only the creator understands what is happening.
This feature makes that dream possible. Each of us can now create a multitude of purely personal scripting languages. Talk about job security !
I'm sorry - I can't go on. It's just - so beautiful.
For a while I have been worried about too much standardization of languages. I mean, if everyone uses a standard language, it makes it easy for competitors to learn that language and that is bad - right ? Software should be as obscure as possible, ideally created on a purely personal basis so that only the creator understands what is happening.This feature makes that dream possible. Each of us can now create a multitude of purely personal scripting languages. Talk about job security !I'm sorry - I can't go on. It's just - so beautiful.
<LOL>!!! Don't reinvent the wheel - reinvent the language!
So I guess you wouldn't want to hear the oppinions of those in the Domain Specific Language camp? :-)