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
Before Java Specification Request (JSR) 223, Scripting for the Java Platform, (and its predecessor, the Bean Scripting Framework, or BSF), many languages were already communicating with Java. Some languages would take textual code as input from a Java program and return the evaluation result back. Others would keep references to objects in a Java program, invoke methods on those objects, or create new instances of a Java class. Because each language would communicate with Java in its own way, developers would have to learn the script engine's proprietary programming interface every time they wanted to use a script engine in their Java programs.
To solve this problem, JSR 223 defines a contract that all script engines conforming to the specification must honor. The contract consists of a set of Java interfaces and classes, as well as a mechanism for packaging and deploying a script engine. When you work with script engines conforming to JSR 223, you'll always program to the same set of interfaces defined by the specification. The details specific to the script engine are well encapsulated, and you'll never need to concern yourself with them.
JSR 223 helps not only consumers, but also producers of script engines. If you have designed and implemented a programming language, you can reach out to a broader audience and make your software friendlier to use by wrapping it with a layer that implements JSR 223 interfaces.
Before we look at the JSR 223 interfaces and this article's implementations of them, I'd like to point out that though the name of the JSR and the title of this article both contain the word scripting, that's not to say there needs to be limitations on the languages that can be integrated with Java the JSR 223 way. You can take any language you fancy and wrap it with a layer that conforms to the contract laid out in JSR 223. The language can be object-oriented, functional, or in any other programming paradigm. It can be strongly typed, weakly typed, or not typed at all. In fact, before writing this article, I had implemented a JSR 223 wrapper for Scheme, a weakly typed, functional programming language, and put it up on SourceForge. For this article, however, we look at a much simpler language so we can stay focused on the topic of JSR 223 without the details of a complex language overwhelming us.
Don't worry whether you have prior experience constructing a programming language of your own. This article is not about programming languages, but about JSR 223's contract between programming languages and Java.
Figure 1 shows all the parties in our example and how they relate to each other. This article's example defines a simple language that I affectionately call BoolScript. I refer to the program that compiles and executes BoolScript code as the BoolScript engine. Besides compiling and executing BoolScript code, to qualify itself as a JSR 223 script engine, the BoolScript engine also implements the contract defined in the specification. As depicted in the figure, all the BoolScript engine's code is packaged into a single jar file called boolscript.jar.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|i18n Script Languages By Anonymous|
|Do we need a scripting language inside Java? Why? By Anonymous|
|Build your own scripting language for Java By JavaWorld|