Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Extend your Java Application with Embedded Languages : Page 4

A scripting engine, built in the language of your choice, and embedded into your application can make a huge difference to your customers, who have concerns about extensibility. Even better, creating a scripting engine is easy and fun. See three versions of a spam filter engine built in Groovy, Jython, and BeanShell.


advertisement
Hints and Tips
Embedded languages are powerful and as with all powerful things they can be misused and abused. Here's some hints and tips that may help you avoid the pitfalls:
  • Pay attention to performance—I did some performance testing with these three examples and the results were a little shocking. Jython was only three times slower than hard coding. Groovy was six times slower. And BeanShell, most likely because of the eval in the code, was much slower than Groovy. There are two lessons to learn: The first is that you need to use embedded languages only when you need flexibility over performance, and second, that you need to optimize how you use the interpreter to avoid excessive compilation.
  • Sourcing the Scripts—I used flat files in this example, but there is no reason that you can't construct script code as a string in memory, or use XML to store script fragments. The only particular advantage of storing scripts as flat text files is that you can get code coloring on the language if your editor supports it.
  • Dropping the context—You can refresh the script context with new code by dropping the interpreter and replacing it with a new one where you load in new code. If you are writing a desktop application you should probably drop and reload the context if the timestamp on the script file has changed. This allows the user to modify the scripts without having to restart your application.
  • Don't make everything extensible—You should make it clear in your architecture and to your users where and how the application should be extended. If you take the position that 'everything is extensible' then you will have problems maintaining compatibility between releases. In addition, your users won't have any clue as to the recommended way to extend the system. So they probably won't extend the system. Apache has been successful because the architecture of the framework made it clear how and where it should be extended. As such, the Apache implementers can make modifications without too much fear of breaking the extension modules.
  • Inverting the design—Another potential extensible application architecture uses the script as the central processing flow. The value of the application is in the objects that it injects into the script context. An example would be a version of Ant where the build.xml file is replaced with a script. The Ant tasks would simply be objects that are injected into the script context.
  • Not just Java—The are some embedded scripting languages for C and C++. Most notable is the Mozilla JavaScript engine. Also VB.NET can be used in a dynamic way through use of the .NET Framework.
With some examples and some tips and tricks in hand we can wrap up this article and get on with implementing this stuff!

There are lots of places where you can apply a scripting language in an application. Below are just a few ideas to whet your appetite.

  • In an ASP model you could allow the user to provide custom business logic through macros, which are run in a sandbox with only limited access to customer records.
  • As an extension layer to input or output processing.
  • To provide an extensible reporting mechanism.
  • In an editor (e.g. Eclipse) to provide a macro mechanism.
  • Providing application integration for your customers.
  • As a rapid-prototyping environment for user interface construction.
  • Providing an extension mechanism where the user can add new components.
  • If your product is a library you can have your QA team use a scripting language in a standalone mode to stress-test the library.
This list just scratches the surface of the potential customer-facing functionality that can be provided by macros. However, the most fun reason, which I haven't mentioned, is that you get to learn a fun new language and to experiment with it within the familiar context of your own application.

Unlike C++ there are no barriers or hard work involved in using scripting languages with your Java application. So pick up one of these languages and take it for a spin. Before you know it your application will go from static, slow-to-compile beast to an agile, extensible, rapid-prototyping platform.





Jack Herrington is the author of Code Generation in Action (Manning) and the editor of the Code Generation Network.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date