Null Creep

I believe it is really important to clearly specify how your classes react to null values. Suppose some class is buried deep in your application code:

public class Company {   private final String id;   private final String name;    public Company(String id, String name) {     this.id = id;     this.name = name;   }    public String getId() {     return id;   }    public boolean equals(Object o) {     // ...hmm...can id be null? Better write some defensive code:     if (id == null) { ... }     ...etc   } }

Perhaps a class like this represents some fundamental concept and is used throughout an entire family of applications. While reviewing the code, you see the equals(...) method checks for a null id. And you wonder…can the id ever be null?

There Must be a Reason

Surely the original programmer put that null check in for a reason. Or maybe not — maybe he generated the equals() and hashCode() methods using an IDE? There are no comments, and you discover everyone using the Company class also checks for null:

public void connectTo(Company c) {   String id = c.getId();   if (id != null) {     ...   } 

Maybe the programmer who wrote that method just wasn’t sure — since Company has no comments. So in an effort to “be safe”, he checks for null before using the company id.

Creeping Dread…

And what do you do if the id really is null? Oh, crap. Now you have to throw an exception, and someone has to eventually catch it. Everything from the data access layer on up to the GUI has to anticipate the possible error.

Because the first programmer failed to document how Company handles null, EVERYBODY who uses the Company class now has to assume the id might be null. The fact that the original programmer included some null checking in the Company class seems to imply that it might indeed be null.

A Better Solution

If null really is allowed, that’s fine — you just need to document that fact. But if null really is illegal, then fail fast:

public class Company {   private final String id;   private final String name;    public Company(String id, String name) {     if (id == null) throw new IllegalArgumentException("null id");     if (name == null) throw new IllegalArgumentException("null name");      this.id = id;     this.name = name;   }   ...etc 

That tiny exception now means everybody using the Company class can eliminate their null checking. Which means instead of potentially checking for null and reacting by throwing NullPointerException from dozens of locations scattered about your app(s), the validation occurs in a single location.

For more fun, check out these @Nullable and @NotNull annotations.

I Have a Stalker!

I’ve probably deleted about 3 comments from this blog due to either extreme profanity or blatantly stupid personal attacks. I think two of those deleted comments were from this guy.

He’s all riled up again and now I’m having some fun with it. Go let him know what you think.

I guess his logic goes something like this:

  • USA SUCKS!

It’s deep, I know.

When Does EJB Make Sense?

Ted says:

If you’re like most Java developers, you heard the term “EJB” and immediately got a note of distaste in your mouth.

Yep, that’s right. The first thing that comes to my mind is…complexity. You never really write EJBs by hand because there is so much duplication and so much configuration. The fact that EJBs (for all practical purposes) require code generation tools (XDoclet, wizards, etc) is a bad sign. He continues:

You know that if you suggest EJB on your next Java project, you will be ridiculed and shamed and made to stand in the corner with the Dunce Cap on, even if it makes complete sense from a technical perspective.

I wouldn’t suggest EJB for the next project. In fact, I’m trying to imagine how it would ever make complete sense from a technical perspective. I cannot think of any reason to advocate EJB.

The paragraph then suggests:

Companies are choosing instead to build their own transactional-oriented client/server middleware infrastructure, just to avoid the “shame” of using EJB. Because, as we all know, you just can’t test EJB.

I don’t think shame has much (if anything) to do with it, nor do I even think testing is that big a deal. Hardly anybody builds transactional infrastructure, although I guess that depends on what you mean by “transactional infrastructure”.

It is damn easy to grab Spring, Tomcat, and a handful of other open source projects to completely replace EJB. Not even a day’s effort. Hell, I recently put together a server-side app using Tomcat and Guice, and the whole “transactional infrastructure” consisted of little more than some ThreadLocal helper classes, a bit of AOP, and a servlet filter. Shame on me for spending a day to build my own infrastructure and be free from EJB for the next several years of maintenance on this project!

I submit to you that my Guice + Servlet project is far easier for humans to comprehend and maintain than any EJB app.

No Shame Here

We do not avoid EJB for “shame”. We avoid EJB because we know how much of a pain EJB is, and we know that thanks to products like Terracotta, for instance, we can duplicate EJB’s feats with far less pain.

EJB is painful because it suffers from accidental complexity. The programming model encourages duplication, and generally forces us to complicate our build procedures by incorporating code generation steps and/or “wizards”. At runtime, it is painful because it promotes a monolithic, gigantic EAR file that makes scaling out to clusters all that much harder. EJB is painful because it locks you in to a particular app server for all but the most trivial apps. It is painful because error messages are so cryptic. It is painful because of classpath woes. It is painful due to slow deployment, and OutOfMemoryErrors when you hot-deploy one to many times.

I feel no shame by advising my friends and customers: avoid EJB. There are better, simpler solutions, free solutions.

On Second Thought…

Maybe I would feel shame if I advised you to use EJB. I guess Ted’s right. I avoid EJB to avoid the shame.

Presidential Race: Bitter Beer

I don’t really watch news, but somehow I catch a lot of it second hand. I may listen to a news station during Opie and Anthony commercials, or read some headlines on the web. Thanks to the way they repeat the “good stuff”, I consider myself informed and up-to-date. Here is what happened in the past few days. Oddly, it’s mostly beer-related.

  1. Obama said some people were bitter.
  2. Hillary and McCain jumped all over that.
  3. Hillary got booed for complaining about Obama’s negative attacks.
  4. Hillary had a beer. And a shot. Obama mentioned the photo-op in a speech.
  5. Oops…turns out Obama had a beer in some bar several months ago.
  6. Some Republican Congressman called Obama “boy”, and then apologized. (was he drunk?)

Bitter Beer

I think that about covers it. I’m ready for my own beer.

New DirecTV PPV Rules

This isn’t really “new” news, but I just noticed this on my DirecTV DVR:

Effective April 15, 2008, DVR recordings of PPV movies will be available for 24 hours of unlimited viewing after purchase. Major movie studios have required that satellite and cable providers alike may no longer allow their customers to view these recordings for longer than 24 hours. During the 24 hour viewing period, you will continue to enjoy all of your DVR features such as pause and rewind.

What a pile of rubbish. You can find their FAQ at this URL:

“http://www.directv.com/DTVAPP/global/contentPage.jsp?assetId=P4540022″

To me, that looks like a URL that will break. So I won’t link to it.

What year is this? Even with old school hand coded Servlets and JSPs, clean public URLs are a piece of cake. Does some programmer really think “contentPage.jsp?assetId=P4540022″ is a good URL? Why not something ending in “ppv/faq/”?

Movies, like music, should be DRM free. And URLs should not expose implementation details.

My E*Trade Experience

I got an E*Trade account a few weeks ago, hoping to buy a stock. As I watched the stock price climb day after day, I waited…and waited…and waited. E*Trade had my money hostage; although the funds were CLEARED and GONE from my checking account, they did not show up at E*Trade. As I discovered, you have to wait five full business days before your transferred funds are available. Shame on me for not understanding the fine print.

So on day four, I decided to open a Scottrade account. I signed on that evening, created the account, transferred some money, and placed the stock purchase order within minutes. The next morning, once the market opened, I had my stock.

It was the NEXT DAY before my money finally showed up on ETrade. So I tried transferring my money out, preparing to close the account. Oops…I received a bizarre “email cannot be confirmed” error. So I called customer support, and they informed me “that’s just a bad error message”. In reality, I have to wait another five days before I can pull my money out.

At long last, about two full weeks after starting down this path, my money is finally out of ETrade. What a joke. A traditional full-service human broker would have been faster, not to mention cheaper, because I could have gotten that stock at the beginning of the week when it was cheaper.

Hopefully this post is useful to someone trying to decide between E*Trade and Scottrade. There is nothing “E” about E*Trade — it is every bit as inefficient as any stodgy old bank.

Killer

I think I found a sure-fire way to identify a product that sucks. Just look for the “killer” claim. For example, Rick Ross says the Nokia iPhone Killer will have Java inside. An “iPhone Killer”? Really? Hmm…

Lest you think this insanity is limited to iPhones…

And it’s not even limited to Apple products. Just do some Googling…

  • Windows killer
  • Rails killer
  • Java killer

I can’t think of an example where the “killer” actually “killed”. The problem is, the market leader became the leader by leapfrogging everyone else with an innovative new product that nobody saw coming. The iPhone was a quantum leap above everything else on the market, and all of these stupid “killer” phones are desperately trying to catch up. So far, nobody even comes close.

If someone really is working on a killer product, you have not heard about it. Not only that, most people probably won’t even recognize it as such, because it will be innovative and new. It’ll storm onto the scene and become the new leader, spawning a whole new generation of “killers”.