... And They Shall Know Me By My Speling Errors

These code quality metrics proviced by PMD and Eclipse are quite nice, it points out all sort of strange things. But there are some thing it doesn't get...

For example I came across a class written by another developer (not sure who at this point). The first thing that caught my attention about that class is the incessent use of this. to refer to local fields. And he would never use a class name to refer to another static field, which is what tripped eclipse to check. After reviewing the class and parent class in question I came across a doozie... all of the methonds and fields were static, except that the fields were initilized by a non-static constructor! It's not like it's a forced option, since you can use static { ... } to initilize static fields. There are just some stupid patterns that you can never imagine until you see them.

PMD definatly needs a "StaticFieldReference" rule, perhaps they also need a "StaticInitInConstructor" rule, where it barks if you set the value of a static field in the same class inside the constructor of a class. Manipulation is ok.

Yesterday Jon Lipsky posted a nice real world comparison of Swing v.s. SWT. A Sun emplyee also had a rather lenghty comparison It looks like people are starting to verify some of SWTs high claims.

One of the biggest problems I have with SWT is that the implementation is not cross platform, but is a sperate undertaking for each platform. This leads to wildly differnt user experiences! The applicaiton I am baseing this statement is Eclipse 2.1 M4 build, under both Windows 2000 and Redhat 8 with the GTK build. The first thing I have to say is that the performance and user responsiveness is so different it's like I am using two differnt applicaitons. On Linux doing multiple ctl+clicks on the source tree takes about 2 second per click for eclipse to repsond to. I can get way ahead of the appplcation, and this leads to ghost un-selections because SWT gets confused. And then a tree update from a mass "organize imports" has massive flashing on the tree. Blech! But on windows it responds just fine. But both platforms still freeze updates to the GUI when doing large operaitons, like compiling the 1023 in my current project when I change one seemingly innocent preference about code quality checks. (As an aside, responsiveness is so importaint that Sun dedicated a entire chapter to it in their Java Look and Feel: Advanced Topics book.)

Another area is that by using the native widgets you immediately upen yourself up to inherent differences of user experience. Like adding jar files to the extrnal library list: on Linux you get a tree control where you can do multiple selections across directories. Windows gives you the standard one directory look. And on windows I can click a column top to get that column to re-sort automatically. Not so on linux, you got to use some wierd triangle menu to change the sort. Stuff like this is why a look and feel that is consistant across platforms is so good. If you don't need to behave the same across platforms then why aren't you writing it with kylix or C#? You get all the native widget goodness you need out of that. If you're going to whine about native performance use native coode then!

And then there is the unproven marketing hype, such as this gem:

The real question isn't about what results expert programmers can get using Swing vs. SWT, but rather what results *average* programmers will get using Swing vs. SWT. In this light, Swing doesn't compare to SWT. [ a comment on jason]

The though of threading your own event queue and disposing of your own object is going to make the *average* java programmer run away in fear. And then manageing all of the paltform specific GUI nuances is going to eat up whatever time they may have saveed assuming they have saved any. Since the person who wrote this is a vendor for an unreleased SWT GUI Builder the perhaps he will be able to show me the money. Then we can judge for ourselves when the product is released. It's got some stiff competition with existing mature tools such as the GUI builder in NetBeans, it'a like codeing a GUI in visual basic, except for the part where you write the visual basic, which is to say it's nothing like visual basic, but I digress.

Ok, I ttried to look up a referencde to ESR's "The Cathedral and the Bazar" for an post I'm writing and the cannonical entry is stored at tuxedo.org, but when you try to get any entry you get thrown to seemingly random sites! All the sites seem to have a decidedly Open Soruce spin though: ethics.org, publicknowledge.org, fsf.org, linux.org, techp.org. Did I miss the posting on slashdot or something?

One of the wonderful things about open source software is that you can scratch an itch. Is Something broke or do you wish it did more? You can fix it! But with the latest adoption of several Extreme Progaming techniques in open source projects it occured to me that XP, and in particular Test Driven Development (TDD), as cannocally formed does not work well for external contributions.

Take my two latest patches, one to Marathon and another for the Parallel task on Ant (apparently I am sill a committer, [note to self get login accout pasword...]). Marathon is hardcore on TDD and at Ant it is a Very Good Thing (but not always a deal breaker). With both of these patches I updated the tests, but should the committers take my word for it that they are valid tests?

One of the basic principals of TDD is you write the test first, then run it, and watch it fail. This is before you add the new functionality. It seems like a sublte point but it is a very essential step: it validates the test can fail. It may seem unnesscicary, but it can be critical. All of the other constraints in the system can conspire to make a test uesless. Without validating a failire it is quite possible that you can accidentally code the equivilent of if (false) { fail("I'm broke"; }. Is that a valid test case? Maybe if you are testing the compiler and it is supposed to choke when it encounters dead code, but cases like that are never that clear to read.

So how does a project handle the case of patches for TDD? In the case I sent to Marathon it was simple, it was broken functionality and it added no new APIs. In this case you apply the patch that has the test first, assert the test fails, and then you apply the rest. But what about more complex cases? Like when the patch is adding new functionality? My proposed solution is submit two patch files, the first one adds the tests and needed API changes needed to compile, and none of the new code for those APIs. The second patch actually contains the code that makes the APIs work. With this the core commiter can take the two patches, apply the first, clean, compile, test, and look at the new failure and say "this is good." Then (and only then) does the committer apply the second patch, clean, compile, test, and see no test failures (or only failires that were there before the patches were applied).

Generating two diffs from the CVS is a pain, but if you are practicing TDD anyway then you could grab your first patch after the test starts failing. This makes developing a two step process, but TDD is already a two step process: (1) create failing test (2) make test pass. Test Driven Patching reflects that as well.

Yesterday while browsing around a new weblog I found I came across this statement/question. I must admit I have a similar question. What areas of java pay more or are in more demand? And I wonder that not in the traditional role (architect/VP/Sr Developer/Jr Developer) type thing, but in a specialized knowledge type thing. Crowbar seems to indicate that developers who develop Swing apps are paid less just because of that skill. I certianly hope not since I've been kind of backed into that role through chance, but fortunately the stuff I did is provable magic and not simple VB form builder stuff. Another local guy got loads of contract work just because he let his contract handler know he was playing around with web services. It's not like he only knew how to spell "Whisdel," he actullay had some good knowledge to back it up, but sometimes it makes wonder if Buzzword Bingo is the way to job security. That and the experience we had with some (not all) of the contractors we used to use proved that just because you can monkey around with J2EE middleware doesn't mean you are worth one tenth of the money that is spent on you. So I throw this question out to the blogshpere... Where's the $$ in Java at?

While I was driving back from dinner with my wife something struck me... if the export of encryption is considered munitions (i.e. guns and bullets) why isn't it protected likewise? I was watching a random news channel with some pundit who said that he had info on the sequel to the patriot act, and one of the provisions was that the the use of encryption would become illegal. So owning an AK-47 is a constitutional right but https for your online purchases isn't?

Amendment XVIII
Section 1. The Congress and the several States shall make no law infringing on the right of a citizen to use encryption.
Section 2. Effective one year after the ratification of this amendment the portion of any law infringing on the right of a citizen to use encryption shall be held unenforceable.

I can see the arguements coming now against it. But for all of the scenarios about how horrible it is, replace the word encryption with gun. Realize that almost all of those argumets applie to guns to. Guns are used in crimes, wars, terrorism, etc, and yet are still very valuable when used properly, and the pros outweigh the cons. The same goes with encryption. Wouldn't there be an armed uprising id the second amendment were repealed? Shouldn't there be the same constitutional protections seeing as the rights for privacy and encryption are slowly being chipped away?

Apologies to the non US readers out there. It is true that this is a US centric solution to a problem as viewed from a US centric position. And I know precicely who that pundit was, I just don't want to give him free advertising.

Bitworking released Aggie 1.0 RC5 friday....

Pros

• SMTP support is reportedly turned on
• site-scraping for regularly formatted web sites
• The pixel theme can add a [ Blog This] link from each entry, facilitating hit and run blogging!

Cons:

• It's Broken out fo the box! We're not talking strange stuff, but basica functionality!
• You cannot add new feeds, it complains about a file missing, which is the local cache for the rss feed. Of course it doesn't exist yet I'm adding it!
• The Pixel theme is horriblyt slow, and this is due to sloppy coding. They have a reference to http://ntbhi22/ in the stylesheet where they meant http://www.perceive.net/. Aggie screaches to a halt doing a NetBios lookup.
• Expand collapse is broken in IE for the pixel theme. It used to work before whjen it was broken in Mozilla...

I hate to bite the hand that feeds by saying this, but Aggie RC 5 is pre-alpha crap (I used the msi installer for reference). Aggie RC4 was truly an RC level release. So I snipped the one interesting feature from the pixel stylesheet (the blog this link which I am using right now), put it in my old pixel theme in RC 4, and uninstalled RC5 (codename CS101 first program submission). I sure hope they do some damage control quick like.

Update 17 Feb: One of the authors of Aggie responded inmy comments, and acknowledget hat the pixel skin is in need of work, and it will be address. As for the add problem I haven't been able to systematically reproduce it, but it involved deleting feeds, then their cache file, then re-adding the file, so it's not a normal case. But I found that after my pixel aggrivations so my tolerance for strange behavior had dropped to sero at that point

Don't get me wrong though: I like aggie, I've used aggie for months now, and will continue to use aggie, just not the RC5 version. Wait for RC6 or an update to RC5 before installing a newer verison of aggie.

Here's another entry in the mutually exclusive UI requirements file:

If all the items in a menu are unavailable, do not make the menu unavailable. If the menu itself is still available, users can display the menu and view all its (unavailable) items. Similarly, if all the items in a submenu are currently not available, do not make the original menu title unavailable. [ Java Look and Feel Design Guidelines (emphasis added)]

If all items in a menu are disabled, disable its menu title. If you disable a menu item or its title, the user can still browse to it or choose it. You should include a status bar message, balloon tip, or other context-sensitive Help support indicating that the command is unavailable and why. If you use a status bar message, display it when the input focus moves to the corresponding item. [ Official Guidelines for User Interface Developers and Designers from Microsoft (emphasis added) ]

What sucks more is when you get a bug assigned saying that your app should behave one way after you've sepnt time explicitly coding it to behave the other way...

Nothing is worse than inexplicable behavior. Obscure behavior is close, but decidedly better.

So I've got this bug in my GUI code relating to changing names in a JTree, basically the structure of the JTree stays the same but the length of one of the names of one of the nodes expands significantly at times. The problem is that the new text is not displayed! (or actually, only 4 pixes of the new text is displayed, for another obscure reason).

My natural inclination is to blame my own code, so I dig into the debugger and stop it durring a swing rendering of the tree (two moniters would sure be nice for this). The first rendeering is perfect. The preferred size on the second (larger) rendering is also perfect. WTF? So after a few failed attempts to move stuff around I think to look at the rendering Graphics object, and lo and behold the clip is set to the first rendering size! This has me really confused, becuse I never have to handle passing around the Graphics object and I have become used to trusting that the rigght clipping is set up (that's a magical black box labeled "Efficient dirty region rendering" in my world). So then I (properly) conclude the causal factor is outside my code. Too bad, 'cause I still have to fix it.

This is where I am truely thankful that Sun ships most of the Java code that comes with the JDK in src.zip. I can crack open the implementation classes and look around and find what the real culprit is: JTree is caching the preferred sizes of the tree nodes when it is drawing it, and it's called an optimization. When you are using straight GDM code on a 200Mhx Pentium MMX running Windows 95 I suppose that optimizations like that make sense, but that is, like, so last millenia.

The problem is that this is a faulty optimization, because it clearly isn't keeping up to date or allowing for a hook to change the size of the widgets. Fourtionlatly my diging around also gives me anoter clue: when JTree.setLargeModel is set to true these cachings are ignored. I've always wondered what that property did! But the documentation is so... vauge. It was a real.... bummer. Six hours of head scratching work and the A-Ha moment comes and all I have to show for it is one measaly line of code.

There is still one last mystery in this though: this fix requires largeModel to be true and for rowHeight to be set to a non-zero value. Using the Windows Look And Feel sets this row height automatically, but not for Swing, and for the life of me I cannot find that code in the Windows Look and Feel code. So I just set the value to a previously rendered value when I am done with my data load thread, and it's all good on Linux. So a total of three lines changed (the second change was quite long, and I had to wrap it onto the next line).

NetBeans is embarking on a community based marketing push as of late, as seen on their Move the needle! page. Actually it started, like, nearly a month ago. I was going to do this a month ago, but I'm actually starting to do some interesting stuff at work. But do me a favor, click on my main blog page and click on the netbeans link.

So what's in it for you if you click the link above? Nothing, unless you actually download netbeans and use it. What's in it for me? Probably a book I won't read and will just sit on my bookself in my cube looking importiant. It's not like I'm selling out, anyone who has been reading my blog knows that currently NetBeans is my IDE of choice, and that I have looked elsewhere *cough*eclipse*cough*, and NetBeans is currently the pair of sneakers that fit most comfortably.

Also, I am going on a short vacation tomorrow. I can tell this because my mind has basically already turned off, I'm even going to leave my laptop at home and jsut bring along my game boy. Once I get back (or sooner, it's that or work) and my brain turns on I'm going to add links for the other tools I actually use.