Evan Summers's Blog

Mayhem roundup

I've been meaning to start blogging on java.net 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.

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

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 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!

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 nbextras.org.

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 javapassion.com :)

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 bloged.dev.java.net

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!

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...

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.

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.

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.

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.

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!

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.

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

In 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.

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.

Comments

• Just like with your last post, this one is repeating over and over in the rss feed. You sure everything works OK?

  Posted by: jordihs on June 08, 2006 at 07:49 AM

• Probably cos i making amendments. Probably I shouldn't do that!? I mean once it's published?

  Posted by: evanx on June 08, 2006 at 08:08 AM

• I guess you shouldn't if it necessarily means a new posting for feed readers. I've never published to an RSS feed so I don't know if you can edit somehow without republishing but I guess you should be able to.

  Posted by: jordihs on June 09, 2006 at 12:25 AM

• Dude, where's the executive summary?

  I also gave up on Linux for the desktop; far too much fiddling with drivers for my sanity. Moved to Mac OS X and I love it. Easier than windows and as powerful as Linux.

  Do you prefer Netbeans over Eclipse? I'm an Eclipse monkey personally, but I was impressed with the JSF support in Netbeans, although it was so damn slow I could barely use it.

  Oh, and check out http://nextapp.com for the Echo2 framework: swing for the web. Used it a few times and it's great.

  Posted by: vaughnd on June 09, 2006 at 01:17 AM

• 
  hey Jordi! I'll be gutted if i shouldn't be editing a blog after it's published. Because when i publish it, i give it a final read over, and always find things to amend, and can carry on like this. I've always been that way, eg. with publishing on websites. I confess I don't use the RSS and dunno how it works. But i think it should only announce the article when you first save it as "publish"
  and not every time you might amend and resave it, after it has been published already? I haven't seen anything or any where to configure this?

  hey, Vaughn! To answer your question, my first love was IntelliJ. I worked on a contract which had IntelliJ licenses, and they lent me one for duration of the contract. My next contract, everyone was using Eclipse. Although I missed the look and feel of IntelliJ, Eclipse rocks. It is a fantastic tool, doing a fantastic job.

  At the time, IntelliJ were offering free licenses for opensource developers, and i was hoping to scoop one, but i didn't have any luck when i asked for one. First because my project (aptframework) was vapourware, just a twinkle in my eye, and then a few months later when it had some code, it didn't have any members or activity on the forums, or something, i can't remember. So i gave up asking for that free license, even tho they said i should ask again in a few months time. It was a shoulder drop at the time, because I was really hoping to hook one of those free licenses, man!

  But in hindsight it was for the best. Because i tried Netbeans 4.1 and i loved the look and feel. It had the native Windows XP look and feel, just like IntelliJ. It gave me warm fuzzy memories of IntelliJ.
  
  One day it occurred to me that Netbeans was built on Swing. And I was a Swing developer. And so i should be in the Swing corner, rooting for Netbeans.

  But i couldn't use Netbeans yet, because I needed "Suggestion" and that was due in 4.2. So when i finished my Eclipse contract, I switched to 4.2dev. I started aptframework (using Netbeans), and the next two commercial projects i did (in the last year) were both using Netbeans, coincidently. One was JBoss project were all the developers used Netbeans, and the other was a Swing project where the previous developer had used Netbeans GUI designer.

  So i love Netbeans. And with Java 5 and Netbeans 5, for the first time, I preferred the Swing Metal look and feel on XP, and switched to that! Actually i think this is a quite a big thing, altho it sounds like a small thing. I was using Linux at work (with Metal), and XP at home, and switched my home XP Netbeans to Metal too!

  Personally i don't like the look of the Eclipse widgets, in the particular, the tabs. Which would be a silly reason not to use Eclipse, i admit. For me, Metal looks best, then XP look, then Eclipse.

  In terms of the core IDE functions, Eclipse is definitely better in some areas, eg. error detection is faster - i guess their internal compiler engine is faster. And better, in that it underlines where the error is in the line, not the whole line. Also I miss Eclipse's quick fix on "addActionListener(this)" that suggests making this implement ActionListener interface, ie. it adds "implements ActionListener" on the target class. Hopefully Netbeans will add this in a future version.

  I run on a Celeron machine with 512Mb and don't have Swing performance complaints with Netbeans. The above performance issue is compiler-related and not GUI related. (Hey maybe it's just my machine in that case!? I should compare with Eclipse on the same machine.) Swing is not slow, and anyone who says it is, is a bit slow themselves, in keeping up with current events ;)

  By the way, I hear that Mustang is very very fast, and its Swing looks better than ever on Linux (eg. fonts), and that Vista look and feel is gonna be ready for Vista. So I reckon Swing deserves to be where it is, ie. the most widely used GUI platform in the world :)

  What's great is for us developers is that Eclipse and Netbeans are in healthy competition, and both will continually improve in leaps and bounds, and egg each other on, woohoo.

  Actually my debate is not about which IDE anyone should be using. It's that if you aren't using an IDE, then maybe you should be!

  I used text editor for 20 years, so i understand that approach as well. But i really, really believe that people are missing out, if they are not using one of these great IDEs, like Netbeans, Eclipse and IntelliJ.

  When choosing a language/technology to develop a project in, I think you gotta consider all the angles, including, are there great developer tools to help us, at what cost, and for what development and deployment platforms. If you want something free and cross-platform (for development and deployment), then Java is a really great choice, isn't it?

  My crystal ball (which has been dropped a few times, so...) suggests a high adoption rate for Netbeans in coming years because of it's out-of-box goodness, Matisse GUI designer, profiler, and jackpot.

  
  

  Posted by: evanx on June 09, 2006 at 03:17 AM

This work is licensed under a Creative Commons License.