The Source for Java Technology Collaboration
User: Password:



Pat Niemeyer

Pat Niemeyer's Blog

JSR-274 - Standardizing BeanShell

Posted by pat on May 25, 2005 at 09:05 AM | Comments (8)

I'm very happy to announce that the JCP has begun voting on a JSR to standardize the BeanShell scripting language through the Java Community Process.

The goal of this JSR will be to formalize the langauge and provide the RI and TCK which will allow it to be included in a future release of the J2SE. This effort will build upon the introduction of the javax.script API by providing a standard, Java syntax compatible, scripting language as part of the Java platform.

I think this is a very exciting proposal and will lead to very good things for both the Java platform and for existing users of BeanShell. I encourage everyone to read the JSR proposal (http://jcp.org/en/jsr/detail?id=274), which provides more details and motivation. But let me briefly anticipate a few questions:

1) Why spend time on this? Why not just put the time into making BeanShell better independently?

Well, the primary reason is that we really believe that the Java platform needs a standardized, "native" Java scripting language and is long overdue for one. There are so many things that developers and end users can do with a dynamic language and scripting capabilities (prototyping, application extension, configuration, testing, dynamic deployment) and this capability has been there just under the surface since Java 1.1, waiting to be tapped. This is why we created BeanShell and have maintained it (sometimes lovingly, sometimes reluctantly) for the past seven years. During that time BeanShell has matured into a truly Java syntax compatible language, while staying relatively lean and simple. It only takes a couple of hundred K of code (less than the size of some of the Swing components) to bring all of this to Java. So, we think it's time that it gets done.

Next, from the project's point of view, we think that this will make BeanShell better. There is nothing like a little pressure to get people moving and get things done. We are very much looking forward to the involvement of new voices and outside experts on the project and I believe that this process is going to benefit everyone, most of all BeanShell users.

2) Won't this effort suffer from the pitfalls of designing a language by committee?

The purpose of the JSR will be primarily to ratify the existing language, not to create a new one. We aren't going to start from scratch or go off in completely uncharted territory. Of course having the benefit of new people and ideas we may find new answers to old problems, but I believe that we can keep a firm grip on the process and get this done with an outcome that will make everyone happy. Because we have been very conservative with the core of BeanShell over the years it has stayed relatively clutter free. This leaves us a lot of flexibility and room for future enhancement. We do have some interesting and bold ideas brewing, but those proposals will come from the community based on their merit and not from an attempt to solve every problem via the expert group.

3) So what is the plan? Where is the roadmap for BeanShell?

The first step will be to finalize the current (2.x) release with the existing feature set. This work will be mainly bug fixes, but will also move a bit further towards Java 5 syntax compatibility. At JavaOne next month we will be hosting a BeanShell BOF (please join us) to talk about plans for BeanShell 3.0 and solicit feedback on the JSR. We expect BeanShell 3.0 to be fully Java 5 compatible in terms of base syntax, to offer some new (long desired) features in the scripting domain, and to address performance and management issues. We are currently updating the beanshell.org web site and services and we're moving the codebase into Subversion. We will soon have a Wiki which will allow the community to help us even more. We will be releasing much more regularly starting immediately. The goal will be to have the JSR in good shape by the end of the year, with an alpha release of 3.0 including new features developed concurrently by the community.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • This is potentially promising but I hope it works out for BeanShell better than for some other projects I could name. I think BeanShell's maturity could be its saving grace here.

    You're going to get a lot of pressure to put more and more stuff into BeanShell, features that a few will care about deeply (and noisily!) but in the big picture aren't that important (i.e., strategic). So just keep in mind the 'silent majority' that are happy with the simple, elegant system you started with and don't care about fancy extras.

    If extras do go in, then keep exploiting the modular design you have and keep your focus on having the smallest possible core of functionality. (Maybe that modularity can be codified somehow in the JSR, through levels or profiles or something.)

    --Ed

    Posted by: eburnette on May 25, 2005 at 10:44 AM

  • I completely agree with Ed.

    I'm a Java developer who has invested a lot of time and energy into understanding the nuances of the Java language and how to think in Java. A scripting language with Java syntax is hugely useful to me. Development build/package/deploy times are hugely painful in Java and BeanShell can effectively solve this problem. If the BeanShell syntax is identical to Java then I can move bsh scripts into .java files and back again for deployment or maintenance. Surely I'm not the only developer who is constantly frustrated by the limitations of JVM hotswap or slow compiles?

    If I wanted to solve the 8 Queens problem in one line or play with closures I could choose one of the many other scripting languages. The Java scripting language must have (at least) a Java syntax. I have nothing against extensions - especially how you designed them.

    Posted by: markswanson on May 25, 2005 at 12:06 PM

  • I love BeanShell and I try to use it whenever I can.

    However, standardization does not make any sense to me; actually, I believe it will simply slow down the process of improving it (since how long 2.0b1 is out without becoming stable?)

    I hoped http://rmh.blogs.com/weblog/2005/05/why_standardize.html would have given some good reasons for standardization... but it does not :(

    IMHO the reason for scarcely adoption is not the stamp, is the activity level of the project. And the BeanShell project looks halted since long time :( (sorry to say that) Stefano

    Posted by: stefano_fornari on May 26, 2005 at 06:45 AM

  • I agree with Ed too.

    Beanshell has proved its worth; it's been shipped in commercial products for years. It deserves "blessing" based on its proven track record (so does Jython).

    Contrast this proposal with the fast-track "blessing" by the JCP of Groovy, a promising language that wasn't fully baked... It really did appear (to me) that the process was accelerated by the backing of a few influential people, rather then the merits of the proposal (I don't know what really happened, but it sure did happen fast).

    I'm not knocking people for backing Groovy, but I think the JCP erred on that one.

    Posted by: johnreynolds on May 26, 2005 at 06:45 AM

  • I think that having beanShell in the J2SE would be a good thing. Not having to bother to have the bsh.jar in the classpath would surely expand the use of scripting language in java, specially whith beanshell, which is so easy to use...

    Posted by: magnum on May 26, 2005 at 01:21 PM

  • Java's syntax is quite simple and BeanShell is close, except say : having to use String[] x and not String x[]; doesn't always like float; bytes appear to be signed etc. To what extent is it intended to make the java like syntaxed scripts run like java say: handling of the constant pool; implementation of static etc. etc. etc?

    Posted by: nigel_galloway on June 15, 2005 at 09:35 AM

  • Contrast this proposal with the fast-track "blessing" by the JCP of Groovy, a promising language that wasn't fully baked... It really did appear (to me) that the process was accelerated by the backing of a few influential people, rather then the merits of the proposal (I don't know what really happened, but it sure did happen fast).

    Posted by: markovich on October 07, 2007 at 02:47 AM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds