Auto-unboxing hazard -- the three states of Boolean: TRUE, FALSE, and...

What do you say about the following code:

boolean isActive = (Boolean) pageContext.getAttribute(IS_ACTIVE);
if(isActive) {
// dosomething
}

If you are worried about the casting to Boolean in case where attribute IS_ACTIVE doesn't exist, don't worry, it's OK to cast null to any type, null stays null.

So, is it OK?

Well, no. The problem is with the auto-unboxing to primitive type boolean, which throws NullPointerException if the Boolean is null. Which is a bit hidden from the programmer who might miss this hazard when writing the code.

How should we fix it?

Is the following a decent fix:

Boolean isActive = (Boolean) pageContext.getAttribute(IS_ACTIVE);
if(isActive) {
// dosomething
}

If you ask "what's the fix?" - we turned the variable isActive to be Boolean rather than boolean. Which should eliminate any NullPointerException on the first line! But only in order to pass the exact same NullPointerException into the 'if'...

So, what about:

Boolean isActive = (Boolean) pageContext.getAttribute(IS_ACTIVE);
if(isActive.booleanValue()) {
// dosomething
}

Yes, you are right, same NullPointerException. Maybe now even more explicit.

We could go with:

Boolean isActive = (Boolean) pageContext.getAttribute(IS_ACTIVE);
if(isActive != null && isActive) {
// dosomething
}

But I believe this looks better:

Boolean isActive = (Boolean) pageContext.getAttribute(IS_ACTIVE);
if(Boolean.TRUE.equals(isActive)) {
// dosomething
}

Frameworks -- Explicit and Implicit Wiring

In any new project, there is that moment when you are reflecting whether a group of classes belong to the package "core" or "utils" or "framework", or whether you need all these three altogether.

The difference between utils, framework and core should be simple. Utils are the basic functions needed by everyone, mostly unrelated to this specific project. They are all stateless by definition, simple input and output, with no dependency with the project's structures. Utils can always be easily tested as stand alone. Core is the basic stuff. The stuff you would direct a new developer to learn first. It is project specific. It may include the basic types relevant for this project, interfaces, enums, project's basic exceptions, etc. Make sure to avoid making it a trash can. It's not the address for things without a context.

Framework is the tricky one of all three. As opposed to "utils", the role of "framework" as suggested by its name is more complex. A framework is a piece of behavior interacting with other code to represent a real, concrete, runtime behavior. Usually, even if built specifically for this project, it has some generic characteristics, it is written in a way that could be extended, or used in the future in other ways that we don't see currently. For this we use design patterns like strategy, command, visitor, and in fact almost any that you can think of, to create some kind of "dynamic behavior", or "dynamic wiring". Which means that the framework describes a behavior, but not entirely, only an exact usage can describe an end-to-end scenario. This is why frameworks are best explained with an example (while utils can be explained by what they simply do).

There are good frameworks and bad ones. EJB in its first versions for example was horrible (some don't like it till today, a first bad impression is hard to fix). JDBC is a good framework. Java-Servlets is a good framework. What makes good frameworks good is that people find them easy to use, they save development time compared to other alternatives, and you would usually find over time very few versions of the same good framework (and the new versions would be fully compatible with old code). Of course the question is how to achieve this simplicity, real contribution and long-run future compatibility.

When designing and implementing a framework, occasionally you want to make life easier for the user by doing something automatic for him, let's say pass the value of some field into another field with a relevant name convention -- thus the user doesn't have to write a single line of code! There is this trick in the framework which does it for him. Let's call it "implicit wiring". Alternatively, you may expose to the user a way to acquire the value and require him to pass it explicitly by writing his own code. Let's call it "explicit wiring".

In some cases the difference is not so obvious. Suppose you have a controller which may implement many kinds of behavior, if not implemented then a default behavior is used by the framework. When the number of different behaviors of this controller start to inflate, things become a bit obscure, unreadable, thus maybe "implicit". A better approach would be to break the controller to different interfaces and allow the user to implement the interfaces representing the relevant behavior for him, thus checked by the compiler that no method is accidentally left out, more readable and "explicit".

This discussion came out recently with my team member Effie.
We had a reference between two UI elements: "table" and "toolbar". I suggested that if "table" doesn't declare on its referenced counterpart "toolbar" then we will assume by default that it relates to a toolbar with some predefined name (e.g. "toolbar"). That way, I said, even if the user forgot to give a name for his toolbar, things would work nicely.

Effie's reaction was a bit frightening. (Well, not for someone who knows him). It is common in our work environment that a worker shouts at his boss. Which happened in this case. "I'm not working this way, if you want such a framework leave me out of it", was the part I can quote. Of course when he chilled out came the explanation. Implicit wiring is the base of all framework sins. I like such semi-emotional semi-professional reactions! And he was totally right. Think of someone trying to understand how the framework connects a toolbar to a table. And if he wants to add now another table and toolbar how can he do it? True, there is still the explicit way of referencing by name, but once I entered the implicit way, most cases would be using the implicit format which makes the explicit less known and less documented in examples. Also, implicit wiring tends to break over time, as at some point it may collide with something else and break old code. On the other hand, if you allow only the explicit way, all examples would present the explicit way, code would be always more simple to understand and maintain, and less prone for future incompatibilities. Even with the costs of higher efforts in the first implementation, explicit shall win.

Frameworks in their nature do things behind your back. Try to narrow this behavior as much as you can. Make things explicit as much as possible. Less to explain and document and more for your framework future compatibility.

Write? Rewrite? Use? - Thoughts on shaky frameworks

Java is a great language. A great framework, tool, environment, libraries, all of that. From the very beginning the designers of Java thought of almost anything. Well, almost. ResourceBundle didn't support UTF-8 till Java 6! A few bugs were opened on that during the years (4093632 from 1997, 4221013 nicely written, 4749531 begging, 4919638 and 6204853 giving a final attempt, probably missing some). But it took a long time for someone to listen.

Were they drunk those guys? localization with support only for ISO-8859-1? are you nuts?

Yes, you could use escaped unicode (like '\uXXXX'), but it's not readable. Yes, you could use a UTF-8 file and escape your unicode as part of your build process (native2ascii). Some IDEs (netbeans) volunteered to do this automatically for you. But this is still bad.

Luckily for us, in Java 6 you can construct a PropertyResourceBundle with a Reader, thus you can create a Reader based on UTF-8. Or maybe not so luckily? The ResourceBundle.getBundle still works the old way, you cannot ask it to use UTF-8, so they hacked only half way - what the point? (Yes, you can use the Java 6 ResourceBundle.Control class to control the creation of your bundles but it's so lame. I implemented it and it works, but amount of code needed for such a simple task is unreasonable).

Here comes the question: should we use this problematic framework or write our own implementation? After all, it's not rocket science.

Usually I tend to be very careful with suggesting "write your own version of it". Our development instinct is usually seeing the flaws in some existing implementation, convincing our boss that we must write our own new version of it. In many cases our new version misses some important parts that the preexisting implementation already handled. In some cases the drawbacks that we saw in the preexisting code are in fact design decisions required in order to deal with scenarios that we don't think of or ignore and may tackle us later. So when I do see some existing commonly used library I'm very careful before I decide it's not good for me.

I found this suggested implementation. Seem much easier than the way to do that with the bone thrown at us with Java 6.

Still, might be not so bad idea to implement the entire thing, load of resource bundle, by myself. I still hesitate.