Book Review: The Essential Guide to Flex 3 by Charles E. Brown

I am quite interested in RIA, and trying to get in touch with the latest trends in this technology. I decided to start reading something about Flex, but now I think i get a wrong book - "The essential guide to Flex 3" by Charles E. Brown.
I am a java developer and my experience in web application development is good, but this book is aimed mostly to the juniors or below-middle level programmes, also, it's not a book for "corporate" programmers really, it's more a book for small-level sites and home applications.
I really like books, when you develop one application through the whole book, constantly adding new features and refactoring existing code. This book is not of this style. Each chapter uses its own small application, and this application is really small - 2-3 pages (or tabs, or windows) at most.
I also like when programming book has some academic material, such as language syntaxis, or application structure, or design patterns stuff etc. Again, it's not this kind of books.
There good parts also about this book:
- The code in the book is really working
- Some sophisticated topics are discussed (like Drag'n'Drop) in good details
- There's an expanding points, like AIR chapter
- There are instructions about how to use Flex with different server-side technologies - PHP, J2EE, Coldfusion
Finally, here's a link to the book on the Amazon

Why Class<T> is parameterized?

Generics are not an easy concept in the Java language, escpecially when you are dealing with some sofisticated wildcards, but still you can grasp this concept in quite a short time. There's even a more difficult task - understand why the developers of the language choose some implementation over another, or introduced parameters in some classes.
Let's take the Class class. It is not a container, so it is not evident from the first sight, why do we have a parameter here. You start getting "Class is a raw type. References to generic type Class should be parameterized." warnings everywhere, and replacing those Class variable with Class<?> looks no good. So - why did they do it?
The best answer to such questyions is to look at the source code, and find references to the parameter. Almost instantly you'll see, that the newInstance() method returns now T, which gives us a very powerful premise to create object factories with strong typing. Like this:

public static <T> Collection select(Class<T> c, int times) { 
  Collection<T> result = new ArrayList<T>();
  for (int i=0; i<times; i++) { 
    T item = c.newInstance(); 
    result.add(item);
  } 
  return result; 
} 

This example is oversimplified, but you should already see, what a gift we've got here!

Struts 2 Zero Configuration issues

I've been working with a Struts 2 application recently. It's a great framework, escpecially compared to the Struts 1. Some of its features are really catching eye, and on of the is Zero Configuration. You simply add such snippet in you web.xml

<filter>
  <filter-name>
    struts2
  </filter-name>
  <filter-class>
    org.apache.struts2.dispatcher.FilterDispatcher
  </filter-class>
  <init-param>
   <param-name>actionPackages</param-name>
   <param-value>
     com.my.acme.application.action
   </param-value>
  </init-param>
</filter>

and voila - all actions (if they end with Action or implement/extend some Struts 2 classes/interfaces) inside this package are parsed and added to the Struts configuration.
There was one particular action, which I preferred to define in the struts.xml. Sometimes it worked, sometimes didn't. The action class name ended with Action, and this was the source of my problems - sometimes it was recognized by the Zero Configuration, and sometimes - by the Struts 2 XML configuration. The behaviour was not consistent, and I couldn't find exact steps to reproduce the problem, but once I moved the Action to another package it started working properly all the time.

I hope they will fix it sometime in future, and overall, they warn the developers with "Zeror Configuration is an experimantal feature" message, so I will definetely continue keep an eye on this framework

Programming to Interfaces Buy me Something. For sure

Today I've read a post from Ben Northrop - Does Programming to Interfaces Buy Us Anything?

I really understand, that interfaces hurt sometime. And many of us use because of these "reduced coupling, maintainability and testability" features. But there are numerous examples of interfaces usage, which you can dind useful every day:
1) It is very common to switch from JDBC DAO to a Hibernate DAO and conversely, for performance gains, or ad-hoc SQL. Or, from Hibernate to iBATIS, for reporting methods.
2) Though you can generate proxies for classes, they are not easy to test and debug. Let's take a simple ubiquitous example - transactional facade, defined via Spring's interceptor. When you proxy with CGLIB you can end up with stacktrace without source code line information. And you couldn't step through the code, because "source is not found". This can be an IDE limitation, but with interfaces thing are much better.
3) Mock frameworks are not a panacea. Sometimes you need to create mock yourself.
4) Miss F3 in Eclipse for interfaces? Use Ctrl+T!

I can found more practical examples of interface benefits, but they already buy me a lot during my daily work as a developer

Beware of hidden autoboxing features

Not so long ago I was asked on some interview - "Can you provide an example of an assignment operation, which causes a Runtime Exception". I started thinking about different casts, but couldn't find such example (though I passed the interview).
I haven't been working closely with Java 5 at those days. I heard and tried all those enums, generics, extended for and so on, but I haven't used this features in a real project.
Now I am involved in such Java 5 project, and recently I was fighting with some obscure exception, which unidentifiable cause and null stacktrace. It looked like this:
InvocationTargetException caused by NullPointerException: null. As all projects now, we are using all those proxies, CGLIB, interceptors etc, but anyway why no stacktrace??
Finally I found the reason. It was an autoboxing usage. The simplest possible example will look like this:

Boolean b = null;
//do something
boolean a = b;

The comparison operator will throw a NullPointerException. Looks very simple, if you already knew this; and if you run a search query "NullPointerException autoboxing" yuo find numerous results. But if you cannot link this NPE with that autoboxing usage, you can spend a day fighting with it, like I did.