« December 2002 | Main | February 2003 »

January 2003 Archives

January 11, 2003

Users Group Presentation on Ant

For those of you who may be remotely interested, I will be doing a presentation on Ant at the Pikes Peak Java Developers Group in Colorado Springs on Tuesday. Even if you aren't going feel free to peruse the slides and send me comments on them. And be as brutally honest as you desire.

January 14, 2003

Automated GUI Testing

One of the buggest deals that people in my office seem to make about XP is the emphasis on Testing. (We could care less about Pair Programming, Iteration driven stuff, and the way they do story management, none of us including me really get disagree that what we have in those areas seems to work). But from all of the reading most of the supprot I have seen is foducsing on either object components or the lowest of the gui portions if even that. For the longest time I have been trying to find a good GUI test too I can integrate with the build, I think I found a hidden gem. But let's look at what's out there and why I didn't use it...

  • Abbot - Serious GUI bug in 1.4, that pane on the right you are supposed to put stuff like classpath and class name in? Doesn't work, won't remember the values or persist it to the model. Hence it is unusable for record.
  • Pounder - I forgot exactly why, but it behaved poorly for me out of the box. I seem to recall it used java.awt.Robot to do alot of the work, which would have been good or bad depending on what you are trying to test. But the use on Linux and the fact component sized change frequently would have been bad news for it. It also takes over the computer to take over the test and does it in real time, good or bad based on how you look at it. The other problem is that it records every stinking possible awt event that exists! Too much clean up on the test when you are done.
  • JFCUnit - The lack of a record option is a killer here. If I'm not going to design the grid bag container by hand I sure am not going to write the test cases by hand. Especialy since some of the GUI is dynamicaly generated and the structure of those components beneath that pane are difficult to derive by hand. Yea, there is aFAQ item that involved wriring your own but it took less effort to keep on looking
  • Jemmy - (a) Lack of JUnit Integration, and (b) Lack of a record option, see my entry on JFCUnit. (a) might not be such a big deal if (b) wasn't there and (c) I had infinite time.
  • Any commercial test suite - I don't know if anyone noticed out there but there is a recession going on. The cost for a autometed GUI test suite to use on the scale we want to (every developer that checks in code) it would cost us at leas one head count. I don't want to see any more of my colleagues leave, we've already gotten rid of the stinkers (and some of the good ones). That's why I'm being cheap about it.

Well, that seems to be the extent of the GUI test tools out there, and they've all got there blockers that encourage me to look elsewhere. Or is that all of them? In doing a google search on "Java GUI Test Tools" I stumbeled upon the mention of a java-gui-testing group on Yahoo Groups, where I learned about the hidden gem I previously mentioned:

  • Marathon - not perfect but Good Enough. Record option, junit playback, was able to get it working with my detateched test harness. Dosen't record random key strokes like I would like it to, but it referes to the JComponents principally by the setName(...) value you gave to it. It uses Jython to record the test and play back the test script. The API for the types of tests it has is a little limited, but the whole set of Java APIs are exposed so you can do whatever you need to inside of the jython script, so to add some custom valdiation logic you don't have to write a whole new stinking java class. And it integrates into my JUnit setup, with the tests showing up in the junitreport.

Good Enough, and much better than what I had before. What I had before was my memory and intuition of what I thought would break. But that tends to be unreliable under time pressure. Doing the same tests over and over again, and when it's automated you don't have to worry about the Intern or Script Monkey (which is not the same as a QA person) finding a better job!

Update : Glen posted about this sunday, and I learned that after I wrote this. So I didn't get to "out" marathon in the java.blogs community. But I felt my selection reasons and some more exposure would be good for marathon.

January 16, 2003

Netbeans does SWT

AndI got the screenshot again, look!

netbeansswt.png

Well, April Fools again, at least this time it's a bit closer to the date than last time. What you are seeing is a feature of NetBeans that is not aggressivly documented, if you open up ide.cfg and add a line "-ui com.sun.java.swing.plaf.windows.WindowsLookAndFeel" in there. And BAM no more "owe my eyes it's purple."

One piece of code in there that is not april foolery is the Ant code competion, sceduled for the 4.0 release of netbeans, which is... ummm... going to be relased in June, really! Actually looking at the scedules it looks like it's achieveable, feature freeze in about a month and three to four months of what I like to term "quality time" with the code.

Ray mentioned that he didn't like the "swingy" look of NetBeans, and this does a good job of getting rid of it. The same option is available in NetBeans 3.x as well. You are not limited to Metal or Windows, there are other look and feel options such as Kunststoff and Metouia. But since the client I am writing is supposed to look best in Windows, I use the Windows look and feel so the GUI designer uses it by default.

January 17, 2003

People Do Learn

I got a letter from Rob Demmer the other day, this time offering a proper applogy for our e-mail flame out. I don't feel the same need to post that e-mail to my blog as I did last time, since I will categorically say it was suffucent, apology accepted. And to imply I was blameless would be wrong, after all Rob didn't make me post it to my blog.

But it actually would up being for the better, without that experience I doubt that I would have given Eclipse as much consideration as I did, and now I feel more confident in my choice of IDEs. The only advantage that Eclipse has left is "Dating the New Girl" (more on the bug attitude later). The biggest (and for my work most significant) disadvantage Eclipse has is the total lack of a Swing or SWT GUI designer, coding stuff like that just simply takes too much time. I'm not even going to look again until Eclipse has something that can compete with NetBeans offering.

January 20, 2003

PMD/NetBeans config

My little nit on PMD got some notice,

...the "deeply nested if statements rule" can now be configured to trigger only after hitting a certain depth:
http://pmd.sourceforge.net/xref/net/sourceforge/pmd /rules/AvoidDeeplyNestedIfStmtsRule.html
It's a bit of a pain to configure, since you have to edit the rulesets/design.xml file and change the "problemDepth" property, but, anyhow, it works :-)

Well, it works for stand alone running, but inside of netbeans it is not configurable...

pmdconfig.png

That cell in the table is un-editable, so I cannot change the depth. It's sitting there, taunting me and laughing at me! (OK, maybe not, I should reduce the caffine intake and get some more sleep). It's really funny it tells you what the optuion is but it won't let you chagne it. I've even tried looking for the pmd module configurations and for those rules.xml files but i cannot find them for the life of me. So I just don't care about that rull and throw it out.

However, the ant task looks to be editable (at least according to t he docs), so it is integratable to a build process easier. I could just create an at task shortcut to run it, and we can keep the rules files in the source control tree, so we get consistent results.

January 22, 2003

NetBeans 4.0 and Swing Themes

Well, for those of you who are running on non-windows platforms and noticed that my tip about adjusting the look and feel won't (legally) work on linux, enter the Netbeans Themes feature "Ouch my eyes it's purple" not bad enough for you? How about "Run for the Hills it's EarthTones!"

nbtheme.PNG

The themes page describes how to do it, but the Readers Digest version is to drop an appropriately formatted themes.xml file into $HOME/.netbeans/dev/system/. It's not perfect, as you can see the window titles in the embeded windows don't catch the theme, they still got the "ouch it's purple" look to it. And this is currently living in the dev tree, so who knows if the code will make it into the "Real" 4.0 fork. Time will tell.

January 23, 2003

NetBeans listens

It looks like one of my previous issues about NetBeans is getting some resolution, that of a bad attitude about bugs, at least in this anectotal case.

I posted a feature request for NetBeans 4.0 (Issue #29467) to add code comletion to Ant Build scripts. I saw that they added it for XSLTs so how much more difficult can the stock Ant 1.5 tasks be? It took about a month from open to working code in the 4.0 dev codeline. It seems to work in the limited bases I have tested it in. I won't use it for day to day work because I have an alergic reaction to beta-quality code I can't or lack the time to get inside of and fix easily.

Granted, if I got requests for changes like some people have I might have a bad attitude about "community" requested features too. And I am seing some more responsibility taken WRT quality and releases. NetBeans 3.4.1 is about a month late. Why? There were several bad bugs identified in teh release candidates that were put out that were deem worthy of stopping work and fixing. One of the decisions in software development is deciding that whether or not it's fit for public consumption as a release. Depending on the scale of the use the threshold of bugginess moves, but it looks like NetBeans is taking the road less traveled and saying "Too buggy, the release date be damned!" rather than releaseing a 3.4.2, then a 3.4.3, etc. etc. Not that I've had any personal experiences with that kind of a release schemdule ;).

January 24, 2003

The Disappearance of the Consistent UI?

Damien noticed my entry on Netbeans does SWT!, I wonder if he saw my entry on Eclipse does Swing! Damien focused on an example from jgoodies about how Karsten made an ugly UI look more like eclipse. The point he wanted to make was how an emulated UI will never look like the "native" UI. Most of hose little nits that he mentnioned however are either fixed in the 1.4 release of java or are an artifact of the custom GUI (probobly because of drop shadows). But there really is a greater issue lurking beneath the surface not constrained to Java.

Remember when all GUIs used to look the same and be consistent? Think way back, think back even farther than that. Think back to the first release of most GUI shells for OSes, and for the first few demo apps released by those companies. Ever since then the GUIs have been changing, and as we get to the present day we have such wildly different looks and feel even from the same OS provider. On my Win2k laptop I am currently running Outlook XP. The toolbar and the menus are wildly different from, say, Internet Explorer. Same company using the same "native" windows look and feel. Even within IE with the right stylesheet arguments you can make the scollbar turn green and take up half the screen as well.

But what is the "native" look and feel? The skin on mozilla I use uses the same native look and feel, looks different from the previous two as well, and it uses MFC as well! I know it does because on my home machine running WinXP I get the nice rounded buttons and funky menus. What's different? Fonts, control borders, insets, margins, colors, etc. Does it look like the "native" widget set? No. But it is!

On WindowsXP not even the window borders are consistent, the command prompt being the worst offender. Microsoft is not alone in this: Apple is a pretty bad offender when it comes to that as well. You can have Platinum/Aqua/brushed metal on your screen all at the same time. I am sure if you tried hard enough you could even get pre-platinum system 7 as well. With the new X11 server you can bring in motif and whatever else you have on the Linux front. And Linux practically uses it's mildly controlled anarchy in the area of "native" widget sets as a marketing bullet.

Is this bad? Has the user sufferd uniformly because of this? No and no. Let me wax philosopical for a minute. Waht is a cow? I mean the most basicness of a cow? Do all cows look alike? Can we agree on one "perfect" form and look of a cow? Is there even one? What about male cows? Are they cows? Does the fact we have to distinguish them as male make them not cows at all or a special kind of cow? If we spent our entire lives living in a cave looking at a shadow cast by a clay figurene of a cow would we be able to recognize a cow if we then went outside and were being charged at by a rodeo bull? Ok, I may have went too far with the last one, but it is a classical question about categorization and characteristics. A point that I want to make that event though the GUIs are not all consistent what they are consistent on are some of the characteristics and idioms. Buttons looks like buttons, menu bars pop up menus, text boxes accept keyboard input, so on and so forth. But even with these items there are some differences. In MacOS you cannot have a button in a dialog gain keyboard focus (you cannot "tab" into it). And then there are other vendors who tried to do there own things with native UIs. Remember Borland's Object Windows Library? Think oversized green check mark.

So where I am going with this is to say that an argument that differences in the JFC PLAF implementation of a Windows look and feel means it is inferior is to say that all GUIs are inferior. It is an argument that is not specific to the JFC and can be applied to every GUI out there to varying degrees. Even the fangled spangeled SWT falls victim to this because there is no least common denominator between all of the GUI platforms it wishes to target. This is becasue some of the requirements of different GUI standards are downright mutually exclusive (the MacOS menu bar being one of the more obvious and flagrant ones). But GUIs have come to the point where for the most part they are consistently usable, if not consistently pleasent to the eye. Jersy milk cows and Angus beef cattle are still, after all, cows.

January 28, 2003

Small World

Sometime's it amazing what some of the people you went to high school with do. At my high scholl reunion I learned that one of my classmates is a doctor in residence in LA, and works in the same ER as Darva Conger (FOX's who wants to marry a multi-millionare 'winner'). Another classmate was on Trading Spaces. I still haven't been able tos ee the episonde but I believe it was one of these. What really shocked me was this morning I read that Derek Cianfrance won Excellence in Cinematography in the Dramatic Competition at the Sundance festival. Wow, and he wasn't even into theater either, jsut one of our better soccer players.

Obligority java reference, the site for the Sundance Film Festival uses JavaServer Pages

January 30, 2003

JUnit Exception Handling

Gherhard Froehlich was wondering if there was a better way to do positive JUnit exception testing than something like this:

public void testAddService() {
    try {
        setUp();
        TRACER.trace("--- Testing addService() ---");
        ssgConnectorProvisioning.addService(serviceData);
        TRACER.trace("--- End of test ---", "\n");
    } catch (Exception e) {
        if(e instanceof SSGConnectorException) {
           TRACER.exception("Test OK, because Exception was controlled", e);
        } else {
           TRACER.exception(e);
           fail(e.getMessage());
        }
    }
}

There is, the thing to do is to take advantage of the fact that java will only use one exception block, and it will match the first one that is an assignable class of the exception, so you could do this...

public void testAddService() {
    try {
        setUp();
        TRACER.trace("--- Testing addService() ---");
        ssgConnectorProvisioning.addService(serviceData);
        TRACER.trace("--- End of test ---", "\n");
    } catch (SSGConnectorException sce) {
        TRACER.exception("Test OK, because Exception was controlled", e);
    } catch (Exception e) {
        TRACER.exception(e);
        fail(e.getMessage());
    }
}

Let's hope he get's this via a Moveable Type pingback. (I've wanted to see if I have it working or not).

Update: I was kind of myoptic when I looked at the post Gherhard had and realized it was missing something this morning. Charles Miller also noticed it last night: the test should fail if no exception is thrown. steve tried to trim it down to a single catch:

public void testAddService() throws Exception{
    try {
        TRACER.trace("--- Testing addService() ---");
        ssgConnectorProvisioning.addService(serviceData);
        TRACER.trace("--- End of test ---", "\n");
    } catch (SSGConnectorException sce) {
        TRACER.exception("Test OK, because Exception was controlled", e);
    }

fail("We expected a SSGConnectorException");
}


Except in this case the test will fail if the exception is throw! (a false failure). And this also assumes SSGConnectiorException is the only exception thrown. If your tests are written so that only one test is done per test method (a good practice IMHO) you could fix this by putting a return statement in the catch block or moving the fail inside of the try block. Otherwise (such as cases where the exception is just a set up for the real test) you will need two fail statements or catch statements or continue the test in the catch block.

Java String Tricks

Raible:

if (request.getParameter("checkbox") != null &&
request.getParameter("checkbox").equals("true"))

With StringUtils.equals(String, String), you get a little less coding:

if (StringUtils.equals(
request.getParameter("checkbox"), "true"))

If you're using Struts or some other library that already depends on commons-lang, why wouldn't you use it? Possibly performance reasons, but I doubt it causes much of a hit.

Actually, the latter implementation will perform better. It has half the hash lookups and HotSpot can inline the method invocation. [ crazybob ]

Actually, even easier than that....
 if ("true".equals(request.getParameter("checkbox")))
The string class already does the null check inside of the equals call and requires no exteranl library. I got this from an old C trick where whenever you are comparing somethingto null you put the null on the left side. If you accidentally type an assignment then the compiler will crash because a constant is not a valid LValue for an assignment.

About January 2003

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in January 2003. They are listed from oldest to newest.

December 2002 is the previous archive.

February 2003 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33