Home

News: JSR-274: The BeanShell Scripting Language submitted to JCP

Bookmark and Share Get thread feed

  1. JSR-274: The BeanShell Scripting Language submitted to JCP (23 messages)

    Patrick Niemeyer has submitted a request to the JCP that it create an expert group for the standardization of Beanshell, a lightweight scripting language for the JVM.

    This is the second scripting language accepted by the JCP, after Groovy, which is JSR-241. Richard Monson-Hafael, in BeanShell: The 3rd Official Language of the Java Platform?," states that "The proposal to make BeanShell another official language of the Java Platform is, in my opinion, a great sign that Groovy succeeded in changing the mainstream view of Java from that of a language to a development platform."

    The expert group is still in formation. If you're interested, this would be an excellent time to step forward and help the JSR along.
    Reply to this

    Threaded Messages (23)

  2. Don't we learn?[ Go to top ]

    I don't see the need to "standardize" these languages in the JCP.

    Are we going to see multiple implementations of Groovy and BeanShell?

    How about focusing on making a kick arse language that fulfills its goals, and forget the bureacracy!

    Dion

    Clean up your web ui with Ajax :)
    Reply to this Reply to original

  3. Don't we learn?[ Go to top ]

    How about focusing on making a kick arse language that fulfills its goals, and forget the bureacracy
    Sure, it shouldn't be too hard to come up with a language that everybody agrees upon :-)

    Seriously, I don't see any problem with the JCP standardizing several languages. If something is going to call itself "Beanshell", it's nice to know there is a specification and a TCK that it needs to pass.

    --
    Cedric
    Reply to this Reply to original

  4. Don't we learn?[ Go to top ]

    The problem is, how many "beanshell" compliant implementations beyond the original one are we expecting to exist? I'd guess none. Until someone comes with a good explanation as to why having a standard over these scripting langages, it will be hard to justify it.
    Reply to this Reply to original

  5. Multiple implementations and standardization....[ Go to top ]

    While I can understand some confusion about the purpose of standardizing a language like this, there are several reasons.

    First, I can easily imagine at least two implementations of BeanShell: the current, light weight reflection based implementation that may be suitable for some smaller profile devices and for work in untrusted environments like applets and a higher performance version that does more bytecode generation and compilation to static classes. Maybe these are the same RI, maybe they are not.

    Next, standardization is simply a requirement and community validation (peer review) for anything that is going to be bundled with the Java platform.

    I think it's a healthy exercise and will benefit both Java and BeanShell.


    Pat Niemeyer
    Reply to this Reply to original

  6. I didn't mean one.[ Go to top ]

    Cedric -

    I didn't mean ONE language. I am happy to see many languages on the Java platform. I have been trying to push this for a long time.

    However, I would rather these languages were allowed to be nice and agile for now, and not get bogged down in expert groups.

    That being said, I hope it works out well for everyone.

    Dion
    Reply to this Reply to original

  7. I didn't mean one.[ Go to top ]

    I would rather these languages were allowed to be nice and agile for now, and not get bogged down in expert groups.

    This might apply to Groovy, but I think BeanShell has been around for about 9 years now. The language is long overdo for specification.
    Reply to this Reply to original

  8. BeanShell is kick arse[ Go to top ]

    I see this standardization as good for two reasons:

    1) The JCP is better positioned to keep BeanShell in synch with Java, which is important since the languages should be syntactically similar.

    2) It means that I can use a standardized scripting language that's not Groovy.
    Reply to this Reply to original

  9. Just say no to Beanshell[ Go to top ]

    If you want a scripting engine that supports Java-like syntax that can be invoked using BSF and whatever comes of JSR-223, then I would suggest Rhino. Until the performance problems with Beanshell are solved I can't consider it a worthy choice as a scripting engine. See:
        http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting_p.html

    Jim
    Reply to this Reply to original

  10. JSR-274: The BeanShell Scripting Language submitted to JCP[ Go to top ]

    This is ridiculous !!
    Can anybody explain me how it is possible to have 2 standarts on scripting languages ?
    Why not 2 or 3 or 5 standarts on EJB ?
    or on JDBC ?

    Standarts are mean for interoperability and interexchange.
    How on earth i'm going to swap my Groovy script with Beanshell script ?
    What is the meaning of these "standarts" ?
    I do not understand anymore what do they mean when they say "standart"
    Reply to this Reply to original

  11. JSR-274: The BeanShell Scripting Language submitted to JCP[ Go to top ]

    This is ridiculous !!Can anybody explain me how it is possible to have 2 standarts on scripting languages ?Why not 2 or 3 or 5 standarts on EJB ?or on JDBC ?Standarts are mean for interoperability and interexchange.How on earth i'm going to swap my Groovy script with Beanshell script ?What is the meaning of these "standarts" ?I do not understand anymore what do they mean when they say "standart"

    Note that the JSRs for specific languages aren't the same as a generalized JSR for scripting languages, which also exists: http://jcp.org/en/jsr/detail?id=223
    Reply to this Reply to original

  12. Apache BSF for swapping[ Go to top ]

    This is ridiculous !!Can anybody explain me how it is possible to have 2 standarts on scripting languages ?Why not 2 or 3 or 5 standarts on EJB ?or on JDBC ?Standarts are mean for interoperability and interexchange.How on earth i'm going to swap my Groovy script with Beanshell script ?What is the meaning of these "standarts" ?I do not understand anymore what do they mean when they say "standart"

    You can swap your Groovy Script with a Beanshell script if you use Apache's Bean Scripting Framework. But yeah, I don't really see the point of declaring either tool a standard. That said, if I had to pick, I'd lean towards beanshell.
    Reply to this Reply to original

  13. javax.script API (JSR-223)[ Go to top ]

    BSF is great, but JSR-223, the new javax.script API fills exactly this role. It is a BSF-like general API for interacting with different scripting engines from Java.

    The combination of javax.script and BeanShell / other languages will be like JAXP and Xerces / Xalan. The big difference of course is that the scripts themselves are not interchangeable. But the application can still insulate itself from execution of the scripts. In many cases this will be sufficient and allow users to drop in their own scripts in their own languages without the application knowning anything about it. The application will expose its API to the script and the script will execute procedural stuff on the application or return values to the application.


    Pat Niemeyer
    Reply to this Reply to original

  14. stupid step[ Go to top ]

    sorry ,but this will slowwwwwwww the development of these langs as each minor change will require the expert group to review and vote for it and we all know that this take monthes if not years
    Reply to this Reply to original

  15. Here is why its necessary to standardize BeanShell?[ Go to top ]

    I've posted a blog entry that answers this question about why standardization is necessary.

    Here is the URL:

    http://rmh.blogs.com/weblog/2005/05/why_standardize.html
    Reply to this Reply to original

  16. Re: Here is why its necessary to standardize BeanShell?[ Go to top ]

    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 standard?)

    I hoped the link 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 for long time :( (sorry to say that)

    Stefano
    Reply to this Reply to original

  17. Re: Here is why its necessary to standardize BeanShell?[ Go to top ]

    ...(since how long 2.0b1 is out without becoming standard?)...

    I meant stable indeed :)

    Stefano
    Reply to this Reply to original

  18. On the JSR and the pace of BeanShell progress...[ Go to top ]

    It is true that (like most open source projects) there have been both periods of intense activity and lulls in BeanShell's development over the years. I believe two factors most contribute to this: 1) The primary maintainers have kept very close reigns on what changes are made. This of course has a negative side in that things get bottlenecked. 2) In something as rich as a language there is almost always a workaround or another way to get things done. So the pressure to fix some bugs is not as high as perhaps it should be.

    I believe that the JSR will improve the pace of BeanShell development on both counts. We'll have more people involved at a high level and we'll have more scrutiny to prioritize bugs and make sure they are fixed in a timely fashion. In other words, you'll all have the right to scream at us if things don't get done ;)


    Pat Niemeyer
    Reply to this Reply to original

  19. ..pace..[ Go to top ]

    If the effect of the JSR is, that the severe bugs in BeanShell will be fixed, i'm a big fan. But i would have liked it more, if these bugs (e.g. wrong scoping with typed variables or the problems when working with a custom classloader) were fixed without such "pressure".
    Reply to this Reply to original

  20. The problem[ Go to top ]

    While this adds scripting to a JVM, this wont work for people writing scripts run from the command line to talk with a remote JVM. The problem is the time to load a JVM, the classes, the classes for the scripting etc is just too long. We have this problem right now with JMX.

    We need a way for scripting languages like perl to drive the core scripting engine on a remote JVM directly without the need for a local JVM. This means reflection driven approaches are not going to work that well. A late binding approach should be provided with optional generation etc for early binding but most people would probably be happy with late binding.

    We use a BSF based scripting framework within WebSphere and this is the main problem I have with it. Plus, the wire protocol between the two environments needs to be non Java centric, like SOAP or something that allows a very lightweight non Java client.

    People may say that this is a different problem but I disagree, if this is how we tell Java coders to script enable their apps then they will also want to do this for automating actions remotely. Both items need to be taken in to account.

    Billy (IBM)
    http://www.billynewport.com
    Reply to this Reply to original

  21. Scripting and remote access...[ Go to top ]

    BeanShell has always supported several forms of simple remote scripting. You can enable a simple telnet/http server pair in the interpreter and then connect the remote application via either a web browser or command line client. There is also a servlet script runner. The BeanShell Remote command line tool will take a local script file and post it to the remote server or a BeanShell servlet and gather the results.

    http://beanshell.org/manual/remotemode.html#Remote_Server_Modeou
    http://beanshell.org/manual/servletmode.html#BshServlet_and_Servlet_Mode_Scripting

    We've had users which added things like better telnet support and SSH protection. Some of these should be in a contrib area.

    You could also simply use curl with the servlet to post the file. Or you could just keep the sending app alive of course.


    Pat Niemeyer
    Reply to this Reply to original

  22. Scripting and remote access...[ Go to top ]

    That looks more promising but I think we're missing an opportunity here. Why not define a SOAP interface to send a script to the server and then add a JAX-RPC handler to it that can be enabled/disabled. The WSDL should be very simple. This would give people one way that they know works rather than the multiple ways you describe and those in the contrib area because the builtin support didn't fill the requirement.

    Billy
    Reply to this Reply to original

  23. To be more clear[ Go to top ]

    What I'm saying is that this should have the equivalent of ssh access builtin. Today, if I want to securely attach to a remote box then I use SSH to do it, it'd be great to have the same for Java JVMs rather than do something that doesn't fill the need and then rely on the multitude of ways that will make their way in to a contrib area. Lets add one way that does work and does it's job and leave contrib for other less critical function.

    Thanks
    Reply to this Reply to original

  24. JSR-274: The BeanShell Scripting Language submitted to JCP[ Go to top ]

    Why Standardisation of BeanShell is "A Good Thing" (tm):

    - BeanShell is relatively mature, which will go a long way to mitigate the usual "design by committee" that some JSR's suffer. There is also usually less bickering about something that is established.
    - While BeanShell has industry support (e.g. BEA and Sun), having a standards body makes it even easier to justify using BeanShell in a corporate environment.
    - JSR's generate interest (this post for example), this translates directly into more people using and improving the language.
    - While a competing version of BeanShell is unlikely, the JSR does open up the possibility
    - Documentation. BeanShell has a user manual that hasn't been updated to 2.x and no language specification. This would be the expected output of a JSR.
    - If the formation of an Expert Group goes well, it means more people thinking about BeanShell as a whole.
    Reply to this Reply to original