Lambda the Ultimate

"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 gravity causes it to become a black hole and fall under the weight of its own mass onto itself"

swan song for java? ;)

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. :-)

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.

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.

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).

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.