This is documentation for Mathematica 5, which was
based on an earlier version of the Wolfram Language.
View current documentation (Version 11.1)

Documentation / Mathematica / Add-ons & Links / J/Link / Part 1. Installable Java: Calling Java from Mathematica /

1.2.10 Using JavaBeans

JavaBeans is Java's component architecture. Beans are reusable components that can be manipulated visually in a builder tool. At the code level, a Bean is essentially just a normal Java class that conforms to a particular design pattern with respect to how its methods are named and how it supports events and persistence.

We have not mentioned JavaBeans up to this point because there really is not anything special to be said. Beans are just Java classes, and they can be used and called like any other classes. It is probably the case that many Java classes you use from Mathematica will be Beans, whether they advertise themselves to be or not. This is especially true for user interface components.

Beans are typically designed to be used in a visual builder tool, where the programmer is not writing code and calling named methods directly. Instead, a Bean exposes "properties" to the builder tool, which can be examined and set using a property editor window. In a typical simple example, a Bean might have methods named setColor and getColor, and by virtue of this it would be said to have a property named "color." A property editor would have a line showing the name "color" and an edit field where you could type in a color. It might even have a fancy editor that puts up a color picker window to let you visually select a desired color.

For the purposes of a visual builder tool or other type of automated manipulation, beans try to hide the low-level details of actual method names. If you want to call methods in a Bean class from Mathematica code, you call them by name in the usual way, without any consideration of the "Bean-ness" of the class.

Note that it would be quite possible to add Mathematica functions to J/Link that would provide explicit support for Bean properties. For example, a function BeanSetProperty could be written that would take a Bean object, a property name as a string, and the value to set the property to. Then, instead of writing what is currently required:

you could write:

The BeanSetProperty function lets you write code that manipulates nebulous things called properties instead of calling specific methods in the Bean class. If you do not see any particular advantage in the BeanSetProperty style, then you know why there is no special Bean support along these lines in J/Link. The advantages of working with properties versus directly calling methods accrues only when you are using a builder tool and not actually writing code by hand.

If you are interested, here are simplistic implementations of BeanSetProperty and BeanGetProperty:

BeanSetProperty[bean_?JavaObjectQ, propName_String, val_] :=
    Module[{methName = "set" <> ToUpperCase[StringTake[propName, 1]] <>
            StringDrop[propName, 1]},
        Through[(bean @@ ToHeldExpression[methName])[val]]
    ]

BeanGetProperty[bean_?JavaObjectQ, propName_String] :=
    Module[{methName = "get" <> ToUpperCase[StringTake[propName, 1]] <>
            StringDrop[propName, 1]},
        Through[(bean @@ ToHeldExpression[methName])[]]
    ]

To make use of events that a JavaBean fires, you can use one of the standard MathListener classes, as described in Section 1.2.7. JavaBeans often fire PropertyChangeEvents, and you can arrange for Mathematica code to be executed in response to these events by using a MathPropertyChangeListener or a MathVetoableChangeListener.