Build your own scripting language for Java

JavaWorld has An introduction to JSR 223 for those that want to roll their own and target the JVM:

The upcoming Java Standard Edition 6.0 release will include an implementation of Java Specification Request 223, Scripting for the Java Platform. This JSR is about programming languages and their integration with Java. This article demonstrates the power and potential of JSR 223 through the implementation of a simple Boolean language.

Past LtU references to JSR 223: The original announcement in Sun, Zend push scripting for Java and a brief mention in the thread on Embedded Languages in Java.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

well

I for one welcome our new scripting platform overlords. :P

Lame slashdot joke aside, it seems to fulfill scripting languages goal of being a glue language for native apps in a platform, except the platform is itself a portable one.

Scripting languages for the past couple of years have grown out of their niche platforms to become platforms themselves, complete with portable libs and frameworks. Perl, Python and Ruby are all like these, while Tcl and Lua still mostly retain their origins as lightweight embeddable languages. Is this trend over and now will see much more focus with a base platform again, this time with Java and .Net rather than Unix?

The 2nd law of PL Dynamics

"The entropy of any Programming Language not at equilibrium will tend to increase over time, approaching the mass of a fully blown Operating System."

until

"...until gravity causes it to become a black hole and fall under the weight of its own mass onto itself"

swan song for java? ;)

And all languages ultimately evolve into

Lisp. I mean really, how does this "new" capability differ from what Lisp provides? :-) ()

Um....

So you're saying "mere programmers" aren't capable of using any other language besides Java? That's a really sad statement on the state of things. :-)

What does this actually do?

I can't figure out what JSR 223 actually offers to make scripting easier. All I see is a standard interface for scripting engines, and a complicated 'discover' mechanism so things appear flexible.

What it does

JSR 223 is based on the Bean Scripting Framework (BSF), which was originated by IBM around 1999 and subsequently donated to the Apache Foundation. Quite a few language implementations have BSF support, including Jython and JPython, Jacl, Groovy, BeanShell, Javascript (via Rhino), JRuby, and NetRexx.

So if you have an application that you want to make scriptable, by implementing support for JSR 223 in that application, you make it possible for any compliant scripting language to be plugged in, without having to modify your application especially for the language in question.

This has obvious implications for tools such as editors - some editors already provide BSF support. Another place where it could have an impact is on JSP engines. The JSP spec has long allowed for languages other than Java to be used in JSP pages, and some JSP engines have exploited this feature to support languages such as Javascript. However, the availability of languages other than Java across different JSP engines has been quite limited. With JSR 223 being a standard part of J2SE 6, it seems likely that it will become standard for a JSP engine to allow you to write JSP pages that use languages that the vendor didn't explicitly build in support for.

What apps use it, though?

I can see the purported advantages for a language implementation (run in more places!), but when the chips are down... if you're doing an application, wouldn't you want to see just one or two languages used to script it, so that you get some network effects going in terms of users sharing scripts, advice, techniques, etc...? Additionally, support requests might be more troublesome if they came from end users using any number of languages.

Old fallacy

If we have learned anything from open systems, it's that interoperability is great for users even if they don't need or want to interoperate. Interoperability lowers vendor costs, increases vendor competition, increases sizes of user communities, increases availability of add-on products, increases availability of training, decreases costs of recruiting skilled assistance, and generally rocks.

As for support, I don't see it. Just document your DOM, and advertise that users can plug in any scripting language they want. If you ship with one standard scripting language engine, and a bunch of example scripts, you'll find that the vast majority of users will script in that language, and that the few who don't will blame any problems they have on the script language engine they installed themselves. You are allowed to assume a certain level of technological maturity from anyone doing scripting, and a higher level from those who install their own engines for unusual languages. For more restricted applications, just advertise that you only support one particular engine that you've tested against. You still get the cost benefits from interoperability, even if you prohibit your users from using it.

Additionally, I can absolutely see end-users using one scripting language for their day-to-day uses, while the product developers themselves use something different for scripting functional tests (a common internal use case for scripting).

What apps use it

I agree with everything Dave Griffith wrote, but to answer the specific question: the motivating example for this JSR was web application servers, where it's to a vendor's benefit to provide language choice to users, and many users want it. Also, app servers like Websphere and JBoss support BSF in their JMX management systems, so that server configuration and management is scriptable, which is a use case that extends well beyond app servers, to build tools, test tools, configuration tools, and management tools in general. Editors like Eclipse and JEdit have also had to face the issue of interfacing to scripts in other languages, but don't yet do so in a standard way.

But the potential uses are far broader than any of these examples - the idea is to provide a standard way to integrate scripting into programs that run on the Java platform.

The important network effects in this case are not at the level of an individual application and its users. Without a standard interface to other languages, an application's only choice is ad-hoc integration of the language(s) it chooses. This means that scripting across Java-based applications is inconsistent - not only in the languages available, but in how those languages provide access to Java objects, and in how applications call out to scripts.

There are two obvious ways to address that: one is to standardize on a single scripting language for Java, and the other is to standardize the interface between Java and scripting languages. The former is clearly problematic. JSR 223 does the latter. Its existence doesn't force anything on applications, but it does mean that if an applications chooses to integrate even just a single scripting language, that the interface between that language and Java will follow a standard. Whether an application chooses to go beyond that depends on the application - in some cases, it'll be a no-brainer, and in others, it might be considered too flexible for whatever reason.

RE: What apps use it, though?

My company's product is targeted at network admins, so we use BSF (and perl's inline java) to allow for perl scripting. The target user is much more likely to have experience with perl than other languages.

Another article

The Mustang Meets the Rhino: Scripting in Java 6, which gives more on the end-user side.