One of the few things that lack seriously, IMO, in C# is the power of Java checked exceptions. In Java world? things happen weirdly. Maybe it is a result of crowd intelligence and a bad side effect of open source. Often, people in J2EE world tend to believe the opposite. Anyway you see the effect in most preferred frameworks (such as today’s popular ORMs and Containers) of wrapping checked Java exceptions and rethrowing them as runtime ones.

I guess offering runtime exceptions together with compile time ones did a hole in the Java type system, but this hole was left to discipline, in a way of giving the tools and letting smart enterprise programmers decide for the right tool for the job. Things turned to happen differently in the enterprise world.  Programmers abused of this freedom of choice and mainstream frameworks designers decided to dismiss and bury one of the most interesting features of the Java type system.

Why do I like Java checked exceptions? Well simply because it saves me from surprises. And I tend not to like surprises much!

The funny thing is that, in my experience, it is mostly architects that dismiss Java checked exceptions whereas Compile time exceptions are a very good asset for cleaner and bug free architecture.

I just take a look at a “standard” DAO method that gets an entity

Customer getCustomer(CustomerId id);

This method lies! what if there is no connection? what if the Id is incorrect? The signature of the methods gives quite a promise that under all circumstances it will returns a Customer. Now for any architecture this is bad. It used to be better before some popular frameworks decided to completely omit it! Before? well I used to control my architecture better!

Before these “good practices” become mainstream, imposed in mainstream frameworks, It used to be often more predictable the return type a method has. For my example, the signature would tell me that the method will either return a customer OR throws a “Dao Exception”.

Customer getCustomer(CustomerId id) throws DaoException;

No surprise. Now when I use this method, I will certainly need to handle the case when the method will return something else than a Customer. Now of course, a Java “enterprise developer” could do one of to things:

1- Out of laziness or incompetence, keep rethrowing data access exceptions up until you’ll have to deal with it up in the GUI logic (where handling an infrastructure error does not often belong)

This often sounds for me the main argument for dismissing Java Compile Time Exceptions claiming that it is a “code boilerplate”. The thing is that you’ll have to deal with these exceptions once even when you turn them into runtime. The fact of wrapping them into runtime does not eliminate them (even if I wish it did). But having them as compile time will make easy to spot where a “bad” developer did not handle the exception correctly simply by following the signature and type system. Then the solution will be to wrap them into more business friendly, context meaningful Compile Time Exceptions that need to be handled. This way the contract communicated better the result of executing a piece of logic.

This turns to be as useful for “void” return type methods. With Compile Time Exception a method can simply communicate the fact that it will either return “void” or will throw an exception to be handled.

2- Out of laziness or incompetence, frustrated developers will start “catch”ing checked exception without rethrowing them.

This one is a result of the hole in the type system that is left intentionally to leave some place for flexibility relying on discipline. Nevertheless, and before the big favor of generous frameworks I mentioned earlier, this turned out to be an easy problem to spot. Most IDEs and code analyses tools can find easily empty catch clauses and warn me about them.

I often get surprised of the limited use of Java language wealth in enterprise J2EE applications!

Good thing: C# and .Net are introducing checked exceptions together with other DbC stuff (like non null objects) in the next release. Sad thing: Java has Compile Time Exceptions since version 1, open source chose to unvalue them!

In short, I do believe that Spring framework forced you for a long time to use a subset of Java, a subset of frameworks you use, and has been implicitly very intrusive on all the frameworks that support it. It constrains innovation and limit choices. And more!

Unfortunately I would not be able to list in this post all the arguments I have because of lack of time. I would rather provide few examples that shows why the Spring culture is unacceptable for me. Of course you can reply saying that Spring will support this, or is supporting this starting with version x. Well I am afraid I don’t care. Spring existed for a long time now, and my judgement is based on a long history. Besides what I am targeting is the culture of the framework.

First of all, if you want to use Spring Beans you need to believe in magic. Don’t agree?

class MyServiceClass {
  private IMyDao myDao;
  // Other stuff goes here.
}

this field "myDao" is never initialized, not by any constructor and it is private. But if you believe in magic, then you can use it. Because you know what? There is a wizard config file that you can find if you search enough in your project that will "inject" it. What?!!

First of all this solution violates member visibility rules in Java. But ignoring that, this results in a practice or a habit to ignore a never initialized field believing in magic! A framework that offers and advocates such a violating is not worth even trying IMHO!

Now the suggested solution is to write a setter for this field that then will be used by Spring, but this changes nothing as anyway you will either make it public (allowing any public user of your API to set you DAO!) or put it back private and back to the never initialized field! Did I mention "final" yet? :)

Spring claims that it is not intrusive. What? Now imagine that you remove Spring from your dependencies list, your application is no more useful and you suddenly get null pointer exception everywhere my friend! Who will inject the private field? or a private setter? This claim is ridiculous!

Now did it happen to you to forget to declare or mistype your beans in your config? What happens? Runtime exception! What? I thought Java applications are statically typed!

Now I can hear you, use annotations! Annotations solves your problem! Well I am afraid not. Annotations like @Required or @AutoWired is just like begging the user not delete the field or property, and it is not mandatory and not forced by any checker. Remember, I am talking culture here…

Now if you are a defender of injection using constructors, then I believe you got something right and most probably you reject most of the hacks I mentioned above (Including setters based injection, private field injection,  aspects based injection (in short 80% of what Spring Beans mainly offers and actually does)). But then, you turned anyway your architecture dependency into dynamic, never checked and its composition specified in desperate XML files! Think of code navigability, and software flow and dependencies that you can not trace without the help of a debugger using this approach.

Oh, what about JavaConfig. Well yeah, I do not need Spring to do that! "new", you remember the keyword "new"? yeah OOP, new, instances. That is Java programming. Trust me "new" is no evil, and guess what, you need no dependencies to any framework to resolve your dependencies in a statically checked, navigable, readable, simple, clear, elegant, concise, safe and beautiful way!

Last thing for now, you need to learn Spring-FU to use any, any framework that wasn’t designed specifically for use with Spring and yet you may not succeed (though framework designers are forced to be distracted by Spring design when defining their architecture, for examples see Restlet and Jersey) ! That reminds me of something…

YAGNI!