JavaBeans « Development « Java Articles

For some, XML seems one of those ideas that, while exciting at first, isn't entirely useable in practice. How would a developer use XML in a real life system? What good is the ability to define custom tags if no browsers understand them? In this month's column, we'll look at a possible application of XML -- namely, using it as a serialization format for JavaBeans.

If you're new to XML, you might consider reading "XML for the absolute beginner," (JavaWorld April 1999). This article discusses JavaBeans property descriptors, property editor classes, and BeanInfo objects, topics previously covered in "The trick to controlling bean customization," and "Soup up your Java classes with customization." Once you have a passing understanding of these subjects, you'll be ready to tackle this final installment of the XML JavaBeans series.

I've received some great ideas from readers on how to improve XML JavaBeans, so I've expanded this topic from two installments to three. This month, we're going to develop a class, XMLBeanWriter, which writes a JavaBean in XML format. Then next month, we'll look at some of the improvements suggested by readers, and implement them (in Java, of course).

As you will see, even the building-block beans are useful for other purposes, which demonstrates another benefit of the JavaBeans approach: As you develop with JavaBeans you build up a library of components that can be reused in future development efforts, saving the time it would have taken to extract or rewrite them.

Though object persistence may seem like a new idea to you, you're probably more familiar with it than you know. Every file on your hard drive or floppy disk can be thought of as a persistent software object of one sort or another. For example, let's say you use a text editor to create a text file. At one point in time, there was a data structure in memory on some computer that contained the characters of your document. When you gave the editor the Save As command, you were really telling the program to persist the contents of its memory to a disk file. (Thank goodness the people who design user interfaces know better than to present information to users this way -- teaching my mom to use a word processor is hard enough without having to deal with menu items like Persist Memory State!)

You might think that this is simply the tale of three different RAD environments, each with their own language. You'd be right in one sense, but you know as well as I do that nothing is quite so simple. The Java language has injected a significant kink into the way programmers are taught to think. That kink was felt most strongly at Microsoft, which saw another competitor to its Visual Basic on the horizon. It was with this in mind that Microsoft took some existing work on generalizing VBXs for its other programming languages and created ActiveX -- a component architecture allegedly suitable for all languages. To reinforce this point, Microsoft has provided support in its newest development tools to invoke ActiveX controls from Java and to invoke Java from ActiveX controls.

Software components hide implementation, conform to interfaces, and encapsulate data, just like classes do in object-oriented languages. So how do components differ from classes? The answer: Almost all software components are also classes. What makes them components is their conformance to a software component specification. The JavaBeans Specification is the document that describes what a Java class must do to be considered a "Bean." Programmers (and, as importantly, integrated development environments [IDEs]) can depend on any class that advertises itself as a Bean to conform to the rules set out in the specification. If it doesn't conform, the contract has been broken and the Bean is defective.

In the September issue of JavaWorld, in my article "Double Shot, Half Decaf, Skinny Latte: Customize your Java," we looked at how to make JavaBeans customizable. A simple naming scheme provides a minimal mechanism for giving an Integrated Development Environment (IDE) or other bean container object -- like the BeanBox, for example -- a way to let a user customize a bean. (For more information on the BeanBox, see my JavaWorld article "The BeanBox: Sun's JavaBeans test container.") When a bean needs to be customized, the IDE analyzes the bean's class and creates a quick-and-dirty dialog box containing little edit widgets (called property editors) for each property, which it then pops up on the screen. Controlling, replacing, and extending what gets popped up is what this article is all about.

Java Beans is the API set for interoperability with non-Java object systems and portability mechanisms. Multimedia programmers are waiting for the Java Media API, which will help them build applications as amazing as the popular packages of today, such as Adobe Photoshop and Premiere and Macromedia Director.

Section 6.5.1 of the JavaBeans 1.01 specification contains an example of event-listener registration and event-listener notification. The source code from this example forms the basis of my analysis:

And, with the growth of the Internet, file upload has now also played significant roles beyond email applications. Other Internet/intranet applications such as Web-based document management systems and the likes of "Secure File Transfer via HTTP" require uploading files to the server extensively. This article discusses all you need to know about file upload. But first things first. Before you jump too excitedly into coding, you need to understand the underlying theory: the HTTP request. Knowledge of the HTTP request is critical because when you process an uploaded file, you work with raw data not obtainable from an HttpServletRequest object's methods such as getParameter, getParameterNames, or getParameterValues.

Well, Robin, of course it will. There are several architectures that application server vendors can use to make your session beans more scalable and more fault tolerant. In my previous article, EJB 2 Clustering with Application Servers, I talked about the generic approaches that a vendor can use to load balance and cluster EJBs, focusing on the importance of load balancing and fail over logic contained directly within the home and remote stubs downloaded to a remote client. This article will expand upon that approach for stateless session EJBs by demonstrating additional load balancing and fail over techniques.

When talking about data binding in Java, people usually think of mapping the contents of XML files to Java objects, as such frameworks have become very popular through the years. However, JAXB or Castor just implement a more general concept. Data binding means wiring attributes or properties of different data structures and optionally keeping them in sync. These can also be JavaBeans.

Consider using the Beans Binding API in your next project. You may be able to save considerable time and effort binding and synchronizing properties between two different Java Bean components. The API allows you all the benefits of synchronized properties but minimizes the amount of code you write for event listening and propagation.

If you've experimented with XML and JavaBeans in this series, you'll have noticed that the XMLBeanWriter class we created in Part 2 is capable of creating XMLBeans XML files that the XMLBeanReader from Part 1 can't read. Some readers have also noted that the XMLBeans file format is somewhat complicated, and that controlling which properties are encoded in XML and which properties are ignored requires a lot of tedious coding. This month, we'll solve these problems by restructuring the XMLBeanReader and XMLBeanWriter classes. In the process, we'll simplify the file format while maintaining backward compatibility. Perhaps most interestingly, we'll simplify and generalize controlling XMLBeans properties by integrating XMLBeans with the core java.beans package.

The Vehicle and Car bean source code provided here illustrates practical use of most of these rules and can be used as a basis or template for future entity beans developments. ( To download the jar file, right-click on the link and then click 'Save Link As'.)

From the point of view of the InfoBus architecture, the application architecture looks a bit different. Note that the InfoBus is similar to a hardware bus; the three applets are all plugged into the same bus, as peers shown in Figure 2. In principle, all applets can see the events generated by all other applets; it is up to the application designer to control which data items will be produced or consumed by each applet. InfoBus-connected applets must all live in the same Java Virtual Machine1, but that doesn't mean InfoBus can't participate in distributed applications. In our example, the DAC has a connection to a remote data source and uses JDBC to query it.

Currently there is no standard way to add validity constraints to Java classes. This is in contrast to other languages like XML in which (using XML Schema) relatively rich constraints may be specified. With the advent of annotations (JSR 175) in the Java 2 Platform, Standard Edition (J2SE) 5.0 a convenient mechanism now exists to allow such constraints to be specified in the Java meta model. This article explores how annotations might be used for this purpose and discusses why this may be an important capability.

Netscape Communications Corp. unveiled details of its new proposed model for using JavaSoft's JavaBean technology, and demonstrated a prototypical application based on the new BeanConnect model at the Netscape Developer Conference.

By using Remote Method Invocation (RMI) in distributed Java application development, no low-level socket or network communication code is involved. The code remains at a higher level, leveraging its use of RMI classes. Similar gain comes with the use of Enterprise JavaBeans (EJB) technology, freeing developers from several low-level coding aspects (transaction, recovery, and activation). With this tip's JavaBean-XML mapping component, developers don't directly deal with XML-related APIs.

Every body shuns CMP entity beans be either they try to blame J2EE or get some political mileage for their unveiled agenda. This happens almost every thread at least in community forums like TheServerSide.com or JavaLobby. However I was surprised to see a houseful when I presented ?Optimizing Container Managed Persistence with Relational Databases? with Mike Keith in JavaOne this year. I was expecting very few attendees with ongoing slaughter of CMP entity beans in the community forums and the fact that EJB is having a quantum loop in the EJB 3.0 spec. And almost everyone stayed in the room. After the presentation, I spoke to few attendees and almost every one of them use CMP entity beans in their production application servers such as Weblogic, OC4J or Websphere. Most of them are happy with their the scalability requirements of their applications.

If you want to use a BLOB column in the database you have to declare a CMP field of byte[] in your entity bean and map this field to the database column of type BLOB. For using CLOB column types in the database you have to use either types java.lang.String or char[] for the field types in the CMP entity bean.

Like, I suppose, many Java developers, I have so often read about the supposed scalability problems associated with stateful session beans, that I simply accepted that these problems were real, and refused to even consider using stateful beans. I guess this was laziness, but we don't have time to verify everything we read - and I'd never had cause to doubt that what I read was correct.

However, being the purist that I am, Sun's wrapper class was not good enough for me. My goal was to create a wrapper class that would make JMS communication as easy as sending and receiving JavaBean events. So I created the Event Distributor, which uses the JMS publish/subscribe paradigm to distribute JavaBean events across Java virtual machines without exposing its details (and repeated code). You can even configure it to use persistent or non-persistent message delivery.

Using the Swing-Specific Binding Utilities Many existing Swing controls do not provide the proper getters and setters in their APIs to easily bind JavaBeans to them. In order to work around this, Beans Binding provides a Swing-specific extension class called SwingBindings. It contains some additional methods that allow you to easily bind a list to a JTable, for example:

Java 5.0 provides new abilities to monitor and manage a running virtual machine. Developers and system administrators can oversee -- and, for some properties, fine-tune -- the performance of a 5.0 VM. The mechanism for carrying out these activities will be familiar to anyone who has prior experience of using Java Management Extensions (JMX). Through JMX technology, a set of platform resources to be controlled can be regarded as simple, well-defined objects whose properties map to the lower-level characteristics of the given resource.

A friend once told me that whenever he learned a new programming language, he would challenge himself to write a Tetris game using that language. So in this tradition, I took it upon myself to do the very same when I first learned to program using the Java language. My first attempt, although a complete game, was very basic and very ugly. As time went on and I gained greater experience in Java design and development, I knew that I could separate the game model from the GUI (similar to Swing components) and create a Tetris bean. So I set about doing just that.

It is now time to look at the process of building an entity bean. We will develop a simple CMP bean, but spend most of our time investigating and perfecting the process.

While developing a small database application for keeping a work journal, I discovered I needed a way to map JavaBean properties to JTable columns. This led to creation of a component for accessing JavaBean properties by name at runtime -- in other words, a JavaBean proxy. In this article, I illustrate my simple JavaBean proxy and show how JavaBean proxies can be created with the new dynamic proxy classes in JDK 1.3.

In part one ( Start serving Java Server Pages: Introduction ), we introduced Java Server Pages and showed some simple examples. Hopefully, you were able to appreciate some of the benefits of JSP and how it simplifies Web application development.

If you choose ActiveX, you'll be limited for now to Windows95 and NT, but that may not represent a limitation for you, and the performance improvement relative to Java may be substantial. With JavaBeans, you'll be developing components that can be shipped over a network and implemented on virtually any machine, regardless of operating system.