Review of Three JMX Books

There are several good books that cover the basics of the Java Management Extensions (JMX) specification. Unfortunately, they are all somewhat outdated at this point. While the basics of JMX are largely the same now as when these books were published, there are many new concepts and additions to JMX that make JMX much easier to use and more flexible than when these books were published. Although just about anything one might want to know about JMX can now be found on the web in articles, blogs, and book chapter excerpts, it is still sometimes useful to have access to a solid JMX book for reference or as a single source to learn about JMX.

In this blog entry, I provide my opinions of three JMX books that I have spent significant time reading and learning from. The three books that I have used to learn about JMX and which I use as JMX references are (in order of publication) Java Management Extensions (O’Reilly), JMX in Action (Manning), and Pro JMX (Apress). I will review them in the same order in which they were published. Before my individual book reviews, however, I will make some general observations regarding these JMX books.

All three of these JMX books, because of their publication dates, do not cover the following “staples” of modern JMX:
* Platform MBean Server provided with J2SE 5 and Java SE 6, including all the useful JMX utility classes introduced with J2SE 5 and Java SE 6
* MXBeans
* Web Services Connector as defined by JSR-262
* JConsole
* Spring framework support for JMX
* Ability for all types of MBeans, not just Model MBeans, to have Descriptors
* JMX best practices and lessons learned are not as prevalent (though some are mentioned in these books) as they are now simply due to lack of time to learn these lessons and observe and collect these best practices.

Another common characteristic of all these JMX books is that none has had a second edition. The reason for this in the case of the O’Reilly JMX book has to do with apparent lack of interest in the first edition. It wouldn’t surprise me if this was at least part of the explanation for no second edition of any of these JMX-focused books.

Java Management Extensions, O’Reilly

The first of the JMX books, this is a useful introductory text for the basics of JMX. Because of its early release date, it does not have any significant coverage of Remote JMX concepts, though it does cover the concept of JMX Connectors versus JMX Adapters as well as could have been done at time of publication. One of the strengths of this book is the chapter introducing all of the MBean types followed by individual chapters devoted to each MBean type available at the time (Standard, Dynamic, Model, and Open). The individual, highly detailed chapters on each type of MBean make this a useful reference for writing these different types of MBeans and the introductory chapter on all types of MBeans helps compare and contrast the MBean types while providing guidance on which MBean types are best for which situations.

A significant advantage of this book that contributes to its value as a reference is its index. I have been frustrated by some technical books that do not include a thorough index. In such cases, I often find myself needing to write in page numbers and topics not already listed in the index but covered in the book. It is very frustrating to know (or at least seem to remember) something covered in a book, but having to spend considerable time finding it again. This O’Reilly JMX book has a thorough index that I seldom find myself needing to add any new topics or page references in. This certainly contributes greatly to its value as a reference.

For me, the biggest disadvantage of this book is exactly what was its advantage at time of publication – it being the first JMX book released. The book is well-written and useful, but by nature of being the earliest of the JMX books reviewed here necessarily lacks some of the developments in JMX that occurred shortly after this book’s publication. The most glaring of these omissions is lack of coverage for remote JMX. The book’s author has blogged about a desire to write a second edition covering some of these newer features, but explained that the first edition did not sell well enough to justify a second edition. That’s a shame because this is a very useful JMX reference and a greatly enhanced second edition would be welcome.

There are several specific characteristics of this JMX book that I have found to be particularly useful. These include the description of using TYPE in descriptors for fundamental types (pp. 67-68) and the coverage of the different types of MBeans. I like how this book covers each of the four types of MBeans briefly and in relation to each other early in the book (pp. 4-12) and then provides a chapter dedicated to each individual type of MBean. This approach is useful because the early introduction allows one to quickly compare the MBean types and to see how they differ. Then, the dedicated chapters provide a nice reference for details on each MBean type. Of course, MXBean was not around at the time and so is not a covered MBean type.

Other reviews for Java Management Extensions are available and include Does O'Reilly's New Book Explain What You Need to Know about JMX? and the Plano Java Users Group review.

At the time of this writing, Chapter 2 of Java Management Extensions is currently available for free download from http://www.oreilly.com/catalog/javamngext/chapter/ch02.pdf.

JMX in Action, Manning

To me, the most compelling feature of this JMX book is the care taken to gently introduce JMX to readers with no previous JMX experience. This book does an excellent job of explaining why one might want to use JMX and of introducing JMX. I particularly liked the book’s explanation of the difference between a JMX Connector and a JMX Adapter. JMX in Action may be the best of the books for an introductory read on JMX. Like the O’Reilly book, JMX in Action focuses on different MBean types in different chapters and can be a useful JMX reference. Because it is newer than the O’Reilly book, it can also cover some JMX ideas that matured since publication of that book.

One of my favorite features of this book is its coverage of a ModelMBeanInfoBuilder class (starting on page 155). When I first used Model MBeans, I had a very similar idea in mind and it was nice to see it already coded. This example pre-dates J2SE 5 and so can be improved with use of generics, enums, and other nice features introduced with J2SE 5.

The most significant disadvantage of JMX in Action is the same as that of the O’Reilly JMX book – it predates Remote JMX and so does not cover that as well as one would like.

At the time of this writing, three sample chapters of JMX in Action are available for free download. These sample chapters are Chapter 2, Chapter 4, and Chapter 9.

There are several other reviews of JMX in Action, including this JavaRanch review (see bottom or go to this page) and the Denver Java Users Group review.

Pro JMX, Apress

I may be wrong about this, but it seems like this book may have originally (at least during writing) had a title of “Connecting JMX Clients and Servers.” In many ways, this would have been a more appropriate title for this book. This book focuses heavily on Remote JMX API and has relatively little coverage of JMX basics as compared to the two previously reviewed books. While an advantage this book has over the two previously reviewed versions is its coverage of the Remote JMX API, this advantage is somewhat reduced by the fact that much of the book’s content is exactly the same or nearly the same as the writing in the JMX specification (to which the author was a contributor). I prefer books covering a specification to provide significant abstraction and new perspective on the specification rather than being word-for-word or very similar to the specification.

Another review of Pro JMX is available in Val’s Review of Pro JMX.

Chapter 3 of Pro JMX is available for download (at time of this writing) at http://www.apress.com/book/downloadfile/1743.

Additional JMX Book Resources

There are some other reviews of JMX books out there. Of course, Amazon.com and Bookpool and other book sellers have reviews on their sites (some of these books can be purchased at deep discounts through Amazon Marketplace or other used book selling options). Sandy McArthur provides brief reviews of two JMX books here. Additional details on freely available JMX book chapters can be found here. Chapter 2 of Java and JMX: Building Manageable Systems [Addison-Wesley] (a book I have not read and did not review here) is also available online for free review.

No Java Switch on Long

Section 14.11 ("The switch Statement") of the Third Edition of the Java Language Specification lists the types that the Java switch statement can support switching on. The Java switch statement supports switching on byte, Byte, char, Character, int, Integer, short, Short, or an Enum. When I was first learning Java, it was somewhat surprising to me that Java supported these integral types (except Enum which was not available at that time!), but did not support long or Long. Switching on non-integral types did not make sense, of course, due to the inability to precisely compare non-integral types. However, it seemed like long should be a valid type to switch on as shown in the next code listing.

package longswitch;

/**
 * This example demonstrates the switch statement.
 */
public class SwitchExample
{
   public static void main(String[] arguments)
   {
      final long value = System.currentTimeMillis() % 5;
      switch ( value )
      {
         case 1 : System.err.println("One");
                  break;
         case 2 : System.err.println("Two");
                  break;
         case 3 : System.err.println("Three");
                  break;
         case 4 : System.err.println("Four");
                  break;
         default : System.err.println("Default");
            break;
      }
   }
}

When one tries to compile the above code, an error ("possible loss of precision") like that shown in the next image is encountered.



As the Java Language Specification pointed out, a compiler error did result from using one of the types (long) that was not listed in the specification.

The code below makes the compiler error go away and, in this simple case, there is probably no need to worry about any rounding or truncation that might occur in the conversion of the long to an int.

package longswitch;

/**
 * This example demonstrates the switch statement.
 */
public class SwitchExample
{
   public static void main(String[] arguments)
   {
      final long value = System.currentTimeMillis() % 5;
      switch ( (new Long(value)).intValue() )
      {
         case 1 : System.err.println("One");
                  break;
         case 2 : System.err.println("Two");
                  break;
         case 3 : System.err.println("Three");
                  break;
         case 4 : System.err.println("Four");
                  break;
         default : System.err.println("Default");
            break;
      }
   }
}

In practice, we rarely "need" to switch on a long and the ability to switch on an int or Enum are sufficient. In fact, especially before Enum was available, I would have liked the ability to switch on String more than on long. Of course, as I have blogged about before, some people insist you should never use the switch statement. The Scala language provides a switch-like match that does not use or require break statements (which Scala does not support). I think that switch statements can be a red flag indicating possible design problems, but I also reject the argument that they are always bad or always the worst possible approach to a particular problem.

Sun's Java HTTP Server

Some colleagues have pointed out that Sun's implementation of Java SE 6 JRE includes a built-in Java HTTP Server. There is not much information regarding this online, but there are enough details to start using it for small HTTP service needs.

The main step a developer must perform to make use of the built-in HTTP server is to implement the HttpHandler interface. The Javadoc API description for com.sun.net.httpserver contains an example of implementing the HttpHandler and includes an example of how to apply TLS/SSL.

The code listing that follows is my own implementation of the HttpHandler interface and is adapted from the example provided in the Javadoc documentation for package com.sun.net.httpserver.

package dustin.examples.httpserver;

import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import java.io.IOException;
import java.io.OutputStream;

/**
 * Simple HTTP Server Handler example that demonstrates how easy it is to apply
 * the Http Server built-in to Sun's Java SE 6 JVM.
 */
public class DustinHttpServerHandler implements HttpHandler
{
   /**
    * Implementation of only required method expected of an implementation of
    * the HttpHandler interface.
    * 
    * @param httpExchange Single-exchange HTTP request/response.
    */
   public void handle(HttpExchange httpExchange) throws IOException
   {
      final String response = buildResponse();
      // UPDATE (01 April 2008): Thanks to Christian Ullenboom for pointing
      // out the constant used below (see comments on this blog entry below).
      httpExchange.sendResponseHeaders(HttpURLConnection.HTTP_OK, response.length());
      final OutputStream os = httpExchange.getResponseBody();
      os.write( response.getBytes() );
      os.close();
   }

   /**
    * Build a String to return to the web browser via an HTTP response.
    * 
    * @return String for HTTP response.
    */
   private String buildResponse()
   {
      final StringBuffer response = new StringBuffer();
      response.append("<title>Sun's JVM HttpServer in Action</title>");
      response.append("<h1 style=\"color: blue\">Hello, HttpServer!</h1>");
      response.append("<p>This example shows that the Java SE 6 HttpServer ");
      response.append("included with the Sun JVM is easy to use.</p>");
      return response.toString();
   }
}

The HttpHandler implementation shown above can be executed with a simple Java application as shown in the next code listing. Note that the port and the URL context that will be used to access the HttpServer are specified in this main executable code rather than in the more generic HttpHandler implementation above.

package dustin.examples.httpserver;

import com.sun.net.httpserver.HttpServer;
import java.io.IOException;
import java.net.InetSocketAddress;

/**
 * Simple executable to start HttpServer for HTTP request/response interaction.
 */
public class Main
{
   public static final int PORT = 8000;
   public static final int BACKLOG = 0;   // none
   public static final String URL_CONTEXT = "/dustin";

   /**
    * Main executable to run Sun's built-in JVM HTTP server.
    * 
    * @param args the command line arguments
    */
   public static void main(String[] args) throws IOException
   {
      final HttpServer server =
         HttpServer.create(new InetSocketAddress(PORT), BACKLOG);
      server.createContext(URL_CONTEXT, new DustinHttpServerHandler());
      server.setExecutor(null); // allow default executor to be created
      server.start();
   }
}

To compile these two classes, one simply performs normal compilation of the Java classes. To run the HTTP Server, one simply runs the main executable just shown. This is demonstrated in the following screen snapshot.



The HTTP Server runs until I instruct it to stop with a CTRL-C. While it is running, I can view the rendered web page by accessing a URL based on port specified in the main class (8000) and a web context specified in the main class ("/dustin"). A screen snapshot of the rendered page in a web browser is shown next.



There are several important observations to be made regarding use of the HTTP Server.

1. The package com.sun.net.httpserver makes it clear that this functionality is part of Sun's JRE implementation and is not standard across all JREs for Java SE 6.

2. It is not shown here, but the Spring framework provides a SimpleHttpInvokerServiceExporter to make use of the Java HTTP Server. Related classes include SimpleHttpServerFactoryBean and SimpleHttpInvokerRequestExecutor. The Spring 2.5, an Update presentation (see slide 16).

3. The Java HTTP server is not a full-fledged HTTP Server.

4. This blog entry refers to the Java built-in HTTP server as "Core HTTP Server" and references "mini servlets."

5. See Bug ID 6270015 ("Support a Light-weight HTTP Server API").


As the code listings and snapshots above demonstrate, it is a straightforward process to implement a simple Java HTTP Server using the Sun-supplied built-in Java HTTP Server.

UPDATE (23 November 2008) Software Development: Easiest way to publish Java Web Services --how to talks about how to use this HTTP Server to publish web services.

Using JEdit with OpenLaszlo and Flex

I like to use JEdit for many "quick and dirty" revisions, especially when I don't want to deal with a full-fledged Java IDE's need for IDE-specific set-up like projects. JEdit can be especially useful for making minor changes to a particular file. I really grew to like JEdit for Ruby text file editing (no compiling, building, or assembling needed in that situation). In this blog entry, I'll demonstrate how easy it is to configure JEdit to employ XML color coding for OpenLaszlo's XML-based LZX language and for Flex's XML-based MXML language.

If you don't do anything to associate LZX or MXML files with XML in JEdit, they will appear as shown in the following two screen snapshots (click on images to see larger versions). The OpenLaszlo file is shown first, followed by the MXML file. Note that there is no color coded syntax in either example.





To enable color syntax highlighting for any file currently open in the JEdit buffer, one can use JEdit's Utilities->Buffer Options->Edit Mode and select "XML" as the Edit Mode. This is shown in the next screen snapshot.



Color syntax highlighting based on XML grammar will then be applied to the file in the buffer. The primary disadvantage to this approach is that it is only temporary.

A more permanent solution is to use JEdit's Utilities->Global Options->Editing tool. The "Change settings for mode:" option should be changed to XML, the checkbox next to "Use default settings" should be unchecked, and then the extensions "lzx" and "mxml" should be added to the text field next to the label "File name glob:"

The next screen snapshots show this window when XML has been selected, but the Default Settings are still in place and the "mxml" and "lzx" extensions have not been added to the "File name glob" field.



After the changes described above have been made ("lzx" and "mxml" added), the window looks like the next screen snapshot.



With the LZX and MXML file types now associated in JEdit as XML source, color highlighting will be available for those types of files. This is demonstrated in the next two screen snapshots, again with the LZX example first, followed by the MXML example. Notice now they both have color highlighting.





You may also have noticed that the JEdit Global Options window in which we set the "File name glob" also has a "First line glob." What this means is that you don't even need to specify lzx and mxml as file extensions in the "File name glob" if you always have an XML prolog in the first line of your LZX and MXML files. For example, I could add the line <?xml version = '1.0'?> to the top of my .mxml and .lzx files and get XML color coding in JEdit via the XML option without ever explicitly associating those file types with XML. However, I like to explicitly associate MXML and LZX with XML in JEdit as shown above to ensure that my LZX and MXML files are displayed with color syntax even if the prolog line is left off.

JEdit does not supply all the features of a full-fledged IDE, but that is also its primary advantage at times when those additional features are not necessary. However, as proven by a recent Java.net online survey ("Do you use syntax coloring?"), nearly every Java developer uses color syntax to some degree. The easy steps demonstrated in this blog entry allow one to enjoy syntax coloring for OpenLaszlo LZX files and for Flex MXML files when using JEdit.

Of course, most modern IDEs and text editors offer similar capabilities for associating other file extensions with a known XML file type. The steps to do this are particular to each IDE or text editor.

Using OpenLaszlo Command-Line Compiler (lzc)

I normally use the OpenLaszlo Developer's Console or the URL approach to compiling OpenLaszlo applications. However, there are situations in which it is handy to use the OpenLaszlo command-line compiler (lzc). This blog entry covers use of the OpenLaszlo command-line compiler.

Two very important first steps when using the OpenLaszlo command-line compiler are to

1. Set the environment variable LPS_HOME to the directory in which OpenLaszlo is installed or unzipped. For example, I have OpenLaszlo unzipped in C:\openlaszlo, so I set my environment variable as OPEN_LASZLO=C:\openlaszlo.

2. Place the OpenLaszlo directory with the lzc executable in your path. On my Windows machine, with LPS_HOME set as described in step #1, I add the following to my path: %LPS_HOME%\WEB-INF\lps\server\bin.

You know you have been successful with these first two steps if you can run lzc --help from your root directory and see something like the following screen snapshot (click on snapshot to see larger version).



As this lzc --help example demonstrates, these are several lzc compiler options you can use. These are described in greater detail in Chapter 49 ("Understanding Compilation") of the OpenLaszlo Application Developer's Guide.

The command-line option you might use the most is the one that controls the supported runtime to compiler the OpenLaszlo application code to. Although the --runtime compiler option in the --help display shown above indicates that swf9, j2me, and svg are possible runtimes to specify, these are actually simply reserved for future use and will instead compile to DHTML if specified. The listed runtime options that actually are currently supported are swf7 (the default if no runtime is specified), swf8, and dhtml.

The next screen snapshot shows how to use the command-line lzc compiler to compile to the three primarly supported runtimes.



The commands above will lead to the generated files shown in the next screen snapshot.



As the screen snapshot above shows, the runtime environment of the compiled files is easy to determine from the name of the files.

The -v option for the lzc command-line compiler prints out compiler progress. The output from the -v option is highly verbose, so you'd probably want to specify a log file with that option. The next screen snapshot demonstrates the use of these two command-line options together.



Note how large this log file is. Note also the relative size of the source file (example1.lzx). The log created from the -v option is 4475 times larger than the source file being compiled and nearly 21 times larger than the compiled example1.js file. In other words, you definitely want to specify a log file for the -v output.

There are many advantages to using OpenLaszlo's Deployer's Console or using URLs with request types (lzt) and Laszlo runtime (lzr) as URL parameters. However, there are times when the command-line compiler is advantageous (such as part of scripted builds).

Viewing Flex Source in a Flash Application

It can be very helpful when a Flash application used as a demonstration or as an illustration of a Flex concept makes its source code readily available for viewing. You can determine if this is the case for a Flash application by right-clicking in an area on the web page that you know to be running in the Flash player. If source code viewing is enabled, the right-click will result in a window like that shown in the next screen snapshot (click on all images in the blog to see larger versions).



When source code view is not enabled, the "View Source" option will not be available when you right-click on the Flash player rendered area of the web page. An example of this is shown in the next screen snapshot.



When one clicks on the "View Source" option, the content of the pointed at URL is displayed in the browser. So, how is the URL specified for which page content is rendered when "View Source" is selected? In MXML, this is accomplished with the viewSourceURL attribute of the MXML root Application tag. A code snippet of this is shown next.

<mx:Application
          xmlns:mx="http://www.adobe.com/2006/mxml"
          xmlns:flash.display="flash.display.*"
          width="500" height="300"
          applicationComplete="doSomething();"
          viewSourceURL="C:\flexExamples\ViewSourceExample\ViewMySource.mxml">

In this code snippet, the URL is local (note the C:\), so I must compile the Flex application that includes this with the -use-network=false option. When I compile the application with this Application opening tag and run the application, I can right-click on the Flash Player section and select "View Source." A separate web browser opens up with the source code of this application.

It is extremely important to note that, in the case shown above, there is no guarantee that the URL pointed in the viewSourceURL attribute actually points to the source MXML code of this application. In fact, it can point at anything, including the C:\ drive of the local machine. If it was expressed simply as viewSourceURL="C:\\" and run, the "View Source" option would actually show a directory listing for the C: drive on that machine. In other words, there is no check or assurance that the file pointed to by the viewSourceURL points to MXML code or even something that exists. That is your job as the developer to ensure the URL is correct.

In many cases, one does not want the URL to point to the local filesystem, but instead wants the URL to point to an online resource accessible via the HTTP protocol.

The code below shows how the URL can reference an online resource via the HTTP protocol.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
                xmlns:flash.display="flash.display.*"
                width="500" height="300"
                applicationComplete="doSomething();"
                viewSourceURL="http://livedocs.adobe.com/flex/3/langref/">

This code example also shown that there is no verification that the pointed to URL actually relates to the application. The example above will compile and run fine (assuming that the -use-network option has been removed or set to false). One will even be able to "View Source" with the normal right-click and selection, but will then be taken to the Flex 3 Language Reference provided in the URL rather than the actual source code for the application.

There are several implications to the fact that viewSourceURL can point at any link regardless of any on no relationship of the linked to content to the application. The most obvious is that even well-intentioned developers may have their applications linking to incorrect or outdated versions of the source code. Another implication is that the only way to turn off the ability to view the source code is to remove the viewSourceURL attribute from the Application tag. The most important implication is that there is no enforced connection between the URL whose content is rendered and the application's actual source code unless the developer makes it so.

There are several resources covering the ability to make Flex and ActionScript source code available for viewing. These include Flex Builder documentation on Publishing Application Source Code, Viewing the Application Source Code, Flex 2 Beta ViewSource, and viewSourceURL: Publish Source in Flex.

JAXB with NetBeans 6 and 6.1

In my article Better JPA, Better JAXB, and Better Annotations Processing with Java SE 6, I showed how to use the JAXB reference implementation's xjc compiler to create Java binding classes from a source W3C XML Schema definition document. In articles on a specification implementation or technology, I prefer to show use of these things directly rather than through an IDE because I believe it is useful to understand how things work "under the covers" and because not everyone uses the same IDE. However, in my actual work not meant to provide examples to others, I make heavy use of an IDE's ability to do things and hide details of the implementation from me. In this blog entry, I'll demonstrate how easy it is to generate JAXB Java classes that bind to underlying XML with NetBeans 6.0 and 6.1 beta.

NetBeans offers file creation wizards for many types of files and W3C XML Schema files (.xsd) are no exception. The screen snapshot that follows (click on all screen snap shots in this blog to see larger version) shows my simple XML Schema file after the wizard created the root tag (xsd:schema with its namespaces and I had added the body of the document.



The screen snapshot above shows NetBeans' "Source" view of this schema file. NetBeans also provides a "Design" view of an XML Schema file and this is shown next for the example schema.



Once you have access to an XML Schema file, it is very easy with NetBeans to create Java classes that bind to that schema. I will demonstrate this next with the SimpleExample.xsd schema file shown in the two screen snapshots above. To use JAXB and NetBeans to generate Java classes from an existing XML Schema file, simply choose "JAXB Binding" from the allowable file types (under "XML" category). This is shown in the next screen snapshot.



Once I have selected "JAXB Binding" as my new file type, the next screen in the wizard is the "New JAXB Binding: Configure XML Binding" window and that is shown in the next screen snapshot.



Once I click on the "Finish" button, NetBeans will generate the appropriate Java classes that bind to XML that conforms to the provided XML Schema. Both the "Projects" view and the "Files" view show the results of this. From the "Files" view, I can see the generated .class files as shown in the following screen snapshot.



The "Projects" view shows that my newly created JAXB Bindings has been added to the project with the arbitrary name I provided it ("DustinArbitraryName"). The next screen snapshot shows this.



In the "Projects" view, there are a few things of interest that I can do at this point. First, I can right-click on "JAXB Bindings" and click on the option "Regenerate Java Code" to regenerate the Java .class files based on the XML Schema. This would be useful, of course, whenever the XML Schema changes. However, it is important to note here that the XML Schema associated with this "JAXB Bindings" entry is a copy of the original XML schema from which I generated the JAXB Bindings. In other words, if I change the original schema file, those changes won't be reflected in the generated Java classes even when I use this "Regenerate Java Code" option. There is an intermediate step I must take in that case and this is discussed next.

To update the "JAXB Bindings" copy of the XML Schema with any changes I make to the original XML Schema file, I must right-click on the schema's name (in this case SimpleExample.xsd) under the JAXB Bindings name (in this case "DustinArbitraryName"). I can then click on the option "Refresh" to refresh this JAXB Binding's copy of the XML schema to match the original one that I have changed. This is shown in the next screen snapshot.



To summarize how to update the JAXB Bindings whenever you update your original XML Schema, you must perform the following steps:
1. Edit and save the original XML Schema file in NetBeans.
2. Right-click on the schema file's name under the JAXB Bindings area and click on the "Refresh" option. This will update the JAXB Binding's copy to match the original copy of the XML Schema file.
3. Right-click on JAXB Bindings and click on the "Regenerate Java Code" option. New Java .class files will be generated for the new XML Schema file.

There are times you may want to regenerate the .class files ("Regenerate Java Code") without refreshing the XML Schema (don't need to use "Refresh"). The most likely scenario for this is when you want to change something about the JAXB mapping used in generating the Java classes, but still use the same existing XML Schema source file. In such a case, you right-click on the JAXB Bindings name (in this case DustinArbitraryName) and select the option "Change JAXB Options." This is shown in the next screen snapshot.



When the option to "Change JAXB Options" is selected a window very similar to the one we saw earlier for creating a new JAXB Bindings is shown. The only difference is that this is titled "Change JAXB Options" rather than "New JAXB Options." As with the "New JAXB Options" window, the "Change JAXB Options" window allows for the developer to provide a binding file, a catalog file, whether vendor JAXB extensions should be allowed, and five JAXB compiler options.

The NetBeans 6.0 "Getting Started with JAXB" tutorial covers what these JAXB Bindings options are. The tutorial describes what it means to check Catalog File, Binding File, Extension, and the five compiler options.

NetBeans 6 (and 6.1 beta) make using JAXB to create Java binding classes from an existing XML Schema document easier for the developer, especially considering that the generated class files are automatically placed in the appropriate classes output directory in a NetBeans project. The wizard simplifies the process, but leaves many options open for customization such as vendor extensions and custom binding files.

By the way, as you've likely heard by now, there is a NetBeans IDE 6.1 Beta Blogging Contest that ends on April 19. This blog entry has been submitted as an entry into that contest.