Rich Unger's Blog

Community: NetBeans Archives

Man, I leave you guys alone for one little year...

Dear Java Industry,

I leave you guys alone for one little year, and just look what happens!

While I was off gallivanting, NetBeans added a GPL license, switched to mercurial, and released a new version. The JDK also went mercurial on me. Google released their Android platform. Spring, Tapestry, Wicket, and GWT are all in new major releases.

Things sure to move quickly around here. I've got a lot to catch up on.

I'm like a kid in a candy store. I can't wait to play with it all!

Unfortunately, my laptop is broken. Anyone know a good laptop repair shop in the Seattle area?

Itinerant Java Speaker: Bariloche, Argentina

As some of you may remember from my last entry, my fiance and I are traveling the world, and I'm looking to meet some java programmers in different places along the way.

Well, the first to answer my call was Gustavo Santucho and his girlfriend Guadalupe. They, along with a few other programmer friends, have their own consulting company, based in beautiful Bariloche, Argentina. This is the a city near the fantastic Nahuel Huapi National Park, near the Chilean border.

They picked us up as we arrived by bus, and immediately we discovered that his English was far better than my Spanish :)
I've gotten a little bit better now, since taking some Spanish lessons from a friend of his in Buenos Aires, but most of our conversations at the time were in English.

Looking around the small city, you wouldn't think there'd be much local work for java programmers. It's basically a tourist town, situated on a very large and sleepy lake. However, Gustavo took me for a drive, and on the way he kept pointing to grocery and pharmacy chain stores, saying "they're a client, they're a client". They also have a significant percentage of clients from overseas. They gain most new clients by word of mouth, and in fact, they're getting more work than they can handle right now, and are thinking about ways to expand the company.

Gustavo tells me that the trend in his part of South America is away from webapps and towards RCP-based software, which is why they started using the NetBeans platform. I was particularly pleased to see them using my JDIC-NetBeans integration on one of their apps.

Guadalupe is the real UI designer in the group. She just emailed me some screenshots for a big new project they have, working for the local electric company:

As you can see, they're integrating components from the NetBeans Graph Visualization library (graph.netbeans.org) and Geotools.

Gustavo and Guadalupe were extremely hospitable, and we had a fantastic time. If you're interested in reading about the more vacation-like aspects of our time together, check out my personal blog.

Well, we're off to the airport soon. We're about to fly to Athens and make our way all the way around Europe (clockwise). Caio!

The itinerant speaker's itinerary

I'm finally underway for my round-the-world trip, and as I said in my last entry, I'm available for speaking on NetBeans RCP, IVR Speech Recognition, and other topics en route.

If you're interested in tracking my progress, regular updates will be in my personal blog.

I'm just posting now because I recently procured the tickets for the first half of my journey. My dates are not set yet, but the cities are. My general itinerary starts with a flight to Buenos Aires on March 12th. I'll be in Argentina and Chile for 5 weeks. Then, it's on to Athens and Crete. From Greece, I'll be going to Italy, Croatia, France, Spain, Portugal, Morocco, the UK, Ireland, Belgium, Amsterdam, Germany, Estonia, Latvia, Lithuania, Poland, The Czech Republic, Hungary, Romania, Bulgaria, Turkey, Egypt, Ethiopia, Kenya, Tanzania, Zambia, Botswana, South Africa, and India (Mumbai, Rajasthan, and Delhi). From there, the itinerary is not set, but it is likely to include Thailand, Vietnam, and Cambodia. Beyond that, we've not decided.

We're looking to meet people who want to show us a bit of their home country, and maybe put us up on their couches as payment for an appearance at your local JUG or company forum :)

A few folks commented on my last post (specifically from South Africa and Italy). I'm sorry I didn't include better contact info in my last post. Blog comments leave me no way to get in touch with you, so I'll try this again: rich (dot) unger (at) gmail.

Itinerant Java/NetBeans speaker

I've not been posting lately, but it's not for lack of excitement around here.

For one thing, I've been collaborating on the forthcoming NetBeans RCP book. If you're at all interested in RCP development, I promise you this book will make your job easier. I started on the NB platform about 3 or 4 years ago, and I struggled with it a lot. I can't believe how much easier it is now. The support in the IDE for writing platform-based apps is better (thanks largely to Jesse Glick), the information on platform.netbeans.org is much, much better (thanks largely to Geertjan), and this book is going to be the icing on the cake.

And, while I was writing that chapter, I also gave notice at Nuance. After 6+ years at the speech recognition giant, I'm calling it quits. I'd like to stress that there were no hard feelings or anything particularly negative at Nuance that made me feel I had to leave. My experience at Nuance has been tremendous. Right out of college, I was fortunate to work in an exciting and technically challenging software field (speech recognition) with a lot of really, really smart programmers and linguists. Everything I learned about developing large, high-quality software products I learned at Nuance. I grew a lot there, both professionally and personally.

I was just ready to take a break, and soon I'll be looking for new challenges. But first...

My girlfriend gave notice at her job as well. We've decided to travel the world together for about a year. We're going to South America, Europe, and Africa. Everything after that we haven't planned out yet, but it's likely to include parts of India, China, southeast Asia, possibly Japan, Australia/NZ, or some islands in the south pacific. I'll be posting all about this on my new personal blog.

As part of this grand adventure, I'm attempting an experiment. I figure, if Sun, with their millions spent on marketing and travel, can have a "NetBeans World Tour", why can't I?

The lonely planet books all say that the best way to travel to foreign countries is to engage with locals in a more substantive way than just interacting with hotel clerks and waiters. Have conversations with people who are not paid to have conversations with you (i.e. people in the tourism industry).

In my opinion, one way to do this is to meet people with similar interests. Like, maybe Java.

I've spoken twice at JavaOne and once at OOPSLA on the subject of NetBeans RCP development. I've also got fodder for talks from my experience at Nuance doing speech recognition with java in general, and NetBeans RCP in particular, as well as the material I've contributed to the new book.

Also, while not specifically Java-related, my girlfriend and travel companion Patty is an expert (and has spoken at conferences) on advances in telecommunications infrastructure, particularly in the realm of FTTP.

So here's my idea: we'll have several slide decks on USB keys with us. If you have a JUG or other organization somewhere on our itinerary, and you'd like one or both of us to come and speak, we'd be happy to, in exchange for space on your couch or in your guest room for the night, and maybe some company to help us explore your home country. Show us your favorite museum, pub, hiking trail, or landmark.

In a nutshell, we're trading expertise for experiences.

A new NetBeans Platform Sample: AudioStation

jdic-netbeans project is online

A simple class browser

At JavaOne, Geertjan gave a talk on building an IDE for a specific framework (Wicket). I work on a similar project for an in-house framework. One feature that I thought would be useful is a convenient Java Class selector.

I really like the "Fast Open" selector that you get from the "Navigate...Go To Class" menu item. I looked at the code, and was dismayed to see that it was hard-coded for opening classes, and was not reusable for just selecting a class for another purpose (such as inserting a class reference in an xml file).

So, I sat down to write such a widget, and was pleased to be able to put something pretty featureful together in a couple of hours. I use the MDR API for querying classes.

The list box contains all classes whose classname (without package) starts with the substring in the text field. The list selection is the value returned by the dialog.

Here's a little tour of the code:

public class ClassSelector extends javax.swing.JDialog
{
    // the data for the ListModel
    private List candidates = new ArrayList();

    // an example usage
    public static String getFullyQualifiedClassName()
    {
        ClassSelector cs = new ClassSelector();
        cs.setVisible(true);
        JCClass c = cs.getSelection();
        return c == null ? null : c.getFullName();
    }

    public ClassSelector()
    {
        this(WindowManager.getDefault().getMainWindow(), true);
    }

    public ClassSelector(java.awt.Frame parent, boolean modal)
    {
        super(parent, modal);
        initComponents();
    }

    public JCClass getSelection()
    {
        return (JCClass)matchingList.getSelectedValue();
    }

    private void initComponents()
    {
        // matisse-generated code here
    }

    private void matchingListKeyPressed(java.awt.event.KeyEvent evt)
    {
        // make ENTER work the same as the OK button
        if (evt.getKeyCode() == KeyEvent.VK_ENTER)
            okButtonActionPerformed(null);
    }

    private void cancelButtonActionPerformed(java.awt.event.ActionEvent evt)
    {
        matchingList.setSelectedIndex(-1);
        dispose();
    }

    private void okButtonActionPerformed(java.awt.event.ActionEvent evt)
    {
        dispose();
    }

    private ListModel createListModel()
    {
        return new Model();
    }

    private ListCellRenderer createCellRenderer()
    {
        return new Renderer();
    }

    private class Model extends KeyAdapter implements ListModel
    {
        private List listeners = new ArrayList();

        public Model()
        {
            classNameField.addKeyListener(this);
        }

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

        public Object getElementAt(int index)
        {
            return candidates.get(index);
        }

        public void addListDataListener(ListDataListener l)
        {
            listeners.add(l);
        }

        public void removeListDataListener(ListDataListener l)
        {
            listeners.remove(l);
        }

        private void fireListChange()
        {
            ListDataEvent evt = new ListDataEvent(this,
                    ListDataEvent.CONTENTS_CHANGED, 0, getSize()-1);
            for (ListDataListener l : listeners)
            {
                l.contentsChanged(evt);
            }
        }

        private void refresh()
        {
            String str = classNameField.getText();

            if (str == null || str.trim().length() == 0)
            {
                // text field is blank, so don't do a query
                if (!candidates.isEmpty())
                {
                    candidates.clear();
                    fireListChange();
                }
            }
            else
            {
                // clear out the old query results, and do a new query
                str = str.trim();
                candidates.clear();

                JCFinder finder = JCFinderFactory.getDefault().getGlobalFinder();

                // TODO: make case insensitive
                List classes = finder.findClasses(
                        null, // don't specify a package
                        str, 
                        false); // don't require an exact match

                candidates.addAll(classes);

                fireListChange();

                if (!candidates.isEmpty() && matchingList.getSelectedIndex() == -1)
                {
                    // if there's no selection at this point, select the first item
                    matchingList.setSelectedIndex(0);
                }

            }
        }

        /** each time a letter is typed, do a new query */
        public void keyReleased(KeyEvent e)
        {
            refresh();
        }
    }

    private class Renderer implements ListCellRenderer
    {
        public Component getListCellRendererComponent(
                JList list, Object value, int index,
                boolean isSelected, boolean cellHasFocus)
        {
            JCClass c = (JCClass)value;
            String str = c.getName() + " (" + c.getPackageName() + ")";
            JLabel label = new JLabel(str);
            if (isSelected)
            {
                label.setBackground(Color.BLUE);
                label.setForeground(Color.WHITE);
                label.setOpaque(true);
            }
            return label;
        }
    }

    // Variables declaration - do not modify//GEN-BEGIN:variables
    private javax.swing.JButton cancelButton;
    private javax.swing.JTextField classNameField;
    private javax.swing.JLabel jLabel1;
    private javax.swing.JLabel jLabel2;
    private javax.swing.JScrollPane jScrollPane1;
    private javax.swing.JList matchingList;
    private javax.swing.JButton okButton;
    // End of variables declaration//GEN-END:variables

}

Neat, eh? The full code is here.

The netbeans and eclipse developers get along just fine

I saw this javalobby discussion on roumen's antics today, and I thought I'd put my 2 cents in.

Yes, the products compete. Yes, there's a lot of heated debate and personal attacks on blogs and message boards.

You generally don't see that from the folks who actually *work* on these products.

Last year, I wrote an entry on a meeting of the minds between architects from the eclipse and netbeans platforms. The other day, I was out at the Thirsty Bear with about a dozen folks from eclipse, netbeans, and OSGi. We discussed modular architecture, opinions on "superpackages" in dolphin, software update methodologies, and how utterly rediculous the flame wars are getting.

We were comparing notes. There was no ideas being held back. The OSGi folks wanted to know what it would take to get NB to talk their protocol (a thorny topic I'll leave to the real experts). I asked about how eclipse handles some project and workspace layout stuff under the hood. It was an interesting discussion, and we all had fun. Competitors, to be sure, but in a very open, healthy way.

So, what about Roumen's prank? Well, I can't say I would have done the same thing. Eclipse paid for their booth, and I think it was a bit inappropriate. But, no real damage done, and I think Steve Northover's comments in Javalobby reflect that there's no real ill will among the folks in the trenches. Roumen was just trying to have a little fun, and he misread the atmosphere at the pavilion. Big deal. It's over. I don't think anyone lost any customers over it. I think it's very likely that the brouhaha was more about Eclipse being disappointed with the location of their booth than about anything Roumen did.

As an aside, I was in the "Eclipse Callisto" talk, and someone asked, "Are you happy with the amount of coverage Eclipse is getting at this conference?" The questioner was implying that the stepped-up NB coverage was Sun shilling, and Eclipse was getting short shrift. The answer from the Eclipse speakers, however, was "we are very pleased." In fact, they said they were late submitting that very talk, and Sun made a special exception to admit them.

People look for controversy, but the real story here is just how friendly this competition is.

Native (JDIC) browser on nbextras.org

Module Suite building tips (part 3)

In this installment, I'll be solving 2 issues with the building of a distributable application from a NetBeans Module Suite:

1. Including a custom conf file (instead of the default etc/netbeans.conf)
2. Including the JDK with my distribution

First, let's take a look at my vbuilder.conf file:

# ${HOME} will be replaced by JVM user.home system property
# ${APPNAME} will be replaced by the app name specified
# in the module suite's project properties
default_userdir="${HOME}/${APPNAME}/4.0"

# options used by the launcher by default, can be overridden by explicit
# command line switches
default_options="-J-Xms24m -J-Xmx128m -J-Dnetbeans.logger.console=true"

# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
# relative paths are relative to the root of the netbeans installation
jdkhome="jdk"

Now, I've checked this file into my module suite's nbproject/ directory. Notice that the configuration sets the default JDK to ${NETBEANS_ROOT}/jdk.

In the suite's build script, I need only override one target:

<target name="build-zip" depends="suite.build-zip" description="Builds a ZIP distribution of V-Builder.">
    <zip destfile="dist/${app.name}.zip" update="true">
        <!-- The JDK that's running this ant script -->
        <zipfileset dir="${java.home}/../" prefix="${app.name}/jdk">
            <exclude name="bin/*.exe"/>
            <exclude name="jre/bin/*.exe"/>
            <exclude name="src.zip"/>
            <exclude name="src/**"/>
            <exclude name="demo/**"/>
            <exclude name="sample/**"/>
        </zipfileset>
        <zipfileset dir="${java.home}/../" prefix="${app.name}/jdk" filemode="755">
            <include name="bin/*.exe"/>
            <include name="jre/bin/*.exe"/>
        </zipfileset>

        <!-- vbuilder.conf -->
        <zipfileset dir="nbproject" prefix="${app.name}/etc">
            <include name="${app.name}.conf"/>
        </zipfileset>
    </zip>
</target>

...and that's all there is to it. Now the zip file generated by the IDE's "Build Zip Distribution" action will contain my custom vbuilder.conf and the JDK that was used to build it.

In the next entry, I'll show you how to set up a nightly build process.

I just ported V-Builder to NetBeans Platform 5.0

A few folks have asked how you move an application from the cluster build harness on 4.x to the 5.0 platform. The way I did it was to create a new module using the IDE, and just copy my source code in. Then use the IDE's facility for adding module dependencies based on what doesn't compile right away. Worked like a charm, except that ClearCase was a PITA about hijacked files (if you're a clearcase user, you know what I'm talking about, and if you're not, feel blessed).

In the entire V-Builder code base of almost 50k lines of java code and around 30 modules, I changed exactly ONE line of java code.

org.netbeans.updater.UpdaterFrame.runFromIDE() added a parameter.

That was it. That, and pulling out my custom build scripts and moving resource files around to conform to the way the apisupport harness expects files to be laid out. It definitely went smoother than expected.

Do you develop NetBeans modules?

We want you.

Okay, that was shameless. I'm sorry. It's also not particularly accurate.

I just got out of a meeting with our recruiter, and I got to wondering about the difference between a recruiter's world view and an engineer's. They have a job requisition to fill, and they look for someone with the precise set of skills required for the job at hand.

In engineering, we'd rather look for a bunch of good coders, and let them move between projects as needed, picking up new skills as they go. At Nuance, I've been on 3 different project teams: a VoiceXML interpreter, a j2ee-based (server-side) tool, and a netbeans-based (client-side) tool. If all I'd ever done was write netbeans modules, I wouldn't have learned enough about server-side programming to work on speech application architecture for V-Builder. If I hadn't worked on the VoiceXML interpreter, I wouldn't have known enough to do a really good job on automatic VoiceXML code generation in V-Builder.

So, if you:

• love to code
• you're good at it
• you think speech recognition sounds kinda cool

...then let me know ... whether or not you've ever written a NetBeans module.

You can reach me at RichUnger (at) netbeans.org

A simple NetBeans module, written in NB 5.0

As promised, here's a recap of a simple module I built to help me test a bugfix.

There is a feature in NetBeans which allows any FileObject (including files in your project) to be served up by an embedded HTTP server. It is exposed by the API method

URLMapper.findURL(FileObject, URL_TYPE)

• INTERNAL: results in nbres://foo
• EXTERNAL: results in file:/foo
• NETWORK: results in http://foo

I noticed that if I passed NETWORK into the function, I was getting back a file URL instead of an HTTP URL. I decided to create a simple module to help me debug the problem.

The module would add an Action to the context menu of HTML files which would perform an URLMapper.findURL() and display the result in a dialog box. What surprised me, as a long-time module developer on previous versions of NetBeans, was how easy it was in 5.0....

1. "File ... New Project". Select "Module Project".
   
2. Give the project a name and location.
   
3. Edit the "Code Name Base" to something that makes sense, and click "Finish".
   
4. Now I want to add a new Action. So, from "File ... New File", select the appropriate template.
   
5. In the next screen, I want to conditionally enable this Action, so that I end up with a CookieAction that is resposive to DataObject.class.
   
6. The Category isn't particularly important. That controls where this item shows up in the Keyboard Shortcuts editor. The important thing to change here is to uncheck "Global Menu Item" and check "File Type Context Menu Item."
   
7. Give the class a name and a display name, and click "Finish".
   

There. That's almost everything. Now all I have to do is implement the performAction() method. The implementation will look like this:

        DataObject dobj = (DataObject)activatedNodes[0].getCookie(DataObject.class);
        if (dobj != null)
        {
            URL url = URLMapper.findURL(dobj.getPrimaryFile(), URLMapper.NETWORK);
            NotifyDescriptor nd = new NotifyDescriptor.Message("URL: " + url);
            DialogDisplayer.getDefault().notify(nd);
        }

As I type this in, certain classes will not be found, even after a "Fix Imports" (Shift-Alt-F). The unknown classes are:

• NotifyDescriptor
• DialogDisplayer
• URLMappper

Now, if I right-click the URLMapperTest project node, and select "Properties", there's a section for "Libraries"

When I click "Add...", I'm presented with a new dialog that lets me search for these classes.

In this way, I can add dependencies on the appropriate modules (Dialogs API and File System API). Once again, I can perform "Fix Imports" in my source window, and I'm done coding!

Now, when I run my project, and browse to an HTML file, I can right-click that file and select "Show URL"

...and the result is this:

Of course, that's the result before I fixed the bug! With my patched version, the URL starts with "http://"

Now, I don't know about you, but I was very impressed by how easy this was. I know how to do it the hard way, because I've been writing NetBeans modules for years. I'm very envious of the folks who are just starting now :-)

Real, supported, module development has arrived

I prefer my JARs sunny-side up: redux

I prefer my JARs sunny-side up

So, I'm sitting at my laptop, building netbeans... oh, wait ... OK, so I'm sitting ... oh, sorry, hold on... so, ... oh crap, not again.

Another scrambled jar.

This has to be the most rediculous, hoop-jumping compromise ever developed between a legal department and an engineering team. I really hope someone from Sun Legal will comment on this blog post, because I'd really like some public discussion with them on this subject.

For those of you who don't build netbeans source code, and are therefore in blissful ignorance of what I'm talking about, let me fill you in. The netbeans source code makes use of a number of third-party libraries. Any that are not licensed with the SPL are "scrambled" in the netbeans CVS tree, and during the build process, it gets unscrambled, but only after a popup window forces you to click through the license.

Mind you, I'm not just talking about proprietary libraries. You have to click through the Apache license every time you do a clean build of netbeans. In fact, there's very little here that is not OSI approved, aside from the javac bridge, which basically amounts to agreeing to the same license you agreed to already when downloading the jdk.

This stinks for a number of reasons:

1. It's annoying to me and everyone else who builds the netbeans source tree. Chances are, anyone building the tree has enough awareness of what's in the product that we shouldn't have to go through all this every time we do a fresh build.

2. No other OSS project out there feels the need to put these kinds of click-throughs when merely linking to OSS libraries with other licenses.

3. It's bad for the perception of netbeans as being open. This causes real damage to netbeans as a product, and is therefore counterproductive for Sun.

4. It causes all kinds of issues with automated scripts that prevent people from working with the netbeans tree (e.g. Gentoo, or anyone wanting to do headless builds).

This looks like a "cover-your-ass" maneuver left over from an earlier time when Sun had less of an understanding of how to work with OSS. Remember, NetBeans was one of Sun's first forays into OSS. Haven't other Sun projects come up with more refined CYA methodoligies by now?

Please, would a Sun lawyer like to comment? Let's get rid of the "scrambled jar" dinosaur!

Eclipse vs. NetBeans *yawn*

OK, I got your attention. Now, can we just forget this horse-race and go back to getting some actual work done?

No?

Oh, fine. So, JavaOne just ended, and everyone's talking about the buzz around these 2 products. There's enough hype around here to stuff a turkey.

I saw an interesting post on ZDNet after JavaOne. It was yet another log on the Eclipse vs. NetBeans fire. The content essentially boiled down to, "they're both technically good, but Eclipse is going to win."

It struck me as not very well thought out, and I'll tell you why.

(To be fair, he later backed off a bit in his tone, if not his conclusions.)

In the original post, one thing that struck me as a particularly bad assumption was, "...as in many tug-o-wars, someone is going to end up with mud in their face..."

Why? You have 2 IDEs competing vigorously for market share, and the result has been astounding. The quality of both programs is amazing. They each have their relative strengths. What is this drive among pundits to try and declare a winner here? I think there's an alternative motive here. This is what pundits do. They evaluate the market, and lend their "expertise" to the reader by declaring a winner.

But he's putting the cart before the horse. The reason so many big industry players went with Eclipse for their plugins is because more developers already used it as their IDE. They're addressing the developer market, and let's face it, Eclipse was a better IDE last year. Naturally their market share was much higher. From looking at the relative attendance of NetBeans and Eclipse talks at JavaOne, I'd have to say that Eclipse still does have more users, but not by nearly as wide a margin.

It's just not so clear-cut anymore.

On the J2EE side, NetBeans has better support for html, jsp, xml, xslt, and deploying/debugging within tomcat. The new project system, designed around ant, is very appealing to a lot of developers I know because their IDE uses the same configuration as their nightly build scripts. On the client side, Matisse (the new GUI builder) is light years ahead of anything Eclipse has to offer. The J2ME support in NetBeans has been getting an awful lot of attention. Finally, coming down the pike is the JFluid profiler. An IDE that makes profiling as easy as debugging is going to win a lot of converts.

Developer mindshare is a fickle thing. Honestly, I believe the 2 will be leapfrogging each other for at least a few years to come. And that's a great thing. That's much better for us average joe developers than having one "winner". Let 'em slug it out!

Finally, to address the platform/framework argument. Yes, there are more people building Eclipse plugins than NetBeans plugins. I think this is for 2 reasons:

1. There have been more Eclipse users, but I've addressed why I think this is evening out
2. There's more functionality out of the box in NetBeans

So, for now perhaps there are more Eclipse-based desktop apps than Netbeans-based ones. However, I think that, by far, the biggest share of desktop java apps has to go to the "no framework" or "homegrown framework" crowd. And, as both the Eclipse and NetBeans platforms mature, and become more compelling for use as the foundation of non-IDE desktop java apps, which one will be more popular? Well, Eclipse will have the headstart of having a few more community members already having written plugins. However, NetBeans has the huge advantage of being swing-based. I'm guessing there's a lot more Swing developers than SWT developers out there.

And if you want to talk about relative buzz, let's consider the companies that are choosing up sides here. BEA, IBM, Sun, etc. These are companies selling app servers (well, except Borland, but I have no earthly idea how they think they're going to survive as a set of not-so-much-value-add for Eclipse). App servers based on EJB technology. Why am I mentioning this? Because the most highly attended JavaOne talk I saw was Rod Johnson's Spring talk, which was busting the seams at the Yerba Buena Theater. This is the guy who wrote "J2EE Development without EJBs". So, let's be honest here. In a world where the tools and the server side frameworks are all free, the app server companies are chasing, not leading, the adoption curve.

(BTW, message to Sun and IBM: the first IDE to treat Spring, Hibernate, and other open source frameworks as first class citizens is going to get a major boost. It may not be welcome news to the companies trying to sell everyone on complicated clustering and transaction architectures, but this is what developers want, and you're just not going to convince them otherwise. Yes, yes, I know that if they'd only wait until EJB3, they'd get the architecture they want, but meanwhile the open source frameworks have built up a huge following and lots of useful APIs. Can EJB3 make any javabean JMX managable? No? Spring can. But, I digress...)

The real market for a client platform is not companies who make app servers and want to give away plugins to IDEs. The real market is companies (and individuals) who want to write client applications that are not IDEs.

Anyone talking about a "winner" when there's still only enough such apps on each platform to count on one hand is blowing smoke.

Most productive night drinking ever

When we got a little too drunk for that, we started in on the source code to my FeedReader. We hacked around until we figured out a way to embed a JDIC browser in a TopComponent.

That was cause enough for the celebratory drinks to migrate from beer to whiskey. After that, a bunch of other folks from the netbeans team showed up. Once I got a complete rundown of Czech history over the last century, I said a fond farewell and caught the caltrain home.

Now it's bedtime.

We Can All Just Get Along

I leaned over to Tim Boudreau, NetBeans evangealist, and said, "Boy, wouldn't the bloggers love to get a picture of this." I couldn't tell if he looked amused or worried.

The picture I was referring to was the two people sitting next to me. They were NetBeans Platform architect Jaroslav Tulach and Eclipse Platform architect Jeff McAffer.

Disclaimer: There's NOTHING going on behind the scenes. Don't be on the lookout for any press releases. These two engineers just happened to meet each other at JavaOne. And, because they solve very similar problems in the course of their work, they had a lot of fun discussing these problems with one of the only other people in the world who understood the issues involved.

And, because both projects are open source, they were completely free to do so.

Afterwards, Jaroslav said to me, "It's nice to have someone to talk to."

For me, it was a lot of fun to listen to. They were both very candid about what they like about the others' approach, and what, given the chance to start over, they might have done differently.

Another fascinating thing was how similarly the two platforms chose to solve certain problems. The NetBeans Lookup mechanism and OSGI Services have a remarkably similar API, and their behavior with respect to corner cases (like what happens if the module providing a service implementation is dynamically unloaded) is pretty much identical.

Let me let you in on a little secret. The engineers on these projects have a healthy respect for what the competition is doing. Nobody I know on the NetBeans team thinks Eclipse sucks, and though Jeff is the only Eclipse developer I've met, from what he's told me, I gather the reverse is true.

So, which IDE will win? Wrong question. In my opinion, they'll be leapfrogging each other in different feature sets for a long time to come. And that kind of friendly, technical competition serves us end-users even better than cooperation.

And kudos to Jeff for approaching me in the back of the room at a NetBeans technical session. You're a classy guy.

Bean Browsing with JXPath

Here's a little trick I've found useful for browsing the contents of my JAXB model, though it works just as well with any java beans. It's a GUI for testing JXPath expressions on a given Object. Try it out on any old object, and start with the XPath expression for the context node, which is just '.' (not quoted).

For example, if you create a new PathTestFrame(new java.util.Date()), and give it the expression '.', you'll see the bean properties of the Date object. Then, if you change the expression to, say 'time', you'll get the results of Date.getTime(). This is not very helpful, as the only bean property of a primitive type, as far as JXPath is concerned, is "class", but you get the idea.

It gets better. Let's say you've got an Object with a bean property called "dateList", a List of Dates. The first date in the list will be 'dateList[1]' (XPath is 1-indexed, not 0-indexed).

You can browse through a very large heirarchy of beans, and even edit the bean property values using the property sheet. Neat, eh?

import java.awt.BorderLayout;
import java.awt.event.ActionListener;
import java.beans.IntrospectionException;
import javax.swing.JButton;
import javax.swing.JPanel;
import javax.swing.JTextField;
import org.openide.DialogDisplayer;
import org.openide.ErrorManager;
import org.openide.NotifyDescriptor;
import org.openide.nodes.FilterNode;
import org.openide.nodes.Node;
import org.apache.commons.jxpath.JXPathContext;
import java.util.Iterator;
import java.util.List;
import java.util.ArrayList;
import org.openide.nodes.BeanNode;
import org.openide.explorer.propertysheet.PropertySheet;

public class PathTestFrame extends JPanel
{
    private JXPathContext m_jxPathContext;
    
    private JTextField m_inputField;
    private JButton m_btn;
    private PropertySheet m_propsheet;
    
    public PathTestFrame(Object model)
    {
        super();
        setLayout(new BorderLayout());

        m_btn = new JButton("Test Path");
        m_inputField = new JTextField(50);
        m_propsheet = new PropertySheet();
        m_btn.addActionListener(new ActionListener(){
            public void actionPerformed(java.awt.event.ActionEvent e) {
                update();
            }
        });
        
        JPanel top = new JPanel();
        top.add(m_inputField);
        top.add(m_btn);
        add(top, BorderLayout.NORTH);
        add(m_propsheet, BorderLayout.CENTER);
        
        m_jxPathContext = JXPathContext.newContext(model);
    }
    
    private void update()
    {
        Iterator values = m_jxPathContext.iterate(m_inputField.getText());
        List l = new ArrayList();
        while (values.hasNext())
        {
            l.add(values.next());
        }
        
        Node[] nodes = new Node[l.size()];

        try
        {
            for (int i=0; i < nodes.length; i++)
            {
                nodes[i] = new BeanNode(l.get(i));
            }
            m_propsheet.setNodes(nodes);
        }
        catch (IntrospectionException ex)
        {
            ErrorManager.getDefault().notify(ex);
        }

    }
}

The class was written to be used in Netbeans, but can be used standalone as long as you have openide.jar in your classpath (and, of course, you need jxpath regardless).

Examining Premises: why use a framework?

In working on my JavaONE presentation, I got to thinking about why frameworks such as the NetBeans Platform and Eclipse RCP are important. It's really because, if they didn't exist, we'd all end up rewriting them, anyway.

Every project I've ever worked on started out as a dedicated application, with a very simple architecture. Then, as features are added, and they don't fit nicely into what I already have, I have two choices:

1. I can do some rewriting, and just "get it working" in time for the release date. This results in buggy, hard to test code.

2. I can begin to modularize what I have, and create a pseudo-framework that can accept new components more easily without breaking what I already have.

The idea with these platforms is to start with the framework, and build out. Of course, the challenge there is to make the learning curve shallow enough that folks making initial versions of their dedicated applications won't blink at starting with them. When I first picked up netbeans (several years ago), the learning curve had Everest-like proportions. It's gotten a lot better, but I still have a few annoyances.

I think the declarative method for laying out components is very difficult to grok, and far too easy to break, especially when trying to create a singleton TopComponent. I've gotten very little traction from netbeans developers whenever I bring that up. After all, they just rewrote the darn thing.

The new projects system is a joy to work with on an API level, though. It's super easy for me to create my own flavor of project. Also, the way the Lookup mechanism works to provide context as the focus moves around to different components has a certain zen to it. It "just works".

And the new UI and tools for modules developers, which is slated for version 4.2 should go a long way towards lowering the barrier to entry.

The J2EE side of the aisle is way ahead of the desktop space when it comes to recognizing the value of a prebuilt framework. Web developers everywhere were building their own dialog management components, until Struts came along and gained a serious following.

Of course, the J2EE crowd went overboard. They're framework-happy! And, boy, am I confused. More on that in the next entry.

Two Rich Client Platforms Are Better Than One

In certain circles, raising the NetBeans vs. Eclipse question is much like discussing the relative merits of vi and emacs. They both pretty much do the same thing (though there are people on both sides who vehemently deny this). They both do a pretty good job. And, there are folks on both sides who think the other product is architected completely wrong.

So how do you wade through the propaganda and choose the platform that's right for your application? The two most important considerations are GUI toolkit and available modules.

Every comparison of NetBeans and Eclipse inevitably raises an SWT vs. Swing debate. Eclipse uses SWT, which is a toolkit that uses native widgets in the underlying platform. NetBeans uses Swing, which emulates its widget set using Java2D graphics. Propagandists on both sides will try to convince you theirs is "faster". This is like debating the relative merits of two cars at a stock car race. Driver skill plays a much bigger role. (In case you missed the metaphor, you are the driver.) For example, if you do any heavy lifting in your toolkit's event loop, your application is going to "feel" slow, no matter which toolkit you're using. Don't believe me? Download the bare platform (without all the Java IDE modules) for both NetBeans and Eclipse and play around with them. They're both pretty snappy.

Another common flamefest is the holy grail of "looking more native". It's a worthy goal to want to make your application look and feel like every other program on your target platform. The trouble is, it's difficult to find any two native apps that look the same! I've never seen a windows application with the same curvy tabs that Eclipse uses in its tabbed panes. Likewise, the tabs in NetBeans that, in some ways, act like title bars, are unique to NetBeans. Not that either of these are bad design decisions. "Looking native" can be taken to an unhealthy extreme. NetBeans and Eclipse both do quite a good job of rendering widgets that look like the basic widgets of the host OS. No naive user would look at either one and say, "Hey, that's not native!"

The ways in which the toolkit should factor into your decision are:

• Do you have prior experience with either toolkit?
• Do you have off-the-shelf components you want to embed in your GUI, that are already written in one of the toolkits?
• Does the finished product look the way you want it to, on the platforms you wish to deploy?

The second consideration in choosing your application framework is the catalog of available modules. Do you need an xml editor? NetBeans comes with two (text and tree based). Will your app integrate an RSS reader? Eclipse has one of those. Don't get caught up in the "which is faster?" or "which looks more native?" religious wars. Pick the framework that's going to do more of your work for you.

Now, this was written about six months ago, and some of my information is out of date. I think Eclipse has, or will soon have, xml modules in the base distribution. NetBeans has an RSS reader, of sorts.

I still stand by my criteria. I've since stopped likening the debate to VI vs. Emacs. Gnome vs. KDE is a more apt comparison. They drive each other forward. On a technical level, Eclipse is the best thing ever to happen to NetBeans. The rate of improvement is higher than it's ever been. In glancing at the Eclipse roadmap, I see they're targeting NetBeans features as well (such as better integration with external build tools like Ant).

The tools market is pretty darned big. There's room for both platforms. There's room for improvement in both platforms. Competition is making it happen.

This work is licensed under a Creative Commons License.