Skip to main content

Mayhem roundup

Posted by evanx on June 8, 2006 at 6:13 AM PDT


"All my life I've had one dream: to achieve my many goals" Homer Simpson

I've been meaning to start blogging on for a while. To promote myself and my project, and because i really love writing. I go into a whole new world, into a trance with a silly grin on my face. Same as coding.

empty_audience_200.jpg align=left hspace=16 />
This new era of an interactive web, this so-called Web 2.0 thing, is something special. In the past, you read an article, and then moved on. Now you can post a comment, and engage other readers, and the author. And blog yourself. This is something special. We can participate, and interact.
We can do what human beings were made to do!

Typically i mostly listen. This comes from when i was a stutterer at school. You were not gonna catch me opening my mouth if i could possibly help it! One day that all changed, and i starting giving big public talks at every opportunity. Anyway, that's probably why i like writing so much, because it's always been a safe, comfortable environment to express oneself without any risk of stuttering and stammering!

So i'm between contracts. Supposedly working on my project fulltime.
But then The Java Posse rode into my iTunes...

Explicit Reflection

"Internet! Is that thing still around? Oh, so they have internet on computers now!" Homer Simpson

posse3.jpg align=right vspace=16 hspace=16 />
When listening to Java Posse in March one morning, working on my project, I emailed in to "If I was the king of Java..." about "explicit reflection." It was something i had wished there was in the language, because it would have helped me.

I was so excited about my email being lasso'ed by The Posse, that i decided to write my first blog to expand upon the issue.

This started a theme pursued in subsequent articles, like Refactoring Translations and Bean Curds 1 and 2, that string literal references are unwelcome.

Netbeans_125.png align=left vspace=16 hspace=16 />

Netbeans Day (South Africa) Trilogy

"Remember as far as anyone knows, we're a nice normal family." Marge Simpson

As it happened, Netbeans Day was taking place that week in South Africa, with James Gosling in attendance.

During the presentation, I decided to take notes of the interesting points. Out of habit. Not because I ever go back and read my notes, but it just feels good to "Save As."

When i got home, I found myself writing a summary of the talks, and those notes came in handy!

href="">Part 1 summarised Geertjan Wielenga intro on Netbeans 5. Preaching to the converted in my case! But there were some very handy tips for me, eg. F2 for bookmarks, "Camel Case Completion" eg. WL for WindowListener, Alt Shift W to enclose with try/catch, and

Geertjan left a nice comment, and also Chuk Munn Lee (who also presented on the day). I was chuffed!

To quote myself from Part 2

Personally i love the idea of wizards, and sample projects, with integrated documentation, rather than traditional static documentation, like a PDF. I call this "active documentation." Netbeans 5.0 JEE Blueprints are a great example.

and regarding the RCP

I have a happy suspicion that we'll see some great Netbeans RCP apps (and IDE extensions) popping up in future. Personally I'd love to see a whole desktop suite built on RCP - mail client, tabbed browser, and file browser. Then we'll really have a consistent, integrated, and extensible Java desktop!

Part 3 summarises Sang Shin's talk on Netbeans for JEE. I dig his master tutorial index on :)

In part 3, I got gushy...

The golden age is dawning, with fantastic languages, libraries, tools, databases, servers, frameworks, components - all freely available, and cross-platform - with tutorials to rule them all - and with Netbeans, it's all in one little download.

Roman Strobl commented on Derby integration.
I was chuffed to find that anyone was reading my blog entry, but Roman Strobl! I have really appreciated his video tutorials, and blogs and podcasts, in the past, so that was great.

I ended the article wishing for a Netbeans weblogger plugin, and
Gregg Sporar
pointed me to

Geertjan left a comment that he was gonna link to my summaries of Netbeans Day (South Africa) from his blog. Wow, this blogging thing was really working for me! You start to feel like you are inside this whole community, and not outside looking in, and it feels great!

thinkfreeCalc175.png align=left vspace=16 hspace=16 />

Swing trumps... everything!

"Burns releases the hounds on every charity that comes to his door - Feed the Children, Save the Whales, even Release the Hounds."

I was writing a comment to Swing trumps Ajax.

I suggested that Sun will opensource Java because...

"Sun wants developers to be a field of Sunflowers, following the Sun."

Everyone has their favourite things, that they feel passionately about, and other people feel passionately about different things. I wanted to write passionately about my favourite things. At the same time, one doesn't want to offend and upset people. So it's a tight rope. I gotta respect other views that I might disagree strongly with. Not least because they might be right. Certainly they are right, in a situation and perspective other than my own.

I learnt a few tricks at navigating the tight rope. For example, I said, "I think that GNOME is gonna overtake KDE." GNOME people are happy because I'm saying GNOME is best, and KDE people are happy because I'm saying KDE is best. Whereas if i had said, "GNOME is better than KDE" or visa versa, well, the "comments" section would have got messy. Which fortunately it didn't! :)

Lemme paraphrase some thoughts presented there.

My dream for the future of computing, is stateless rich client applications using web data services, where we cache in on rich applications via the web, like Thunderbird, OpenOffice, and of course new Swing and .Net ones too, via WebStart, Google Pack, or whatever, and where your documents and settings follow you around on your GDrive, LiveDrive, Amazon S3, YahooDrive, SunGrid, or whatever.

Personally I think that Sun should reinvent itself as a Web 3.0 software service company in this way, and become the biggest
consumer of their own hardware.

Step one is to build SunGrid storage support into OpenOffice (and Firefox and Thunderbird). Why sell CPU time to a few organisations, when you can sell computing to the whole world?

The issue of Java/Swing performance came up in the comments, and i weighed in...

Swing_s.png align=right vspace=16 hspace=16 />

If i'm given the choice (and clients too) of delivering something in three months that's gonna need 1Gb of RAM to run, or the same thing in six months, at twice the cost, but that'll only need 512Mb to run, i think you can guess everyone's answer ;)

Considering that Java and C# are languages much like C/C++, any implementation performance issues are solvable engineering problems. This is evident in Hotspot and Mustang. Memory use will be higher (for garbage collection), but apps will be much easier to write and debug. Performance will be comparable, sometimes slightly better (eg. Glassfish's Grizzy using NIO), sometimes worse, than native C/C++ (or Python, or C#) implementations. When it's a lot worse, and that's a big problem, it becomes a priority to fix it, and it gets fixed. It just takes resources allocated - excuse the pun.

You point out that C# is newer and learnt from Java's mistakes - which ones bother you the most, and can't the community do something about them? An (dis)advantage of Java over C# is that there is a community and the JCP (of which Apache, IBM, Google, Oracle, et al, are no small part of) to evolve the language (and standards and libraries), rather than one company. Java 5 has evolved, in response to C# and thanks to the Java community - introducing enums, generics, varargs. Java 5 took away all my big itches.

The point is that every language (and tool and library) needs to evolve in response to new developments, and Java is doing that, and C# is doing that, and they are in healthy competition. In hindsight "mistakes" are made of course (even tho at the time there were the right decisions). When they are identified they should be fixed as soon as possible (eg. aggressive refactoring). Sometimes they can't be fixed right away because that will break backwards compatibility. So lets deprecate them and fix them in five years time. Yes, there are cases where in hindsight, we wish we had done things differently from word go, and would be better off if we had (eg. generics, altho at the time, that was too much effort, and other priorities were more important, probably). Which is why designs and APIs should be, first and foremost, blindingly simple and minimal. Then there's less opportunity to do wrong. And Java got that pretty much right.

Let's make Java (through the JCP), stand the test of time, and get better with age, so we don't have to throw everything out and start again with C#, or the next "best language." Lets make Dolphin etcetera, be the next "best languages."

But enough about you, let's talk about me!

"You couldn’t fool your mother on the foolingest day of your life if you had an electrified fooling machine." Homer Simpson

I had a huge amount of fun and catharsis writing My Desktop OS: Windows XP. I could not wait for my brother to get home from work so that we could giggle hysterically over it.

linux-av.png align=left hspace=4 vspace=0 border=0 />

In case you were wondering, this blog is being written on my new "Windows XP" notebook. I downgraded my cell phone and got a notebook thrown in. Well, a 50% rebate. Notebooks have power saving modes and all types of fancy things, and there is no ways i'm gonna reinstall the thing with Dapper!

I'm embarrassed to say, I do prefer Windows these days. I cannot be arsed to fiddle around with video drivers, and editing repositories,
I'd rather be blogging! :) I know Dapper and Easy Ubuntu rocks. So I've made a note to try the Ubuntu after Edgy, ie. April 2007. Until then, my Windows XP notebook, and Mac Mini media center, are gonna keep me very happy.

Bin Bash Java

"I’ve figured out an alternative to giving up my beer. Basically, we become a family of traveling acrobats." Homer Simpson

In his blog, Damien Katz wrote on "Signs you are a crappy programmer, and don't know it." At the top of the list is "Java is all you'll ever need." Since i'm guilty of that, I explained
why i choose not to add other languages to my toolbox in Java is all you'll ever need.

Java developers should be programming/scripting in Java (or Groovy), for the same reason that we program in Java and not C... "Give me more scripting power, Scotty McNeally!"

C# programmers are gonna be using that fabulous C# .Net command-line, and make our bash scripts look silly. And make us look silly using Python because Java can't cut it. Lets make Java sharper, not just for big applications, but also for small tasks too.

A reader commented that "anyone thinking he needs only a single tool to do any job is a fool." Since that would be me, I wrote A Fool's Errand to introduce Bin Bash Java 1.

penknife3.jpg align=right hspace=16 vspace=4 />

I try to make the point that rather than invent/implement a scripting language, another approach is to implement a support library that achieves similar convenience and functionality, with other advantages, eg. readily toolable using Netbeans and Eclipse, today.

Bash and shell scripting is great if you know it, but not so great for a student who only knows Java. It's also not so great for CIO's when ex-employees leave scripts behind that have grown into unreadable, unmaintainable and unmanageable monsters, on which your organisation's infrastructure now depends, and which keep jumping out of wardrobes to give young programmers nightmares.

I argue that these are legacy solutions, and there is space for a modern Java solution, for the convenience of Java programmers. At this stage it's an academic exercise. A fools errand, as i said ;)

GNU/unixversal utilities like tar et al, are great, but you usually you gotta program them in an extremely limited and highly fragile scripting language (bash).

In general I think that Java/Netbeans/Mattise is a great tool for building front-ends to such utilities, and also wrapping these utilities into a library that is highly programmable, using Java.

AHalsey's comment below resonated with me.

I am tired of the needless language proliferation I see happening today. It fragments our work - partitioning it into incompatible islands. I am a Java programmer. I've spent years mastering the ever growing mountain of Java APIs and have created some myself. Why on earth should I have to learn a new languages' APIs when writing small scripts - it's crazy! It dilutes our effectiveness. Microsoft knows this and will allow programmers to leverage their API knolwedge investment when scripting. I hope Java community has an answer to this - inititives such as Groovy, BeanShell gives me hope.

He pointed me at NailGun which aims to obviate the start time of the JVM, eg. for Java command-line tasks. They say,

Java has an extensive and robust core API and huge number of available open source libraries. It's a great big hammer, making almost any programming project look like a nail.

GlassFishBowl.jpg align=left vspace=16 hspace=16 />

CDDL'ing the Duke

"Oh no! What have I done? I smashed open my little boy's piggy bank, and for what? A few measly cents, not even enough to buy one beer. Wait a minute, lemme count and make sure... not even close." Homer Simpson

When the JavaOne DLJ and "opensource Java" news hit the headlines, I wrote Dux in a Tux where I mused about GPL'ing Java as "GlassFishBowl" and rigorously protect the Java trademark, so that Java still means "Java" as in the JCP, TCK, JEE, et cetera.

There were lots of comments. Including one from myself as follows.

My understanding of the GPL and the LGPL is that libraries (eg. GNU libc used in Linux et al) have to be LGPL in order to allow non-GPL'ed programs to link to them. That is that non-GPL'ed programs and GPL'ed cannot be statically or dynamically linked together.

The preamble of the LGPL says

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library.

Therefore i would assume that the class libraries (to which non-GPLed java programs link as a "shared library" albeit via the JVM) would have to be LGPL'ed.

GNU Classpath for instance is "licensed under the GPL plus a special exception" as follows

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules...

Since I didn't know much about the CDDL, I explored it in CDDL'ing up to Sun, and summarised the differences between GPL, MPL (of which the CDDL is the state of the art), and BSD (of which the ASL is the state of the art), as follows.

In the BSD/ASL commons, you don't have to contribute your modifications or your derived works back into the commons.

In the MPL/CDDL commons, you have to contribute only your modifications back into the commons.

In the GPL commons, you have to contribute both your modifications and your derived works back into the commons.

My final words were

Opensource promotes common development, where the idea is to engender a community of contributors. But maybe in some cases it's more about distribution. And in others, it's a marketing gimmick. And in most cases, it's some combination of all of the above!

Justice3.jpg align=right hspace=16 vspace=4 />
On the issue of joint-copyright as required by the "Java Contributors Agreement" (and similarly by FSF and Apache), I commented

I don't see how Contributor Agreements and joint-copyright can be avoided in today's landscape. You wanna have at least one entity that is copyright holder of the entire project to defend the project in court, for one thing. If you don't want to contribute code under a Contributor Agreement, then don't - no one is holding a gun to your head - fork it and fork off.

The way I see it, assigning joint-copyright is pretty much like contributing under a Apache license in addition to the CDDL. This doesn't detract from the contributors rights - it just gives the project group "free use" rights. Which I think they deserve since they donated all their work into the commons to start with, to be benefit of those contributors, and everyone else.

Otherwise the project group lose "free use" of their whole project, as soon as they accept one little patch. That being the case, they could not accept any patches to start with.

I really respect the (Free)BSD attitude, which is, "Here, take this software I wrote - please use it as you wish - make me proud."

Jim Driscoll made the following enlightening comment.

Copyright is not land. If two people own land, they both separately don't have the same rights as if one of them owned it. When two people own copyright, they both have the same rights as if they were a single owner. This is why piracy is not equal to theft.

beans_125.jpg align=right hspace=16 vspace=16 />

Bean Curd

"Every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home winemaking course and forgot how to drive?" Homer Simpson

Bean Curd 1, I introduced
an "explicit properties" approach, where bean properties are declared
in an "explicit bean info" class. Actually the bean info class and property descriptors
are absorbed into the components bound to the bean, for convenience.

There are a couple of problems with using string literals as references to properties (and fields and methods).

The most serious problem is that they make refactoring fragile. For example, consider that we wish to rename the realName property to just name. The problem is that our IDE doesn't know to change the string reference "realName" as well.

So we can, and probably will, overlook renaming the string reference, since there is no prompting by the IDE or compiler to tell us to do so. This will definitely result in a runtime error. "That's gonna hurt in the morning!" Ok, this problem should be solved using unit tests to make sure that fragile string references are valid.

Hey, I'm lazy. So i don't like string references, because they do not take advantage of the IDE's prompting, auto-completion, and error highlighting. In this sense, they are not readily "toolable."

In Bean Curd 2: The SQL, we apply the "explicit properties" approach to
object-relational mapping, and the DAO pattern. This enables us to support
"native queries" ie. stringless queries which are toolable,
and promote ORM refactoring.

The problem with string queries is highlighted as follows.

So we map our database to nice Java names (in our entity beans).
The problem is that as soon as we use the mapped names in string queries (eg. OQL,
EJBQL, HQL), then we immediately lose refactorability. It becomes
impossible to fix up spelling errors and naming inconsistencies, without
breaking our queries. "Thaaat's mentil!"
And if you ignore a few broken windows, the next thing the whole building is run down, innit.


Refactoring Translations

"Bart, always remember that you’re representing your country. I guess what I’m saying is, don’t mess up France the way you messed up your room."

In Refactoring Translations, I presented an approach I used for "refactoring" strings out of an application, as a first phase in preparing a resource bundle for translation.

In general, I argue that source code should contain no string literals whatsoever! The reason for this is that string literals are typically fragile references, which are not refactorable. This applies to strings that refer to field or method names, as discussed in Explicit Reflection, string references to properties, as discussed in Bean Curd 1, and strings used in OR queries, as discussed in Bean Curd 2.

Clearly strings that are text messages are also undesirable, because they should be externalised for translation (in resource bundles).

And finally string references to externalised messages in resource bundles, are fragile and unable to be unit tested, and consequently dangerous, eg. getString("loginError").

Swing and roundabouts

"Don't eat me! I have a wife and kids! Eat them!" Homer Simpson to the Alien

In my last project, most Swing event handlers kicked off a string of "long tasks" (namely, communicating to a server over a GSM network), and I got into such a tangle with SwingWorkers upon SwingWorkers (so as not to block the EDT), that the code became increasingly difficult to follow.

swings4.jpg align=right vspace=8 hspace=16 border=0 />
In Swing and Roundabouts 1: Event DTs, I presented how I left the event
handlers pretty much as is, run them using a SwingWorker,
but where they use an "EDT-hardened" GUI helper class, to manipulate the GUI, eg. popup a dialog, request focus for components, and enable/disable components.

I used an event/listener type solution for my nested SwingWorkers at first, but what i didn't like about it, was that i could not easily follow the sequence in the code using Alt-G. So i was losing track and found development and debugging very difficult. So i gave up on that.

Ideally the developer should be able to code naturally, without concern for the EDT, threads, and such plumbing. The developer has a hard enough job as it is implementing the required functionality, without the added strain of worrying about technical plumbing issues.

So the framework (eg. the future JSR 296 one), should, i believe, enable the developer to code relatively naturally, ie. without concern for EDT issues.

An elegant solution that someone proposed (that i came across somewhere in my reading), is to use annotations, eg. @InEdt for methods, that might cause them to be compiled to run within the EDT, eg. taking care of the boiler-plate code like "if not isEventDispatchThread(), then invokeAndWait(new Runnable() {})."

Coming soon

"When will I learn, the answer to life's problems aren't at the bottom of a bottle, they're on TV!" Homer Simpson

Future articles in the "Bean Curd" series might be "Bean Curd 4: On Form", looking
at using our "annotated integrated explicit property" approach for HTML forms,
for the purpose of capturing parameters for native query servlets,
and Bean Curd 5: PH&P - Pdf, Html and Poi for producing
reports in PDF, HTML and/or Excel, using annotated property descriptors, native queries
and servlets. But first I might do, Bean Curd 3: Swing Form Binder just to mix it up.

Finally, Swing and Roundabouts will delve into the all important Action's, look at automatic registration of event handlers,
and also an application shell with a menu and tool bar, to support tabbed application panels.