The other major change is the inclusion of the dynamic event adapter generator. This eliminates the need to write the one liner event adapters that you may have had to write previously - this generator automatically generates byte codes (not Java code) for these adapters on demand!

Finally, a "value" attribute has been added to string and cast by popular demand.

The player can be used as a driver to run Java applications created dynamically or otherwise. The BML language allows one to easily and completely describe the structure of component Java applications (i.e., apps consisting of a set of beans wired together to form the functions of the application). The player is a very small interpreter for this language that can be easily embedded in applications or Web pages (using the Java plug-in from Javasoft). By embedding the player in an application, you can expose the application to dynamic configuration and editing by BML scripts at any time.

The BML compiler generates Java code from a BML script. The code that is generated is basically the same Java code you would have written to implement the configuration that the script describes. Hmm, in that case, why would I have written something in BML if I could've done it in Java directly you ask?

BML, the language is really an abstract model for describing the structure of a component-based application. The advantage of describing the structure in this form vs. in Java is that the structure is explicit rather than implicit. If you don't need the dynamic execution flexibility offered by the BML Player which interprets these scripts, then you can simply compile the script to get the .java and .class files which do exactly what you want without the added overhead of including the player in your application. The compiler is also useful if you generate wirings using processes such as XSL, but you don't need the dynamicism. Then, you generate the BML script (since that's a lot more natural to generate in an XML environment such as XSL vs. generating Java code) and then compile it to get the Java code you want.

The capabilities of BML as a bean configuration mechanism are similar to those of bean builders, with the added advantage of being an automatically generable text form instead of an interactive tool. No, we're not expecting that VisualAge for Java users would suddenly switch to BML either! So, why BML??

- BML is useful in cases where you want to configure a set of beans in a non-interactive setting. For example, if you are using XSL to generate a Java application, then you want BML.

- It is also useful when you want to dynamically modify or create new components and wire them into the running application (using the player, see below). A demo of this is available now using the base juggler demo and adding functionality to it (see the user's guide for details).

- It is also a useful high-level, textual abstraction to capture the structure of component-based applications. That is, while bean configuration in Java is of course possible and extremely popular, writing Java code does not make explicit the set of components (beans) that comprise the application and how they inter-relate. Java is a superb language for implementing components, but when Java is used to wire the components together (which is the typical task of the "main" program), Java is not necessarily the best tool; BML is what you want.

Application generation via XSL still remains as a major use of BML. This allows one to generate (from a server say) a Java application instead of an HTML application in response to a query against the server for some XML content.

BML's architecture is fully extensible and if there's interest we will document it and make it available. The extension framework which was mentioned earlier is also in the same category!