Script JavaBeans with the Bean Scripting Framework

Add scripts to your JavaBeans or JavaBeans to your scripts

The Bean Scripting Framework (BSF) is one of the more interesting Java offerings available free at IBM's alphaWorks site (see Resources). BSF lets Java programs run scripts written in other languages and also allows other scripting languages to use existing Java classes. If you have useful scripts written in Python or Perl, for example, or have some useful BasicScript program you don't want to reimplement in Java, BSF will let you call that script from your Java program. BSF can also do the reverse, letting you use Java facilities and existing classes from your scripting language. BSF currently supports interoperability between Java and the various languages that appear in Table 1. The documentation shipped with BSF indicates that support for more languages is in development. All of the languages listed are freely available, though the restrictions for commercial use vary. Downloading information for each language is available from the documentation shipped with BSF.

Some languages (as indicated in the table below), run only on Windows 95 or later, because the ActiveX scripting technology on which they rely is limited to Windows. The rest of the languages run portably on any system that has a Java Virtual Machine (JVM), since they are written in portable Java.

LanguageDescription
BMLIBM's Bean Markup Language
JScriptMicrosoft's implementation of JavaScript. Windows only.
Mozilla RhinoNetscape JavaScript, available from Mozilla. Written in Java.
NetRexxIBM's Java implementation of the Rexx editor language. Written in Java.
PerlScriptActiveState's Perl scripting environment. Windows only.
VBScriptVisualBasic scripting environment. Windows only.
JaclJava implementation of a large subset of Tcl.
JPythonJava implementation of Python.
LotusXSLIBM/Lotus implementation of the XSL language

Scripting languages supported by BSF

In this article, I'll explain why you may want to use BSF in your application, whether you're writing it in a scripting language or in Java. You'll see how to use an existing Java class from a script written in a scripting language. Then, you'll see a Java program that can evaluate scripts written in other languages and can use the results. Finally, I'll explain some of the ways IBM is using BSF in its own products.

Why scripting?

I've always found Java's lack of an eval statement to be a bit disappointing. Of course, I understand the reasons for leaving it out. The JVM is big enough without building a Java compiler into it, and eval would add another level of complexity to security control. Besides, a lot of the things I'd like to do with eval can be done more efficiently, elegantly, and type-safely with class loading. But still, sometimes I just want to be able to evaluate an expression. Is that too much to ask?

Since I was born and raised on Unix, my head is filled with arcana about various scripting languages I've learned. I've written a lot of useful scripts over the years, some of them quite complex. (I once wrote a compiler-compiler in Perl. Don't ask.) I'd love to be able to use my scripts from Java, but doing so by way of System.runtime() is what I call "3-I": inefficient, inelegant, and icky.

I'd also like to be able to make my applications extensible by adding scripting languages to them, so users can add the functionality they want. Extensibility is a key requirement for all of the servers with which I've worked. A venerable and still-popular Web server extension mechanism is CGI (Common Gateway Interface). CGI allows any program, written in almost any language, to masquerade as a Web page, providing dynamic content. But CGI can be very inefficient: common implementations of CGI start a new process for every request. Server developers began adding embedded scripting languages to their server offerings, allowing their customers to extend and customize servers without the overhead of individual processes. Modern servers, such as Apache, provide an API or other facilities to let users create extensions in virtually any scripting language.

All of the situations described above can now be addressed in Java, by way of BSF. As I mentioned earlier, BSF allows Java programs to evaluate and access results from scripts written in other languages. BSF also does the reverse. With BSF, scripts written in those other languages can create, manipulate, and access values from Java objects.

Let's start our tour of BSF by using it to call Java code and using Java classes from some common scripting languages.

Using Java code from a script

One of the ways languages, and particular implementations of languages, differ from one another is in their relative ease of support for various features. For example, writing screen resolution-independent GUI elements may be easier in languages such as Java and the Tool command language's (Tcl) Tk extension, with their customizable layout managers, than in languages such as BasicScript or JavaScript, which have little or no dynamic layout control. BSF provides the scripting languages it supports with access to all the features of Java classes and the existing Java code base.

In the examples below, I demonstrate how to use BSF to create a simple Java user interface from JavaScript and Jacl. Then I'll show you how to use an existing Java dialog box to get user data from a Jacl script.

Ave, mundus!

Listing 1 shows a simple example for using BSF to create Java objects in Jacl. The script creates a simple frame containing a single button labeled "Ave, mundus!" (The label means "Hello, world!" in Latin. This spring I'm visiting two Latin countries, France and Italy, so I'm brushing up.) Clicking the button causes the script to exit. Listing 1. The "Ave, mundus!" program in Jacl

001 package require Java
002 
003 set f [java::new java.awt.Frame "Jacl running in BSF"]
004 bsf addEventListener $f "window" "windowClosing" "exit"
005 set b1 [java::new java.awt.Button "Ave, mundus!"]
006 bsf addEventListener $b1 action {} { quit "Jacl says goodbye" }
007 
008 $f add $b1
009 $f pack
010 $f show
011 $f toFront
012 
013 proc quit { message } {
014     puts $message
015     exit 0
016 }

Line 2 in Listing 1 is a standard Tcl command that tells Jacl to load the java package. This statement creates a number of new commands in the Jacl interpreter, allowing Jacl statements to manipulate Java objects. BSF then allows Java objects and Jacl scripts to "talk" to one another via events.

Line 4 uses the standard Jacl java::new command to create a java.awt.Frame and associate it with the variable f.

Line 5 instructs BSF to add an event listener to the frame. (The following discussion assumes you understand Java 1.1+ event listener interfaces; if you don't, or if you need a refresher, see Resources below.) BSF creates a window event adapter object whose sole purpose is to listen for a windowClosing event to occur on the Frame object $f. When a windowClosing event occurs, the adapter object evaluates the Jacl expression "exit", causing the program to exit.

The general syntax that tells BSF to add an event listener to an event source is:

bsf addEventListener eventSource adapterType filter handlerScript

The event listener is an object, called an event adapter, that evaluates the handlerScript whenever an event of a particular type occurs on the eventSource. The event adapter classes for standard Java event types are defined by BSF and come with the distribution, but you also can define new adapters for custom event types (see the BSF documentation to find out how). The adapterType is the type of event, and the filter is the name of the Java event interface method handling that event.

Line 6 creates a Button with the label "Ave, mundus!" and line 7 instructs BSF to evaluate the given Jacl script { quit "Jacl says goodbye" } whenever an actionEvent occurs. Since there's only one method in the ActionEventListener interface, the filter argument is empty.

Lines 8 through 11 correspond to method calls on the Frame object $f. The ability to call Java methods directly from Jacl, shown here, is provided by Jacl and the java package imported in line 2. Each scripting language has a slightly different way of calling methods on JavaBeans created in that language; see the BSF documentation for the description for the language you're using.

Lines 13 through 16 in Listing 1 form the definition of the quit procedure called by the event listener defined in line 6. This is the script that's evaluated when the user pushes the button.

Figure 1 shows the window that results when running the sample file hello_world.jacl (you can download the sample code and scripts free; see Resources). To run BSF directly from the command line, be sure the Jacl and BSF jar files are in your classpath, then simply issue the following command to make sure the sample file is in your current directory:

java com.ibm.bsf.Main -in hello_world.jacl
Figure 1. The result of Listing 1

Reimplementing the same script in JavaScript is simple. The reimplementation appears in Listing 2 below.

Listing 2. "Ave, mundus!" in JavaScript

001 
002 f = new java.awt.Frame("JavaScript running in BSF");
003 bsf.addEventListener (f, "window", "windowClosing",
004                      "java.lang.System.exit (0);");
005 b1 = new java.awt.Button("Ave, mundus!");
006 bsf.addEventListener(b1, "action", null, "quit('JavaScript says goodbye')");
007 
008 f.add(b1);
009 f.pack();
010 f.show();
011 f.toFront();
012 
013 function quit( s ) {
014     java.lang.System.out.println( s );
015     java.lang.System.exit(0);
016 }

The program looks so much like Listing 1 that it scarcely needs explanation. The two scripts really differ only in the syntax of function calls and in how they access Java objects. Rhino JavaScript uses Netscape's LiveConnect to make Java objects' methods directly accessible in JavaScript. The resulting window, shown in Figure 2, is even more similar than the source code.

Figure 2. The result of Listing 2

You may have one lingering question: where did the bsf command (in the Jacl example) or object (in the JavaScript example) come from? The answer is simple: the BSF Main method, which you used to run the script, created a com.ibm.bsf.BSFManager object and "registered" it with the Jacl or JavaScript interpreter you were using. BSF lets you register JavaBeans with the interpreter, making that JavaBean instance available from within the scripting language. In both examples, Main() created an object with methods corresponding to BSF operations (like addEventListener()) and registered it under the name bsf with the interpreter in use. The script then used the resulting new bsf object to communicate with the BSF framework.

Note that bsf is a bit of a misnomer, because it's not limited to JavaBeans. In fact, any Java object, JavaBean or not, can be created by a script and/or created in Java and registered with a BSFManager for access by a script.

Now that you have the basic idea of how the framework can be used to create a Java object from a scripting language, let's create a slightly more complicated script.

A Java/Jacl dialog

Jacl is a pretty cool implementation of Tcl, but it has a major limitation. The standard extension for Tcl used for building GUIs, the tk library, isn't available in Jacl. So Jacl scripts are somewhat limited in their ability to provide user interfaces. That's OK, though, because with BSF, you can use Java's UI facilities from Jacl.

The user interface I happened to have lying around (after writing it as a sample for this article) is called AddressDialog. It has eight bound properties, all of type String:

  • firstName
  • lastName
  • address
  • city
  • stateOrRegion
  • zipOrPostalCode
  • homePhone
  • workPhone

The AddressDialog fires a PropertyChangeEvent each time one of these properties changes. External objects (for example, a Jacl script) can register as a listener for PropertyChangeEvents, and then react accordingly when a property changes.

A Jacl script that uses this dialog appears in Listing 3.

Listing 3. Using a Java dialog class from Jacl

001 
002 package require Java
003 
004 #
005 # Create an instance of the AddressDialog class and  activate it.
006 #
007 proc getUserData { varName } {
008     set propertiesToTrack  { firstName lastName address city stateOrRegion
009                              zipOrPostalCode homePhone workPhone }
010     set dialog [java::new com.javaworld.javabeans.mar2000.AddressDialog]
011     foreach property $propertiesToTrack {
012        bsf addEventListener $dialog propertyChange $property "
013           reportPropertyChange $dialog $property $varName
014        "
015     }
016     $dialog show
017     unset dialog
018  }
019 
020 #
021 # Update the property whose value has just changed
022 #
023 proc reportPropertyChange { dialog property arrayName } {
024     upvar #0 $arrayName arrayToUpdate
025     set arrayToUpdate($property) [java::prop $dialog $property]
026 }
027 
028 #
029 # main
030 #
031 
032 getUserData myData
033 
034 # Report input
035 foreach key [lsort [array names myData]] {
036      puts "$key = $myData($key)"
037 }
038 
039 exit

1 2 3 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more