Java Interface Library/en

This Article describes the old, now obsolete Java Bridge V1. Here is the documentation of the new "Java Bridge V2"

Introduction

The Java Interface library ("Java Bridge") is used to interact with Java objects inside an external Java Virtual Machine (JVM).

The access to Java objects, classes and programs is done via a framework called "Java-Bridge", which is similar in operation to the dotNET bridge. This framework implements transparent forwarding of method (virtual function) calls to Java objects, which exist in a local or remote Java Virtual Machine (JVM). Also, return values, callBacks and exception information are passed back from the Java program to expecco. This is done by a proxy-object mechanism, which catches all function calls, wraps the arguments, sends a datagram to the other bridge side, awaits the reply and returns the result to the original caller. Thus, remote procedure calls are almost completely transparent to the Smalltalk/JavaScript code inside expecco. In your elementary code, you can write remote function calls as if they were to local objects.

Notice that this document describes the low level framework, which implements the bridge communication. A much easier to use high level interface (called "Groovy Blocks") exists and should normally be used, if you need access to a Java application's internals during testing. Please take a look at "Groovy Block API" and "Testing Java Applications using Groovy blocks".

Architecture

On the expecco side, the bridge consists of a number of Proxy objects, which behave like regular Smalltalk objects as seen from elementary expecco code. However, instead of performing an action when one of their methods (virtual functions) is called, they send a message over a socket connection to the Java VM (actually: to a bridge software inside the Java application) which decodes the message and sends it to the destination Java object. The same is done in reverse direction with the return value.

+---------------------+     +----------+     +----------------+      +----------------+     +---------+ 
|                     |     |          |     |                |      |                |     |   Java  |
|       expecco       |---->|  Proxy   |---->|      Bridge    |==>>==|      Bridge    |---->|  Object |
|  (elementary code)  |<----|          |<----| (expecco side) |==<<==|   (Java side)  |<----|         |
+---------------------+     +----------+     +----------------+      +----------------+     +---------+

This setup allows for transparent communication with objects inside a local or remote Java VM. This may be either utility functions which happen to be convenient for the test application (for example: file parsing, syntax analysis, protocol implementations or access to specific hardware via driver libraries), or the tested application in the system under test itself.

Especially, it allows for the objects of the tested application to be looked into, manipulated and for functions of it or underlying frameworks to be called.

For expecco code, we tried to make this as transparent as possible, however there are a few exceptions, when function names need to be translated (for example, because the function naming syntax is different) or due to the fact that for some operations no corresponding name exists in Smalltalk (array access, for example).

Of course, multiple such connections can coexist and be served/handled in parallel. This enables an expecco test suite to communicate with both sides of a tested client-server Java application, for example.

Notice that a similar mechanism is used in expecco to communicate with DOTNET, Qt (C++) and C applications.

Initializing / Releasing the Bridge

Before any communication can take place between expecco and any Java object, the Java side of the bridge has to be started, and a communication has to be established. In expecco, all of the bridge classes are found in the JAVA namespace.

The main interface class is "Java", in the "JAVA" namespace:

    java := JAVA::Java newWithServer.

or (in JavaScript):

    java = JAVA::Java.newWithServer();

This starts the Java-side of the bridge (actually executes java as a background command) on the local machine, and establishes a connection to that JVM.

The bridge connection should be closed, if the bridge is no longer needed. Release the bridge with:

    java.closeBridge();

which terminates the connection.

Start and Connect to a Remote Machine

The above started a Java VM and connected to it. Alternatively, you may want to connect to an already running Java program (typically, your system under test). In order for your program to be reachable, it must allow for the bridge to connect to it via a special bridge-connection, which is a socket connection. For this, it must execute the server code found in the "JavaBridge.jar" file. To pass parameters you will typically start it from a command line or a little shell/batch script.

Call (on the shell/cmd level):

   $ java -jar <PATH_TO_JAVABRIDGE.JAR> <PARAMETERS>

The "JavaBridge.jar" file is found in the installation directory of expecco at:

   \exept\expecco\packages\exept\technologyBridge\javaBridge\javaBridge_Server_Client\JavaBridge.jar

The Java Bridge code allows for either side to initiate the connection - i.e. it can be run in server mode, where it awaits an incoming connection, or in client mode, where it actively initiates a connection. After connection establishment, there is no difference in the operation of the bridge, however depending on the setup of your network infrastructure, especially firewalls, either mechanism may be easier to be used.

Assuming that the bridge is already running on the remote machine as server (default), use newConnectedTo:port:withTimeout: to connect to it from the expecco side:

   java := JAVA::Java newConnectedTo:'myHost' port:4567 withTimeout:30.

This will initiate the connection setup from the expecco side.

Alternatively, if started in client mode use newWaitingForConnectOnHost:port:withTimeout::

   java := JAVA::Java newWaitingForConnectOnHost:'localhost' port:4567 withTimeout:30.

which will open a port on the expecco side, and wait until the Java side connects to it. For more details see API

Startup Parameters

You can use any parameter in any order. If no parameter is used then the bridge listens on port 14014 in server mode without keepAlive.

-help

• Shows the help

-ip <aHostnameOrIP>

• In client mode this specifies the IP address or the hostname to connect to.

-port <aPortNumber>

• In client mode this specifies the port to connect to. In server mode this specifies the listening port.

-asClient

• The bridge will start in client mode. If not set the bridge is started in server mode.

-keepAlive

• By setting this flag the bridge will not exit after the connection has closed and starts to connect or listen again. Otherwise, it will run for a single connection session only.

Loading Applications (from the expecco side)

Normally, you would start your application with the required command line arguments and include the Java Bridge as jar there. However, in some situations, it may be required to dynamically load other jars into the connection Java VM. By accessing a classloader, additional classes, or applications as contained in JAR files can be loaded from the expecco side.

This can be used to add a JAR file to the class path:

    java addJarByPath:'pathToJarFile'. "/ assuming "java" is a handle as returned from the above connect

be aware, that if the JVM is on a remote machine, you should ensure somehow that the jar file is present on that machine. If required, transfer it to the machine's "tmp" directory, and use that folder as path. (you can use another expecco block for that file transfer, or write a little batch/shell script to do that).

Java Package Import and Class Access

The import (loading) of additional required packages is done automatically in the JVM, when one of the package's classes is accessed for the very first time. In other words, when the Java code references a class for the first time, whose package is not yet loaded, it will search for the package along the class path and load it. Thus the above "addToClassPath:" actually does not yet verify or load the package, but only prepare any future "load on demand". This may be a bit dangerous, as failures may be reported much later, when a missing class is actually loaded (so better double check, that all the class paths are valid, and the corresponding files are present on the system on which the JVM runs).

This following code sample simple references (i.e. accesses) the class "JFrame" from the "javax.swing" package. The fully specified class name in Java would be "javax.swing.JFrame". Note that in Smalltalk code, the dots are replaced by underscores and the full class name is written as a message send to the Java Bridge handle:

    java javax_swing_JFrame. 

After that call, the Java VM has loaded the required package(s) and now knows the package "javax.swing". It will lookup short form class names in the set of known packages. Now we can access all classes of that package without a need to provide the full class name. For example, if we now want to access the class "javax.swing.JButton", it can be done via the class's short name:

    java JButton. 

ATTENTION: If a classes' short form exists in more than one package on the Java side, then you still have to specify the full name of the class. Otherwise, the first matching class will be taken and that's probably not the one you were looking for!

Instantiating a Class

Object instances are created via the "new"-message, sent to a proxy of a Java class. You can get this proxy as described in the previous section. For example, if we want to create a new instance of a "JFrame" and a "JButton", write:

    frame := java javax_swing_JFrame new.
    button := java JButton new. 

The first statement results in a proxy object for the "JFrame" instance (and as a side effect of referring to the class will import the "javax.swing" package). The second line results in a proxy for a new "JButton" object.

Calling Instance Methods

A method call is done by a message send to a proxy object, where the message is the method name to call. For example, to call the "setVisible(boolean isVisible)" method on the above JFrame object, we send the following message to that proxy:

    frame setVisible:true.

As method naming is different in Smalltalk and Java, a dynamic translation is applied when sending messages from Smalltalk code to a remote Java object. Smalltalk has arguments embedded inside parts of a so called "keyword" message, such as in "receiver foo:arg1 bar:arg2", where "foo:bar:" would be the message name, and "arg1", "arg2" be the arguments.

In Java, the message name is a single identifier, and arguments are written in an argument list after the message name: "receiver.fooBar(arg1, arg2)".

When message names are translated, only the very first part of the Smalltalk keyword message is taken ("foo" in the above example), and the remaining parts are simply ignored. Thus, any of the Smalltalk messages "foo:bar:", "foo:xxxx:" and "foo:_:" (a single underscore as second part) all translate to the same Java message name "foo()".

Therefore, to call a method with more than one argument, like "setSize(int width,int height)" on a JFrame instance we can write:

    frame setSize:300 _:200.

but just as well:

    frame setSize:300 anyWord:200.

or any other selector with "setSize:" as its first component. The selector translation mechanism simply takes the first part as the Java selector.

In practice, you should take a reasonably descriptive name, such as: "frame setSize:300 height:200" or only the Java name as first part, such as "frame setSize:300 _:200".

For a call of a method with 4 arguments, we could write:

    frame setBounds:100 y:50 width:300 height:200.

or:

    frame setBounds:100 _:50 _:300 _:200.

Also here the "y: width: height:" can be named as you want, but the first part must be "setBounds:".

Calling Static Methods

Calling a static method on an object is not different from calling non static methods. In most cases you will call a static method not on an object but directly on the class. This is done by using the class object as "receiver" of the message. For example, if we want to call the static method "isDefaultLookAndFeelDecorated()" of the JFrame class, write:

    java javax_swing_JFrame isDefaultLookAndFeelDecorated.

or if the package is already known:

    java JFrame isDefaultLookAndFeelDecorated.

Accessing Fields

As Smalltalk does not support access of an object's fields from the outside (it is fully encapsulated, and access from outside is ONLY allowed via getters/setters), an additional translation mechanism is provided for field access.

Accessing a field of a Java object or a class's static field uses the same syntax as method calls. To access a field, send a message where the message is the field name. To access the field of a class the field must be static. For example, to get the value of the static field named "EXIT_ON_CLOSE" of the "JFrame" class, write

    value := java javax_swing_JFrame EXIT_ON_CLOSE.

or (using short names):

    value := java JFrame EXIT_ON_CLOSE.

The variable "value" now holds the integer value of the "EXIT_ON_CLOSE" constant.

Assuming that a "JFrame" object had a field named "myField", to access this field, we'd have to write:

    value := frame myField.

and "value" now holding whatever "myField" returns. This could be another object reference or any primitive value.

Setting Fields

To set a field, use a setter-like method call:

    frame myField: newValue.

Name Conflicts

In very rare situations, a Java object may contain both a field and a method by the same name. In this case, the Smalltalk code cannot depend on the dynamic translation mechanism (which actually looks for either a field or method name to match), but instead make it explicit, which operation is wanted: Use:

    frame getFieldByName:'myField'

to read a field, and:

    frame setFieldByName:'myField' value:123.

to write the field.

If there are both fields and methods by the same name, and you use the non-explicit call, the bridge will always assume that you want to call the getter/setter and perform a method call.

Callbacks from Java

Sometimes you may want to execute a piece of Smalltalk code during the execution of the Java code. For example, we may want to install a Smalltalk observer to be notified when a button on a Java GUI was pressed, or some other callback from a Java framework.

The following code registers a Smalltalk block as a callback for a mouse press event of a button:

    listener := MouseListener new.
    listener mousePressed:[ Transcript showCR:'Hello from Java' ].

The above creates the callback and the listener, which can now be registered on a button:

    button addMouseListener:listener.

Now, with the press of the button in the Java GUI, the Smalltalk block will be executed and writes "Hello from Java" to the Smalltalk console. Of course, any other (Smalltalk-)action code can be made to run via this mechanism.

But be aware, that the callback is possibly called later (when the elementary action, which installed the code, has already finished long ago). Also, as the Java code execution is not synchronized with any of your expecco action execution, the callback may also be called at any arbitrary time, even at times when no activity at all is executed on the expecco side. If you forget to cleanup, and the Java object is still alive, it may even be called after you have finished your test run (if you keep the Java Bridge handle around and alive, for example in an expecco environment variable).

So the Smalltalk callback code should not depend on any particular elementary action to be currently running, but instead in most cases write some information into a shared data container, preferably an instance of "SharedQueue", which is thread safe. Then, some other action (an elementary action) would read-wait and read events from that shared queue.

make sure that your test correctly cleans up any such callbacks afterwards. As a last resort, use the "Shutdown Bridge Connection" menu item, which closes the bridge connection, and thereby - as a side effect - removes any leftover callbacks. It does close the connection, and any remaining Java proxy object handles become invalid, though.

Another example, using an observer could look like:

    observer := java Observer new.
    observer update:[:sourceObservable :argument| 
        argument notNil ifTrue:[ Transcript showCR:('I was notified with: ',argument toString) ]
        ifFalse:[ Transcript showCR:'I was notified and the argument was nil' ].
    ].
    myObservable addObserver:observer.

When the observable calls "notifyObservers", the Smalltalk block will be executed.

Exceptions in Java

Exceptions on the Java side are signalled back to the Smalltalk side and raise a corresponding exception there. However, on the Java side, the call stack which lead to the exception has already been unwound at that time (Java exceptions are not proceedable). So a proceed in the Smalltalk-side exception handler only affects the Smalltalk caller, but may leave the Java side in an undefined state.

Examples

This example creates a JFrame with one button inside. Then a MouseListener is created and registered on the button. When the button is pressed, the title of the window changes to "onPressed" and the Transcript shows the message "onPressed". When the button is released, the title of the window is changed to "onReleased" and the Transcript shows "onReleased". If the button lost the mouse focus, the bridge will exit (disconnect), and the Java side is terminated.

    |java frame button listener|
 
    "/getting a bridge
    java := JAVA::JavaBridge newWithServer.

    "/creating a new frame and button object
    frame := java javax_swing_JFrame new.
    button := java JButton new:'Click'.

    "/creating a new mouse listener and adding callback blocks
    listener := java MouseListener new.
    listener mousePressed:[ Transcript showCR:'onPress'. frame setTitle:'onPressed' ].
    listener mouseReleased:[ Transcript showCR:'onReleased'. frame setTitle:'onReleased' ].
    listener mouseExited:[ Transcript showCR:'onExited'. java closeBridge. ].

    "/register the mouse listener on the button and make the frame with button visible
    button addMouseListener:listener.
    frame add:button.
    frame setSize:300 y:100.
    frame setVisible: true.

Simple RMI Call

The next example is written in JavaScript syntax. It shows how an RMI host is queried for an RMI object and then the "getHello" method is called on it. The following code is not directly executable: you must replace the path to the compiled MyRemoteObject class with the directory containing the class file, and replace the RMI host name with a real one in your network:

    var java, reg, myRemoteObject, callResult;

    // Start a local Java VM and connect the Communication-Bridge to it
    java = JAVA::Java.singletonInstance;  

    // Add the class path where the description class of the shared RMI object can be found. RMI could also load the class from the server, but then we would need a RMI SecurityManager with download rights
    java.bridgeSide.addClassSearchPath("my\added\class\path"); 

    // java.rmi.registry.LocateRegistry gets us the RMI Registry on the host
    reg = java.java_rmi_registry_LocateRegistry.getRegistry("rmiHost",4567);  

    // get the rmi object
    myRemoteObject = reg.lookup("myObject");   

    // get the hello string that was written by the RMI server into the rmi object
    callResult = myRemoteObject.getHello();

The RMI server written in Java:

RMIServer.java:

    import java.rmi.AlreadyBoundException;
    import java.rmi.RemoteException;
    import java.rmi.registry.LocateRegistry;
    import java.rmi.registry.Registry;

    public class RMIServer {

        public static void 
        main( String[] args ) throws RemoteException, AlreadyBoundException, InterruptedException {
            int port = 4567;

            if(args.length > 0)
                port = Integer.parseInt(args[0]);
                    
            Registry reg = LocateRegistry.createRegistry(port);
            reg.bind("myObject", new MyRemoteObject("Hello from RMIServer: "+port));
            while(true) {
                Thread.sleep(100);
            }
        }
    }

The implementation of the shared RMI object written in Java:

MyRemoteObject.java
    import java.io.Serializable;
    import java.rmi.Remote;

    public class MyRemoteObject implements Remote,Serializable {
            
        private static final long serialVersionUID = 1L;
            
        private String hello;
            
        public MyRemoteObject(String hello) {
            this.hello = hello;
        }

        public String getHello(){
            return hello;
        }
    }

API

JAVA::Java

class protocol

newWithServer

• This will start a local Java VM, running the Java Bridge, and establishes a connection on a random free port.

A new connected instance of JAVA::Java class is returned.

newWithServerForJavaPath:aJavaPathFilename

• This is the same as newWithServer but the path to the Java executable can be specified. The Java VM version must be 1.6 or higher to run the Java Bridge.

aJavaPathFilename - must be a instance of Filename

   Smalltalk: JAVA::Java newWithServerForJavaPath:('my\path\to\java.executable'asFilename).
   JavaScript: JAVA::Java.newWithServerForJavaPath("my\path\to\java.executable".asFilename());

newConnectedTo:aHostString port:aPortNumber withTimeout:aTimeoutSeconds

• This is used to connect to a running Java Bridge on the network. The Java Bridge must be started in server mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.

aHostString - the hostname or IP of the remote machine as String

aPortNumber - the port on which the remote machine is listening as Number

aTimeoutSeconds - a connect timeout in seconds as Number

   Smalltalk: JAVA::Java newConnectedTo:'myHostName' port:4567 withTimeout:30.
   JavaScript: JAVA::Java.newConnectedTo_port_withTimeout("myHostName",4567,30);

newWaitingForConnectOnHost:aListeningAddressString port:aListeningPortNumber withTimeout:aTimeoutSeconds

• This is used to wait for incoming connections of a running Java Bridge on the network. The Java Bridge must be started in client mode on the remote host. After connecting a new connected instance of JAVA::Java is returned.

deprecated: aListeningAddressString - no longer used. Can be nil.

aListeningPortNumber - the port on which to listen for incoming connections as Number

aTimeoutSeconds - a connect timeout in seconds as Number, If nil it will wait endless.

singletonInstance

• This will call newWithServer for the first time and then always returns the same connected JAVA::Java instance until the connection was closed, then a new connected instance is returned.

exitAllInstances

• This will close all instances of JAVA::Java.

instance protocol

addJarByPath:aPath

• Adds a jar to the class path of the running Java VM. If the jar depends on other jars or libraries you have to add them too.

aPath - the path to the jar file as String.

addLibraryByPath:aPath

• Adds a library to the library path of the running Java VM. If the library depends on other libraries you have to add them too.

aPath - the path to the library file as String.

isConnected

• Tests if a connection is still established.

return: - true if the connection is still established, else false.

isAlive

• Tests if a connection is still responding.

return: - true if the connection is still alive, else false. Does a message round trip.

closeBridge

• This will close the bridge connection. Depending on in which mode the Java Bridge was started, the Java VM is also closed (-keepAlive startparameter not set).

exit

• Same as closeBridge.

See Also

The DOTNET Interface Plugin & Library, which implements a likewise interface for .NET applications/libraries.
Version 2 of the Java Interface Library

---

Back to Plugins
Back to Online Documentation.

---

Copyright © 2014-2024 eXept Software AG