|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Some Java applications' requirements make integration with a scripting language necessary. For example, your users may need to write scripts that drive the application, extend it, or contain loops and other flow-control constructs. In such cases, it's sensible to support a scripting language interpreter that can read user scripts, then run them against your Java application's classes. To accomplish that task, run a Java-based scripting language interpreter in the same JVM as your application.
Support libraries, such as IBM's Bean Scripting Framework or the library Ramnivas Laddad developed in "Scripting Power Saves the Day for Your Java Apps" (JavaWorld, October 1999), successfully help you plug different scripting languages into your Java program. Such frameworks don't require major changes to your Java application, and they let your Java program run scripts written in Tcl, Python, and other languages.
A user's scripts can also directly reference your Java application's classes, just as if those scripts were another part of your program. That's good and bad. It's good if you want scripting to drive regression tests against your program and need to make low-level calls from the script into your application. It's bad if a user's script operates against your program's internals instead of against an agreed-upon API, thus compromising your program's integrity. So plan on publishing the API you want your users to write scripts against and clarify that the rest of the program remains off limits. You could also obfuscate the class names and methods you don't want customers to write scripts against but leave the API classes and method names alone. By doing so, you'll make it less likely an adventurous user would code against a class you didn't want them to.
Hooking in several scripting languages into your Java program is remarkable, but think twice if you're writing a commercial application -- you're opening a can of worms by trying to be all things to all users. You must consider the configuration management issue, since at least some of the different scripting interpreters get updated and released periodically. So you'll need to ensure which version of each scripting interpreter makes sense with which release of your application. If a user puts a newer version of one of these interpreters in your application's install tree (hoping to fix a bug in the older version), they will now run an untested configuration of your Java application. Days or weeks later, when the user finds and reports a bug in your application unearthed by the newer scripting interpreter version, they probably won't mention the scripting interpreter change to your customer support staff -- making it difficult for your engineers to reproduce the problem.
Moreover, customers likely will insist you offer a bug fix for the scripting interpreter your application supports. Some interpreters are actively maintained and updated through an open source model; in those cases experts may help you work around the problem, patch the interpreter, or get a bug fix included in a future release. That's important because without support, you could be stuck with the unpleasant task of fixing the problem yourself, and scripting interpreters run from between 25,000 to 55,000 lines of code.