BeanShell 2.0: A Fully Java Compatible Scripting Language


News: BeanShell 2.0: A Fully Java Compatible Scripting Language

  1. Pat Niemeyer has released a beta version of BeanShell 2.0. This release shows that BeanShell is now fully compatible with Java.

    It can now read in ordinary .java files and BeanShell scripted classes are fully typed and appear to Java as ordinary classes.

    The new version also includes static imports:

    static import java.lang.Math.*;

    and mix-ins. You can import the methods and fields of a Java object instance into a BeanShell namespace:

    Map map = new HashMap();
    importObject( map );
    put("foo", "bar");
    print( get("foo") ); // "bar"

    Previous limitations on the implementation of anonymous inner classes have also been lifted, allowing BeanShell to extend arbitrary Java classes and implement abstract base classes.

    Read the BeanShell 2.0 Announcement

    Visit the BeanShell Home Page

    Threaded Messages (13)

  2. Must be a Java Web Start application ![ Go to top ]

    I'll really enjoy it if Pat could make a Java Web Start version of BeanShell on his web site !
  3. BeanShell security[ Go to top ]

    How I can restrict access to the internal program methods in BeanShell ? I think that this is important security requirement for many apps.
  4. Secure Beanshell[ Go to top ]

    You can add permission checks that only allow code trusted code to make calls into you.

    As long as beanshell isn't granted these permissions you should be ok.

    This is pretty invasive but would apply equally to all scripting languages and dynamically loaded code.

    I spent a few hours investigating this and I think that beanshell expects to have "AllPermission" or at least some pretty invasive permissions. It makes heavy use of reflection.

    I think some changes may be necessary to make beanshell run in a hardened environment.

    I investigated this and I think that beanshell needs a few doPrivilegeds() around the reflective code but still execute the reflective calls in the non-privileged context.

    bean shell consoles then need to be opened in a non privileged access control context and all should be well.
  5. Bravo![ Go to top ]

    This is what JavaScript should have been all along. This is an immense windfall for the community.
  6. Feedback regarding Judoscript[ Go to top ]

    Can someone give some feedback on Judoscript ( ? It is also a java based scripting langauge and has some high level features for doing JDBC and EJB stuff.
  7. Performance[ Go to top ]

    Good news!

    Does anybody know if the version 2 release features any performance improvements, I remember in this article BeanShell came out looking quite sluggish (

    I would be interested in any users views on BeanShell performance in general and this new release in particular.

  8. Another...[ Go to top ]

    And there's Dynamicjava
  9. While working for business application ISVs , I have always been intrigued by the possiblity of allowing the customer to modify the application and making it easier for them inject their specific logic into the application without them having to spend $$ for customization .

    With technologies like Beanshell, DynamicJava and AspectJ, I can sense that this should be achievable ; can someone share some insight into using any of these for the purpose of application customization ?
  10. For specific tool customization, like editors, it sounds great. But, for business applications, seems difficult to do. One would have to really constrain the reach of the scripts or create a 'little language'. Scripts, unless they have safeguards like 'strict' modes, can be very brittle. Another, problem is that script languages have very powerful scripting syntax, and so can be harder to read and maintain than normal Java. This is one great advantage of BeanShell; it is Java with scripting freedom.

    There are probably more robust approaches, like Business Rule Engines, MVC frameworks, and perhaps some web service 'Orchestration' tools that present an IDE. Of course, some applications can present a visual component that allows an ISV engineer to connect components and services.

    OTOH, an application can have entry points that instead of invoking compiled components, can access a script library. Thus, supplying an easily changed library, even in the field, can be cool. The edit, compile, store, deploy, cycle seems very prehistoric. We should be at quasi-compiled(?) languages like Python, Perl, etc. There is plenty of cpu cycles and network bandwidth is going up with Internet2 and other develpments. Ooops! Got into a rant.
  11. BeanShell vs. DynamicJava...[ Go to top ]

    Someone with more experience with DynamicJava will have to set me straight if I'm wrong, but after my quick look I see these differences:

    1) BeanShell interpretes a superset of what DynamicJava can interpret - e.g. BeanShell (2.0) interprets standard Java source but also allows allows true loosely typed variables and method signatures, as well as method closures and other scripting language features.

    2) BeanShell appears to be about half the size of DynamicJava (with even smaller subsets if you require less functionality).

    3) Ironically, DynamicJava is less dynamic than BeanShell - I'd image because it generates bytecode for everything. DJ does not seem to support dynamically loaded commands or scripting language features such as the "eval()" method. BeanShell can create scripted objects and classes bound in the current scope at any time. It also has sophisticated scoping extensions such as "this.caller" that allows BeanShell command writers to write methods that have side effects in the caller's namespace.

    4) DynamicJava is probably faster than BeanShell right now... again, just guessing because it generates bytecode.

    5) Dynamic Java's full Java language support is probably more mature than BeanShell's interpreted classes which are only in beta-1 right now.

    Pat Niemeyer
    Author of BeanShell and the book Learning Java, O'Reilly & Associates
  12. Re: BeanShell performance....[ Go to top ]

    Certain aspects of BeanShell performance were improved significantly in version 1.3 a few months back. If invoking methods on Java classes is what you do most then BeanShell is about twice as fast as it was.

    BeanShell is wide open for future performance improvements. Much of BeanShell's small size and simplicity is due to the fact that it relies almost entirely on the Java reflection API and does no bytecode generation (only the new class emulation in 2.0 requires bytecode generation). However there are several places where the architecure has been specifically designed to allow optimizations that are not yet in place. For example, resolving an ambiguous name (basically everything from a variable reference to a method call) in a namespace utilizes a name resolver abstraction that allows BeanShell to cache arbitrary information about the resolution so that it doesn't have to repeat it if the namespace hasn't changed (e.g. new variables or classes are added to the scope). This is 90% (just guessing) of what Beanshell does at runtime - aside from calling methods... (see above) - and we have hardly touched it yet.

    I think there is a lot of potential for BeanShell to get very fast in the future.

    Pat Niemeyer
    Author of BeanShell and the book Learning Java, O'Reilly & Asssociates
  13. Hi All

    We use BeanShell in the JDO Genie Workbench. Users can write and execute snippets of JDO code for cut and paste or data fixes or whatever. Adding this capability to an application is a huge feature and was very easy to do with BeanShell. Thanks guys!

    JDO Genie -
  14. If anyone is interested over at the Viva! site I've put together a page listing the major free open-source scripting languages for Java (including Python, Ruby, Smalltalk, Scheme and more) @