Tag: programming

I read a very interesting article on the NY Times today, linked from this /. article, about the Monty Hall Problem. The problem has apparently caused much embarrassment among mathematicians, and now psychologists, and it's a very interesting read.

I couldn't quite agree with the argument put forth, and I'm no mathematician, so I wrote a simple program to calculate some numbers for me... first, lets review the problem at hand:

1. I present you with three closed doors. Behind one is a new car, the other two, a goat.
2. You choose one of the three doors, hoping it has a car.
3. I open one door exposing a goat.
4. You may keep your original door, or change your mind choosing the other closed door.
5. Open your door, if it's the car, you can keep it.

So as impulsive humans, it's easy to see, and think, that since I open one door, your final choice gives you a 50/50 shot at winning a car. The argument in the paper those posits that you should change your mind, since your original decision only had a 33% chance of being correct, and a 66% chance of being wrong.

Here is my source for the simulation I ran: MontyDoor.cpp. It very closely follows the steps I laid out above, resetting the doors at the start of the loop, randomly choosing which one contains a "car" (true value). The simulates a user's choice (rand mod three), opens a door containing a goat, and then simulates the user randomly choosing to change their mind (rand mod 2). It totals how many times the user kept their original door and won a car, as well as how many times the user changed their minds and won a car.

I present the results here for you to mull over - I ran 75,000,000 iterations of the loop and got the following:

How many iterations: 75000000
In 75000000 runs, we won a car 44.4418% of the time.
	Used original choice and won a car 12499628 out of 37505245 times... 33.3277%
	Chose the other door and won a car 20831722 out of 37494755 times... 55.559%

Suggesting that your original choice is only correct 33% of the time - which makes perfect sense. However, after I open a door and narrow your choices down, you have about a 50% chance of winning the car when you change your mind.

Since your original choice was made out of three closed doors, you'll win with that choice 33% of the time. However, when you change your mind you're only choosing out of two closed doors, so you'll win about 50% of the time.

Doesn't add up, I know - but makes a certain bit of sense.

I just recently started playing with EJB3, and found it extremely tricky to get through my very first EJB3 Session Bean. While significantly simpler than EJB 2, the online resources just aren't there. Hopefully this simple Hello, EJB3! will help get you started.

Note: Your mileage may vary based on your application server platform. I do my development work on WebSphere Application Server 6.1.0.9 with the EJB3 Feature Pack Beta installed.

Write Your Session Bean

The first thing I did was create a new, empty Java Project - not a J2EE project, not an EJB project, just a blank project space. This avoids the built in wizards in your environment from creating deployment descriptors and other such silly EJB 2 nonsense.

Next, create a new interface called HelloEJB3, like so:

package com.timfanelli.ejb3;

import javax.ejb.Stateless;

public interface HelloEJB3 {
   public String sayHello();
}

This will be the local business interface for our session bean. If you want a remote business interface, annotate the interface with @Remote.

Next, create the bean implementation class, like so:

package com.timfanelli.ejb3;

import java.ejb.Stateless;

@Stateless
public class HelloEJB3Bean implements HelloEJB3 {
   private String greeting = "Hello, EJB3!";

   public String sayHello() { return greeting; }
}

And that's it! You have yourself an EJB3 stateless session bean with a local (or remote, if you annotated) business interface!

EJB3 eliminated the need for several complicated things noone liked, such as home interfaces, deployment descriptors or complicated EJB interfaces. Pretty neat. JAR it up and you're ready to roll on to writing a test client.

Oh - it's worth noting for backward compatibility, the @Stateless annotation tells your container that this is a stateless session bean, and it will be bound to java:comp/env/ejb/HelloEJB3.

EJB3 Session Bean Client

For our client, we'll create a new servlet application. The application will have a single servlet, HelloWeb. We'll use the new EJB3 dependency injection to obtain an instance of our bean, and use its business interface to execute methods on it; like so:

package com.timfanelli.ejb3;

import java.io.IOException;

import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {
	
	 @EJB
	 private HelloEJB3 hellobean;
	 
   protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      response.getWriter().write(hellobean.sayHello());
   }  	
	
   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
	// TODO Auto-generated method stub
   }   	  	    
}

The important parts are in bold for you. Note the line annotated with @EJB. This is all you need to do to perform the JNDI lookup for your EJB bean. The container will automatically lookup java:comp/env/ejb/HelloEJB3 from the JNDI context for you.

Then, all you need to do is use its business methods, as shown in the doGet() method of the servlet.

Don't forget to add the name of the jar file that holds your HelloEJB3 interface and HelloEJB3Bean class to your web applications MANIFEST. Otherwise, you'll hit runtime classpath errors.

Deployment Setup

Here's where the really tricky part came in for me. I had to create an EAR project to add my HelloEJB3 project to, and also my web application project. Since I'm using Rational Application Developer 7, which does not yet have tooling support for EJB3, this was a little difficult.

In my EAR, I have added the WAR file as a war module - no surprise there. I then added my java project, called HelloEJB3.jar, as a utility jar and an ejb-module. Since I'm not overly familiar with many other tools, I don't know what that means for the rest of you. In any event, here's my application.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<application id="Application_ID" version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
	<display-name>
	HelloEJB3EAR</display-name>
	<module>
		<web>
			<web-uri>HelloTestWeb.war</web-uri>
			<context-root>HelloTestWeb</context-root>
		</web>
	</module>
	<module><ejb>HelloEJB.jar</ejb></module>
</application>

That's all there really is to it. You should be able to deploy to your EJB3 ready application server, access your servlet, and see your hello message!

Best of luck. And remember, stateless session beans are only the tip of the iceberg. I'm also investigating the Java Persistence API to replace my EJB2 Entity Beans... will post migration stories later!

Lately, I've been using IBM's Rational Application Developer 7 to develop J2EE applications targeting the WebSphere 6.1 platform... all in all, I have to say RAD is a phenomenal tool with excellent integration to the platform. My only real complaint after almost a year of use is it's default paths and settings when you create a project.

By default, your source folder is named "ejbModule" - this in and of itself is not an issue... but "ejbModule" is also used as the default output folder, AND is where the deploy tools output their generated code.

The result is that when you publish your application to a local test environment, you wind up with a very messy source folder.

My original "work-around" for this was to ignore the source folder completely, and just access my beans via the deployment descriptor hierarchy. This works out well most of the time, until you change the remote or local interface of a bean. Then the generated sources need to be recreated... and to recreate them, you need to delete them (why they're not deleted when you clean your project is beyond me)... since they're mingled in with your actual source files, this is a very dangerous thing to do. Several times, I've accidentally deleted source files, and got myself into irritating situations attempting to restore files out of my repositories and other backups.

But today, persistence paid off. I've finally managed to configure my projects to have a very clean structure in RAD. It's actually so simple and obvious, I can't believe it took me this long.

The key is to do two things:

1. Create a second source folder, called "src". This is where I keep my sources. META-INF can, and should, stay in the ejbModule folder. RAD7 seems to get confused when you try to move this in an existing project.
2. Go into your project settings and edit the Java Build Path. On the "Sources" tab at the bottom, you'll find the default output folder. Click browse, create a new folder in your project called "bin", and choose that.

Now, your structure should look something like this:

Project/
   source/
      com/
          timfanelli/
              
   ejbModule/
      META-INF/
   bin/

When the deploy tool runs, your sources remain under source and generated code is created under the ejbModule folder. When you build your project, all the binaries go into bin. Cleanup is a snap then, when you want to delete the deploy tool's generated code, simply delete all source packages under ejbModule.

Wrote a quick function today also to verify that the syntax of an email address is valid, using regular expressions.

^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$

This will match a userid containing letters, numbers, underscores, dots and hyphens, followed by an at sign, then a domain name containing letters, numbers, hyphens and dots, followed by a suffix of 2-to-4 characters.

Using this regex, I can ensure that the user has entered a potentially valid email address before attempting to send out a confirmation email.

Part of my new comment system for Blosxonomy includes an email verification system that requests the user to confirm their email before their comments will be displayed on the blog. To do this, I wrote a simple random-hex-code generator to build unique url's. When a comment is posted by a user with an unconfirmed email address, a random URL is generated using the random hex code, and emailed to that user.

Generating such codes in ruby is very simple, and often useful, so I thought I'd post the method I wrote to do it:

def generateUniqueHexCode( codeLength )
    validChars = ("A".."F").to_a + ("0".."9").to_a
    length = validChars.size

    hexCode = ""
    1.upto(codeLength) { |i| hexCode << validChars[rand(length-1)] }

    hexCode
end

validChars is initialized to be an array containing characters 'A' through 'F', and '0' through '9'. I then append codeLength random characters from that array to the hexCode string and return it.

While a more robust implementation would validate uniqueness against the list of already generated IDs, the assumption is that these ID's are short lived, and the likelihood of generating repeats IDs given a sufficient length (I use 64) is miniscule.

It's often useful to either extend WPF controls or create custom controls to supplement to functionality provided to you by the WPF classes. In this brief tutorial, we'll refactor the code from the first part of the Drawing a RubberBand in WPF tutorial and see how we can add use a custom class in an XAML document.

Refactoring

We've already built a simple window class that contains a System.Windows.Controls.Canvas instance, and registered several mouse handlers with it to draw the rubber band. Instead of instantiating a base Canvas instance though and telling it how to behave (i.e., by registing external handlers), we'll extend the Canvas class, and move the handlers inside it so that'll it'll know how to behave.

The first step is to create a new User Control (WPF) type to our project. This will create an XAML document and associated code-behind file for a class that extends UserControl. Simply changing references to UserControl to Canvas will result in a class that extends Canvas, like so:

RubberBandingCanvas.xaml:
<Canvas x:Class="Rubber_Band_Tutorial.RubberBandingCanvas"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	Background="White">

</Canvas>

RubberBandingCanvas.xaml.cs:
public partial class RubberBandingCanvas : Canvas
{
    public RubberBandingCanvas()
    {
        InitializeComponent();
    }
}

As you can see, the XML root element in our XAML is a Canvas type, which matches the base-class type specified in our partial class definition in the code-behind. Also notice the addition of the Background="White" attribute to the canvas in the XAML... recall from part 1 that a canvas with no background does not respond to mouse event handlers (still haven't figured that one out, btw).

The next thing to do is move our mouse handlers out of the Window class, and into our new Canvas-derived RubberBandingCanvas. I'll also update the methods to be static, which'll help minimize the application footprint if I were to allow use of multiple canvases.

RubberBandingCanvas.xaml.cs: public partial class RubberBandingCanvas : Canvas { public RubberBandingCanvas() { InitializeComponent(); this.MouseLeftButtonDown += OnLeftDown; this.MouseLeftButtonUp += OnLeftUp; this.MouseMove += OnMouseMove; } private Point mouseLeftDownPoint; private Shape rubberBand = null; protected static void OnLeftDown(object sender, MouseEventArgs args) { RubberBandingCanvas canvas = sender as RubberBandingCanvas; if (!canvas.IsMouseCaptured) { canvas.mouseLeftDownPoint = args.GetPosition(canvas); canvas.CaptureMouse(); } } protected static void OnLeftUp(object sender, MouseEventArgs args) { RubberBandingCanvas canvas = sender as RubberBandingCanvas; Shape rubberBand = canvas.rubberBand; if (canvas.IsMouseCaptured && rubberBand != null) { canvas.Children.Remove(rubberBand); rubberBand = null; canvas.ReleaseMouseCapture(); } } protected static void OnMouseMove(object sender, MouseEventArgs args) { RubberBandingCanvas canvas = sender as RubberBandingCanvas; if (canvas.IsMouseCaptured) { Point currentPoint = args.GetPosition(canvas); Point mouseLeftDownPoint = canvas.mouseLeftDownPoint; if (canvas.rubberBand == null) { canvas.rubberBand = new Rectangle(); canvas.rubberBand.Stroke = new SolidColorBrush(Colors.LightGray); canvas.Children.Add(canvas.rubberBand); } double width = Math.Abs(mouseLeftDownPoint.X - currentPoint.X); double height = Math.Abs(mouseLeftDownPoint.Y - currentPoint.Y); double left = Math.Min(mouseLeftDownPoint.X, currentPoint.X); double top = Math.Min(mouseLeftDownPoint.Y, currentPoint.Y); canvas.rubberBand.Width = width; canvas.rubberBand.Height = height; Canvas.SetLeft(canvas.rubberBand, left); Canvas.SetTop(canvas.rubberBand, top); } } }

The code is almost identical to the handlers we wrote last time, with the exception that member variables are resolved against the canvas object that raised the event (i.e., the sender paramter of the handler method).

Adding a Custom Class to a XAML

The only thing left to do is to update my main window's XAML to use the new RubberBandingCanvas class instead of the WPF's base Canvas class.

This is a simple two step process... the first is to add an XML Namespace declaration that will map my CLR-Namespace to an XML namespace, effectively giving me access to my class names as valid XML element names.

Window1.xaml:
<Window x:Class="TimFanelli.WPF.Tutorials.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:Rubber_Band_Tutorial;assembly="
    Title="Rubber_Band_Tutorial" Height="300" Width="300"
    >
	<DockPanel LastChildFill="True">
		<ToolBarTray DockPanel.Dock="Top" Background="{DynamicResource {x:Static SystemColors.ControlBrushKey}}">
			Removed for brevity...
		</ToolBarTray>

		<local:RubberBandingCanvas/>
	</DockPanel>
</Window>

The first bold line give me access to public members of the Rubber_Band_Tutorial clr-namespace via the local xml namespace. Then to add a RubberBandingCanvas to the windows dock-panel, I simply add it the same way I would any other element.

Conclusion

Most of this post was concerned with setting up the derived class we used, however the real goal was to add my custom class to the Window1 XAML document, which you can see if a very simple task. This method will work for not only any custom or derived controls you write, but indeed any CLR object with a default constructor.

It's also worth noting, since we didn't use the feature explicitly, any public CLR property (or dependency property) you expose in your objects can be set using standard XML syntax as well, with the property name used as an xml-attribute name on the element in question.

Overview

Rubber-banding is a very simple and familiar concept in most graphical applications where the outline of a shape to be drawn is painted to the screen, following the mouse cursor so the end user can visualize exactly where the shape will be placed.

This tutorial will guide you through implementing a very simple WPF window containing a canvas, with rubber-banding rectangles. Adding additional shapes is then a trivial matter, which I'll address in a follow up to this post.

(read more)

Microsoft has officially released the .NET Framework 3.0! This release comes with a handful of new technologies that I'm pretty pumped about, particularly WPF - The Windows Presentation Foundation. WPF is, to greatly oversimplify it, their new framework for developing Windows GUI applications.

I've been teaching WPF this semester at Clarkson and am really thrilled with its capabilities. It's by far the most well thought out and put together GUI API I've had the pleasure of using. Now that I've got my website back up and running, I do plan to post several articles and projects in WPF so you all can get started too.

You can find download links for the framework, SDKs, and visual Studio extensions on this blog post on the .NET FX3 website.

Pure virtual, or abstract, methods are those that are defined with a signature and no body, and must be implemented by some base class definition before you can instantiate an instance of the object.

One of the key concepts in the test first programming paradigm is to write as little code as possible in order to compile test cases that fail. If you're not a test-first programming addict like I am, the concept takes a little getting used to, and I won't try to explain it here. Suffice it to say you should do some reading and try it out, you'll like it.

I've come to the conclusion that pure virtual methods force you to write more code than is necessary for a test to fail, and therefore violate good test-first programming techniques. The reason being that in order for your test to fail, you must also implement some base class definition that implements your pure virtual methods so that you can instantiate an instance in order to compile your tests.

Instead, simply write virtual methods with default implementations that throw an exception. Here's an example (in C# using NUnit) of how one would write a test using a pure virtual function:

[TestFixture]
public class MyAbstractClassTester {
     [Test]
     public void MethodWorksTest() {
          MyAbstractClass mac = new MyConcreteBaseClass();
          mac.DoSomething();
     }
}

public abstract class MyAbstractClass {
     public MyAbstractClass() {

     }

     public abstract void DoSomething();
}

public class MyConcreteBaseClass : MyAbstractClass {
     public MyConcreteBaseClass() : base() {

     }

     public override void DoSomething() {
          throw new ApplicationException( "Method not implemented.");
     }
}

In this trivial example you can see that the only reason we implemented DoSomething in the base class was because we had too. While it's only a few extra lines of code and doesn't seem like a big deal, it's more than I had to do in order to make my test fail. Here's how you can do it more simply:

[TestFixture]
public class MyAbstractClassTester {
     [Test]
     public void MethodWorksTest() {
          MyAbstractClass mac = new MyConcreteBaseClass();
          mac.DoSomething();
     }
}

public abstract class MyAbstractClass {
     public MyAbstractClass() {

     }

     public virtual void DoSomething() {
          throw new ApplicationException( "Method not implemented." );
     }
}

public class MyConcreteBaseClass : MyAbstractClass {
     public MyConcreteBaseClass() : base() {

     }
}

As you can see, having the DoSomething() method be virtual in the base class with a default implementation means I've written less code, and my tests are equally valid.

Now I can hear many of you thinking that "the use of virtual methods rather than abstract methods opens you to the possibility of not implementing required functionality." While this is an valid initial argument, remember, if you're doing test first programming correctly, you rely on your tests to tell you what's working and what isn't. Your tests won't pass if you don't implement the required functionality. All you're doing is moving the requirement that the method be implemented out of compile time and into the test phase - and it could be argued that testing is the more appropriate place for it. You'll still see the error glaring at you through the bright red bar, AND you'll have the context in which the error occurred.

This further drives home the goal of writing just enough code to make your tests fail, and then only implementing exactly what's required to make your tests pass.

I added a subtle feature to my blog this morning; my tag cloud now shuffles every hour. I did this by seeding the random number system using the current hour and shuffling the tags in my tagcloud, like so:

srand( Time::now.hour )
tags = tags.sort{ |a,b| rand() <=> rand() }

The result is that with each hour my tag cloud takes on a new form, and there will be 24 different combinations.

If you wanted to shuffle every hour and not repeat every 24 hours, you could also seed using the decimal representation of the current time rounded to the previous hour:

now = Time::now
srand( ( now - (now.min * 60 + now.sec) ).to_i )

Ruby is a very powerful, fun, and expressive language - I thought instead of continuing my sometimes long winded Intro To XXX series this morning, I'd post a cheat sheet of sorts to get you started writing Ruby code quickly.

(read more)

I recently decided I was going to take up Ruby programming as a hobby. Prior to that I had taken on Python, which has quickly become one of my favorite languages. Ruby is coming in a close second, and could easily take it over as soon as they have built in XML support - so I thought I'd follow up my Intro To Python series with some Intro To Ruby posts.

I've found Ruby very easy to learn and use - I decided to learn Ruby about 2 weeks ago now, and have since released Blosxonomy, a Ruby implementation of a Blosxom like blogging system that powers this site. Its syntax is simple and intuitive, and the grammar is expressive and easy to learn.

(read more)

I while back I began posting an Intro to Python series, and for lack of time I haven't posted anything in it for a while. Since I've started writing plugins for pyBlosxom, I've gotten to learn a lot of cool stuff about the language. I wanted to do a write up on what's easily become my favorite feature thus far, the String join method.

(read more)

I installed the tags plugin tonight, and tagged most of the entries on my site. I decided to replace categories all together, and as such, you'll notice a tag cloud on the left side of my site.

I wrote a simple pyBlosxom plugin to generate the tag cloud, to be used in conjunction with the tags plugin. You can download it here: tag cloud plugin.

(read more)

Here's a very thorough article that supplements my recent const rant very nicely. I received a number of emails back arguing against my point that const is important and influential. While I realize that many developers maintain that const-correctness is a waste of time, I maintain that those people are unskilled and lazy ;).

Developing classes that are not const-correct severely limits its usage in well thought out applications, if for no other reason than that a constant instance of your class is unusable! You can't call non-const methods on const instances, nor can const-methods access non-const (or non-mutable) members. It's just plain lunacy to not keep const in mind when developing a solid object oriented system.

Just as a follow up to my last post, here's a quick overview of the const keyword

1. const int x = 5;
2. const int * px;
3. int const * px;
4. const int * const px;

1. A constant integer with a value of 5. The value of x will be 5 for its entire life.
2. A pointer to a constant integer. The value of the integer pointed to by px can not be changed; however you may point px to a different integer.
3. This is the same as #2. The const keyword may appear before or after the type it is qualified on. I prefer the style in #2, but both are syntactically correct.
4. A constant pointer to a constant integer. You can not change the value of the integer being pointed to, nor can you point px to a different integer.

const is, in my opinion, the most influential and least frequeuently used keyword in the C++ programming language.

This may seem like a very bold statement, but having recently started work on a relatively large C++ application, I'm finding that developer's lack of const usage is hindering my ability to write solid code. I'm trying desperately not to fall into the trap that many developers do, of abondonding const because it'd been forgotten; but the Software Engineer in me can't let go, and I'm spending a lot of time re-writing code with proper const usage.

Lets look at a simple example of how many developers would write a simple class:

#include <string>
using namespace std;

class Monkey {
public:
  Monkey( string name );

  string GetName();
  
private:
  string name;
};

Simple enough. It's a monkey with a name. Let's say I manage the Monkey House at the zoo. I might then want to have a collection of monkeys available to me:

#include <map>
#include <string>
#include "monkey.h"

using namespace std;

class MonkeyHouse {
public:
  bool containsMonkey( string & name );
  void addMonkey( Monkey* m );
  void removeMonkey( Monkey* m );
  Monkey * getMonkey( string &name );

private:
  map< string, Monkey* > myMonkeys;
};

Again, simple enough. Too bad it's horrendous. This simple API raises numerous questions that should be obvious to the conscientous developer:

1. Will containsMonkey( string& ) change the value of my name parameter?
3. Will addMonkey( Monkey* ) change the value of my monkey?
4. Will removeMonkey( Monkey* ) change the value of my monkey?

And more importantly for each of these questions, if the answer is yes, then when -- before or after it performs is expected function?

Lets say you were dropped into this project and wanted to make it "more solid". We can start by addressing those questions above with the const keyword:

class MonkeyHouse {
public:
  bool containsMonkey( const string & name );
  void addMonkey( const Monkey* m );
  void removeMonkey( const Monkey* m );
  Monkey * getMonkey( const string &name );

private:
  map< string, Monkey* > myMonkeys;
};

This simple addition of const to your method parameters ensures users of your API that objects passed will not be changed by that method. Remember that a const Monkey * m though is a pointer to a const monkey. The method could still change which monkey is pointed to my m if it so chooses. A slightly safer declaration might look like this:

class MonkeyHouse {
public:
  bool containsMonkey( const string & name );
  void addMonkey( const Monkey* const m );
  void removeMonkey( const Monkey* const m );
  Monkey * getMonkey( const string &name );

private:
  map< string, Monkey* > myMonkeys;
};

Now the methods that take monkey pointers take constant pointers to constant monkeys. Users of your API can now be utterly certain that the method will not change the monkey, nor will it change the monkey you're pointing too. Good! This is a great start.

Too bad it won't compile.

I think it's safe to assume that addMonkey( const Monkey* const m ) looks a lot like this:

void Monkey::addMonkey( const Monkey* const m ) {
  myMonkeys[ m->GetName() ] = m;
}

We can't assign m to myMonkeys[ key ] though, because myMonkeys contains pointers to monkeys, not pointers to constant monkeys. You'll get a cast error. Fixing the map declaration is easy enough though, we'll just make it:

  map< string, const Monkey* > myMonkeys;

Great! Too bad it won't compile.

You're now assigning a pointer to a constant monkey to myMonkeys[ m->GetName() ]. However, you can't call Monkey::GetName() on a constant monkey, because it's not a constant method! Argh! Lets revisit the Monkey API, shall we?

class Monkey {
public:
  Monkey( string name );

  string GetName() const;
  
private:
  string name;
};

By declaring GetName() to be const we are saying that GetName will not change the value of this Monkey instance. I can now call GetName() on constant monkeys.

Great! Too bad in won't compile...

MonkeyHouse's getMonkey( const string &name ); method returns a Monkey*. The implementation will look a lot like this:

Monkey * MonkeyHouse::getMonkey( const string &name ) {
   return myMonkeys[ name ];
}

But remember, myMonkeys[name] is a const Monkey*! We need to change the method signature to:

const Monkey * GetMonkey( const string &name );

Now call me crazy, but just for this toy example, that's an AWFUL lot of work to add some safety. Imagine having to do this in a large, 5th generation, production level desktop application! So my plea to all you developers out there, C++ or not, STOP BEING LAZY. Pay attention to your own work. Excersize your right to say "NO! You can't change this value, and NO! I won't change yours." It's only five little letters and a whitespace token. It's not difficult, and I won't feel the need to hunt you down later.

As a follow up to yesterday's post about using intermediate datastructures, I wanted to add some concrete numbers to my Big-Oh runtime statements.

I came in to work this morning and got my hands on what I thought was a relatively large sample set of data, and setup an operation that would populate an array with 2000 items, and them "keep" items from an array with 350 elements. The result was that 300 elements were left in my array.

The original alorithm I had to work with was as follows:

keep( source, keepers ) {
  for each element S in source
    found = false;

    for each element K in keepers
      if ( S == K ) found = true; break;

    if ( not found )
      delete S from source
}

So source is size 2000, keepers is size 350, and I know from observation that I'm going to delete (2000-300) elements from source. The overall (worst-case) runtime then is 2000 * 350 + 2000 * 1650 = 4,000,000 steps!

My re-implementation using intermediate datastuctures looks roughly like this:

keep( source, keepers ) {
  Populate set S(s) with elements of source
  Populate set S(k) with elements of keepers

  for each element E in source
    if ( E is not found in S(k) )
      remove E from S(s)

  Reset source array to be empty with size length(S(s))
  Copy contents of S(s) into source
}

The runtime here then is: 2000log(2000) + 350log(350) + 2000*log(350) + 1650 = 43,625 steps.

Now in my book, 43625 if significantly fewer steps than 4,000,000. But let's face it, when your average user is running well over 2 billion cycles a second, and you're talking about arrays of pointers, four million operations is nothing :-\.

I guess it's time to hunt for a much larger supply of data :-\

It never ceases to amaze me the drastic impact our choice of datastructures has on application performance, and how little thought many developers seem to give it. I was charged with the task of optimizing a specific feature of our application at work this week involving set logic -- since set logic is so common and well defined, I was nervous that there'd be little improvement to be had short of optimizing how the data in question was physically stored. Much to my horror, I found several blocks of code that did something like this:

void ( CObArray &aryObjects1, CObArray &aryObjects2) 
{
  int i, j;

  for ( i = aryObjects1.GetSize() - 1; i >= 0; i-- ) 
  {
     CObject * obj1 = aryObjects1.GetAt(i);

     for ( j = aryObjects2.GetSize() - 1; j >= 0; j-- ) 
     {
        CObject * obj2 = aryObjects2.GetAt(j);
        if ( obj1 == obj2 ) 
        {
           // do something
        }
     }
  }
}

So right off the bat I have two major complaints:

1. Who picks arrays to perform set logic? Especially a CObArray -- use a SET CLASS for SET LOGIC, I BEG OF YOU.
2. Why are we looping backwards? There's nothing wrong with it, but it's much more intuitive to start with 0 and work up.

Lets be more concrete though and talk about the specific method I worked on first -- set difference. The method takes 2 CObArray instances, and removes all occurrances of items in the first from the second. The do something block above then, looked like this:

delete obj2;
aryObjects2.RemoveAt( j );

While this seems innocent enough, that CObArray::RemoveAt(int) call just bumped your runtime from a horrendous O( n^2 ) to an even worse O( n^3 )!! Remember, this is an array, not a list - therefore deletion time is O( n )...

My immediate though was to just swap out the datastructure for something better, like a set, but as I found out, you can't always come into production code and start swapping out structures. There were thousands of places in the application that relied on this array being a CObArray instance :-\. So I decided to make use of an intermediate datastructure to optimize the task at hand.

The STL provides a number of template classes implementing various datastructures. I'll show you my re-write first, and then we'll discuss it's subtletees:

struct MyComparator 
{
   bool operator()( CObject* obj1, CObject* obj2 ) 
   {
      return obj1->Compare(obj2) < 0;
   }
}

typedef std::set< CObject*, MyComparator > ObjectSet

// Removes all objects occurring in aryObjects1 from 
// aryObjects2 in O( n * log(n) ) time.
void RemoveAll( CObArray &aryObjects1, 
                CObArray &aryObjects2 ) 
{
   ObjectSet myset;

   for ( int i = 0; i < aryObjects2.GetSize(); ++i ) 
   {
      myset.insert( aryObjects2.GetAt(i) );
   }

   ObjectSet::iterator itr;
   for ( int j = 0; j < aryObjects1.GetSize(); ++j ) 
   {
      itr = myset.find( aryObjects1.GetAt( j ) );

      if ( itr != myset.end() ) {
         delete *itr;
         myset.erase(itr);
      }
   }

   aryObjects2.RemoveAll();
   aryObjects2.SetSize( myset.size() );

   int i = 0;
   for ( itr = myset.begin(); 
         itr != myset.end(); 
         itr++ ) 
   {
      aryObjects2.SetAt( i++, *itr );
   }
}

It works by first creating a set with all the elements from aryObjects2. This takes O(n logn) time. I then iterator aryObjects1, searching for each item in the set I just built. This takes O(logn) per lookup. If I found the item, then I delete it from the set, which is a O(logn) operation as well. The final step is to copy the items from the set back into the target array. Note that I allocate the memory space all at once to avoid having to reallocate and copy the array items each time it grows.

This last point can cause major problems for you as well. I used a technique similar to this one to optimize an AddAll method as well -- the add all had an O( n^3 ) loop to detect duplicates, and then at the end did something like this:

aryObjects1.RemoveAll();

for ( int j = 0; j < aryTemp.GetSize(); j++ ) {
	aryObjects.Add( aryTemp.GetAt(i) );
}

While this looks like a O(n) on the surface, my handy debugger showed me that it was actually "growing" the array one insert at a time -- so for each insert, it allocated new memory space, copied the entire array over, and then inserted the item. That's O(n^2)! By simply realizing that we already knew how big the array was going to be, and statically allocating it up front, we can eliminate an order of magnitude from the runtime (that one's for you, Doug ;))!

So by simply introducing an intermediate datastructure to perform a specific task, you can greatly improve your runtime performance, while not having to recode for a new datastructure.

I recently posted a link to Bjorne Stroustrup's C++ FAQ, in which he points out that the value of:

int i = 2
int j = i++ + i++

is undefined. I decided to throw together a couple little sample problems to see just what it would do. My toy program looks like this:

#include <iostream>

using namespace std;

int main( int argc, char ** argv ) {
	int i = 2;
	int j = <expr1> + <expr2>;

	cout << j << endl;
}

Where expr1 and expr2 are either i++ or ++i. So for instance, when I throw in

int j = i++ + i++

I would expect j to take on a value of 5 -- since i is initially 2, the first i++ would evaluate to 2 and assign a value of 3 to i. The second i++ then evaluates to 3 and assigns a value of 4 to i. The results were, as expected, not what I would expect. The following table summarizes the combination of i++'s and ++i's, what I would evaluate it to in my head, and what actually happened:

Expr 1	Expr 2	Expected j	Actual j	i
++i	i++	6	6	4
i++	++i	6	6	4
i++	i++	5	4	4
++i	++i	7	8	4

As you can see, when we mix ++i and i++, things seem to evaluate as expected, however i++ + i++ and ++i + ++i are incorrect. As B.S. points out in his FAQ, this behavior is due to the fact that the order of evaluation of expressions is undefined. So when we do i++ + i++, there is no garuantee that expressions are evaluated left to right, and there is no garuantee that the ++ operators will be evaluated before the addition operation (even though, interestingly enough, ++ has a higher precendence than +)

Bjarne's answer to this nasty "problem"? Just don't do it. Expressions like this are confusing anyway, and simple enough to avoid.

That's right, a C++ FAQ by Bjarne Stroustrup himself (what did you think BS meant?) I ran across this faq this morning while googling for the forgotten name of the famed designer of C++.

This is easily the most interesting C++ FAQ I've ever come across, with interesting tidbits about why there's both pointers and references and C++ (turns out he only kept pointers in the language to maintain C compatibility), dispelling the commonly taught myth that "friend" access violates encapsulation, why you should stop using macros, and my favorite, "char" is NOT pronounced "KAR" as in "character", the "ch" is pronounced like it is in "cheese".

Definitely worth the read, even for you veteran C++'ers

How many times in the recent past have you written a method and not performed some sort of validation on your input parameters (i.e., null check, range check, etc)? I ran across a pathetic example of this while browsing Clarkson's news site this morning... here's a screen shot from normal usage:

As you can see, the view.php script expects at least one parameter, "id". I had hopes that removing the parameter would do something cool, like show me a list of artcles to choose from, but I was sadly mistaken:

As you can see, the author of this script doesn't even bother to make sure a parameter is provided before using it! This is especially critical in web applications where your parameters are exposed to mangling by the users. Never trust that data is there; always check. Aside from the fact that it just provides a very unprofessional feel to your application to see a screen such as above, you never know what kind of security holes you may be opening yourself up to by not paying attention!

Justin Williams over at Mac Zealots posted an article back in April about the various development technologies that ship in OS X Tiger, called Max OS X Tiger: For Developers. He gives a great overview of the platform and why it is, indeed, a developer's paradise.

In addition to the tools and technologies that come with OS X, I also use Ximian's Mono Project for C# development and Java 1.5 Tiger (OS X still ships with 1.4.2, but you can get 1.5 from apple here).

As for development environments, I'm primarily using Apple's XCode 2 nowadays. C# development is best done in using MonoDevelop, which runs using GTK# under X11. Installation can be a little tricky, Brian Jepson provides instructions here. For Java development, I love JetBrain's IDEA, but it's not free (as in speech or beer); but for it's features and stability, I think it's worth the price; I own a license for IDEA 4.5, and IDEA 5.0 was just recently released. Of course for you Unix freaks there's always trusty vi and emacs.

Most popular open source databases are available for OS X as well, Mark Liyanage has assembled native OS X installation packages for MySQL and PostgreSQL

For you web developers, OS X ships with Apache 1.3.3 with mod_php (version 4), mod_perl and mod_dav. You can get mod php 5 from Mark Liyanage as well. You can install Apache 2 using a package management tool like Fink. Tomcat 5.0 and 5.5 run on OS X as well under Java 1.4.2 and 1.5 respecitvely. For something more robust in the Java world, there's also JBoss.

Finally, most (if not all) of your favorite project management tools work for OS X as well, including Ant, make, Maven, CVS, and Subversion.

So all in all, you really can't miss as a developer on the OS X platform; and since it's a BSD at heart you'll have virtually no work to do in porting existing projects... It's what drove me to make the switch back in 2002, and I've never looked back.

I had read something a while ago about a design pattern called Inversion of Control (IoC), which came back to me this morning as I was working. I looked it up on Google and found a decent overview of the pattern, and wanted to share it: IoC Article

The basic jist of IoC is that if your class needs an object that is outside of its primary responsibilities, it should not instantiate it itself, but rather should accept that object either in a constructor or with a setter method. This writeup uses a database object manager for it's example, however a more common example is logging. I'd be willing to bet that at the top of most Java Code with logging, you'd see a line that looks like this:

private final static Logger LOG = Logger.getLogger( myclass.class );

And then the rest of the methods in that class use the LOG instance. IoC says that it is NOT your class' responsibility to instantiate a logger, and therefor should be passed one instead.

Some benefits to doing this:

1. It ties in well with Test-First programming, as it helps to minimize the amount of setup needed in your testcases. In the case of logging, it means that you can pass in a "dummy" Log implementation rather than configuring a Log4J runtime.
2. It allows us to log based on "use-cases" rather than at a functional level. Take for instance the core/Reports framework. Every class in core/Reports right now has it's own logger, but in general, I only use 2 or 3 of the classes in the package (t he classes which expose the high-level functionality of the framework). If I implemented IoC with respect to Logging in core/Reports, I'd probably only have 2 distinct Log instances in the entire package, making it a) easy to configure logging for core/re ports and b) easy to identify flow-of-control in the logging output.
3. It minimizes the amount of work we need to do when we all of a sudden decide we want to, say, drop in commons-logging rather than use Log4J directly :).

IoC happens to be very easy to re-factor in, here's an example of how that would be done without breaking compatibility:

Existing Class:

public Class Foo { private final static Logger LOG = Logger.getLogger( Foo.class ); public Foo() { // Initialize the class here. } ... }

Refactored class:

public Class Foo {
    private Logger LOG = null;

    public Foo() {
	// Default constructor creates a logger so 
	// as to not break any existing code.
        this( Logger.getLogger( Foo.class ) );    
    }

    /**
     * New usages of Foo should use this class 
     * instead, passing in a Logger instance.
     */
    public Foo( Logger log ) {        
        // Initialize the class here.
        this.LOG = log;
    }

    public void setLogger( Logger log ) {
        this.LOG = log;
    }
}

You should really take the time at this point to find usages of the "old" constructor, update them to usages of the new constructor, and remove the old constructor. This may not be very easy to accomplish, especially when you're refactoring libraries.. . The refactoring shown above guarantees that no current usages of your code will break. New code, however, should implement IoC and NOT give users the option of using a Default logger, as follows:

New Class:

public Class NewFoo {
    private Logger LOG = null;

    // Explicitly remove the ability of constructing 
    // this class w/o a logger. This prevents outside 
    // instantiations, and subclasses of this class 
    // from doing this.
    private NewFoo() {
    }

    public NewFoo( Logger log ) {
        this.LOG = log;
    }
}

I left off yesterday in my Python series having shown you the very basic language elements. Today, we're going to expand on that a little bit by introducing modules and packages, as well as making a Hello, World! CGI script.

Each Python source file is a Python module. The module's name is the name of the source file (without its extension), and the attributes, methods, and classes of that module are defined by the contents of the source file. Modules access other modules by 'importing' them -- which I'll show you below. To any of you with a Java background, this is extremely similar to Java's 'import' statement being used to identify the other classes that a Java class uses.

Before we get to that though, there's another very important point about Python. Everything is an object. Now I'm sure you've heard that before about other languages, such as Java (commonly - and incorrectly - described as a 'purely-object oriented language') -- but it's true this time. As such, a module is an object. When you import a module, you are actually instantiating a module object bound to a variable with the same name as the module. That module object has the attributes and methods defined in the corresponding source file; and you access them as you would attributes and methods of any first class object.

So here we go, let's jump right into the CGI Hello World example to show you the CGI module, and then we'll talk about the CGI module below.

#!/usr/bin/env python
import cgi

field = cgi.FieldStorage()
print "Content-Type: text/plain\n\n"
print 'Hello, world!\n'
print "You submitted the following values in your query string:"
for x in field.keys():
        print "\t" + x + " : " + field[ x ].value 

Save this file as helloworld.cgi, and save it to your web server's cgi-bin directory, and run it... see what happens! It's very simple, almost embarrassingly so, but it serves our purpose. It says Hello, world!' and then prints a list of all the request parameters.

You can see the results of this script here

The #!/usr/bin/env python directive in the first line causes the CGI script to be interpreted by the Python environment. If we were executing the script directly, using python helloworld.cgi, we wouldn't even need this, but it's there for the web server, so it knows what to do with the CGI script when it executes.

The CGI module, importing in the second line, is very simple to use. As you can see, the CGI module defines the FieldStorage object (we haven't talked about object oriented programming in Python yet, that'll be my next post... for now, think of FieldStorage as a function that returns a dictionary... ofcourse functions are objects too, you know.) When the FieldStorage object is initialized, it parses the CGI request string, and populates itself as a dictionary of key=value pairs from it. The CGI module hides the request method (GET or POST) from you, and parses either type of request.

The print method writes out what is interpreted as the response by the web server. Easy :). So that's all you really need to start writing dynamic html using Python and CGI.

The only other thing in the CGI module is a function called 'escape'. It takes a string, and returns a copy of it after replacing all occurrences of '&', '<', and '>' with the corresponding HTML character '&', '<', and '>'

Well I've said once or twice that I've finally taken up learning Python... so far I'm really impressed with the language, although I'm not overly familiar with it yet. Since the purpose of my site was originally to post tutorials about the things that I'm learning -- you'll all get to learn Python with me. This serves the dual purpose of getting my site back on track as a technology and programming blog, as it was originally intended... unfortuantely since I completed my M.S. (effectively ending my J2EE research for the time being), this site has become a place to post about my cat. And I know none of you want to read about that.

So back to basics -- today I wrote my first CGI Hello World in Python. I'll go over the very basics of the language here and show a regular Hello, World! example, as well as some other code examples to illustrate some basics. Sorry to all you Planet Cosiites who already know this stuff.

The first major point about the Python language is that it is not freeform. Coming from the freeform world C/C++/Java i thought this would be annoying and inconveniencing, but it's actually very natural and elegant. The statement delimiter (";" in C/C++/Java) is a line-break in Python, and code-blocks are identified by their indentation. I think this is great -- especially for new programmers; there's no "remembering the semicolon" or getting lost finding the semi-colon in multi-line statements; and it forces you to tab your code. As a former TA of Software Engineering at Clarkson -- I can attest to the fact that one of the most common mistakes in new-programmers is forgetting that damn statement-delimeter... and when they do remember it, their style is typically non-existent (left-aligned all the way... it's like they're using MS Word as a code-editor...).

The next thing to know about Python is that the language is dynamically typed, and strictly typed. This means that a variable's datatype is determined at runtime by its value; and that an objects type can not be changed. To give examples of other languages: C, C++, and Java are statically typed languages* -- a variables type is declared explicitly in the source. VB is not strictly typed, meaning that when you declare a variable intending to use it as a string, you can also use it as an int, or any other type, without casting.

* Yeah yeah, object-oriented languages support dynamic typing through polymorphism.... but we're keeping it simple here, k?

So without further ado, my hello world :)

def sayHi( name ):
	print "Hello, " + str( name ) + "!"

sayHi( "Derf" )

def name declares a function called name. The parameter list is required, but may be empty; notice that the type of the name variable is not declared, that's because it's dynamically typed. The str( x ) function that you see takes any object, and makes a string out of it. This example would still work great without using str, but if I were to do something stupid and pass an integer type in, I'd get a runtime exception for trying to use the + operator on mixed types. The code outside of the method declarations is the "main" part of the program. This is analogous to writing the "main" method of a C or C++ program.

So that's the very very basics. One more thing about the language for today, some basic data structures: lists and maps; Python has amazing built in support for these data structures. Since this isn't an intro-to-programming tutorial, I'm just going to show some basic examples of how to use lists and maps, and also show you method delcarations and some basic looping, without the fuss:

def createList():
	mylist = []
	for x in range(10):
		mylist += [ x ]

	return mylist

def createMap():
	mymap = {}
	for x in createList():
		mymap[x]=x*x

squares = createMap()
for x in squares.keys():
	print str(x) + ": " + str( squares[x] )

When this program is run, the output is as follows:

Timothy-Fanellis-Computer:~ timfanelli$ python test.py
0: 0
1: 1
2: 4
3: 9
4: 16
5: 25
6: 36
7: 49
8: 64
9: 81
Timothy-Fanellis-Computer:~ timfanelli$ 

Note that the function's return type is also dynamically typed... you can return anything you want from a function; and what you return determines its type. the createList method returns a list, therefore I can can use it as shown in the createMap method as a list... Now me, I've always been a stickler for being explicit -- I like declaring types statically; however I have to say, I'd almost prefer having meaningful names for methods that imply their type. I'm still kind of torn on this issue... Maybe I'll post a commentary about it separately.

So there you have it, my very brief, overly simplified, intro to python. This originally started as my "Hello World, CGI" post, but it's gotten kind of long winded. I'm going to end this one here and start a new one. Hopefully this will be the start of a long-running Python series for developers interested in getting started with the language.

So I ran across an article not too long ago, can't remember where, it was one of those things that just gets passed around, about the importance of try/catch/finally... and how the finally block is executed no matter how the controlling block is terminated. So I put together a toy example to test something out, and thought it was a little cool. Consider the following java method:

public boolean trytest( final int x ) {
     switch( x ) {
          case 0:
                try { return true; }
                finally { break; }
          default:
                return true;
     }
     return false;
}

Now if you were to call this method and pass it 0, what would happen is the try block would return true. Since the controlling block exited, the finally block is hit and the break statement executes, dropping control out of the switch statement so that the return false line statement is executed. The method returns false.

So there ya go. Be careful what you do in your finally's; you can easily override the behavios of your try if you're not paying attention.

A while ago I had posted an article about the Anonymous Abstract Factory Pattern - an adaptation of the Abstract Factory Pattern that takes advantage of anonymous class loading in Java. Well I've finally got around to pulling the framework for that pattern out of the jETIA source tree, so I CPL'd it and am making it available here: AnonymousAbstractFactory-1.0.0.tar.bz2.

Please let me know if you're interested in working on the project. I'd love to get a couple developers working on it, adding features such as support for factory constructors, configurable factories, and a few other features. If I get a couple people who are interested, I'll set up an SVN repository for the project and we'll start making plans. Sorry for the minimal documentation, I'll work on that as well.

So since I'm bored, unemployed, and spending a lot of time goofin around with my websites, I thought it'd be fun to write a little RSS parsing utility so I could put together a toy RSS Aggregator site (yeah yeah yeah, it's been done, I know... but where's the learning experience in using someone else's code?). So what I've done is to write a class that extends org.xml.sax.helpers.DefaultHandler to be my callback handler for RSS2 XML streams. In this class, I use the characters method to handle text (as you're supposed to). It appears, however, that there are "special" characters in the XML stream that either break the input, or cause '?' characters to appear in my output.

By "special" characters in the XML stream, I mean character codes like &#8216, which is supposed to be an opening single quotation mark. This appears as a '?' in the output. My first inclination is that it must have something to do with the character encoding of the input stream (in this case, "UTF-8"). Shouldn't the XML Parser be able to tell this though and handle it automatically? If not, how do I get around it? Perhaps it's not a character encoding issue at all -- does anyone have any other ideas?

Please leave comments!

UPDATE: Turns out the problem was not in the input, but rather in the output! My terminal shell was not set to recognize the UTF8 character set, and was therefore drawing '?' symbols for unrecognized character codes -- and the JSP I was using to test it wasn't setting the content-type properly, and my browser doesn't default to UTF-8 either. Thanks to those of you who got back to me, both in comments and via email.

A factory is an object that creates instances or related types of objects. An abstract factory provides the interface that factory objects implement, as well as a method return a concrete factory implementation. For example, jETIA contains an Abstract DAO Factory that defines abstract methods to get different types of data access objects, and a static method to obtain a concrete instance of a DAO Factory.

In the abstract factory pattern as described in "Design Patterns", the Abstract Factory's static method to obtain a concrete factory instance would take a parameter identifying the type of concrete factory to return, and instantiate the appropriate sub-class of itself to satisfy the request. This hard coded knowledge of the available types of concrete factories makes it difficult to supply new types of factories later.

The Abstract Anonymous Factory is an adaptation of the abstract factory pattern that takes advantage of the anonymous class loading abilities of the Java runtime environment. Instead of explicitly telling the Abstract Factory about each type of Factory, the Abstract Anonymous Factory reads information about the types of concrete factories from a configuration file. The anonymous abstract factory then asks the runtime environment to find the class by name, and instantiate it.

Using this method, to add support for a new type of factory, the developer must implement the objects that are created by the concrete factory, create a new concrete subclass of the abstract anonymous factory, and modify a configuration file that is read dynamically at runtime. There is no need to recompile any of the code to deploy a new factory.

To help illustrate this concept, consider the sequence diagram shown the figure below. It depicts the sequence of events that occur when an application needs to use a Widget. In order to support a wide variety of widgets, an abstract anonymous widget factory is used. As you can see, the client obtains a concrete widget factory from the abstract anonymous widget factory. The configuration file is read to determine what types of widget factories are available, and in this instance, since no particular type is specified, the name of the default widget factory to use.

This is why the factory is referred to as "anonymous." Neither the client application nor the abstract factory has any advanced knowledge of the type of factory to instantiate. Since the concrete widget factory implements a known interface, it can be instantiated as a generic Object instance, and then cast to the appropriate interface type.

So I tested my client tools for the first time on a Windows XP platform the other day. The system was a clean install running JDK 1.4.2_03 -- and to my horror, my JTabbedPane looked horrendous; here's how it went down... I have a class that extends JFrame, called MainFrame, and MainFrame's constructor looks something like this:

public class MainFrame
{
   public MainFrame()
   {
      JPanel panel = new JTabbedPane( ... );
      ...
      this.setContentPane( panel );
   }
}

Now, on the Mac and Linux platforms, there is absolutely no issue with this. Everything works great. However, on the windows platform, everytime the panel had to be redrawn, the tabs would be shifted, skewed, missing, duplicated, and other strange sorts of things. It was very strange indeed.

Simple fix:

public class MainFrame
{
   public MainFrame()
   {
      JPanel tabPanel = new JTabbedPane( ... );
      ...
      JPanel panel = new JPanel( new BorderLayout(), true );
      panel.add( tabPanel );
      this.setContentPane( panel );
   }
}

So it seems that the JDK1.4.2_03 on Windows isn't double buffering their JTabbedPane. Hopefully this will be resolved soon. Do any of you know where I could submit a bug report to sun? :).