I think the JSR 223 team has done a fantastic job. I was worried when the original goal was just for web-tier stuff. However, in this latest version they've separated the javax.script.http stuff from the javax.script stuff. Very nice. Looks like BSF is going to replaced with this, which I'm fine with. It's served it's purpose.

However, one thing that concerns me is, where's beanshell? I know Pat Niemeyer from beanshell is in the expert group, so where's the beanshell samples? I see php, javascript (rhino), groovy.... No beanshell? Only a brief mention in the pdf and no samples?

Personally I've never liked groovy. Beanshell is much more natural for a java programmer to use. Seems like beanshell's been at 2.0b2 *forever*. It plugs in nicely with BSF and I want to see it plugged into this now too. Maybe now that the JSR's shaping up Pat will have time to bring beanshell into it.

However, one thing that concerns me is, where's beanshell? I know Pat Niemeyer from beanshell is in the expert group, so where's the beanshell samples? I see php, javascript (rhino), groovy.... No beanshell? Only a brief mention in the pdf and no samples?Personally I've never liked groovy. Beanshell is much more natural for a java programmer to use. Seems like beanshell's been at 2.0b2 *forever*. It plugs in nicely with BSF and I want to see it plugged into this now too. Maybe now that the JSR's shaping up Pat will have time to bring beanshell into it.Again, great job everyone.

I totally agree about the naturalness of Beanshell, although one aspect of Groovy I really like is the compilation to Java byte codes, which means that scripts can be as fast as normal Java. I don't believe any other of the scripting languages do this?

although one aspect of Groovy I really like is the compilation to Java byte codes, which means that scripts can be as fast as normal Java.

I don't think this is true. Groovy is still dynamically typed which means it must be doing reflection in the generated bytecode. In fact, I'd be surprised if Groovy was that much faster than BeanShell. I don't know though, anyone up for a benchmark?

although one aspect of Groovy I really like is the compilation to Java byte codes, which means that scripts can be as fast as normal Java.

I don't think this is true. Groovy is still dynamically typed which means it must be doing reflection in the generated bytecode. In fact, I'd be surprised if Groovy was that much faster than BeanShell. I don't know though, anyone up for a benchmark?

My mistake. The reflection could well slow it down considerably, although I believe there have been significant speed improvements in HotSpot to help with reflection performance.

Beanshell doesn't fare so well, being worsted only by Jacl and JRuby in a field of 8. This corresponds to my own personal experience in which we implemented a template-based computation engine that used interpreted scripts for the calculation algorithms. Beanshell just wasn't up to the task so we chose to use Rhino, although the implementation fronted it with BSF so we could swap out anytime we wanted.

"Interestingly, despite numerous references to the BeanShell Java scripting language in the specification, the development of a BeanShell engine by the spec lead, and the participation of the primary BeanShell developer (me) in the spec development, the Sun download does not include a BeanShell engine implementation or examples. (The politics of Groovy continue to amaze me.) But not to fear, the next release of BeanShell will include an engine implementation as part of its own distribution."

This is not meant to start a flam war it is just a simple question. I have seen a lot about java scripting in the last few months and I always wonted to know how it would be useful. Other than the fact that this technology is cool where/why would it be used.Thank you,Chris

This is not meant to start a flam war it is just a simple question. I have seen a lot about java scripting in the last few months and I always wonted to know how it would be useful. Other than the fact that this technology is cool where/why would it be used.Thank you,Chris

Hi Chris,Actually this is a perfectly valid question. A scriptable application, as you may know, is an application that can be extended at runtime through programs usually written in a high er level language than the application itself. These programs are called scripts.

The uses of an embedded scripting language really depends on your audience.

If the intended user of your application's scripting interface is you or other Java developers working on your application then scripting offers benefits such as:- the ability to query information about objects in your application at runtime, great debugging tool- the ability to prototype new application features quickly and easily- the ability to provide a quick fix to your application quickly and easily- the experience of developing with a new (more fun?) language

I think scripting adds the most to an application when it can be used by end users. Depending on how the interface is put together, embedded scripting can offer end users a way to add new features to your application, a way to customize your application beyond what is allowed in dialogs, a way to create shortcuts for common taks, and in general a way to really make your app do what they want it to do.

One of my own applications is scriptable. The interface lets users define new commands, recreate the entire menu structure in the app as they'd like it, respond to events in the application, and bind new keyboard shortcuts.

My users like it as it gives them the ability to customize the experience to what they want.

Scripting is a very cool thing that opens up a lot of possibilities for you and your end users.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.