How Do I Hate Struts? Let Me Count The Ways

The more I use Struts, the more I learn to hate it.  Today I was trying to figure out why a particular Java class was throwing a null pointer exception when it executed a particular method.  Had I broken something?  No.  Struts ActionForward scheme is a method for a Java method running on the server to tell the browser what JSP should be loaded next.  In a warped way, it's rather like the evil goto statement--but between two programs running on two computers that don't even have to be on the same planet.  (And yes, I'm serious.  JPL updates software on their space probes via ftp, so if you were really, really warped, you could run a server on a space probe circling Uranus, and have it respond to web requests here on Earth.)

It turns out that the ActionForward scheme looks up where to go next in an XML file--and it is, of course, case sensitive.  And if the code has the wrong case (as was this code written years ago by someone who is no longer present), instead of some sort of useful exception that might give you a clue as to problem, something like UnrecognizedActionNameException, it just throws NullPointerException.

Java, I like. Struts, I detest.

Needed: Senior Java/SQL Engineer

Needed: Senior Java/SQL Engineer

My employer is hiring. Okay, the pay isn't spectacular, but there's not much danger that the State of Idaho is going to go under, nor is there much chance that the Idaho legislature will decide that prisons are a useless luxury. In addition, while those of you on the coasts may be shocked at the pay scales, keep in mind that the cost of living here is very, very low. When I searched for a list of single-family homes in Boise below $100,000, I got 141 listings. Those of you who live in Silicon Valley can move here and buy a house free and clear with the equity in your California home.

In addition, I work with a very nice bunch of people.

Java Question

Java Question

Somewhere in recent history, Java compilers started to spit out warnings when you use unparameterized Vectors. For example:

Vector params = new Vector();

params.add(new Integer(randomValue));

The code works--but from a type safety standpoint, this is dangerous. If you retrieve an item from params, but assume that it is a String, you are risking an exception--and of course, you only find out about it when the code executes--not at compile time. The preferred strategy now is:

Vector<Integer> params = new Vector<Integer>();

params.add(new Integer(randomValue));

This gives you type checking at compile time, and prevents someone who does maintenance on your code from retrieving the wrong type--and not finding out about it until runtime.

However, what happens if there is a legitimate reason to have a multitype Vector? For example, params is a list of parameters to be passed to an SQL stored procedure, some of which are integers, some are strings, some are characters. You can just leave the Vector unparameterized, and ignore (or disable) the warnings.

My thought is that it would be best to define a type that includes all of the types that would be valid in this instance. For example, you know that the only valid object types to add to params are Integer and String. That way, you could get the benefit of type checking at compile time that would allow you to add either Integer or String type objects to the Vector, but not other types.

In C, you would somewhat approximate this with a union. Any ideas how you do this in Java? Or is this really not possible, and I should just leave these multitype Vectors as unparameterized?

UPDATE: One reader says use <object>--the other says use <?>. I'll try on Monday.

UPDATE 2: The answer is <object>. This is still not what I consider optimum--it just shuts up all unparameterized references. It would be much better if you could identify a set of object types that are legal to add to or get from a Vector.

JSP Is So Cool!

JSP Is So Cool!

JSP=Java Server Pages. My new job involves programming JSP. Here's a really well done tutorial I found. The temptation to start programming in JSP in my spare time is very strong.

Eclipse Experts Out There?

Eclipse Experts Out There?

I'm trying to do something that ought to be really simple: tell Eclipse where to find a Java class. I have two classes, in two separate files (as Java generally prefers): ButtonDialog and ContextSensitiveHelp. ContextSensitiveHelp has the main; ContextSensitiveHelp needs to be able to find ButtonDialog class. When I run ContextSensitiveHelp, ClassNotFound exception happens.

Outside of Eclipse, this would be easy: set CLASSPATH to include the directory where both of these classes are located. But this is Eclipse--not so simple, it seems.

I've already discovered that Project->Properties->Java Build Path only tells Eclipse where to look for what to build; it doesn't set the CLASSPATH so that ContextSensitiveHelp can find ButtonDialog at runtime. So Run->Run Configurations takes me to a tab that lets me set the CLASSPATH--but both ContextSensitiveHelp and ButtonDialog are in the same directory. What am I missing?

UPDATE: It appears that the CLASSPATH started finding ButtonDialog after I closed Eclipse and restarted it. This is a bit surprising.

Eclipse: All Your Base Are Belong To Us

Eclipse: All Your Base Are Belong To Us

If you don't recognize "all your base are belong to us"--here's a Wikipedia article about how this fractured English expression became part of the popular culture. And that's about how I feel after banging my head against the Eclipse wall yesterday and this morning. But I did get Eclipse to do the following:

1. Let me update both the application and applet forms of the plotting tool that I wrote about ten years ago, to teach myself Java. The somewhat more demanding type checking of Java 1.6 is now happy with my code.

2. Let me determine the cause of, and fix a couple of minor bugs that have been sitting there this whole time.

3. Let me create the JAR files so that the web pages here and here use the new and improved version.

4. Reminded me how much I learned about OOP and Java after writing this sometimes repulsive piece of dreck. (There's a reason that I am not posting the source.)

There's still an awful lot about the Eclipse user interface that causes me to shake my head and wonder what alien species came up with this, but it does work, and I am sure with time, I will also learn to think of it as my friend.

This, of course, assumes that anyone will hire me. I am beginning to get this discouraged feeling that 51 may not only be too old to work for a startup, it may be too old to work anywhere as a software engineer. I am finding plenty of positions for which I am qualified--but when they find out that I am planning to move there and fly home on the weekends (maybe every other weekend), the reaction is stunned silence.

Fun With Java & Eclipse

Fun With Java & Eclipse

I still find the Eclipse IDE hides a bit more from me than I like, but I am able to get some of the Java that I first compiled and executed with Emacs and the Java compiler building and working under Eclipse. In some cases, I suspect that I was unraveling bugs that I didn't notice, ten years ago. In other cases, Java has become a bit more demanding than it used to be--complaining about coding techniques that aren't typesafe--and I can't argue the point!

The next step will be get the applet version compiling and building.

Integrated Development Environments

Integrated Development Environments

When they are good, they are very, very good. And when they are bad, they are horrible! Microsoft Visual Studio is so nice that it makes me stop looking down my nose at the language specification for C#.

I can't remember what Java IDE almost made me give up on the language ten years ago, but using Eclipse today makes me think it may have been an early version of Eclipse. What an incredibly obscure user interface this is. Yuck! But there is demand for Java engineers who know Eclipse--and I can see why previous Eclipse experience matters--it has a pretty stiff learning curve compared to Visual Studio.

UPDATE: Oh yes, and since I haven't done much Java the last few years, I have to remember all the subtle details. And Java 1.6 seems to be a lot better at giving warnings than Java 1.3. In particular, it used to be completely legal to simplify specify objects as being of type Vector. Now you are apparently supposed to specify the type, much like a C++ template.