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

Archive for the ‘Programming’ Category

My quest for awesome css

I was stunned when I discovered the existence of the calc method in CSS. Finally a way to express relative widths!

Instead of tackling the issue of ‘define width as 100% minus some amount of pixels’ by implementing some ugly hacks (javascript or wrapping everything into several divs, also called ‘divitis’) I could finally implement it in a clean way!

By using the calc function in CSS you can write something like calc(100% – 18px).

I added that to my LESS file and LESS seemed to ignore it because it can also handle expressions itself. So the CSS output was calc(82%) 😦

That disappointed but didn’t demotivate me so I continued my quest and I could also fix that – thanks to Google – by finding a way to escape stuff with LESS. Writing calc(~“100% – 18px”) should result in calc(100% – 18px) in CSS.

Uhu, SHOULD indeed! The LESS to CSS compiler from twitter – recess – we use here ignores the escaping (for the record, lessc doesn’t seem to)… Bummer!

And then again – Google to the rescue – I found the solution to my final problem! A patch for recess. I hope they’ll fix it in a future version of recess but for now the patch satisfies my needs.

I suggest you to patch recess too! How? Well uhm,…

  • First try to find where recess is installed. If it’s installed via npm it should be installed in C:\Users\<username>\AppData\Roaming\npm\node_modules\recess\lib (<username> = your username on your pc). 
  • Then open the file core.js in an editor.
  • Next, find the comment with the typo: // iterate over defintions and compress them (join with new lines)
  • The line below should be: css = (def) { 
  • Replace this by css = this.parsed ? : (def) {
  • Save your file and yup you fixed it!

7 mistakes of software testing

Though most developers know the importance of testing, it seems that a lot of them still aren’t testing enough. And if they write tests, they test just test wrong.

Unit tests

If some tests are written in applications, most of them will be unit tests. It’s easy to test a utility class by just calling all utility methods, passing some values and checking if the expected result is returned.

A first mistake arises here. Most people don’t think out of the box, or not enough. You can test that 1 + 1 =2 , that 2 + 1 = 3 and that 3 + 1 = 4. But what’s the benefit of doing almost the same test 3 times? It’s better to test the boundary cases. Are the arguments of the sum( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?


If for example the service layer is unit tested, all other components like the DAO layer should be mocked. In many cases this is done manually. That’s a second mistake.

By mocking stuff manually your mocks are thightly coupled to the implementation. It’s much better to use mocking frameworks. They are made for it. Just trust that they will create the mocks the way you want. Some mocking frameworks are capable of doing more than others, some are easier to use than others. My favourite mocking framework is Mockito because of its power and simplicity. EasyMock is by far the best known but imo a bit too complex to use. What was the sequence again? Expect, replay, assert, or …?

So it’s not only a matter of choosing a mocking framework. It’s also a matter of choosing the right one.

Integration tests

Integration tests are tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). The best known type of integration tests are   tests of the DAO layer. In these tests, multiple things are validated: the input parameters, the use of the ORM tool, the correctness of the generated query (functional), if the DB can be accessed, the fact that the query is working and the fact that the correct ResultSet is returned.

A third mistake that is made often is that developers provide test data in a dbUnit XML dataset. This data is most of the time no representation of live data. The best way to handle this is to make functional people provide and maintain this test data. Because you don’t want to make them struggle with a specific XML format, it’s a good practice to use the XlsDataSet format. Data can be provided in an Excel sheet. The name of the tab is the table, in the first row, each column contains the name of the column and in all other rows, effective data is added. Insertion into the DB will be done tab per tab, from left to right. Deletion is done the other way around.

Functional tests

Functional test are forgotten too often because the perception is that they are difficult and costly to maintain. It’s true that you’ll have to tweak them to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there’s no need for stress for screens/functionality that will be broken in the next release.

Selenium is a great framework that is able to record functionality in the browser. A fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium keeps tracks of HTML components by their HTML id. If you don’t specify id’s in your HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.

A fifth mistake is made by just pasting the recorded test in a JUnit test. Common functionality like login and logout, the time to wait for a response, … should be added to a higher level. For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won’t break.

A sixth mistake is the absence of testing logical flows. It’s perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, update until delete of the same entry won’t work. TestSuites are a great way to group multiple tests and run them in sequence all together.


Mistake nr seven: most of the tests are technical tests instead of functional tests. It’s much more important to test logical behaviour than to test if the things work technically. That can be done by means of Behavior Driven Design.
Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.

The Ceylon Project

A couple of weeks ago I heard about Ceylon for the first time. Ceylon is a new language which will run on the JVM, influenced by Java and Scala, and has many similarities with Java and C#.  The name comes from the island Sri Lanka, also called Ceylon, and from the Ceylon tea, so the link with Java is very obvious.
A compiler release is planned for late 2011.

Ceylon’s design goals include:

  • to be easy to learn and understand for Java and C# developers,
  • to eliminate some of Java’s verbosity, while retaining its readability,
  • to improve upon Java’s typesafety,
  • to provide a declarative syntax for expressing hierarchical information like user interface definition, externalized data, and system configuration, thereby eliminating Java’s dependence upon XML,
  • to support and encourage a more functional style of programming with immutable objects and higher-order functions, and
  • to provide built-in modularity.
The authors of Ceylon -Gavin King, inventor of Hibernate, is the lead of the Ceylon project- really like Java but it doesn’t evolve a lot anymore as a language which means that the suboptimalities won’t ever get fixed. C# has some solutions for these suboptimalities, it has delegates and Java still doesn’t have clojures, getters and setters are obsolete while Java still has them, … But on the other hand C# also has some suboptimalities that Java doesn’t have…
So the guys behind Ceylon wanted to create a language which combines the best of breeds.

No static methods

Ceylon doesn’t have Java-style static methods, but you can think of toplevel methods as filling the same role. The problem with static methods is that they break the block structure of the language. Ceylon has a very strict block structure — a nested block always has access to declarations in all containing blocks. This isn’t the case with Java’s static methods.

Method annotations

Ceylon has some annotations which can be used to describe a method. The doc annotation contains documentation that is included in the output of the Ceylon documentation compiler. The documentation compiler will support several other annotations, including by, for specifying the author of a program element, see, for referring to related code elements, and throws, for alerting the user to exception types thrown by an executable program element.


doc "The classic Hello World program" by "Gavin" see (goodbye) throws (IOException) void hello() { writeLine("Hello, World!"); }

There’s also a deprecated annotation for marking program elements that will be removed in a future version of the module.

Note that annotations like docbysee, and deprecated aren’t keywords. They’re just ordinary identifiers. The same is true for annotations which are part of the language definition: abstractvariableshared,formalactual, and friends. On the other hand, void is a keyword.

String template

There are two nice things about strings in Ceylon. The first is that we can split a string across multiple lines. That’s especially useful when we’re writing documentation in a doc annotation. The second is that we can interpolate expressions inside a string literal. Technically, a string with expressions in it isn’t really a literal anymore — it’s considered a string template.

An example of a  string template:

doc "The Hello World program ... version 1.1!" void hello() { writeLine("Hello, this is Ceylon " process.languageVersion " running on Java " process.javaVersion "!"); }

The only requirement is that the string template starts and ends with a string literal.

Dealing with objects that aren’t there

In Java we’re used to the fact that command line arguments only can be retrieved via the main method’s String array parameter. In Ceylon we can retrieve command line arguments via the process object which has an attribute named arguments, which holds a Sequence of the program’s command line arguments.

An example of an improved version of the original Hello World program:

doc "Print a personalized greeting" void hello() { String? name = process.arguments.first; String greeting; if (exists name) { greeting = "Hello, " name "!"; } else { greeting = "Hello, World!"; } writeLine(greeting); 

The local name is initialized with the first of these arguments, if any. This local is declared to have type String?, to indicate that it may contain a null value. Then the if (exists ...) control structure is used to initialize the value of the non-null local named greeting, interpolating the value of name into the message string whenever name is not null. Finally, the message is printed to the console.

Unlike Java, locals, parameters, and attributes that may contain null values must be explicitly declared as being of optional type. And unlike other languages with typesafe null value handling, an optional type in Ceylon is not an algebraic datatype that wraps the definite value. Instead, Ceylon uses an ad-hoc union type. The syntax T|S represents the union type of T and S, a type which may contain a value of type T or of type S. An optional type is any type of form Nothing|X where X is the type of the definite value. Fortunately, Ceylon lets us abbreviate the union type Nothing|X to X?.

To avoid non-null checks, default values can  be specified as a method parameter. Below you can find an example.

void hello(String name="World") { writeLine("Hello, " name "!"); }

There’s an even easier way to define greeting (cfr example above), using the ? operator. It’s just a little extra syntax sugar to save some keystrokes.

String greeting = "Hello, " + name?"World" + "!";

The ? operator returns its first argument if the first argument is not null, or its second argument otherwise. Its a more convenient way to handle null values in simple cases. It can even be chained:

String greeting = "Hello, " + nickName?name?"World" + "!";

The related ?. operator lets us call operations on optional types, always returning an optional type:

String shoutedGreeting = "HELLO, " + name?.uppercase?"WORLD" + "!";

Hiding implementation details

In Java and C#, a class controls the accessibility of its members using visibility modifier annotations, allowing the class to hide its internal implementation from other code. The visibility modifiers select between pre-defined, definite visibility levels like publicprotected, package private, and private. Ceylon provides just one annotation for access control. The key difference is that Ceylon’s shared annotation does not represent a single definite scope. Rather, its meaning is contextual, relative to the program element at which it appears. The shared annotation is in some cases more flexible, in certain cases less flexible, but almost always simpler and easier to use than the approach taken by Java and C#. And it’s a far better fit to a language like Ceylon with a regular, recursive block structure.

Members of a class are hidden from code outside the body of the class by default — only members explicitly annotated shared are visible to other toplevel types or methods, other compilation units, other packages, or other modules. A shared member is visible to any code to which the class itself is visible.

And, of course, a class itself may be hidden from other code. By default, a toplevel class is hidden from code outside the package in which the class is defined — only toplevel classes explicitly annotated shared are visible to other packages or modules. A shared toplevel class is visible to any code to which the package containing the class is visible.

Finally, a package may be hidden from packages in other modules. In fact, packages are hidden from code outside the module to which the package belongs by default — only explicitly shared packages are visible to other modules.

It’s not possible to create a shared toplevel class with package-private members. Members of a shared toplevel class must be either shared — in which case they’re visible outside the package containing the class, or un-shared — in which case they’re only visible to the class itself. Package-private functionality must be defined in un-shared (package-private) toplevel classes or interfaces. Likewise, a shared package can’t contain a module-private toplevel class. Module-private toplevel classes must belong to unshared (module-private) packages.

Ceylon doesn’t have anything like Java’s protected. The purpose of visibility rules and access control is to limit dependencies between code that is developed by different teams, maintained by different developers, or has different release cycles. From a software engineering point of view, any code element exposed to a different package or module is a dependency that must be managed. And a dependency is a dependency. It’s not any less of a dependency if the code to which the program element is exposed is in a subclass of the type which contains the program element!

Instantiating classes and overloading their initializer parameters

doc "Print a personalized greeting" void hello() { Hello(process.args.first).say(process.output); }

The rewritten hello() method above just creates a new instance of Hello, and invokes say(). Ceylon doesn’t need a new keyword to know when you’re instantiating a class.

I suppose you’re worried that if Ceylon classes don’t have constructors, then they also can’t have multiple constructors. Does that mean we can’t overload the initialization parameter list of a class?

I guess now’s as good a time as any to break some more bad news: Ceylon doesn’t support method overloading either! But, actually, this isn’t as bad as it sounds. The sad truth is that overloading is the source of various problems in Java, especially when generics come into play. And in Ceylon, we can emulate most non-evil uses of constructor or method overloading using:

  • defaulted parameters, to emulate the effect of overloading a method or class by arity (the number of parameters),
  • sequenced parameters, i.e. varargs, and
  • union types or enumerated type constraints, to emulate the effect of overloading a method or class by parameter type.

We’re not going to get into all the details of these workarounds right now, but here’s a quick example of each of the three techniques:

//defaulted parameter void print(String string = "\n") { writeLine(string); }
//sequenced parameter void print(String... strings) { for (String string in strings) { writeLine(string); } }
//union type void print(String|Named printable) { String string; switch (printable) case (is String) { string = printable; } case (is Named) { string =; } writeLine(string); }

Don’t worry if you don’t completely understand the third example just yet. Just think of it as a completely typesafe version of how you would write an overloaded operation in a dynamic language like Smalltalk, Python, or Ruby.

To be completely honest, there are some circumstances where this approach ends up slightly more awkward than Java-style overloading. But that’s a small price to pay for a language with clearer semantics, without nasty corner cases, that is ultimately more powerful.

Let’s overload Hello, and its say() method, using defaulted parameters:

doc "A command line greeting" class Hello(String? name = process.args.first) { ... doc "Print the greeting" shared void say(OutputStream stream = process.output) { stream.writeLine(greeting); } }

Our hello() method is now looking really simple:

doc "Print a personalized greeting" void hello() { Hello().say(); 


Ceylon looks like a great language which has a lot of similarities with Java and C#, so easy to learn. It tries to solve the suboptimalities of both languages, to remove overhead and to set good defaults. Though at this moment I don’t know if it will be a Java killer. But I’ll keep you informed guys! Stay tuned!

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.