Those two JSR seem now to be in conflict. Even if the scope of the JSR 223 seems broader in scope, it is initially just a launch pad for PHP 5 into the world of enterprise applications, whereas the JSR 241 has the honnesty to be "just Groovy". The JSR 223 has not evolved much since June 2003, at least from an outsider point of view: maybe it's just a dead end. Let's wait some more months to see where all this lead us to.
JSR 223: silent renaming
mercredi 17 novembre 2004. Lien permanent Cyberpunk
Unnoticeably, the JSR 223 was renamed two days ago from "Scripting Pages in JavaTM Web Applications" to "Scripting for the JavaTM Platform". It's a significant change in the scope of this JSR. It concerned initially only Web applications, aiming at improving the somewhat crappy JSP scripting model. Now it seems they want to propose a standard scripting model at the standard platform level. Solutions already exist for that, albeit non standard. Names like BeanShell, Jython or Groovy come to my mind. Their status is quite different: BeanShell is integrated in WebLogic since version 6, and bundled with quite a number of tools, Jython seems to be used in an "enthusiast only" community and Groovy aims at becoming a standard throuch the JCP JSR 241 ("The Groovy Programming Language").
3 réactions
1 De fletch - 17/11/2004, 07:35
It could just ratify the BSF as a standard and include PHP support...
2 De - 17/11/2004, 11:31
It looks like JSR 223 is the "interface" to the scripting languages while JSR 241 the Groovy implementation.
3 De Damien - 17/11/2004, 11:49
Yes Anonymous, that's what the JSR 241 peoples say about the JSR 223, but that doesn't mean that "the scope and purpose is completely different" between the two JSR. In fact, it overlaps with the interfacing specification. That means there can be a clash and we could *in theory* have Groovy as a non valid JSR 223 scripting environement. It's unlikely though, because James Strachan, specification lead of the JSR 241, is a member of the JSR 223.
Initially, the JSR 223 concerned mainly the non-JVM based scripting languages, and their bindings in a Web app environment. Broadening this to a generic J2SE context leads to a whole new problematic, and BSF is not the answer, because it supports only JVM based languages.