Personal opinion on software development in general, development methodologies, tools and best practices in particular

Archive for the ‘Java’ Category

Will Google become the new Sun?

Since Oracle took over Sun a lot of Java community members feared the future of their favourite programming language. And their worst nightmare came true. Oracle started lawsuits against different companies, they postponed the implementation of new language features requested through JSR’s, OpenSolaris is no longer really open source, the JDK based on JRockit is paid, … What’s next? IDE’s that will be paid? …

A lot of Java lovers, me included, hope that a new player will stand up, a new Sun, a company that has at least the same mindset as Sun (open source, community driven, …). In my opinion, Google is the ideal candidate to become the new Sun.

Active in the Java World

First of all Google is already very active in the Java world. They have Google Web Toolkit- a framework to create Rich Internet Applications in pure Java -, Google Collections – a Java library which makes it easier to manipulate collections in a type-safe way -, Google App Engine – a set of services which can be used to deploy your own java based web app on Google’s infrastructure for free, a Google Plugin for Eclipse, Google Project Hosting – supports multiple languages, Java included, Google Java Developer Tools, …

Next to that they have created Android, the most used and fastest growing OS for smartphones and tablets which has an SDK and code syntax that have many similarities with Java.

Mindset, quality and usability

Google’s mindset is very clear, a lot of Apps are available through the Android Market, some of them are paid, some of them are free. You’re free to develop your own Android app and to distribute it on the Android Market. Thanks to the great technology and usability, a lot of smartphones are equipped with Android and the number is still growing!

Google has a lot of products which can be used for free, which are of great quality, have great usability and really add value. It all started with the Search Engine, then GMail was introduced, a complete new way of managing e-mail. A lot of people use Google Adsense, Analytics and/or Adwords for their website. One can create a site easily with Google Sites, make translations with Google Translate, chat with Google talk, browse the internet with Google Chrome, create and edit documents online with Google Docs, easily find files, mails, docs and start programs on your pc with Google Desktop, manage your photo’s with Picasa and find a location with Google Maps… and then I probably forgot a lot of products…

The company culture at Google stimulates innovation and it doesn’t just deliver good products and technology but there’s also a bunch of Google lovers which is very important if you want to have an active community as a company.

Great People

Google doesn’t hire anyone, they look for great people with great minds that fit in their organization.

Google is chock full of ex-Sunites (= ex-Sun employees) like Ron Ten-Hove, Frank Kieviet, Igor Minar, Tor Norbye, Tim Bray, Alex Ruiz, Amanda Waite, Bill Sommerfeld, Ari Shamash, Eric Schmidt, Ken Russell, Chet Haase and Java founder: James Gosling!

Now that James Gosling joined Google, it’s probable that a new Java-like language will arise!

Lawsuits from Oracle

No word yet on what James will be working on, but I wouldn’t be surprised if this job offering is connected to Oracle’s lawsuit against Android. However, I’m sure a vast number of companies were planning on courting Gosling to join their ranks. It’s probably not a coincidence that Gosling has been taking the last year off. It’s possible that he was under a 1-year non-compete contract with Oracle.

Although Oracle likely owns everything that Gosling ever developed at Sun, there may be a way that he can help Google out of its legal wrangling with Oracle. One of his patents (RE38,104) is part of Oracle’s current patent infringement suit. Of course, I’m not saying that Google didn’t also want Gosling’s vast programming expertise and creative mind. I’m sure Google understands that they need to use him as more than just a patent shield – and there’s no guarantee that he could actually deflect any of Oracle’s infringement claims.


Oracle’s CEO Larry Ellison tried to maintain control of OpenOffice by kicking supporters of LibreOffice off the OO Community Council. He was defeated, though, when most of the remaining developers quit the OO project. Losing cash, Oracle decided to give in and free OpenOffice.

More info:

Vaadin: what’s new

It’s been a while since my last blog post about Vaadin. Summertime you know 😉

But Vaadin was still evolving towards an even better framework. I’ll summarize the new fancy features.

Last week I went to a very interesting talk about Android. THe programming language isn’t Java but is very similar to Java. Creating fancy applications seems still a bit difficult but one can only develop webapps of course. Vaadin also has a framework to develop smartphone applications (webapps) called Touchkit.


A lot of people don’t know that you can develop applications for smartphones with Vaadin TouchKit . These applications have an iPhone look and feel but will run on iPhone, iPad and Android.

TouchKit is optimized to run on smartphones so it’s optimized for low low performance and low memory (ROM) devices.

The well known Vaadin sampler, which demonstrates all Vaadin components along with the Java source code, is also available for Vaadin TouchKit:

If you want to know more about TouchKit (who developed it, why, what’s the roadmap,…) you can read these blog posts:

Add-on directory

The add-on directory that was released this year is a marketplace where themes, UI components, tools, data components and miscellaneous add-ons are distributed to the community. Most of them are free, for some of them you’ll need to have a license.

It’s a very good initiative, no need to write a fancy component because there’s a big chance you’ll find it in the add-on directory. Most of the add-ons have a demo site, source code, project homepage, issue tracker and forum attached. But there was 1 shortcoming: maven integration.

Most Java projects are based on Maven, Spring and Hibernate and Vaadin supported all of these. But if you wanted to use an add-on in your project, you had to download the jar and add it to the classpath. Since I use Maven I do not longer like the idea of commiting jar’s in Subversion. So I added a script to SVN which contained the code to install the add-on jar in the local repository. Next I installed it on Nexus and added the dependency to the pom.xml.

But times change and the guys from Vaadin really listen to the community. They know very well that a framework on itself isn’t good enough. Integration with other common used frameworks is a must these days. So the guys set up a Maven repository, add all existing add-ons to it and all newly added add-ons will be automatically added to that repo.

More info about the add-on maven support can be found here. The code that must be added to the pom.xml file is also available on the add-on directory site.  Easy huh?


Another proove of the fact that Vaadin is still evolving are the amount of talks that cover this framework. Joonas Lehtinen, CEO of Vaadin will present on Devoxx on 17/11/2010:

Another more detailed talk about Vaadin will be the success-story of the conversion of Black Belt Factory (aka Java Black Belt) to Vaadin. It’s scheduled on 30/03/2011 in Brussels and is organised by the  Brussels Java User Group (BruJUG).

The talk will take 3h and will be presented by the CEO of Black Belt Factory.

I will attend the talk, and you?


Vaadin, Maven and Spring

Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I’m really in favor of it.

I see a lot of advantages compared to Sun’s Java EE standard front-end framework JSF.

  • First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that’s an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J.
  • Another advantage is the fact that Vaadin is easy to learn (JSF isn’t!) and to use: it’s straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I’m used to.
  • Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure.
  • Vaadin is very well documented. There’s the book of Vaadin wich explains every aspect of the framework very clear. On the site there’s a blog, a FAQ section, a wiki, a forum, examples with Java source code, …
  • It’s very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There’s also an add-on directory where you can download UI components, data components, tools, themes, …

But enough about Vaadin itself. The purpose of this blog post is not to explain Vaadin itself in detail but how to integrate it with other commonly used frameworks: Maven and Spring.

Vaadin comes with a plugin for Netbeans and Eclipse. These plugins provide a wizard which makes the creation of a new Vaadin project, themes and components (also client side) very easy, it even provides a WYSIWYG editor but that’s still experimental.

But as expected (or not) the project structure created by the plugin is not the structure I want because Vaadin uses its own structure which differs from the well known Maven structure. Though this is not a big pain in the ass because Maven integration is extremely easy to accomplish. The easist way is by using Vaadin’s Maven archetype:

mvn archetype:generate

There are also archetypes ‘vaadin-archetype-sample‘ and ‘vaadin-archetype-widget‘. The first one generates a sample Vaadin app and the second one creates a project to illustrate how to create custom GWT widgets (yup Vaadin is based on GWT). Of course the Vaadin library itself can be found in several Maven repo’s. The only shortcoming at the moment is that the add-ons aren’t ‘Mavenized’ yet. You’ll have to download the jar’s manually. But an issue is created fror that and they’re working on it, so it will be there soon.

To enable Spring in a Vaadin app you’ll have to use SpringApplicationServlet as explained here. That’s all.

Since frontend and controller are now written in java, we can inject Spring managed beans into the Vaadin controller classes. Of course we would like to use annotations instead of all those XML config so we would like to make use of the @autowired annotation for example.

To do that we must put the <context:spring-configured /> element in our applicationcontext and enable component scanning by means of the <context:component-scan /> element to scan out controller classes.

The controller classes can be Spring managed by adding the @Component annotation but it sounds acceptable that you don’t want to make some front-end stuff Spring managed. If you don’t want to do that you can use the @Configurable annotation. It marks a class as eligible for Spring-driven configuration.

Now the last thing that needs to be done is AspectJ weaving, otherwise using the injected Services will cause NullPointerExceptions. You could add the maven-aspectj-plugin to enable compile time weaving. The disadvantage of this approach is that you have to do a Maven compile because compiling in the IDE won’t trigger AspectJ weaving.
You could change the project  into a Maven project instead in Eclipse but then everytime you save your file, Maven compilation will be executed and that’s not what we want.

We can use <context:load-time-weaver /> to enable AspectJ load time weaving. This way we don’t have to run a Maven compile to weave. You’ll have to pass spring-agent.jar to the application when running it to make loadtime weaving work. Once this is done, it’s pure AspectJ LTW which can be configured using ‘META-INF/aop.xml’ which is automatically loaded as AspectJ LTW is initialized by <context:load-time-weaver/>. The last step is to pass ‘-javaagent:path/to/aspectjweaver.jar’ to Tomcat’s VM arguments instead of using the aop.xml and load-time-weaver tag.

If you don’t like load time weaving (it makes hot redeployment fail from time to time), you can remove the <context:load-time-weaver> element and the aop.xml file. Instead you can install AJDT plugin for Eclipse. The project will be recognized as an AspectJ project and yhe only thing you need to do is adding spring-agent.jar to the project’s Inpath.

More Vaadin stuff in one of the next blog posts!

Programming antipatterns

Did you ever do a code review where you recorded an extremely high amount of WTF/m? And did you ever wonder what the cause of all this bad code is? Most of the time cause number 1 are the use of design and coding antipatterns.

If you like definitions, here is one: An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context.

Reinventing the wheel
IMO an antipattern of frequent occurrence is the lack of knowing the existence of some useful frameworks/libraries. Apache commons lang and commons collections are dependencies that should be present in every Java project.
You can write your own fancy for loop for filtering or selecting some objects in a collection or you can use…) or CollectionUtils.filter(…).
You can do some fancy not null checks ending up with a huge if-else construction or you can use StringUtils.isNotBlank(…). It’s up to you.

A general rule is not trying to reinvent the wheel. Some people like to write their own Reflection utils while Apache commons beanutils, Spring’s BeanUtils and BeanWrapper will do the trick.

Cargo cult programming
Cargo cult programming is a style of programming in which patterns and methods are used without understanding why. The term “cargo cult”, originally referred to aboriginal religions which grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war.

Most of the time this way of programming is used by unskilled or unexperienced programmers that copy-paste some code from somewhere else.

– adding unnecessary comments to self-explanatory code
– adding deletion code for objects that garbage would have collected automatically with no problem
– creating factories to build simple objects

Coding by exception/Expection handling
Instead of checking for some specific corner case values like null values, some people like to catch a NullPointerException and do some logic in the catch block. This way of coding is called expection handling because the exception is expected to happen.

Exceptions are invented to inform you of the fact that something really bad happened but they’re not meant to be thrown often. That’s why they are called ‘exceptions’. If they occur, please handle them carefully but never abuse them to execute some logic that could have been implemented with a simple if-else check.

Avoiding/swallowing exceptions
Referring to the previous antipattern, when an exception is thrown that means that something unexpected happened. The last thing you should do is swallow these exceptions instead of processing its useful information.

For example, if you have a method that should only return 1 object because you expect it be unique, perfoming a DB query that returns a list of results, checking if the list’s size equals 1 and then performing a query that can only return 1 unique result (if not an exception is thrown). If you’re implementing something like that, it means that it could be possible that the expected object is not unique which means that implementation differs from what the analysis says.

Inheritance hell
Inheritance should be handled with care. It’s very useful but you should only use it what it’s intended for. If the inheritance tree becomes to bloated, something is wrong. Do not write abstract classes for 1 specific case. Use composition instead. The strategy pattern can come in handy here.

For example if your JSF managed bean ‘EditUserManagedBean’ extends AbstractEditingManagedBean which extends AbstractSelectionManagedBean which extends AsbtractParentDetailManagedBean which extends AbstractManagedBean you should know that something is wrong and that there should be other ways to implement this behaviour 😉

Gold plating & Premature optimization
Some people like to enhance their code by continuing to work on it well past the point where the extra effort is adding some value instead of sticking to the requirements. The mistake made here is thinking the end user would be much more delighted to see the additional or enhanced features in the product, than what the user asked for or expected. The user might be disappointed in the results, and the extra effort by the developer might be futile. This process is referred to as gold plating.

Gold plating is related to premature optimization. Premature optimization refers to thinking about possible issues that could arise in the future but that are not the case at this moment. You should only think about what is asked and what is required, not about what eventually could be useful for future purposes. A frequent occuring premature optimization is the premature performance optimization. If there are no preformance issues at this moment, do not try to handle them, handle them when they happen.


Why webapps?

Sometimes I wonder why we are always writing web applications instead of desktop applications. It seems that web applications have a lot of advantages that desktop applications don’t have. But is this really true? Is it because of these so called advantages that most applications are web applications nowadays?

Actually, I don’t know why customers prefer these kind of apps, all I know is that it can be quite frustrating to write them from time to time. First of all you have to know the underlying protocols TCP, IP, HTTP, …) by heart. In fact that’s not really complex but a lot of web frameworks put their specific flow logic on top of that.

JSF for example, Sun’s current web application technology standard: if you do not know the JSF lifecycle by heart, you can spend a lot of hours on fixing stupid bugs which could have been avoided by knowing each part of the lifecycle very well. A common heard complaint is that JSF is just too complex, and I admit, it really is. And wait until you use it together with Spring Webflow, for example to add some extra scopes like page scope, flash scope, flow scope and conversation scope because request scope, session scope and application scope don’t meet your needs. Trying to access JSF’s FacesContext will fail because you need to use Webflow’s ContextHolder. Yet another example of leaky abstractions.

Browser incompatibility
Enough about complexity now, I think I made a point here. Another big disadvantage of web frameworks -maybe the biggest one- is the browser incompatibility. We need to support Internet Explorer (ouch) and firefox in most of the cases and if possible Chrome, Opera and Safari too. The biggest pain in the ass is IE6 -every developer knows that- and still a lot of people and companies use it as their default browser. It has a lot of security problems, doesn’t have tabs, it’s just outdated, but what I hate about it are all the css hacks you need to tackle specific IE6 problems wich can introduce problems in other browsers. Why do customers still ask to support this crappy piece of software? It’s 9 years old! Drop it please!

To solve the browser incompatibility issues a lot of frameworks are created with the aim of letting the programmer only focus on the requirements, the business, the use cases, the functionality, without the need to spend a lot of time and money on fixing these issues. Richfaces, GWT, Wicket, Vaadin, you name it. It’s a rarity but sometimes these frameworks don’t tackle all the browser incompatibility issues very well which means you have to solve it yourself and again, you need to know how the framework works and what it does. So as I said before, the problem of leaky abstractions can never be solved. They will always be there.

Web 2.0 issues
The fact that you sometimes need to fix bugs in those web application frameworks is not the main problem, the real problem is that those bugs are javaScript or css bugs. Ever tried to debug javaScript? Yes there are tools like Firebug but what if the bug does only occur in IE? Good luck! And the web 2.0 evolution makes it even worse, everyone wants Rich Internet Applications (RIA) because they want the rich experience of desktop applications… Why not just writing desktop applications? I guess that would be too easy 😉 Oh and then I’m not talking about the need to install a browser plugin to make these rich features available (Flex for example).

AJAX can do a lot, but again, it’s based on javaScript 😦 It’s not only difficult to debug, it’s a client side scripting language. And what I dislike about client side scripting languages is the absence of compile-time safety, it’s untestable and can not be refactored.
GWT’s aim is very good. Just write Java code which will be compiled to javaScript. You can test, debug and refactor it with ease and there’s compile-time safety.
Wicket drops the need to use and know custom tags (like jsp’s core tags, JSF’s default tags, richfaces tags) and lets you write plain HTML. So the markup is done with HTML while the business logic is done in Java code. Components are added to the view in Javacode too. This code is linked to the html page by means of wicket:id.
But Vaadin goes even further, it’s based on GWT which means that there’s no need to use HTML. LayoutManagers are used to do create complex layouts. IMHO the biggest advantage is that Vaadin has very clear documentation (Book of Vaadin) and provides commercial support, something a lot of companies really want and are willing to pay for.

Model View Controller
It seems that finally the strict MVC pattern is introduced into webapps , something I really missed (I don’t wanna think about Servlets: ‘HTML in Java code’ and plain JSP: ‘Java code in HTML pages’). So it’s a good evolution. The core evolution is bringing all features and richness of desktop applications to the web but still I wonder why we just cannot use desktop applications. It’s less complicated, you don’t need any plugins, you can use plain MVC, there’s no browser incompatility, it’s easy testable, dubuggable and refactorable, there’s compile-time safety, you can use events (loose coupling) you have all features available and you can set it up as a client-server application by means of Java Webstart.


Standards: Pros and cons

It’s widely accepted that it’s a good idea to use standards in software applications. But is this really true?

Let’s take JPA (1.0) vs Hibernate as an example. A lot of people use Hibernate as JPA implementation in their project. The idea is that one can easily switch to another ORM framework that implements JPA.
That sounds as a very good pro but what is the chance that within that specific project another implementation than Hibernate will be used? Why would you want to change?

Standards are made to introduce a general way of working. If you know JPA you don’t have to learn specific implementations like Hibernate, iBATIS or TopLink . That’s true. But what if the standard doesn’t support everything that a specific implementation can do? Will you still use the standard even if you lose some features? In my opinion the answer to that question is definitely ‘no’!

Did you ever try to make use of delete-orphan with JPA? You just can’t do that for the simple reason that it’s not supported by JPA. Solution: use the Hibernate implementation instead.

Another example: Criteria API. You can use Hibernate’s Criteria API for retrieving entities from the DB. It’s not included in JPA. Same for Hibernate Validator. It’s not (yet) included in JPA. So we still use Hibernate specific code.

I know it’s included in JPA 2 but to be honest, how long will it take till a lot of projects will use JPA 2? It can take some time until a new version of some framework will be adopted by a lot of people. The point is that standards seem like a good idea but most of the time not enough features are available at the time the first stable version is released. They’re immature at the moment a lot of people start using them. Which means that the introduction of a lot of standards comes too late.

In my opinion standards can be useful in a long-term project subject to a lot of change like a framework or something similar. But in most of the fixed price software projects an immature standard can be contraproductive instead of generating a lot of added value.

Focus on quality

Why do a lot of people say that testing is a waste of time? Because it takes time to write software tests? Hmm looks kinda strange don’t you think?

Software analysis, design, programming, bugfixing,… are all time consuming activities that are part of the application development process and it’s accepted that those activities take a lot of time so no one ever thinks about skipping them. So why would people skip testing? Because they like bugs? Because they hate visibility? Because they like bad quality?
Oh now I remember, because tests are obsolete and cost time and money. And we’re getting out of time or out of budget so we skip tests. Big mistake!

Tests are also part of the development process! Why? For many reasons!

  • Tests create visibility and a safety net. By writing tests you can pinpoint bugs as soon as possible. And you can fix them as soon as possible.
  • Tests reduce the amount of bugs in new and existing features. Because we see bugs by writing tests, we can fix them and reduce the amount of bugs.
  • Tests allow refactoring. Because there’s a safety net, you can refactor without fear. Tests will be broken if the refactoring failed.
  • Tests reduce the cost of change. Because you see and fix bugs as soon as possible, you don’t introduce extremely long bugfixing phases. The longer the bugfixing phase, the more money that will be spent to fix the bugs. The graph below explains everything.

Most bugs are introduced in the coding phase and this phase is the cheapest one to repair bugs in. So we can conlude that quality is what we should focus on. You can do this by writing enough tests but there are other ways to do it:

  • Don’t overdesign. Of course you should think about the design first but don’t program with the idea that maybe this feature could be useful. A  software application is not meant to exist of several selfmade subframeworks that contain unused features. Thinking about those features and writing them is a waste of time in fact.
  • Design as late as possible. If you write some code, do not think about reuseablity at that moment. Extract the code at the moment you wrote the same code twice.
  • Refactor as much as possible. When time’s ready, refactor code to keep it clear, readable and maintainable. Code duplication is a bad practice.
  • Use tools to track possible bugs. Findbugs and PMD are very useful.
  • Make use of continuous integration. CI will tell you that something will be broken, so if CI is green, you don’t have to bother about it.
  • Do code reviews of each others code. Every developer has an other point of view and will detect bugs and bad coding practices that you didn’t notice because it’s your code.

So if you don’t like to focus on quality but on costs, remember that by focusing on costs, quality won’t improve. No, quality will even be worse, meaning that it will even be more expensive to guarantuee a product without major bugs and thus costs will raise by fixing a lot of bugs at the end of development! If you focus on quality from the beginning, costs will be reduced and quality will even get better.

An easy formula can illustrate this:

So please please if you’re thinking about dropping tests to save money, think again! Focusing on quality is the only way to reduce costs.