JSON is another alternative. Not as expressive or structured as XML but much faster to parse and easy to work with loosey-goosey. JSONHttpRequest supplies two new methods: getResponseJSON which returns a JSONObject, and getResponseMap returning a Map -- essentially what JSON boils down too. Ok, one more example and I'm calling it quites for today:

    public static void main(String[] args) {
        final JsonHttpRequest req = new JsonHttpRequest();
        req.addOnReadyStateChangedListener(new PropertyChangeListener() {
            public void propertyChange(PropertyChangeEvent evt) {
                if (evt.getNewValue() == ReadyState.LOADED) {
                    //extracting the data using JSON Java library
                    JSONObject json = req.getResponseJSON();
                    json = json.optJSONObject("ResultSet");
                    System.out.println("Total Results Avail.: " + json.optString("totalResultsAvailable"));
                    System.out.println("Results: ");
                    JSONArray results = json.optJSONArray("Result");
                    for (int i=0; i<results.length(); i++) {
                        System.out.println("\tTitle: " + results.optJSONObject(i).optString("Title"));
                    }
                    
                    //extracting the data just using maps & arrays
                    Map map = (Map)req.getResponseMap().get("ResultSet");
                    System.out.println("Total Results Avail.: " + map.get("totalResultsAvailable"));
                    System.out.println("Results: ");
                    Object[] results2 = (Object[])map.get("Result");
                    for (int i=0; i<results2.length; i++) {
                        Map m = (Map)results2[i];
                        System.out.println("\tTitle: " + m.get("Title"));
                    }
                }
            }
        });
        try {
            req.open(HttpMethod.GET, new URL("http://api.search.yahoo.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&query=JavaOne&output=json"));
            req.send();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

I hope you found this interesting. Hopefully in a future installment I'll get to showing a real live Swing demo doing something useful, besides printing junk out to System.out. Romain? Come on buddy, give a brother a hand!

A (Barely) Better Looking Yahoo! News Demo

I was greeted this afternoon by a retching Hans Muller who begged me to upload a better looking demo for the Yahoo! News web service I posted about last time. He likened last week's entry to a fat man in a speedo. Yikes. Here's a barely better demo (pun intended).

(Note: This one also uses Mustang. Get it here!).

As before, you can download YahooNewsDemo.java, as well as the source files and libs.

For the impatient:

and the relevant source code:

    public YahooNewsDemo() {
        initComponents();
        results.setHighlighters(new HighlighterPipeline(new Highlighter[] {AlternateRowHighlighter.beige}));
    }

    ...

    private void workerProcess(org.jdesktop.swingx.event.BackgroundEvent evt) {                               
        results.setModel(new RssListModel((SyndFeed)evt.getData()[0]));
    }                              
    

    private static final class RssListModel extends AbstractListModel {
        private SyndFeed feed;
        private List entries;
        
        public RssListModel(SyndFeed feed) {
            this.feed = feed;
            entries = feed.getEntries();
        }

        public int getSize() {
            return entries.size();
        }

        public Object getElementAt(int i) {
            SyndEntry entry = (SyndEntry)entries.get(i);
            return entry.getTitle() + " (" + entry.getPublishedDate() + ")";
        }
    }

Simple Yahoo! News Reader

My last few blogs have been on using web services in Swing. This time I've created a simple Yahoo! News RSS reader JavaBean you can use in your own apps. And yes, this time I went all the way and wrote a JNLP. But beware, it is only running on 1.6 for now. I didn't even know I was developing on 1.6 until I tested the deploy, and now I'm headed out on vacation.

Here's a screenshot, for those you can't or won't run the demo:

It is a very ugly demo. Again, vacation and all that. But, here's basically what it does. You enter the name of the feed you'd like to see in the combo box on the top. Or you can pick one of the predefined ones, its up to you. Then click the "Refresh" button. On a background thread (there ya go, vtech!) I get the feed results, parse them, and then back on the UI thread I load them into the JTextArea. The results are raw output from the ROME RSS reader which I use to do all the heavy lifting.

The point here isn't to show off some slick looking application -- its the work that went into creating it. Or the lack thereof. Read the source code yourself. You can also download the sources and rebuild the project (but good luck getting it to load up in NetBeans. Sorry no time to make it pretty, vacation calls).

For the impatient, here's the source code boiled down. First, I created a YahooNews bean (well, after creating the UI). I then created a BackgroundWorker bean called "worker". I then filled in the BackgroundWorker's event handlers, and wrote an action listener for the "Refresh" button. Here's all the magic:

    private void workerStarted(org.jdesktop.swingx.event.BackgroundEvent evt) {                               
        executeButton.setEnabled(false);
        setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
    }                              

    private void workerProcess(org.jdesktop.swingx.event.BackgroundEvent evt) {                               
        textArea.setText("" + evt.getData()[0]);
    }                              

    private void workerDone(org.jdesktop.swingx.event.BackgroundEvent evt) {                            
        executeButton.setEnabled(true);
        setCursor(Cursor.getPredefinedCursor(Cursor.DEFAULT_CURSOR));
    }                           

    private void workerDoInBackground(org.jdesktop.swingx.event.BackgroundEvent evt) {                                      
        try {
            evt.getWorker().publish(yahooNews.readFeed());
        } catch (Exception e) {
            JOptionPane.showInternalMessageDialog(this, e, "Failed to show feed", JOptionPane.ERROR_MESSAGE);
        }
    }                                     

    private void executeButtonActionPerformed(java.awt.event.ActionEvent evt) {                                              
        yahooNews.setFeedName("" + feedNameBox.getSelectedItem());
        worker.execute();
    }                                             

Aerith is free!

The Aerith source code has just been released to the aerith.dev.java.net project. With this milestone I thought I'd just blog a bit about the backstory that went into Aerith. Hopefully, by the time you're done reading this, you won't stone us for some pretty hacked up code.

Aerith was a really fun project to work on. We sort of had an idea for what we wanted to do for JavaOne. We had a lot of fun doing the Joplin music player the year before and really wanted to get back up on stage this year with something even cooler. Romain had a lot of demos lying around. The client group had this sweet intro screen idea and Romain had already mocked up a UI that would form the basis of the Aerith look.

Every year James Gosling holds a kind of "tryouts" for keynote demos. We didn't know when those tryouts would be held, so we sent a few emails to find out. What we found was that we had about a week to get the demo finished before the tryouts. I was at home at the time and had to say goodbye to the wife and kid for the next few days.

Romain, Josh and I setup a war room in one of the conference rooms here on campus. As all good war rooms, ours was stocked with food, liquid nourishment (water for me, on a diet :-)), and pizza (so much for the diet). Oh, and chocolate cake. No "Romain" war room is complete without chocolate cake.

In three days of intense coding (Thursday, Friday, and Saturday. Usually about 18 hours+ each day) we wrote the entire map viewer and editor, and part of the applet. The original applet contained only the 3d "twinkle" code. (For those familiar with Romain's blog, Twinkle is one of the projects he released that we reused for this demo). With that, the demo was more or less feature complete. Later that week I added what we called the "Indiana Jones" viewer in the applet. Otherwise, bugfixes occupied our time. And endless tweaks to get things up to Romains standards.

It was also a lot of fun to tryout for James' keynote and finally make it into Jeff Jackson's keynote on Tuesday morning. I always have a blast at JavaOne, and love getting up on stage. Even if I am boring to watch :-).

The moral of this story (if there is one, besides diet's and war rooms not getting along so well) is that a sizeable portion of the Aerith code is very, very raw. It wasn't written as a "best practices" application, or to be maintained. It has a lot of bugs, is difficult to setup, needs a better build script, and nobody knows how the 3d stuff works besides Romain.

It was written to show off what is possible with Swing/Java. It was written to demo well. And it was written because it was fun to do. I think in all three respects it was a home run. Especially the last one: it was a lot of fun.

I think there is a great deal of potential in Aerith as a consumer application. We're looking for individuals who want to move Aerith to the next level. I'd be stoked to see it deployed and working with real people's data in real world situations. That'd really make my day.

So, this makes 3 blogs in 3 days. If I keep this up, I'll have my yearly quota down by the end of the week!

Swing, JAX-WS, and JavaBeans

On the SwingLabs Forums we have been discussing Web Services and Swing. In particular, I want to start/retrofit a project on java.net where we can build both visual (like the Aerith map viewer) and non visual components. Some examples of non visual JavaBean components could include a Flickr bean, YahooSearch bean, YahooWeather bean, and so on.

During the discussion, Adam expressed some concern about focusing on potentially gimicky web services like Flickr at the expense of more mainstream services such as those that would be developed in house at your local enterprise.

I decided to take a shot at that situation and see what the development landscape looked like from the enterprise angle, especially when using the latest JEE 5 features. What I found was surprisingly easy, and very... uh... addicting.

There's no webstart demo, because I don't have a webserver ready to handle the server side tasks. I guess you'll just have to trust me that it works. Or better yet, try it yourself :-)

Setup

JAX-WS can be daunting. The most difficult aspect of it is the setup and configuation of the build environment. This will become a bit more clear as we go along. I've chosen to sidestep the whole issue and just try NetBeans 5.5 with the Enterprise development pack This really made the setup process a lot easier for a lowly desktop guy like myself.

I went to the NetBeans 5.5 download area and downloaded both the NetBeans IDE 5.5 Beta Installer and the NetBeans Enterprise Pack 5.5 EA Installer. I then downloaded and installed NetBeans 5.5, followed by the Enterprise Pack. I chose to install the SJAS 9 application server as part of the Enterprise Pack install. This was to make sure I had a Java EE 5 compatible server handy to test the new featuers. Note, I'm running on an Intel Mac with Mustang, and was surprised that everything *almost* worked. The only thing I had to do special was configure my netbeans.conf file to point to the JDK. This may have been because I've been messing with my JDK settings on MacOSX to get Mustang running.

Finally, after installing everything and starting NetBeans, I had to enter the Server Manager and configure SJAS 9 as a web server. This is important, because later when we create our web application a Java EE 5 compatible server needs to be available.

Now that I had everything installed and configured, I created two projects: Swing-WS-Website and Swing-WS. Swing-WS-Website is a normal NetBeans Web Application project type. The only special requirement was to make sure SJAS 9 was selected as the target server, and that JEE 5 is selected as the target.

The Swing-WS project was just a normal Java Application project type. Nothing special.

Creating the Web Service

package org.jdesktop.swingws.services;

import java.util.ArrayList;
import java.util.List;
import java.util.Random;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;

/**
 *
 * @author rbair
 */
@WebService()
public class RandomNumbers {
    @WebMethod
    public List generateRandomNumbers(Integer count) {
        Random rand = new Random(System.currentTimeMillis());
        List results = new ArrayList();
        for (int i=0; i<count; i++) {
            results.add(rand.nextInt());
        }
        return results;
    }
}

There really isn't much to this code. I simply marked the RandomNumbers class with the @WebService annotation, and then marked the generateRandomNumbers method with the @WebMethod annotation. By creating this class with the NetBeans wizard, it made sure that the appropriate build configuration was done so that at this point, all I have to do is deploy.

In SJAS 9 I can test my web service by going to the admin site. By default this is installed at http://localhost:4848. I won't go into any more detail on this product. I've found it very easy to use, and you can find info on the net for it.

Writing the Client

Now that I knew my service was deployed and working, I was ready to write the client. First, I had to make the client project aware of the web service. When doing this by hand, this is where the nasty part is.

All SOAP web services (which is what NetBeans created and deployed for me) have a WSDL file. This file describes the service in a language neutral manner. The same WSDL can be used by .NET clients or Java clients, for instance. In Java EE 5, the wsimport command line program reads WSDL files and generates java source files. You can then call these Java classes from within your client.

I've tried doing all this by hand in the past and found it to be a huge pain. Tool support makes this experience much, much better. In NetBeans, I opened the New File wizard and selected Web Service Client. I then pointed it at my RandomNumbers web service (note: in the IDE I didn't even have to deal with the WSDL directly, NB hid all this mess from me). NetBeans automatically called wsimport and created the source files for the web service for me.

The only problem I had was that I never saw these source files. Even though I'd specified a source package. As it turns out, NB 5.5 puts the source files in the "build" directory (which normally just contains class files). I guess they're trying to be clever and hide the sources from your source tree (no point cluttering it up). I'd have preferred that they generated a jar file and put it on my classpath, or at least told me what was going on. It took a while to figure out what was happening. Now that I know, it isn't so bad.

Once the web service was imported into the project, I wrote a quick main method to test it out:

    public static void main(String[] args) {
        try {
            RandomNumbersService rns = new RandomNumbersService();
            System.out.println(rns.getRandomNumbersPort().generateRandomNumbers(250));
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

Before running the sample I opened the SJAS admin webapp in my browser to check the logs and see what happened when the webservice was called. I then ran the client. Bingo. Worked perfectly.

So that's cool, but now how do I write a Swing application with this knowledge? Here's what I'd like it to look like (please Romain, don't laugh ;-))

<SIDETRACK>
Those familiar with me know that I'm into JavaBeans. For this exercise, imagine that you are the desktop guy tasked with writing applications as fast as your hot little hands can type. Wouldn't it be nice if the gal who wrote the webservice also provided a fancy little JavaBean you could use in the UI? The story goes something like this:

Sally is a server side super-engineer. She dreams in XML. Not just any XML, but we're talking namespace-declared, Schema-validated, fully robust XML. She's written a few web services to make available to the masses within her company. To help facilitate their work, she bundles the generated client stubs (generated by wsimport) along with a set of simple JavaBeans.

Clint is a client side desktop kind of guy. He has more work to do than time to do it. All departments in the company want him to write their apps because he gets them done fast, and they work pretty well. Clint needs to access Sally's web services. No problem. He gets her web service bundle (including the client side stubs and JavaBeans) and adds them to his project. He takes the JavaBeans and adds them to his Visual editor's palette. He then creates a new form, adds the WS JavaBeans to the palette, configures them (and the rest of the UI) in his editor, compiles, tests, and deploys. All as fast as his little hands can type... er, click, since he uses the visual designer as much as possible to simplify his life.

Funny enough, Wally the Web App guru also needs to write some clients. He also takes advantage of Sally's hard work and imports the JavaBeans into his JSF visual environment. Since I don't know enough about writing webapps, I'll stop the story here. Except to say that there is no fundemental difference between writing desktop and web applications when it comes to these simple JavaBeans.

Ok, enough of the somewhat silly story, but perhaps you can see a bit of the vision. So, how do we write these JavaBeans? For this example, it is really quite simple. Basically, my RandomNumbersWS bean needs to allow the developer to specify the count -- the number of random numbers to return. In a real example it may take your Yahoo application id and search params. But that's another blog. Here's the code:

package org.jdesktop.swingws.beans;

import java.util.List;
import org.jdesktop.swingws.client.RandomNumbers;
import org.jdesktop.swingws.client.RandomNumbersService;
import org.jdesktop.swingx.JavaBean;

/**
 *
 * @author rbair
 */
public class RandomNumbersWS extends JavaBean {
    private int count = 10;
    private RandomNumbers port = null;
    
    /** Creates a new instance of RandomNumbersWS */
    public RandomNumbersWS() {
    }
    
    public void setCount(int count) {
        if (count < 0) {
            throw new IllegalArgumentException("Count must be 0 or a positive whole number");
        }
        int old = getCount();
        this.count = count;
        firePropertyChange("count", old, getCount());
    }
    
    public int getCount() {
        return count;
    }
    
    public List generateRandomNumbers() {
        if (port == null) {
            port = new RandomNumbersService().getRandomNumbersPort();
        }
        return port.generateRandomNumbers(count);
    }
}

JavaBean is a convenience class in SwingX that I can extend. It makes writing these non visual beans a lot easier because it handles the infrastructure for a lot of the property change notification. You'll notice that this bean isn't doing much: it's simply a wrapper for the RandomNumbers client side proxy (called a "port" in JAX-WS). Now, let's see how to use it.
</SIDETRACK>

I created my Swing GUI with Matisse -- took a minute, maybe two (Note for Scott: I didn't get any baseline support for JSpinner). I then wrote this code in the actionPerformed event handler for the generate button:

    private void generateButtonActionPerformed(java.awt.event.ActionEvent evt) {                                               
        randomNumbersWS.setCount((Integer)countSpinner.getValue());
        final List results = randomNumbersWS.generateRandomNumbers();
        resultsList.setModel(new AbstractListModel() {
            public Object getElementAt(int index) {
                return results.get(index);
            }
            public int getSize() {
                return results.size();
            }
        });
    }                                              

If bean binding was ready to go, this would have been even simpler. But as it is, this is just normal Swing code. I set the count on the ws bean, then asked it for the random numbers. I then put the resulting List into the JList component.

Ok, so why bother with the bean? Seems like extra overhead here. Yes, this is a trivial example and it doesn't show off the point to a Bean very well. However, if I were using JSR 295: Bean Binding then having a Bean to bind to would have been really useful. Further, more complicated web services may benefit more from the beans approach.

There is another subtle benefit to using the JavaBean in this case. It insulates the UI developer from the web service implementation. Both Clint and Wally won't have to change anything is Sally decides to switch to XML-RPC instead of SOAP and redistributes a new bean. From the UI perspective, they are dealing with the Web Service on the semantic level, rather than the level of the implementation.

Once I learned how to use NB to execute web services from the client, it was a very easy process to get these calls into the UI. Those paying close attention will notice that the call blocks, though, so I have some more work to go before this is a genuinely rich rich client application. Gotta get rid of those blocking calls!

Baby Boy

I've never posted an "off-topic" blog posting before, but permit me a short indulgence: Luke Allen Bair, my first child, was born February 3rd at 6:31pm. Wife and child are doing well. Here's a couple quick pictures (as any proud papa would have to post, of course :-)).

JIC -- Java Icon File Format

Tired of "dealing with a dozen png representations of a single (logical) icon as separated files"? Tired of writing/debugging the code to treat multiple files as a single logical unit? Well, Daniel Leuck, SwingLabs, and Ikayzo bring you JIC : the simple multi-resolution cross-platform icon format for Java!

Ok, ok, a little dramatic I know. But hey, it's cool technology and cool technology is what SwingLabs is all about. Daniel Leuck from Ikayzo recently contributed some code to the SwingLabs/JDNC Incubator Project for Java(tm) Icons. Read through the source (it's a quick read), as well as this SwingLabs forums posting.

Essentially, JIC is a zip file that contains a series of png or jpg images. All images are named in a standard manner. From the JavaDoc for JIconFile:

Each image has the name "image_(size).(png|jpg)" where (size) is the image size. All images have square dimensions (same width and height.) Variants such as icons with drop shadows are stored within the archive in a folder named after the variant. For example, an icon variant having a drop shadow with a size of 24 should be stored as "shadow/image_24.png". Variant names are all lowercase by convention.

Bam, that's it. As you can imagine, a lot of cool things can be done with this basic structure. Since JIconFile represents the logical icon rather than the physical icon, we can imagine cool utilities for getting grayscaled images (for disabled icons, of course), accessible (large) images, images with badges, etc.

Oh, and by the way, I can't help but plug the awesome icons over at IconExperience. I'm sure these icons (with all their wonderful variations) motivated JIconFile in the first place.

Cool stuff, keep it comin'

Richard

Deployment

A new sub project has been added to SwingLabs today, http://deployment.dev.java.net. A few weeks ago Erik Vickroy approached me about starting a project related to deployment issues for rich client Swing applications. After a little brainstorming, it became clear that such a project would be a great addition to the SwingLabs suite of projects. Indeed, easing the deployment of rich client apps is an extremely important aspect of improving Swing developers' productivity.

We're looking forward to continued collaboration between the Deployment and Swing teams here at Sun and the Java developer community!

SwingLabs and Swing

In my last blog's comments Andy Roberts asked the following question:

I always keep my eye on SwingLabs because it is adding great value to the existing Swing toolkit. One thing that confuses me is just *how* it interacts with Swing, within the development process, that is. SwingX is an incubator for neat features, for example, sortable tables. Yet the approach adopted by Swing devs in Mustang is different than that in SwingLabs. And license issues seem to be contradictory, with SwingLabs being LGPL, it can't ever be absorbed into the main Java code. I've personally communicated to Richard discussing this, but it would be worthwhile clarifying fully the interaction between Swing and SwingLabs for all.

The Short Answer

SwingLabs is simply an incubator for ideas that can be incorporated into Swing. Swing engineers work on both Swing and on SwingLabs (incidently, SwingX contributors include Scott Violet who is the Swing architect, and Josh Outwater who is a Swing engineer for Apple, as well as several other Swing engineers).

The Long Answer

There is a real need in the desktop java community for components and frameworks to aid in writing rich client Swing applications. This need is deeper than simply updating the Swing toolkit. Things such as a data binding framework, application framework, tool support, progress management, and so on are really not part of the Swing toolkit per se. Rather, they are built beside or on top of Swing to help make the Swing application programming experience better.

There are also many things which are directly related to Swing, such as our JXTreeTable component. Another example is the filtering, sorting, and highlighting support for trees, tables and lists. The JXDatePicker is another good example. Work on these components is directly related to the Swing toolkit.

This is a minor distinction that substantially alters the way that SwingLabs interacts with the JDK. Frameworks built around the Swing toolkit that are included in the JDK will go through a formal JSR process, while additions to the Swing toolkit itself will be done via one of the release JSRs (such as the JSR for Dolphin). This is more a matter of procedure, but is a good thing to keep in mind.

As I mentioned in the "Short Answer", SwingLabs was initially created as an incubator for Swing. It was a place that Swing engineers could test out proposed enhancements with the community. It's LGPL license ensured that any changes to the code would have to be publicly available, while also allowing developers to bundle the code with their proprietary applications.

But it didn't take long to notice that developers wanted to build Swing apps now and couldn't wait 18 months or longer for these changes to be made available in the JDK. I was one of those developers. Helping rich client Swing applications take root is a very important goal for the SwingLabs project.

If the project is LGPL, then how can it be incorporated in the JDK?

This is a legal question more than a techinical question, but I'll do my best to answer it with the general caveat that I am not a lawyer. However, as I understand it, when you write a piece of code there are two different kinds of rights that you get. The first is copyright. Copyright means that you own what you wrote the instant that you wrote it, and you have the right to do with it as you please. One of those rights is to assign a license to your work. The License dictates what rights others have with your work. However, as the copyright owner you have the right to be able to change the license at any time.

So, if a Sun engineer writes some code for the SwingLabs project, then Sun (who is paying the Engineer) owns the copyright for the code. It is licensed under the LGPL, but whenever Sun decides to change license we are free to do so, since we own the copyright on the code. What was originally released as LGPL is still LGPL, meaning that it is impossible for Sun to revoke your rights to the code that was released under the LGPL, but they can dual license the code.

What does this mean for the JDK? Well, it means that in order to migrate code from SwingLabs into the JDK we need to fork the code, change license, and put the new code into the JDK. Because Sun owns the copyright, Sun can do that

However, what happens if code is contributed from folks outside of Sun? In that case, there are a couple of concerns. First, as demonstrated above, in order for SwingLabs to fulfill it's mission as an incubator for Swing Sun must own the copyright, or the code could never be included in the JDK. However, since nobody would want to hand over copyright to their own work, we use a Joint Copyright Agreement for the SwingLabs project. The JCA grants joint copyright between you the contributor and Sun. You still maintain every right you once had, but you also grant Sun copyright ownership.

In this way, Sun is able to migrate code from the SwingLabs projects into the JDK.

If SwingLabs is an incubator, then why does the implementation differ between Mustang and SwingLabs?

In an ideal world, it wouldn't. Ideally new features would be implemented in SwingLabs first, and then simply included in the JDK rather than being rewritten. Unfortunately, due to time constraints this was not fully realized for Mustang.

Can SwingLabs be used with my proprietary application?

Yes!

Well, that's it for today. If you have any more questions, I'd be happy to answer them as best I can!

This work is licensed under a Creative Commons License.