Joshua Marinacci's Blog

Programming Archives

A Response to GUI Building: tool vs hand coded

The debate of hand coding your GUI screens versus using a tool has come up again. I suspect that Stuart wasn't expecting quite the volume response that he got. For some of you this is old hat and I suspect we aren't going to come to any conclusions here. I would like to say one thing, however. We need to split issue into two separate items that are actually independent, though related.

We like to say it's a matter of writing your GUI by hand using GridBagLayout (which is the one layout manager always discussed) vs. using an proprietary opaque visual tool like NetBeans GUI Builder or Apple's Interface Builder (even more opaque). I think this is wrong. There are distinct issues here that should be handled separately.

Visual Tool vs Hand Coding

First there is the issue of using a visual tool instead of hand coding your GUI. I think there really is nothing to decide. Laying out your GUI is a visual task. Use a visual tool! End of story. I wouldn't design a newsletter without a visual tool like Quark Express. I wouldn't edit photos without a visual tool like Photoshop. Why should I design my GUI without using a visual tool like NB? That's madness!

Now notice I didn't say that you have to only use a visual tool. It's perfectly acceptable lay out your GUI initially using NetBeans and then add tweaks afterwards. In fact, I do this all the time. NetBeans will create an uneditable method initComponents() called from your form's constructor. initComponents() does the initial layout but you can then customize it however you like after that. You've got field references to every component. You can use them to do all sorts of cool things like adding painters, tweaking the layout of certain components, changing defaults, adding bindings, and pretty much anything else you want to do with hand code. It's not one or the other. You can use hand code and the GUI builder.

But what about the noneditable code? It's too complicated to understand! Why yes, that's right. It is complicated (though actually fairly straightforward, if verbose). However, you are never supposed to edit that code. That's why it's in an noneditable block! :) The form XML file is the definitive representation of your GUI. The generated code is simply an implementation detail with a few nice side benefits (like not needing to have NetBeans running to compile your code with Ant). We could just as easily generate bytecode directly and never show you the Java at all. Or we could parse the XML at runtime instead of compile time. You should never have to deal with that generated code just as you should have to directly deal with the bytecode generated by javac.

Proprietary vs Standards based

This is the other big thing I see mixed up in the hand code vs GUI builder issue, but it is an entirely separate issue from the previous one. I agree that standards are better because you do not want to be locked into a tool. Imagine you tried to move away from Visual Studio for your .NET apps. You'd find it pretty difficult to modify VS's form files. But the solution here is not to throw away visual tools. The answer is to use a tool that saves in an open and hackable format, preferably with open tools.

NetBeans is an open source product (and has been for many years). The GUI builder (formerly called Matisse) has even been ported to Eclipse. The form files generated by NetBeans are straight forward XML files that are actually pretty easy to modify by hand when necessary. So you can see that NetBeans's GUI builder is not the lock-in with proprietary specs that some people might think it is. It's actually quite open and hackable.

So we have reduced the problem to one a lot smaller. The only downside to NetBeans GUI builder is that it's not a standard format, meaning it hasn't been documented and there is no DTD. The format could change in the future as we add new features. Opening up the form.xml format would be a great thing. This is an issue we are aware of and hope to address in a future release of NetBeans. [Disclaimer. I'm not the keeper of the NetBeans roadmap and I'm not saying that we have immediate plans or that it's scheduled for NB 6.0 (it's not). I'm simply saying that it is on our horizon and something we would like to do. Everything in this post is my opinion only.]

Conclusion

So I hope I have split the issue successfully into manageable parts and cleared up some misconceptions (you'd be surprised how many people aren't aware the form files exist and think that NetBeans would read back their changes if only they could edit the 'blue' code blocks). Please send us you feedback. We really do listen and we really do want to hear what the community wants.

Thanks, Josh

Subversion Support in NetBeans 5.5

I've been so busy with NetBeans 6.0 work that I haven't commented at all on NetBeans 5.5. We just went final about a month ago and had a big party in Prague. 5.5 is a big release, though most of the work is under the hood or on the server side and being a client side developer it doesn't affect me much.. The new Visual Web Pack is pretty nice though. There is one feature, however, that I am really excited about and that I use every day. Subversion support. With NetBeans 5.5 you can download Subversion support through the Module Update center, and it will be built in to NetBeans 6.0. So let's dive in. What is Subversion anyway?

What is Subversion?

Why is Subversion Awesome?

Subversion is basically CVS with the bugs fixed and the sharp pointy bits rounded off. It improves upon CVS in pretty much every way while still keeping the same basic model. Here's just a few of the things that Subversion (also called SVN after it's 'svn' commandline program) get's right.

• Atomic commits. When you commit a bunch of files at once in CVS they are turned into a whole bunch of separate commits instead of one big one. This means you can't roll them back as a unit, or track them as a unit. With SVN you aren't changing a file, you are changing the entire structure of the tree as a unit. This means you can easily track and rollback changes as a group, the same way the developer committed them.
• Working offline. You can edit files and to diffs and status checks without having access to the server. Only when you actually commit does the server need to be there. This is great for hacking code on long trans-atlantic flights.
• Standard Protocols. Subversion uses HTTP and WebDAV as it's main transport protocol. This has two huge benefits. One, you can easily set up a Subversion server by using the mod_dav and mod_svn modules for Apache. This gives you easy maintenance and access control through a standard mechanism. You can even use HTTPS! Second, HTTP goes through firewalls better than anything else. No more futzing with SOCKS proxies and ssh tunnels to make CVS connect when you are at work.

Why is NetBeans Subversion Support Awesome?

Works like CVS. Previously Subversion support was an addon to the older versioning control system. Only CVS uses the modern API. Now Subversion does too, and it acts the same way. This makes switching between the two very easy. (very common when switching between java.net projects which can be either)

Built in. For 5.5 you can download it from the update center and in 6.0 it will be built in (I use it every day, actually). Nothing extra required.

You can still use the commandline. NetBeans acts like a good Subversion client, storing all of the versioning information in .svn directories. This means you can easily switch between the NetBeans client and the commandline version. For doing advanced Subversion tasks that aren't built into NetBeans this can be quite useful. For day to day use I say in NetBeans but it's nice to know that I could drop down to the command line if I need to.

change visualization NetBeans will icon badge and change the color of every buffer you have open as well as the source files in your Project view. This lets you know at a glance what has changed. You can also use the Show Changes command to see a list of changed files project wide and compare it to the server. You can also call the Show Changes command on just a directory branch of the tree. I do this all the time when I want to update something in the painters part of swingx, but not the whole project.

diff view NetBeans has a diff view which will show you both the server version and your current local version of any given file. When merging it will show you a third version at the bottom combining the changes of the two. You can use this tool to see what a merge will do. My only complaint is that you can't edit the file being diffed as I could in jEdit. I've been told that's coming in a future version, however.

Conclusion

Subversion really is a great tool. It provides almost everything I've ever wanted out of a revision control system. You can now choose Subversion instead of CVS when you create a java.net project, so it's great to finally have good support for it in NetBeans. You can learn more about the subversion support in Netbeans at http://subversion.netbeans.org/. Let me know what you think. What are you're favorite Subversion features and tips?

Swing Hacks in Japanese Ships

I'm going to be a complete nerd for a second and expound upon how amazingly cool it is that something I wrote has been translated into Japanese. I mean, writing down words that someone else pays for is cool and all, but it's even cooler when someone else translates my words into another language. The book even looks cooler. It's a tad smaller and has a very nice book jacket. The paper has a very different feel from the english printing; manga-esque actually.

Many thanks to Yuka Kamiya from Sun's Japanese division for sending them to me and Chris. Extra special thanks to Miyagawa-san and the rest of the folks at O'Reilly for publishing such an excellent translation.

Okay, back to your regularly scheduled english reading.

The Summer of 1998

Some time ago I wrote an article for Slashdot discussing Be, Apple, and the future of operating systems. The mention of Be should indicate just how far ago this was. The other day I decided to try to find the article both to find out if I was at all correct in my conclusions, and to see if my writing has improved at all. Well, I couldn't find the relevant article, as Slashdot's archives are not complete (and their search engine even less so) but as I was going backwards in time I ran across some articles that are quite interesting today. I suppose it's odd to think of something as recent as 6 years ago in an historical context, but in Internet years it must be centuries. So let's dive in:

It was the Summer of 1998

The now defunct Australian Erasure-esqe sugar pop band Savage Garden had the top rated rock (??!) song of the year: Truly, Madly, Deeply. Google had yet to reach it's historic stock prices and the bubble was still in full swing. I was fresh out of college and had just finished nine months as an intern at Xerox PARC. Fresh from the high of having been in a joint published research paper I was ready to tackle writing something on my own! Okay, in reality I just was a 22 year old code monkey for the real researchers, but it was a fun time and I got to soak up some PARC history. So here is what I wrote:

Remembering the Star.

After seeing an on screen demonstration of the last functioning Xerox Star computer I was struck both by how primitive it's hardware was (though rather advanced and expensive for the time) and by the things it got right that we still get wrong. I quickly wrote up this article based on my observations. I also started a short lived 'Simple Linux' initiative that died when I lost interest (as did most of my projects from that era).

In terms of writing I think I did fairly well, though I'm much better about not having run-on sentences today. I've also learned about these far out concepts like "the outline" and "listening to your editor" which have greatly improved my final drafts.

So what else was going on in The Summer of 1998?

Inevitable Microsoft Decline. While Windows may be collapsing on itself, Microsoft doesn't appear to be going anywhere. UI wise I think that Vista is going in the right direction. Heck, just renaming Outlook Express to Mail is worth an upgrade by itself. The XBox is certainly doing well, and now there's even a Palm Pilot that runs Windows CE. I'd say MS is fine.

The Myth of the Fall of SGI I don't really have much to add here. Ummm.... apparently it wasn't a myth.

Apple and Rhapsody x86. Ah, back in the days when we foolishly believed Apple was going to release Yellow Box, the code name for the NextStep API developer toolkit on Windows. Oh sure, it would have been crufty, slow, and not made any money for Apple at all; but it certainly sounded cool. I'm glad that I just bought a tangerine iBook three years later instead. :)

In other news

Well, that's it for now. In other news I've been working with Rich and Romain to build a truly killer demo that you'll get to see at JavaOne. I'm also working on some cool stuff with Painters that you'll see very soon.

Have a good week
  Josh

Props to the Trig Teacher

I'm working on a program that requires I convert degrees of longitude into miles. Since we are mapping radians on to the sphere (mostly) that is Earth, I needed to do some trigonometric calculations. Upon whipping out some paper and pencil and drawing the triangles I needed I realized had to remember which function to use. Is it Sine, Cosine, or Tangent? Hypotenuse over Adjacent? Adjacent over Opposite? All... blurring... together....

Then, from the back of my mind came the word: Socatoah; or, properly: SOH-CAH-TOA. This single word can be translated into everything I need: Sine equals Opposite over Hypotenuse, Cosine equals Adjacent over Hypotenuse, and Tangent equals Opposite over Adjacent. Perfect!

So I would just like to thank my Trigonometry teacher today for drilling SohCahToa into my head, oh, about 15 years ago. Proof that these silly mnemonics do work! Thanks!

Incidentally, Google reveals that Mathwords.com has a page on just this topic.

Java One Lessons : The book

Java One Lessons

The highlights for me were our session for Swing Hacks and meeting with customers at the JDIC and JDNC booths (more on that in my next blog). It's great to interact with developers (my "customers" essentially) and get some real feedback.

The session for Swing Hacks went quite well. I was incredibly nervous (I've never spoken in front of more than 50 people before), but calmed down once I got going. I sure drank a lot of water though! The talk was well attended (about 75% full) and we had quite a few people hang around afterwards to ask questions and sign copies of the book. Very exciting.

The book finally went up on Amazon during the conference so we can finally see what the sales ranking is (4kish, last I checked). It was originally supposed to be shipping from Amazon on the 22nd but there was a last minute glitch with the printing and we had to scrap a lot of books. Some pages near the front (all of the preface, I think) were missing the purple headers and chapter numbers. Since this was the printer's fault (not O'Reilly's) they had to scrap them all and rush to print up new ones. For the first few days the bookstore at JavaOne was the only place you could buy the book, which is why it didn't show up on Amazon until later in the week. We kept a few of the misprints to give away to the audience and other attendees, but all of the ones for sale (both at JavaOne and at other traditional sellers) are the correct copies.

We started getting our first few reviews in. The one on Amazon was very positive. The one from elliotth was pretty negative. Well I knew not everyone would be happy with the book. It's a bit of a departure from the other hacks books but I think it turned out pretty well. I think the biggest issue with the book is that it's not for everyone. If you are a super advanced Swing developer then some of the techniques will be things you already know. (Also, being in the hacks format we don't always have room to fully explore an idea, just show it's possible and suggest where it could go in the future.) Now if, on the other hand, you are a newer Swing developer who knows the basics but wants to push the envelope then this book is for you. Either way, read the reviews and tell me what you think.

One thing that worries me is that both reviews mention visual problems with the beginning of the book which makes me wonder if they got one of the misprints. If you purchased the book (rather than a freebie or promotional copy) and don't have a purple (headers, chapter numbers, etc) in the preface then please let O'Reilly know.

If you do want to buy the book I suggest you get it from Amazon. First, it'll save you 10 bucks off the coverprice that you can go spend on a nice frost beverage or three. Second, the sales numbers on Amazon are probably more important than from anywhere else and it gives us better feedback than browsing in a store. (Of course, if you really want to check out the book in a physical store and buy it there we certainly don't want to discourage you! :)

Enough about the book. I'm glad we wrote it and I hope you like it. If you have any questions feel free to email me. If you don't have the book (or don't have it yet :) you can read several of the hacks up on the official Swing Hacks site for free. If you have your own Swing related hacks you'd like to contribute then you can send them here.

Thanks for all of your support. Without your positive feedback here on Java.net we never could have written the book.

- Josh

New MiniApp: Storm Drain

While playing around some more with this miniapp idea, I came across geographer Tyler Mitchell's weblog post about hurricane tracking using Web Map Service urls. I thought this would make an interesting MiniApp and give me a good opportunity to play with a few webservices. Starting from his base (and with some greatly appreciated clarification emails from Tyler), I've created StormDrain, a simple program that loads WMS data and displays it graphically. Here's what it looks like:

Storm Drain: Jeanne Data

WMS data services give you access to lots of useful information. It can render storm data for any geographic area and resolution you want, returned in a variety of image formats. It also has a discovery mechanism that lets you programmically find out what storm data is available. http://dev.gomoos.org/cgi-bin/wms_nhc?request=getcapabilities will provide you with a XML list of every request and format the service understands.

In my program you can left click to recenter and zoom, and right click to zoom out. The Storms menu gives you the list of storms generated by the GetCapabilities request type. It uses a zoom factor to determine which latitude and longitude to use when requesting the maps.

The land map images have a light blue background that I wanted to replace with something more oceany. To pull this off I created a color swap filter that will replace one color with another. For the land data it replaces the background with a dark blue. For the storm data it replaces the background with the transparent color (0,0,0,0) so that the other layers will shine through.

Java2D's image APIs make this kind of a color filter quite easy to implement. First you need a custom RGBImageFilter called ColorSwapFilter:

class ColorSwapFilter extends RGBImageFilter {
    private int target;
    private int replacement;
    public ColorSwapFilter(Color target, 
                           Color replacement) {
        this.target = target.getRGB();
        this.replacement = replacement.getRGB();
    }

    public int filterRGB(int x, int y, int rgb) {
        if(rgb == target) {
            return replacement;
        }
        return rgb;
    }
}

Any RGBImageFilter must implement the filterRGB method, which will return a new color based on the input color at the current x and y coordinates. In this case it returns the replacment color when the current color matches a target, otherwise it just returns the original color. Note that I've used getRGB() to work with the colors as integers instead of color objects.

Filter in hand, you can now filter any image to swap the colors. This is a utility function that gets the source image, creates a new filter to swap the target color with a transparent color, then executes the filter with a call to createImage() on any component (a new JPanel in this case). It's that simple

public Image loadTransImage(URL url, Color target) {
        Image src = new ImageIcon(url).getImage();
        ImageFilter imgfilter = 
           new ColorSwapFilter(target,new Color(0,0,0,0));
        Image img = new JPanel().createImage(
           new FilteredImageSource(src.getSource(),imgfilter));
        Image imgx = new ImageIcon(img).getImage();
        return imgx;
    }

StormDrain loads data from a WMS service provided by GoMoos.org

Storm Drain webstart link

updated webstart link

Myth: There aren't any commercial apps written in Java.

The last few months have been great for client side Java. With the release of JDIC, JDNC, Java 1.5 betas, and more support than ever from Sun, I think we are seeing a revival in interest for client side Java. Still, I hear the usual refrain: "If Java is so good on the desktop, then where are all of the commercial apps?" If I point to something like LimeWire I get: "No. I mean big applications, like Word." Well, I never have an answer for that one. I didn't seven years ago and I don't know. Speed and API support isn't an issue anymore, but there still aren't any well known commercial applications written in Java. That finally led me to the question "Is any big name application written in anything other than C/C++?"

The answer is, strangely, no. Perl, TCL, PHP and Python. No big commercial app is written in anything other than the stalwarts: C and C++. But I also came to another observation. There aren't any new big commercial apps.

I want you to seriously think about this for a change. What big established software is there that's new? On my computer I have running: Mozilla, Outlook, Word, Excel, Photoshop, and jEdit. All of those, except for jEdit (a Java program), stem from a code base that is at least 7 years old. Excel is twenty! There simply aren't any new big desktop applications.

I remember ten years ago browsing through various computer magazines that would review the latest versions of word processors, layout programs, and databases. There was real competition then, and whole new categories of software came out like disk repair utilities and floppy disk compression.

Today all of that software has been either commoditized or monopolized (or both). All of the new software is small. There aren't any new large applications. The market for such things is already saturated, and no new software means no new languages for writing it.

New software is being written, of course. Constantly. It's just that the new software isn't what we would call Big Desktop Applications. The new stuff is all small. All attacking small problems with specific solutions. No need for a general multi-media package. Instead we have one for playing and managine music. One for editing music. And one for combining music with photos. Instead of one package Apple gives us four with iLife.

In addition to being smaller the new software is increasingly webbased, like Yahoo Mail, or living half on the network and half distributed desktops. This new breed of software is increasingly being written in new languages.

And most importantly, this kind of software is where the growth comes from. There aren't many new desktop spreadsheets anymore. In fact the only new software I've seen come out of the word processing category has been a result of commoditization of the file format (.DOC is now a stable target for reverse engineering) or of the category itself (it's easy to reimplement the features that we now know we need in a word processor).

There's lots of new network and multi-media apps though. Chat. Distributed PIM. P2P file sharing. MP3 players. And I don't even know what category to put Friendster in. These categories are increasingly being done in Java. And Java's faster development type and rich API really shine in these kinds of applications.

So don't worry about the lack of large applications. There's only a few of them anyway. Be more interested in the multitude of exciting, dynamic, and little applications.

Java's got a Bad Rep: The Rebuttal

So it's been a week and I've seen a lot of response to my last entry. One commentor in particular asked for a point by point rebuttal; which struck me as a spectacularly good idea. Here are the bulk of the arguments and my responses.

The Arguments

• Java isn't Free / Open Source / GPL / RMS-friendly
• Why use Java when there are plenty of native languages / environments to choose from.
• Java is missing templates / preprocessors / lambda functions / other advanced language feature that only backwards cave-dwelling languages lack.
• There aren't any applications written in Java. It must be a failure.
• Java / Swing is slow, looks bad, and doesn't feel native, doesn't let me do cool stuff like animation, 3D, or sound.

Here we go.

The Rebuttal

(1) Since it's such a huge (and apparently controversial) topic, I am covering the open sourcing issue separately in this other post. However, in summary, opensourcing doesn't solve our problems and buys us very little, in exchange for a lot of new problems. Follow the link for a full analysis.

(2) Why use Java when there are plenty of native toolsets to choose from? Well, first of all, it's better than a lot of them. If you want to write an application (not a script or a device driver) then Java provides you with a good toolset, great libraries, and a clean language which learned from the mistakes of the past. It's simply a good applications language that can make your programmers more productive.

Java can also be "write once, run anywhere". For people who need to support multiple platforms, especially more esoteric ones where you could never hire a native expert (say the palm pilot, or win 98), or if you simply don't want the headache of dealing with bizarre version issues, then Java provides you with a consistent platform to code against. It's compile once, run anywhere features are especially important in the age of ubiquitous networks with code flying over the wire. Java Webstart has been a godsend to companies with locked down desktops spread over the globe. (potentially running eight different versions and patch levels of Windows).

So why use Java? Because its better than a lot of the alternatives for writing applications.

(3) Java is missing language features. This is probably more a matter of taste than anything else, but Java isn't lacking features because no one thought to add them. Nothing in Java is new. Every part of the system, from language to library to VM, was carefully considered against the 20 year history of OO languages. Preprocessors were left out for a reason. So were pointers. Java is missing a lot of the more esoteric features, but most of those features aren't used in day to day programming anyway. A few of them, like generics, are slowly becoming more mainstream, and Sun is adding them as people ask for it. Remember, computer languages evolve slower than hardware or software platforms. It took 20 years for inheritance and polymorphism to become common place (and it's till not as common as you might think). The features Java is supposedly lacking we really shouldn't miss. And if there's something you just have to have, then you can use one of many addons to provide it like XDoclet and Shark, safe in the knowledge that if it compiles to Java bytecode then everyone can use it.

(4) Nobody uses Java. This simply isn't true. Probably 99% of Java applications are either serverside (where the user doesn't know or care what the application is written in) or are made for internal corporate use. As Eric Raymond pointed out: "there is empirical evidence that approximately 95% of code is still written in-house". Most Java applications, even Swing apps, are for corporate use. In these environments the robustness, productivity, and easy of deployment more than make up for Java's other flaws. There are plenty of high quality applications that people don't know are written in Java, and that's really the problem. Especially on the desktop I'd like to see more highlighting of Java success stories (and more ways to get the word out!)

(5) Java is slow, ugly, and doesn't do modern native things. I've saved this for last because I think it's the biggest problem. Java has this impression because, well, it was slow and ugly. Back when Java debuted nothing worked properly, applets were slow to load, and AWT used a horrid subset of the available widget set on each platform, all of which looked different and ugly.

Today the situation has changed. Swing has gone through several revisions to become a powerful toolkit, if complex. The speed issues have mostly gone away from improving the libraries and a decade of faster processors. Even on my now aging iBook I run jEdit quite nicely and have written tens of thousands of lines of code with it.

Swing itself has also matured (and gotten prettier). Most of the big bugs have been fixed. Quite a few attractive Look and Feels are available from Sun and 3rd parties. A lot of the missing functionality from the early days is finall in place. It is entirely possible to make great desktop applications, even consumer apps, with Java. We just need to get people to realize it.

The plan

Despite all of my argument preceding, Java still has an image problem. People still think that you can't write good desktop applications in Java because they don't see them. So what can we do? Show them! And keep building more!

First, we need to show off the good apps. Get the word out. I think we need a place to highlight great applications. Perhaps a sidebar on Java.net with a new application each day. The only requirement is that it be a desktop application with a downloadable demo. This spot should have it's own RSS feed and archive. Then we have to start the publicity. Get other sites to link. Make a download.com for Java apps.

Second, create a place to collect all of the tips and tricks it takes to make a quality desktop application. I've started a Wiki node here with a framework of what we should pull together: exe packaging, good look and feels, swing tutorials and articles, how to work with different kinds of media. Contribute whatever you know. We need to fill out the missing pieces.

Third, start a contest for quality Swing applications along the lines of O'Reilly's MacOSX app contest. We should have different categories for commercial and open source, full applications and mini programs, and maybe further sub-classification (word processing, media and graphics, personal organization). We'll probably need to get a corporate sponsor for this.

We all know that Java can make great software on the server. It's time to reclaim the desktop. (Wiki Here)

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

Does Java have a bad reputation?

I recently read on Slashdot (something I promised myself I was going to do less) about Miguel de Icaza's comments on Longhorn. It was a pretty interesting read and makes me think I should read up on XAML and Avalon, Microsoft's new technologies for making advanced rich web applications. What struck me as particularly jarring, however, was this thread where someone asked about Java as a webapplication stack to compete with Microsoft or an as yet unwritten opensource toolkit. Most of the readers jumped on this and attacked Java from all sides. What particularly worries me was not that so many of these readers are opposed to Java, but that their arguments are almost completely wrong. Take a look at some of these comments:

Stock Java is not an option because it lacks a few things: the easy-to-build functionality of a web page (XAML) and the advanced graphics and rendering of Avalon.

However, it really does not matter what is going on in the java world. Java had its chance, and failed. Java the language has outgrown the Java the (virtual) machine. Java the language is now being extended in weak syntatic ways, think of generics where it is possible to corrupt generic containers because the support is only syntax deep.

Java is faster now, and computers are faster now, but technical analyses of .NET and the CLR tend to indicate that it is better thought out than Java. No wonder, since it came substantially later than Java, but that doesn't change the fact.

If Sun brings us a Java 3 in the near future which addresses these performance and scalability issues (among others) then this post will be irrelevant (well I guess it is already, welcome to slashdot right?) but right now it makes more sense to emulate the CLR and the non-Windows portions of .NET. Since Java is not open source, and the open source world would like to have something like Java but open, and .NET and the CLR are superior to Java (arguably anyway) why not implement .NET? If Microsoft changes their implementation to a point which destroys compatibility, there is still room for Mono to provide a cross-platform runtime environment which will run on Windows.

The main problem that I, personally, see with Java-based apps, is the non-native widget set. I have to admit, I honestly detest Swing/AWT stuff. Swing even more. Not only is the default theme ugly IMO, but even if you make it *look* like WinXP or Gtk or whatever, it doesn't *feel* like it.

Java is a minor cleanup of a horrible set of object oriented extensions of a 35 year old high level assembler. Perl/Python/Eiffel/Tcl-Tk show what Java could have been and where it could have gone. Furthermore, even as a cleanup of C++ it got too many things wrong, as illustrated by the numerous minor bug patches in Java "the next generation", more commonly known as C#

I'm starting to really wonder why Java, or at least Java on the desktop, has such an image problem? If you are talking about rich web enabled applications that run on your desktop and on the web, then Java should be at the top of the list. Do we need a PR agent or something?

The future is Vectorized

I know it's been a while since I've posted. But I've been busy. With, um, you know, stuff! Writing stuff. Coding stuff. Drawing stuff.

I'm especially interested in drawing stuff. In particular I've noticed a growing interest in SVG and vector displays. I'm personally a fan of vector formats since it makes a great base for interesting drawings in Photoshop, but I've started to discover other uses too. This article covers the history of SVG on desktop Linux.

What I find most interesting about SVG is that it was created as a webcentric technology but it's finding great traction on the desktop in places like icons and window decorations. So why the new buzz about SVG in a technology world still in the doldrums? I attribute this to two things. First, processor speeds have continued their inexorable rise, making realtime vector drawing feasable for lots of non-standard (wasteful) uses. Second, Flash, SVG, and other tools have raised a generation of people who think of vector art outside the confines of Illustrator and it's print mindset.

Of course, if we rendering everything as vectors the curves and angled lines won't be as sharp as they could be with bitmaps. Even with modern anti-aliasing nothing will be as clean as an image from photoshop. Assuming you have a normal resolution screen.

We are reaching the limit of usefulness for normal desktop screen size, but what happens as pixel densities increase instead of screen inches? My ibook had a 109 dpi screen and I found it to be much more readable than the larger 92dpi laptops I tried. Years ago when I interned at Xerox PARC I saw a prototype of a 270dpi flatpanel. It was black and white, not even greyscale, but at that resolution you can start doing halftoning. The clarity was amazing. Many people also noticed the announcement of Sony's epaper initiative. This is the kind of product that requires real vector art.

So now that the tools, devices, and the platforms are coming along, what can we actually do with SVG and other vector formats. We've still go the usual suspects: clipart in Word, animation for games, and technical diagrams. But somehow I think more is coming. So where could we use vector rendering creatively?

• Scale the desktop icons. This happens to some extent in OSX and now in Gnome and KDE. That's how we get those nifty dock effects.
• Theme your app's UI with CSS. Change the selection color. Make every font bold and every line thicker. If it's all drawn with SVG then CSS for style will be a snap.
• Scale the screen widgets. Menus, icons, buttons and checkboxes, everything. Rumors are that this will happen in OS X 10.5: Jungle Cat's Revenge. Adjust the screen to match your eyesight, distance from the monitor, and lighting.
• More special effects: how about a ripple through your screen when you receive an IM?
• Vectors on gadgets: My Palm Zire71 is fast enough to do quite a bit of vector drawing. We need more screen readers and vector games. Not to mention a really good drawing application.
• How about Alice in Wonderland with the original illustrations? Or maybe mathematical texts with the real symbols. Vectorizing chunks of Project Gutenberg could go a long way towards making the etexts more accessable.

The possibilities of commonplace vector rendering are limitless. The only limiting factor I see is that we don't have a good archive of opensource vector art to start with.

2004: the year of the Net-App

A lot of people have put out lists of what they expect to see for the new year. Instead of going across the industry I'm going to focus on one topic in particular: networked applications. I really think that 2004 is the year of the netapp. Now sure, I know what you're thinking: "I thought 1994 was the birth of the most popular networked application ever: the webbrowser. You're about ten years too late". I'm not talking about the webbrowser. It's a general purpose application that isn't very good at anything, but good enough for almost everything. I really think the last few years have shown a desire for specific networked applications that, in the long run, will blow the pants off ye old browser.

We've seen the apex of business applications. Crunching numbers and wordproccesors just don't interest people anymore. The growth is dealing with small nuggets of information, and lots of them. Most consumer apps involve media manipulation or communication in some form, almost always over a network. It's not quite 'the network is the computer', but it's certainly the case that 'without the network there is nothing for the computer to do'. Dedicated networked applications, not just general purpose webbrowsers, really seem to be the way to go.

But this is still a lot to cover in a blog entry. I'm going to narrow it down even more. Being a UI guy I have ask myself: what are they going to look like? Thinking about this over my vacation here are my predictions of what we will see in the coming wave of dedicated networked applications:

• Search: Searching is important. By definition, networked apps give us access to something that our desktop can't, one of which is holding huge datasets. Thus searching those datasets will be of the utmost importance. I expect every application to have a search feature in it. Google has conditioned us think in terms of keywords ANDed together. iTunes has popularized incremental (keystroke) searching. I think eventually all GUI toolkits will have a custom search widget to support this behavior right out of the box. I also think that Lucene is one of the coolest open source libraries ever.
• HTML will be heavily used. This means both the browsing metaphor where appropriate (bookmarks, forward and back buttons, clickable links) and literally HTML rendering in the middle of the application. The iTunes Music Store, Sherlock, RSS readers, and even chat applications are all using HTML for the display of formatted text and graphics. I think this trend will continue, especially as HTML rendering engines become more embedded in our operating systems and programming languages.
• Connectedness All netapps need a sense of when they are online and when they aren't, and when to pass that information on. Since it will be a long time before we are permanently connected, and etiquette may dictate not even then, we will need connectedness built right into the UI. Chat apps have logged in / away / offline status indicators. Gnutella clients tell you when you are searching and when people are searching you. Even email tells you the state of the network with it's greyed out folders and a checked for mail alert sound. The sense of connection state will become integral to the UI.
• Drag and drop I know, it's not a new UI component, but it's becoming more and more important. Since the desktop is rapidly becoming a set of portals into other servers and datasets, we need better ways of extracting and moving data between these datasets. All netapps will need to accept and produce drag and drop events for text, files, links, and images. This also implies ubiquitous media libraries with thumbnail previews. (Can you say QuickTime for Java?) DND support has been growing steadily in all UI toolkits, but I think we are at the point when they will finally become massively useful. Of course this will cause new problems with information overload. I'm hope to have a shelf on the side of my screen that can accept drags from any application and store them for later use. Is anyone at Apple listening?
• Syncing While the technology is established it is only just now becoming ubiquitous. The link between desktop, server, and device is more common than ever and Palm has gotten everyone to accept syncing as a metaphor. (This dispite the fact that sync is not actually a word) Now phones sync addresses to Outlook, calendars sync through servers to other calendars, and iPods (my new christmas gift. thanks honey!) sync music from iTunes. Syncing is everywhere and many netapps will need some form of syncing worked into their feature list. I expect to see more syncing toolkits as we get too many devices needing custom conduits.
• Discovery You know something is out there but you don't know what or where. This is why we've seen an explosion in discovery protocols lately. Really it's a meta search, a search for things to search. I expect to see rendezvous/zeroconf, jini, jxta, gnutella, and other discovery protocols integrated into reusable libraries. Perhaps they will even hook up with RSS and Google to become truly internet savvy.
• Non-heirarchical organization Sorting is the opposite of searching and putting things into a structure is actually much harder than getting them back out. Our data is just getting too big. There's too much information to keep track of. I personally organize my email as a nested tree structure: friends, work, online, other; with many subcategories. Now I have too much to sort comfortably. What I really need is a gigantic flexible relational database to hold it all. And every netapp I have should dump it's info into the database without my assistance. And it should intelligently sync with my server and my Palm, phone(s), and iPod.

I used to think that networked applications and distributed computing would take advantage of one simple idea: use someone else's cycles. Now, with Moore's law showing us that there's no application too big to run on the desktop of the future, I'm seeing that the real use for the network isn't to get at someone's cycles but at their databases. Every thing on my list above boils down to accessing someone else's databases. Storing, searching, manipulating, and syncing databases.

In some ways this is new because we are using new technology to do it, but this is really what we have always used computers for. The UI advances I've listed all reflect a need to visualize the above tasks in ways that are meaningful to humans. And that's what good software has always done.

This work is licensed under a Creative Commons License.