Tim Boudreau's Blog

Tim Boudreau had his first startup when he was 13, and has been hooked since, with brief departures to play rock and roll, write and play music and do graphics and photography. He is the coauthor of NetBeans, the Definitive Guide from O'Reilly and Associates. Tim was part of the team that open sourced NetBeans, Sun Microsystems' Java(tm) development environment, and currently work as a developer on that project. Originally from Massachusetts, he lives in his adopted home city, Prague, Czech Republic.

In my other life I'm a musician

It's a hard thing, to decide what to say about a song or any work of art you've created - some people want to know what you were thinking and feeling when you created it; some people want to know the technical details of how you did it. Both are valuable and interesting information, but they are interesting to different audiences. I'll say below what matters to me - sometimes the technical details, sometimes the personal ones, and it will just have to do.

So here's the player, and below are the stories:

Milltown Stars—this came out of a songwriters group exercise - draw a character, a setting and an action out of a hat, and have a song that incorporates them for next week. I drew "a barber smoking a cigarette in a funeral parlor" and spent 6 days wondering WTF to do with that bizarre combination. The result incorporates of bits of my grandfather's life, my life, and my friendship in high school with Steve Toutant (whom I'm glad did not find a career as a barber) and I think is one of the best story-songs I ever wrote. Sometimes you just need an excuse to write. Naah, always you need an excuse to write - it's just that when I was a teenager it was the everpresent need to get laid. Us middle-aged folks have to find *actual* inspiration - this is why I'm growing an appreciation for country music - I've written enough baby-baby-wanna-wanna for a lifetime. Max Cohen on acoustic guitar, Kevin Sharpe on drums, Steve Toutant on bass and me on piano, vocals and slide guitar. Walk Out On The Water—this is a song about miscommunication or misunderstanding. Two guys both have the ability to walk on water and each thinks the other is crazy, because of course that's impossible I Know That You Are—One of the most interesting production bits I've ever done (thanks to Warren Ondras for the binaural recordings of cicadas in the woods during the electric guitar solo). The lyrics certainly don't represent my attitude toward women, but it does reflect an attitude I've encountered; I've tried to represent that authentically. Max Cohen laid down the immaculately inappropriate acoustic guitar solo over a sea-of-tuned-bulldozers a few weeks ago, finally finishing this song up. Thanks to John in Prague for suggesting I redo the drums to be more hip - you were right. Song for Maryanne— Co-written with Doug Finn. A song of unrequited love, and how life gets in the way and there's no fix unless your willing to change, from the perspective of someone who can't change when it's long past time when any change could do any good anyway. Not quite for but a bit inspired by Lori Silverman Hurley. Young Again— written for a woman I fell madly in love with when I was about 12, and never quite fell out of madly in love with. I wrote this while renting an apartment in my hometown in 1995 and feeling like I'd gone nowhere in life, just before christmas, contemplating giving her a call. The invitation to her wedding arrived two days after I laid down the demo of the song. Lesson: Spend less time writing self-pitying songs and more doing something about it :-) On the musical/technical side, I wanted this song to be sort of Tom Waits meets The Byrds - twangy guitars against a voice that sounds ruined and destroyed. I had to do the vocal over three days because it plain hurt to sing like that - but I wanted it to hurt and sound like it hurt, and you only get that by doing it honestly (or perhaps genetic quirks - I don't know what explains Bruce Springsteen). This is one of the few songs I've recorded where I can say that what I got recorded was almost exactly what I imagined it should sound like. It's paid for itself. Much thanks to the guitarist from the band Leticia that let me use their 12-string Rickenbacker electric guitar to get The Sound for this tune.

• I Dunno Whatchakindu Wif Yo Luv—in the 80's I kept getting this urge to write obnoxious mysogynist spinal-tap-esque bad metal songs. Really I just wrote it to see if I could sing scratchy falsetto like the guy from Britney Fox (look it up). Basically everything I do is because I love to sing, and the point there is to see just what things I can make my voice do. This was 1991 reel-to-reel, pre-digital-magic, so apologies for the arthritic guitar solo - I learned the instruments I play because I love to sing, not because I wanted to be Eddie Van Halen (now that dates me!)
• She's Putting It Into My Head— In the UMass dorms in 1988 or so, I had this idea for a song called "She's putting it into my head" - with the idea that the title sounds like an innuendo until you think about it and realize it's straght-out gibberish. Noah Jorgensen, my dorm-mate supplied most of the chorus other than that line; the verses are pure gibberish I ad-libbed into the mic in one take

There are about 240 more songs where these came from. Some better than what's here. If you think my programming work is good, and that my musical work might be good too, you'd be doing me a personal (and repaid if you ever ask me to repay it) favor by clicking the "Become a Fan" link on the widget above. Enough of those and one day I can get some of this stuff on ITunes and Rhapsody.

I've been writing songs for 20 - wait, no, going on 30 - years - not because I want fame and fortune, but because it's a compulsion and I love doing it. Listen to the stuff. If you like one of the songs, click the Become A Fan link (and uncheck any send-me-spam boxes - I don't like it any more than you do). After all this time making this stuff, it would be nice for it to be heard.

My style is so schizophrenic that you get one jazz tune, one Rossini overture, one death metal tune, followed by a hard rock tune, a folk rock tune, and something uncategorizable - give me two songs in any style and I can write in that style. So if you don't like the first thing you hear, please try another before giving up - my style is really whatever I've been listening to most recently. And let me know your thoughts, what you like, don't, and what could be improved. Nothing is ever finished (especially if you have all the raw tracks. Harry Chapin got all his family members to bombard Boston radio stations with requests for his songs. They did it. If it hadn't happened, "Cat's in the Cradle" and "Taxi" would not be in our collective consciousness - we all heard them when we were kids and for many of us they caught our hearts. You could help that happen again just by going to my music page and clicking the "Become a Fan" link on top of my picture. You'd be helping me out, and it would be much appreciated.

Only if you think some of this stuff is good.

Juggy gives Duke a workout

Photos from JavaOne

It lets you do some things that were possible on old-fashioned bellows cameras, but are normally impossible with an SLR camera, where you can't change the relative angle of the lens to the film/sensor. For example, the "Java = Opportunity" photo below is taken at an extreme angle - yet all of the phrase is in focus. It's also great for putting the "sweet spot" in the focus in weird places.

NIO file backed buffered images

One of the JDK team guys assured me about two years ago that with JDK 7 this would no longer be a problem - but I got no sense that he either understood what the problem was, and I couldn't think of a way you could really solve it without doing your own memory management.

Say you're writing an image editor application. "Tools" draw on the surface of an image. You want to provide undo support. You have a few options:

Make copy of the whole image - but this is silly, the user changed part of the image, not the whole thing Notice the minimal rectangle, and save the previous version of that plus its coordinates - this is easy - wrap the Graphics2D that is drawn to in a proxy that records the bounds that are actually modified - then save a snapshot of just those bounds

The solution was ByteNIOBufferedImage - it's a regular BufferedImage you can treat like any other. But its backing data is a index into a memory-mapped file (there are still fragmetation issues to be solved - this *is* doing home-grown memory management, the thing Java is supposed to save us from). You don't want to take one of these images and paint it straight to the screen - it will be non-accellerated and pretty much deathly slow.

But it does provide a way to store semi-unlimited amounts of image data for a Java app without requiring huge heap sizes.

Anyway, it's definitely not for everyone but I've gotten enough private emails from people who wanted to use it that it seemed worth mentioning.

Pong: The most truly daft NetBeans plugin ever

I had a pong game when I was in about 3rd grade. It plugged into the black and white TV in the kitchen, had two paddles and one switch for ball speed. The real fun was when the cat would stand up with her paws on the bottom of the screen and try to swat the ball as it went by.

I've been demoing integrating a hex editor into NetBeans for years, to show how easy it is to take a Swing app and turn it into a plugin. It was time for something new. So I spent an hour and wrote a Java pong game - enhancements are welcome.

I'm thinking the demo should be a backward version of the "boss key" those apps that pop a fake spreadsheet up on your desktop whenever your manager walks by so it looks like you're not surfing the net. This is just that, in reversed. It's the "Please fire me" key - press it whenever your boss walks by, and you're obviously spending all your time playing dimwitted video games! There are enough dumb companies and awful programming jobs out there that I think it just might have a market :-)

I'll demo it at our Java University talk tomorrow night - we've now got seven speakers lined up, and it's going to be a load of fun - and I'm trying to get the doors opened for anyone who wants to come, whether you paid for Java U or not (still waiting for the response on that, but I'm hopeful).

And in a totally unrelated development, I was in an elevator today and ran into two colleagues from when I was in Grenoble, France, (still one of my favorite places in the world - although, do not buy reblochon (sp?) cheese, let it sit in a backpack for two days and then open it in a train car and not expect to get dirty looks - it's much less stinky when cooked!) helping out the Real Time Java guys. It seems they've been retasked for some months with creating a really cool JavaFX graphical designer - animation timelines and all. These guys are really good, and I'm looking forward to seeing their work on Tuesday!

NetBeans and Its Ponderous Plugificators - coming to JavaOne - fun to be had

Yes, the title is "NetBeans and It's Powerful Plugins", and no, I had nothing to do with the title. My job is to make it something you'll enjoy so much that you'll be proud to have attended a talk with a name like that.

And the main thing is to open it up to the audience - what can we show you, what can you show us, what do you want to learn about, what do you wish we'd support more in NetBeans. Open source is collaboration between the users of a technology and the makers of a technology - and ideally the merging of the two. I hope you find you can come and be part of that.

Ohloh's open source project statistics - WTF?

Take, for example, the Wizard project. Now, this is something that I initially whipped up in two afternoons in September '05. It's a small library - it's attracted six contributors since then, who've all made valuable contributions. I tend to do work on it sporadically, for a couple days every 4-6 months. At most I've put 2 weeks work into it. With contributors, the pattern is that it's people who are using the library and want a feature that isn't there. They implement it, and get on with doing what they wanted to use the library for, which is as it should be. If somebody wanted to take on an ongoing role, that would be great, but I'm not holding my breath.

According to Ohloh, this weekend project represents (!)

• 8 person-years of work
• More than 1 million dollars of at something resembling my current salary (deliborate obfuscation) - but even more interestingly, only half that if you leave out the documentation :-)

• Made 3 (!!) commits since 1999
• My primary language is HTML (!!!)

Separately, I take issue with the notion that Decreasing year-over-year development activity deserves this warning icon - for example, it is displayed on Ohloh's page for my Color Chooser project.

I mean, think about it: Especially with small projects (IMO in a perfect world, most library projects should be small and tackle one thing well), a positive goal is for the project to reach a steady state where it does not need a great deal of, or ideally any, maintenance. If software rotted like fruit, there wouldn't be any progress in the software industry. There is such a thing as a library that can be finished!

What was that quote about lies, damned lies and statistics?

A library for diffing java.util.Lists

There are a number of libraries around that support using Collections as models for Swing components. But most revolve around observable lists, or wrapping lists in observable wrappers.

But sometimes, you simply don't control the code that is handing you a list. I was in that situation when writing the Navigator for NetBeans 4 — I could get a list of class members, but there was no way to detect changes between them except to compare the previous list I got with the new one.

So I wrote this general-purpose library for generating diffs between lists. It has proven useful in many projects, some not NetBeans-related, so it makes more sense as a project apart from NetBeans.

The main wiki page for the project describes it, and the choices of algorithms available, in detail.

With it, there is also a subproject that implements Swing ListModels, to make it easy to use with JLists (it will be there as soon as I make a build of NB with this bug fixed).

Trademarks and Open Source

Since article comments are less often read, I am posting my comments in expanded form here. This comes with the usual caveat: I am not a lawyer (I don't even play one on TV), and my opinions are my own.

Ironically, most of what I am discussing does not help the author of that PC World article, since his issue was with using the trademark of a Linux distribution. In the article, however, he brings up the subject of the licensing of the word "linux" — which touches on a legal rats' nest in open source licensing that I have seen cause a great deal of trouble.

I've been saying for years that somebody needs to do for trademarks what the free software and open source movements have done for licensing. At Sun Microsystems, I have watched trademarks wreak havoc with various open source projects.

I disagree strongly with the comments such as "Trademark laws are critical to the success of open source software." I have seen them be harmful or benign, but I have never seen them provide a positive benefit.

Names are important - software is for human beings, and human cognition requires that a piece of software have a name - ideally a sayable, memorable name. Especially with open source projects, where there may be multiple distributions, name recognition builds perceived ubiquity. Without a name, potential users and community members cannot find each other.

Imagine if every Linux distribution had to have a different name that didn't use the word "linux" (think: Joe's Operating System, Foobar Corp. OS), would linux have ever become popular? In the early '90s I used Slackware Linux, and later RedHat Linux. If these things had not used "linux" in their names, how would I have even known that they could be somewhat interchangeable, or how to find help on using them? As a Linux user, there have been plenty of times that documentation from, say, Gentoo Linux, has helped me solve a problem in my install of Ubuntu Linux, or vice-versa. If I didn't have the noun "linux", would I have ever found that documentation? Or would I have given up at some point and not even be a linux user today?

In the real world, I have never seen trademarks be good for open source. At best, they're sometimes not harmful.

One response said:I can download Ubuntu for free, but how do I know I am getting the real thing

You know where you are downloading it from. And that's the point - a trusted source for software is much more reliable than a trusted name when it comes to open source software. Open source software can be recompiled by anyone to create the same binary. The distributor, or the point of distribution, is the brand. The name of the software belongs, or should belong, to the community.

To pick on one of Sun's own projects for a minute (let the hate mail come), the kind of mess trademarks can cause when they meet open source can be seen in action with OpenSolaris where alternative distributions are required not to use the word "solaris". This is suicidally stupid for the health of the project, particularly for distributions - there is no way for people who don't already know that multiple distributions are really the same thing to find out. That puts a very low cap on the amount of adoption it is ever going to receive, by undermining the ability of distributors to even indicate what it is they are distributing.

Go to the OpenSolaris download page. There are distributions called BeleniX, Jaris, MartUX mBE, MilaX, NexentaOS and SchilliX. Who would ever guess that these are names for the same thing?

Each of those vendors would probably like to become the 10,000 pound gorilla which takes over the operating system world. But none of them are today. If these things could say, in their name, what they are, these distributions could synergize each others' popularity. They would still compete, and there would be winners and losers. But the common name creates the competitive playing field. It facilitates competition. Without it, all of the burden to connect the dots and figure out that all of these distributions are versions of the same thing is put on the potential customer. That's too much work to ask of people - the lack of a common vocabulary, a common noun, ends up being a massive barrier to adoption. The result is an order of magnitude fewer potential customers.

The Apache license's requirement that distributions of Apache software be named something different seems similarly wrongheaded and destructive. I can think of 6 or 7 Linux distributions, off the top of my head. I can think of 1 Apache web server distribution — WebSphere.

Demanding that users of software figure out on their own that five different things with five different names are actually the same thing is demanding that human nature be violated. If we want the open source software we create to compete viably with commercial software, this is like trying to run a marathon with untied shoes.

In other words, the way trademarks are currently handled in open source projects stifles competition and hurts smaller or less-known vendors. The name of the software is the way a vendor communicates what they are adding value to.

There is a fundamental tension between an open source project's name, and how it is subsequently branded. It is somewhat expressed by the fact that the person who posted the above comment used "Ubuntu" several times as a noun (which is actually verboten for the trademark holder if they want to protect their trademark). A small vendor creating a distribution benefits from name recognition of the underlying software - if I am familiar with Linux, I am much more likely to try something called Acme Linux, because my expectations are set by the use of the word Linux. If it were called Acme Super Operating System, I would be much less likely to ever hear of it, or find it in a search, much less consider it something I might want to use. Which is exactly the situation with OpenSolaris - how would I ever figure out that a distro called Nexenta is actually Solaris? I have to start by knowing about Nexenta, which is exactly where their potential customer does not start.

As a particular distribution increases in ubiquity, the vendor is less dependent on the name of the underlying software, because it has developed independent brand recognition. When a distribution reaches a level of popularity where many people will just use the name "Ubuntu", unqualified, in a forum post, and can have a reasonable expectation that others will know what they are talking about, the vendor has less interest in using the name of the underlying software, and more interest in protecting the brand belonging to their distribution.

The respective value of the vendor's brand and the name of the underlying software, to the vendor, changes over time. So does the value of the vendor's work to the underlying project. Yet trademark law assumes a fixed and permanent value for both — one which must be vigorously and labor-intensively defended from the start. In doing so, it pits two parties in a mutually beneficial relationship against each other — and in fact creates an advantage for closed-source vendors who suffer no such conflict. While this might make such vendors happy, reducing competition definitely does not benefit the consumer.

This is particularly a problem when smaller vendors are creating the software - they cannot afford a massive marketing campaign to build recognition of their "brand". For small vendors, brand growth has to happen virally. That fairly guarantees that the trademark must be violated, as a condition of success. Especially in the early stages of an open source project's lifespan, you have a no-win situation with the way trademarks are currently handled: You have a trademark which gains its value over time by being violated. And if it is not violated, it will most likely never develop any value at all. If people had not been allowed to use the word "linux", there would be no Linux today - it would have never become a competitive force.

In some ways this is analogous to how pirated copies of Microsoft Windows were the thing that made it ubiquitous — the success of the software actually depends on others violating the rights, as they are currently legally defined, of its creator. Revising the legal framework to take into account the actual behavior of the market seems to me to be a reasonable response.

Especially early in an open source project's life, other people using the name is a sign of success - in fact it is necessary for the project to succeed. Someone else calling their distribution "Ubuntu Linux" helps the "Linux" brand (and I think it would be safe to say that there would be no Linux as a force in the O/S marketplace if the name "Linux" had not been freely usable in the '90s).

I work on NetBeans. Now, if someone creates spam-mailing software and calls it NetBeans, trademark law is a way to stop that. But if someone is redistributing NetBeans, why on earth would I want to stop them from using the name? It can only enhance NetBeans brand equity to allow that — and a cease-and-desist letter from your lawyers is not a nice thing to do to people who are helping you. The best decision we ever made for NetBeans was to stop having Sun "branded distributions" of NetBeans — nobody could figure out that Forte for Java Internet Edition cum Sun Java Studio actually was NetBeans — it just fragmented the user base and guaranteed that no distribution was successful because NetBeans was competing with itself! Now, I still think creating rebranded versions of something you own the brand and the code to is mind-bogglingly stupid, but if these things had at least been called Something NetBeans, it wouldn't have been as disasterous as it was. From those times, I have first-hand experience of how much damage not having a common name can do — and we wouldn't even have been violating our own trademark to do it!

The problem is that the way the law handles trademarks is exactly backward for the needs of open source - the requirement is that the trademark holder treat all third-party uses of their trademark as violations and pursue them aggressively, even when the trademark holder benefits from the third party usage.

An open source project needs permissive trademark licensing - at worst, no more difficult than filling out a web form with contact information, a description and a URL - while still having recourse to pursue clear abuses of that trademark.

I wonder if something like that is possible, even within the framework of existing U.S. trademark law — I suspect some creative lawyering is possible. Given my experiences with regard to trademarks, at least with Sun's lawyers, I suspect nobody has tried — or stated succinctly what the problem is. It does look like LinuxMark.org is pretty close to what would be needed.

While not as broken as patent law is, with respect to software, long-term, trademarks do cause significant problems — problems that are a greater burden to open-source than closed-source projects, and which hurt new projects and small vendors disproportionately. What is really needed is trademark law that better fits how trademarks work in practice. In the meantime, it would be nice if our industry could develop some best practices for mitigating the harm.

Sneak Preview: Java Card tools for NetBeans 6.7

Java Card is an interesting platform to work with - a JVM that runs on smart cards and tiny devices that fit in the palm of your hand. As of Java Card 3.0, it comes in two flavors:

• Classic—this is the same as earlier versions of Java Card. The platform is extremely limited. For example, java.lang.String does not exist, there is no java.lang.Object.hashCode() method, no floating point numbers
• Extended—for newer, more powerful smart cards—this is new in Java Card 3.0. It supports a much more complete implementation of the Java Platform. Probably the coolest thing about it is native support for Servlets—you can actually write a web application using familiar APIs, which runs on a smart card!

The Java Card plugins will be available sometime after NetBeans 6.7 is released, on the update center, at or near the same time that the Java Card 3.0 Reference Implementation is released. We're finishing the legal process to move the source code for the plugins into NetBeans source repository, and that should happen soon.

Setting up a Java Card platform is done using Tools > Java Platforms, just like setting up another JDK.

Extended Applet and Library projects use the extended API in Java Card 3.0—so you can use java.lang.String and so forth. The boot classpath will be different for Classic and Extended projects, so, for example, code completion will not show java.lang.String in Classic projects, but will in Extended projects.

• Application Identifiers (AID)—these are unique identifiers that look like //aid//720A75E082/0058AEFC20. The first wad of hexadecimal is a vendor ID (you get one from the International Standards Organization (ISO)); the second part is a unique value you come up with. AIDs are used to identify applet classes, Java packages (classic applet & classic library projects only), and unique instances of applets (you can deploy the same applet multiple times on one device — the instance AID is used to select which applet to send information to).
• APDU scripts—these are scripts to send data to an applet. It involves a somewhat sadistic amount of hand-typed hexadecimal; the script needs to select a specific applet instance, and then send data to it.

• When you create a project, reasonable values for Applet AID, Classic Package AID, and one Instance AID are automatically generated.
• When you select the Applets tab in the Project Properties dialog, the project scans its classpath for all Java Card applet subclasses it can find:

  

• Once it has found them, the dialog allows you to select what applets are actually deployed, and customize the AID values used, deployment parameters and so forth. The IDE validates all of the data you entered, so that it is hard to enter invalid data:

  

• If you want to deploy two instances of the same applet, you can set that up as well; however, for simple cases where you just want to deploy one applet instance, you don't need to think about it:

  

• For testing running applets, you do not need to hand-write an entire APDU script—you can use the built-in Console to interact with deployed applets directly:

  

  

• The "package AID" for Classic projects (they are only allowed to contain one Java package) is also taken care of by the IDE, but is customizable.

  

• I mentioned that part of all AID values in your projects will be an ISO-assigned vendor ID (called the RID). For quickly getting started, the IDE will generate a random value for the RID, which is fine for development and testing. If you have an offical RID, you can set that up in Tools >Options; it will be used for all new projects, and clicking the Generate button in the project customizer can update the values in existing projects.

  

We're in the home-stretch of getting these plugins out the door and available to everyone using NetBeans—hopefully we'll also be able to bundle the Java Card runtime so that you can get everything you need to play with Java Card in one simple download. Look for more news soon!

A lot of the credit for these modules goes to Anki Nelaturu and the rest of the Java Card team, who created the first draft of these plugins, and who have been fantastic to collaborate with over the last few months.

Per-object workqueues - is this a thing anybody needs?

The fun part was really getting to dig into the java.util.concurrent classes, to do it such that enqueueing work is always non-blocking and transparently handles scheduling of work on a background thread and delivering the results.

The basic idea is simple:

• In an IDE, the user is editing a file. A lot of components may be interested in that file. The Navigator shows a structural outline of the file, and should re-parse the file. A task list may want to parse it and show TODO items and errors. Error markers and hints should be reprocessed.
• When the user saves, or stop making changes - on a triggering event - all of the things that are interested in the file's contents should have a chance to get updated. But, if, say, the file is an XML document, you don't want every interested party to do a separate SAX parse of the document, or create its own DOM tree - that's not good for performance.

The specific use of it in NetBeans is in the DocBook XML module, which we were using at the time to write Rich Client Programming. Basically, I wanted a way where all of the parts of the IDE that were interested in the file the user was editing could pass in a SAX ContentHandler; the library would then run one parse of the document, and all of the content handlers would be invoked in that one parse.

But it is usable for anything - any situation where you have one object, and multiple callers want to process it, and you want the whole thing to be thread-safe, and the callers to be invoked in a background thread. The whole thing is three classes. You implement one interface:

public interface QueueWorkProcessor  {
    public void process(Target key, Drainable  work) throws Exception;
    public boolean handleException(Exception e, Target key, 
            Drainable  work);
}

The question is, is this too esoteric and weird a thing to have its own project (you can already get it from NetBeans sources, after all), or is there someone out there who actually needs such a beast?

And as usual, there is the question what do you call a thing that does this? I've been calling it "workqueues" (you can find it in NetBeans sources in contrib/api.workqueues), but suggestions are welcome.

What do you call a...well, that's the problem

Names are important — they should either be communicative and say what a thing is/does — or they should be completely ad-hoc (think bird names and such).

What do you call a library/class where:

• You pass in a Map or map-like thing (Properties, Preferences, Wicket PageParameters...) and an interface type as a blueprint
• It gives you back an implementation of that interface/blueprint that lets you access the data in an intuitive, type-safe way

Lobby of the Blue Tree hotel in Brasilia, Brasil
It amazes me that they found real trees that look
like computer-generated fractal trees in an architect's 3D model

Any suggestions out there?

How evil would it be to enforce direct subclasses only?

Every now and then I get tempted to do this: public abstract class AbstractType { protected AbstractType() { if (getClass().getSuperclass() != AbstractType.class) { throw new AbuseOfInheritanceError(); } } } I've seen so much code that was made less readable and more complicated by overuse of inheritance; there are cases where it would be doing the world a favor. However, probably it would just make people want to shoot me.

Converting objects from A to B and back - there ought to be a library

I was just looking at Fabrizio Guiduci's Better Beans Binding project, which took me to the original beans binding project. Embedded in it is a mini-framework for converting objects back and forth between types - an application provides a List, a JList wants a ListModel.

Last week as part of my new Simple Validation project I wrote into it a mini framework for object conversion and a converter registry:

public abstract class Converter<From,To> {
    public abstract <To> convert (From from);
    public static <From,To> Converter<From,To> find (Class<From> from, Class<To> to);
}

And on it goes - I'm sure there are many, many more examples. All of the subclasses of java.text.Format in the JDK count. Pretty much anything that communicates via HTTP and uses an object-oriented language is one.

Perhaps something like this already exists and I don't know about it.

But what I would really like to see is a simple framework that solves the problem, that the rest of these projects could use - it's really an area where there is endless spinning of wheels. The characteristics something like that would be:

• Simple - if the framework exposes more API classes than you can count on your fingers, it's overcomplicated
• Converters are injected - i.e. you ask for a Converter for Date -> String -> Date; you do not ever refer to the actual implementation type of the converter unless you are writing it yourself. Getting a stable of converters for the preexisting types you need should be as simple as putting the right JAR on the classpath. Only if there are really multiple right ways to approach the problem should you need to instantiate a converter yourself.
• Does not assume bi-directionality (the Beans Binding version does this, but it needs that for some cases) - i.e. you have

  Converter<From,To> {
     To convert (From from);
  }
  

  and

  BidiConverter<From,To> extends Converter<From,To< {
     From reverseConvert (To to);
  }
  

  or maybe skip the bi-directionality assumption altogether.
• Comes with an optional set of useful converters for common things such as JDK classes
• Conversion errors are unchecked exceptions with meaningful error messages, and few but useful-if-present exception subtypes

I don't generally propose One Library To Rule Them All approaches - but in this case, the problem is general enough that the goal is to provide a library useful enough that people would use it and simple enough that people would contribute. And since the pattern is the same almost everywhere, all the mini-frameworks could easily wrap another framework's converters - in the current fragmented state, nobody really wants to do that because they'd have to drag in the rest of the library when it's not needed - for example, SimpleValidation could have probably used Wicket's validation - but I wouldn't force someone who just wants to validate a URL to drag around all the JARs needed to borrow that from Wicket - and everybody is in the same situation.

I mean, this seems like such a boring and simple thing that it should be a Solved Problem. So how much time do we all spend writing mindless code to marshal data between types?

Too bad about IBM and Sun...

:-)

"Fisheye View" plugin for NetBeans

And if an error marker shows up somewhere in your source file, but it's above or below what is visible, then in one mouse gesture you can both see the error message (which you could see by hovering the mouse on the error marker bar beside the editor, or in the task list if you have it open), and you can also see the code associated with the error without losing your place in the editor by scrolling or changing the caret position.

It shows any annotation (error markers, breakpoints, bookmarks, etc.) by highlighting it, and providing a description is one is available (same as the tooltip for the mark in the error bar). It also was a chance to have fun with some animated fade-ins for the component itself and the text-bubbles that show the annotation text.

The code for it is actually not NetBeans-specific. It is a general-purpose text fish-eye view for Swing text components which will work with any JTextComponent and another component to drag the mouse on, so this can be used in any Swing application (as long as you don't mind that it will screw around with the glass pane of whatever window it's in) - the sources are in contrib/fisheye - just one interface to implement to use it.

Alas, I'm doing a bit of a hack to hook into the error marker bar, so it is using an implementation dependency to get access to it. So publishing a binary would be somewhat useless, since it requires that it run against the exact version of the error marker bar that it was compiled against. But I can probably get it on the update center for development builds.

So ideally this would be tuned a little more and go into the actual NetBeans distro. If you think this would be a Good Thing, you can vote for enhancement request 163729.

And of course, if you think it's a horrible or insane idea, comment below :-)

A few new NetBeans modules - VNC, Breadcrumbs, License Header Changer, a better Java Navigator and more

Some of them are things I've had lying around for a while, some are new:

• VNC Client for NetBeans—This is a module that integrates the TightVNC Java VNC client (with much patching, which I have contributed back) into NetBeans, so that you can connect to a remote desktop inside NetBeans. Note you also need the TightVNC Library Module to install it.
• Breadcrumb—This was actually written in about 20 minutes at a trade show in Manila - a colleague said he wished we had a breadcrumb of recently visited files. So now we do. You can see it in the bottom right of the screen shot below.
• Color Chooser Component—This is a library that installs my single-mouse-gesture Color Chooser Java Bean into the component palette for use in Matisse. Jeremy Wood recently contributed a gorgeous color-wheel based component to the project which is also included. (web start demo here)
• Get A Tan—A module that turns the whole NetBeans UI sort of tan, and installs a similar editor theme. Probably a love it or hate it kind of thing, but if you don't like black-on-white UI's it might be for you.
• License Changer—This is a module which adds an action to any folder, Change License Headers. You supply a new header, and it will let you pick directories to exclude, give you a preview of what files it will change and let you exclude them, then it will mow through XML, Java and Properties files and replace or add license headers
• Annoyance Whacker—I'll probably catch some flack from colleagues for this one - it turns off all the popups (update checking, metrics submission, welcome screen, etc.) that show up when you start NetBeans, and on non-macintosh platforms, moves the status bar to the top of the window next to the menu to save screen real estate.
• Java List Navigator—This is a list (as opposed to Tree) Navigator view for Java files which features single click navigation, and lets you move methods and fields to different locations in your source file by dragging the method name, among other things. Note you also need the List Diffs library to use it.

For example, the TightVNC module exists because I'm a musician. A small problem with home digital recording is that if you spend a bunch of money on Neumann microphones and super-quiet sound cards, it doesn't do much good if you're recording in a room with a computer with fans whirring and buzzing. Solution: Get some long mic cables, and remotely control the recording software on your desktop machine from a nice, quiet laptop in another room. The only problem was I couldn't find a decent free VNC client for my MacBook, so I could start and stop recording remotely. So, I tried the TightVNC client, found the UI atrocious, set about detangling the protocol handling code from the UI code, and ended up with a NetBeans module. Scratch your itch, as they say...

The Get A Tan module was created to solve some pain: The backlighting finally went on my 7 year old desktop monitor that travelled with me from Prague to California to Massachusetts. So I went out and bought this lovely 23" Samsung monitor. Which is great, but if you calibrate it so that photos are accurate, it's like staring at a lightbulb all day. Solution: Tweak the look and feel to get rid of all of the white. My eyes feel better already! (Screen shot below)

The License Changer module came into being because I got handed a huge codebase to work on, Java Card support for NetBeans a few months back, to get it production-worthy. I needed to add license headers to hundreds of source files. I asked friends who had needed to do this sort of thing in the past, and everyone had some one-off script they wrote and couldn't find anymore. So I figured this was a problem that should be solved once and for all. It has an API for plugging in handlers for additional file types - currently it supports Java, XML and Properties files (with tons of unit tests for every pathological case I could imagine to make sure it wouldn't turn files into garbage). Contributions are most welcome.

The Java List Navigator module has been sitting in contrib/ for about a year. When I wrote the original Navigator component for NetBeans 4.1, it was intended as a fast way of navigating through source files - single click navigation, use a list rather than a tree to avoid horizontal scrolling, and it could abbreviate class member names to keep them visible (even doing weird tricks with removing vowels). The Navigator actually started as an example for NetBeans: The Definitive Guide, and I found I couldn't live without it.

Alas, in 6.0 it fell victim to the Every other IDE uses a tree for this, therefore we have to use a tree too mentality (on my list with But that's the way we've always done it! of thought patterns that ought to be firing offenses...). So this is a Navigator that works the way it was intended to work - as a tool for quickly navigating a source file with a single click or a few keystrokes (it's on the right in the screen shot below).

The Annoyance Whacker module is something I'd encourage regular users of NetBeans not to use - it turns off features that help us know how many people are using NetBeans and what features we should concentrate on (if you choose to tell us - no personal data, just statistics). But if you develop NetBeans modules for a living, A. you're probably not a typical user - my usage patterns would only skew the metrics, and B., you probably start NetBeans 50-100 times a day, and popups on every startup get really annoying. So this module gets rid of a few mouse or keyboard gestures every time I start NetBeans.

A lovely (to me anyway) tan theme
(click the image for the full size version)

A simple library for Swing UI validation

The project can be found here, and there are JAR, source, javadoc and NetBeans library module downloads available. An overview of the project can be found in the project wiki.

I'm currently working on mobile and embedded tools for NetBeans - in particular a marathon race to get the new Java Card development tools ready for release (there's nothing in NetBeans source repository yet - we're waiting for the lawyers to give their okay to move it there).

In both the Java ME modules, and the Java Card modules, there are a lot of pieces of user interface where you want to show the user a “problem” if their input is not valid. In the case of the mobility modules, for a lot of the code, there is no validation implemented at all; for the Java Card modules, I wanted to replace many lines of code that look like

String text = fooTextField.getText();
if (text.trim().length() == 0) {
   setProblem ("Enter foo");
   return false;
}
text = barTextField.getText();
if (text.trim().length() == 0) { ...

Then there is the issue that some UIs live inside a wizard, and there is one API for showing problems in wizards in NetBeans; there is another API for disabling the OK buttons in dialogs, but there there is no API for showing the user problems; there is another API for showing problems in project customizers, and yet another for option panels. And some of these UIs are used more than one such place.

So I wanted a way to encapsulate and reuse that sort of validation logic, and make it simple to attach it to any UI. The result was the Simple Validation project.

I looked at some of the existing libraries for doing validation - particularly JGoodies Validation. The existing solutions are nice - and if I were probably writing a UI from nothing, I would use one of them.

The two main problems I had with the existing solutions are

• They tend to want you to rewrite your UI from scratch - for example, to create a model for the data content of the entire UI - which would be nice to have, but is not cost-effective on existing code
• They tend to be very concept-heavy - A theoretically complete description of UI validation might include problem severities from 0.0F to 1.0F and ProblemSources that extend MessageSources and reflection-based validation of ad-hoc Java Beans. However all of these concepts are just noise from the perspective of writing a simple, narrowly scoped library for validating user input and transparently handling conversion between Document, et. al., and String. The result is extensible, and should be widely useful, but it does not try to “save the world.”

• Problem messages can be influenced by the component name and the input value; currently they are not customizable, but if you set a component name, you get a reasonable result (i.e. set the component name to "URL" and if the field is empty, the empty field validator will show a problem URL may not be empty). Messages are localized; do they really need to be customizable?
• Is the psychadelic duck logo too weird? :-)
• Are there other UI patterns for displaying problems to users that aren't covered here?
• Are there concrete, non-estoteric use-cases for more than three levels of problem severity?

With this project, I also got to try out Kenai for the first time. It is quite slick and speedy - much nicer to work with than java.net or netbeans.org - I'm pretty impressed. The only annoyance or bug that I noticed was that there seems to be no way to modify the content of the home page except for the 500 char project description and a logo image.

Are constructors the enemy?

The major problems with constructors as I see it are

• Especially in deep inheritance hierarchies, or when you inherit from a class in a library which could involve incompatibly, it is easy for your object to be called when it is in a not-fully-initialized state. We just had to do an update release, NetBeans 6.5 to deal with such a change in JDK 1.6_12 - this conversation shows the tip of the iceberg that crashed into NetBeans when changes from JDK 7 were backported - because of such a problem
• A constructor ties you to the precise type of the object being constructed. As a library author, you get much more flexibility with a factory method, where you can return a subclass, possibly choosing which one based on an argument to the factory method. This makes it much easier to keep backward compatibility and guarantees your object is never exposed in a semi-initialized state (unless you're inheriting from something you don't control, which should be avoided when possible

I don't know how realistic that would be for a language, but it is some interesting food for thought!

June 2009

Search this blog:

Categories

Archives

June 2009
May 2009
April 2009
March 2009
February 2009
October 2008
August 2008
June 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
February 2007
January 2007
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
September 2004

Recent Entries

In my other life I'm a musician

Juggy gives Duke a workout

Photos from JavaOne

This work is licensed under a Creative Commons License.