When I was in college, I got a copy of NetBeans (a Java IDE) and did some Java projects to see what the language was about. Recently, I found those projects burned onto a CD with a lot of my old files from college. I'd like to think I've learned a thing or two about programming in the interval, so I thought it would be fun to take a look through my old code. I've selected a couple and published them here — unchanged — along with notes on my present day reaction to my student code.

Apparently (from the comments) I used to have a copy of 'Core Java 2.' I wonder where it's gone to. The Bounce project seems to be an exercise from that book, but the code style and comments look like mine. The Solitaire game seems to be original though; that's the only reason I can find for my apparently blissful ignorance of certain basic concepts.

Before I talk about the first project though, let me give you a taste of what you're missing from the others. This snippet is from a simple drawing program:

switch(type){
    case 1:g.drawRect(X,Y,w,h);break;
    case 2:g.fillRect(X,Y,w,h);break;
    case 3:g.drawOval(X,Y,w,h);break;
    case 4:g.fillOval(X,Y,w,h);break;
}

I don't think I really "got" polymorphism yet. :)

Bounce

Bounce is an 'inelastic collision simulator,' which is a fancy way of saying 'completely useless toy.' Take a look at the source file or download the executable jar.

Ooh, bouncing!

Unlike the earlier projects, there are quite a few comments; I seem to have started documenting the intention behind my code. Here are some comments I like:

• "You ever kill a Ball just to watch it die?"
• Error Message: "BallVector.run():Cycle of Life Broken!"
• "call move, then sleep. (A ball is a simple creature.)"

The application is heavily - and pointlessly - multi-threaded. Each Ball is on it's own thread. I assume that's part of the recipe I was following. The simulation isn't accurate; for one thing, it doesn't track angular momentum. It shows a complete disregard for separation of concerns: "Of course the physics simulation acts directly on the sprites location. Of course we bounce directly off the 'walls' of the frame. How else would I do it?"

I've noticed that Java makes it as easy as Visual Basic to embed business logic directly in the UI. At least Java folks have mythic legends of MVC to make them feel guilty about it.

GenericCard

Here's a solitaire game. It seems to be fully functional, with a drag-and-drop interface coded directly on top of mouse events, but god it's ugly. There are several source files:

• CardFrame
• CardPanel
• CardPile
• GenericCard
• PlayingCard

and the executable jar file.

It's more object oriented than I expected from a beginner, but I still had a long way to go. (Still do, I suppose.) For example, there's no separation of concerns between a logic card or deck and the visible objects being displayed.

I notice that I'd already started using the // end block idiom after the } of a long block, which is something I still do. I'm using camelCase; I think I started doing that for these Java projects. In general, this isn't particularly well commented. The style's a little off too:

fileMenu=new JMenu("File");         menuBar.add(fileMenu);

I guess I thought it would be clearer on one line?

I sure went to a lot of trouble to avoid learning how to use images. God, those cards are ugly, aren't they?

One thing that actually is pretty cool is that the scores are computed every 1/10th of a second on a separate thread. I think that's a reasonable design: although the Observer pattern would be cooler, the thread thing is easier, more orthogonal, and has negligible performance impact. (In all fairness, I'm sure I'd never heard of the Observer pattern back then, although I suppose I could have deduced it from all those Listeners Java uses for UI events.)

Words of Wisdom

I don't really have any, except to suggest you go through your own student projects sometime. It's fun. You must see what was before you can see what is. Hey, that actually sounded pretty wise! Maybe I can land a gig writing lines for old men in movies.