Code Reviews Done Right

Posted on Leave a commentPosted in Uncategorized

Recently, I’ve been working with a project team embracing code reviews. The experience wasn’t pleasant. Most of the time, it was downright annoying.

The general idea of code reviews is that one of your team members dedicates several hours of their precious time to look at your code and help you to improve it. That’s a generous offer. Plus, hardly anybody rejects an opportunity to learn and improve their coding style. I, for one, definitely don’t. So how come the code reviews were such a pain in the ass?

Comments in JSF Files

Posted on 5 CommentsPosted in BootsFaces, JSF

Earlier this day, a developer opened a bug ticket for BootsFaces. <b:panelGrid />, they said, is buggy. Adding a comment between the columns corrupts the layout, they said.

Actually, that’s true, but I wouldn’t call it a bug of BootsFaces. It’s a peculiarity of JSF. We could solve it in BootsFaces. At least, most of the time. I’m sure there are corner cases we’ll always miss unless we start to parse the code as thoroughly as a compiler. That’s possible, but it doesn’t match the general idea of JSF. Even worse, we can only solve the bug for BootsFaces components. It still exists for standard JSF, PrimeFaces, ButterFaces, and every other JSF framework you combine with BootsFaces. So I prefer to explain the bug instead of solving it.

Why are Angular Components more Successful than JSF Components?

Posted on 6 CommentsPosted in Angular2, JSF, simpliying JSF

At first glance, there are many similarities between Angular and JSF. Both offer a decent abstraction layer from the DOM, both offer two-way binding (yes, I know it’s optional since Angular2), and both use components as building blocks of the application. Even better, both frameworks offer a way to create your own custom components. The difference is that hardly anybody creates custom components in JSF. Angular programmers do it all the time.

Things get even more mysterious when you learn that JSF has been designed with creating components in mind. It should be easy. But the vast majority of developers doesn’t think so.

Angular: Components first

Angular takes components to a whole new level. When AngularJS 1.0 was released seven years ago (on Oct 20, 2010), that was a revolution. Developers used components all the time, no matter which framework they used. Everybody knew it’s a good idea to download or buy a powerful third-party framework. The idea was that powerful components like datatables or charts should be developed by experts.

AngularJS and its predecessors changed all that. They made the process of creating components much more democratic. They enabled everybody to create their own component. React and Angular 2+ go one step further down that road. They force every developer to write their own components. The entire program is built on custom components. There’s no way to avoid custom components.

That fundamental design decision forced the Angular team to make creating components as simple as possible. They did a great job. Angular components are powerful enough to cover every conceivable use case. At the same time, it’s easy to write them. Actually, it took me a while to realize that this isn’t the programming style I used before.

JSF: components as expert tools

JSF comes from an older tradition, and it’s focused much more on the enterprise market. In a big company, there’s a framework team providing useful stuff like standard architectures and reusable components.

Actually, that sounds better than it is. More often than not, those central framework teams aren’t accepted by the developers doing “the real work”. The central team imposes restrictions the developers “at the front” would like to circumvent. I suppose that’s part of the problem: the developers working for the customer just want their problem solved. The central framework developers have a different perspective. They want to find solutions solving the problems of every other developer.

This state of mind leads to very generic solutions, usually involving a lot of boiler-plate code and often including concepts which are either difficult to grasp or weird. It’s like in real life: trying to make everybody happy is doomed to fail.

But JSF has been developed with components in mind, hasn’t it?

Like I’ve mentioned before, JSF has been designed specifically to make it simple to create a component. But it was designed at a time when XML was state of the art. So you have to create an XML file (called “taglib”) to register your JSF library, you have to register each component and each attribute of the components within the XML file and you have assign ids to link the implementation to the declaration in the XML file.

Truth to tell, that’s not difficult, but it’s tedious, and there are many pitfalls along the way. Popular errors are putting the taglib into the wrong folder or adding typos to the ids. The baroque API of JSF doesn’t help, either. Most developers consider it difficult to call the Java API to create simple HTML code.

There’s another effect, and it’s probably even more important. For some reason, developers assumed they shouldn’t create JSF components. After a while, everybody believed it’s very hard to write such a component. I guess that was just a prejudice because few people actually tried, but that’s how things go.

JSF composite components

With the advent of JSF 2.0, the problem was addressed with the composite components. In my eyes, that was a huge step in the wrong direction. Composite components are defined using XML files. The result is a clumsy, verbose syntax and not being able to use “if” conditions or loops. It’s a typical Java enterprise solution: very ceremonious and not very flexible.

Consider this example (taken from the blog of Yong Mook Kim, aka Mkyong):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns=""

  <composite:attribute name="namelabel" />
  <composite:attribute name="nameValue" />
  <composite:attribute name="emaillabel" />
  <composite:attribute name="emailValue" />
  <composite:attribute name="registerButtonText" />
  <composite:attribute name="registerButtonAction"
                       method-signature="java.lang.String action()" />

    <h:message for="textPanel" style="color:red;" />
    <h:panelGrid columns="2" id="textPanel">
      #{cc.attrs.namelabel} :
      <h:inputText id="name" value="#{cc.attrs.nameValue}" />
      #{cc.attrs.emaillabel} :
      <h:inputText id="email" value="#{cc.attrs.emailValue}" />
    <h:commandButton action="#{cc.attrs.registerButtonAction}"

This component definition consists of 32 lines. The component itself is defined in 11 lines (lines 20 through 30). The other two-thirds of the file are overhead.

Angular’s approach to defining components

Truth to tell, I doubt an Angular component consists of fewer lines of code. It just feels a lot more natural. There’s an HTML template corresponding to lines 20 through 30. The interface section is replaced by a TypeScript class.

This has several advantages over defining the interfaces in XML. A class is real code. In other words: you can debug it. Plus, you’ve got the full power of a programming language. Implementing loops and conditional rendering is a walk in the park compared to what you have to do in JSF. In fact, I often see desperate JSF programmers using the “c:” namespace. Usually, that works, but it’s not part of JSF, but of the older JSP standard, which doesn’t play well with JSF.

Angular’s locality principle

Every Angular component consists of four parts:

  • the HTML snippet, using the values of a “code behind” class
  • a class playing roughly the role of a “code behind” class in the .NET lingo
  • a CSS file (or SASS, or LESS, depending on your preferences)
  • an (optional) test class.

By convention, these four classes are always put into a common folder. So the HTML class isn’t far away from the “code behind” class. You see at first glance that the files belong together.

That’s what I call the locality principle of Angular. IMHO, it’s also a key to the success of Angular. Angular programmers define many, usually hundreds of components per application. The locality principle makes it easy to find out which files belong together.

Compare this to the JSF approach: in general, the XHTML file is in a completely different folder than the corresponding JSF bean. Either you’re using a clever naming convention, or you’re looking for your files all the time. In JSF, it usually takes a while to figure this out.

Adding insult to injury, JSF allows you to put your XHTML files into different folders. In the case of composite folders, that’s even mandatory. So I often seen projects putting the publicly visible XHTML files in src/main/webapp, the include files in src/main/webapp/WEB-INF and the composite components in the folder src/main/resources. In a recent project, I had to use pen and paper to keep track of the files.

Cutting a long story short: organizing your directory layout along technical layers is often a bad idea. Angular drops this idea, encouraging you to organize your project structure along business domains.

Shadow DOM

Angular’s shadow DOM is another important key to the success of the components. It allows you to design a component without influencing the design of other components accidentally. JSF programmers (and web developers in general) are familiar with the problem: each CSS rule they add applies to the entire page. In the case of a single page application, that may even be an entire application consisting of hundreds of views. So adding a CSS rule improving the layout of a view often ruins the layout of another view of the application.

Of course, it’s possible to solve the problem with JSF. However, the nice thing about Angular is that it makes it a no-brainer. If you want to modify the look and feel of the entire application, you change the global CSS file. If you want to apply face-paint to an individual component, you change the CSS file in the package of the component.

Before you ask: the shadow DOM is not a unique property of Angular. It’s a web standard that’s soon going to lift off. Currently, Angular simulates the shadow DOM by default, making it available to old browsers, too. Other frameworks support the shadow DOM, too, but JSF definitely doesn’t.

What might a JSF port of the ideas of Angular look like?

I believe it needs three ingredients to make components more useful in JSF:

  • Using a real Java class instead of declaring interfacing clumsily in XML.
  • The locality principle. The JSF template, the “code behind” class and the CSS class should be in the same folder.
  • Simulating or using the shadow DOM.

There’s already a template language we could use: the JSF facelets. So basically all we’d have to do is to read the template from an unorthodox folder, binding the XHTML template, the CSS file, and the Java bean together, and to make it available as a new JSF tag.

Maybe this is something a component library can do. In any case, it should be a relatively simple extension to MyFaces and Mojarra.

Wrapping it up

I’ve got the nagging feeling that creating components has been considered an expert job in JSF. Angular, on the other hand, forces developers to create components from day one. So the Angular team has optimized the component building until it’s intuitive and fun. The resulting programming style differs a lot.

Dig deeper

Mkyong on creating composite components

Modbus in a Nutshell (Plus a Short Introduction to IoT and PLC Programming)

Posted on Leave a commentPosted in factory automation, IoT, PLC programming

Have you ever had the opportunity to work on a factory automation project? Currently, I’ve got the opportunity to program software controlling real hardware in an assembly line. My program influences real machines in the real world. Most of the software I’m writing remains in cyberspace, so I consider “getting real” pretty exciting.

One of the key requirements of our project is that we have to use the Modbus protocol. That’s an old protocol dating back to the 80s. Even so, I wasn’t happy with the documentation. One might expect such an old, battle-tested protocol to be thoroughly documented. Well, it is, in a sense. The only problem being that most of it has been written for experts. So I decided to write a cursory introduction for the hurried Java developer. After reading it, you should be able to understand the expert documentation. Along the way, you’ll learn something about the IoT world the media keep raving about. If you’re only interested in Modbus, just scroll to the PLC section.

Static Code Analysis: SonarQube, Facebook’s Infer, and TypeScript

Posted on Leave a commentPosted in quality assurance

Infer is a static code analysis tool promising finding many bugs that escape the attention of many other tools. My curiosity was piqued. The result was underwhelming: Infer found four possible NullPointerExceptions in the source code of BootsFaces. Later I ran SonarQube. It found many other potential NullPointerExceptions. Any in both cases, half of the findings where false positives.

Since version 2.0, TypeScript has a built-in NPE finder. It works very well. Of course, it sometimes finds false positives, too. But if you activate the compiler switch --strictNullChecks from day one, that’s not a big problem because you notice the problem while you’re writing the code. You can tell the compiler to ignore the non-bug in a couple of seconds.

Compiler as a Service: Why TypeScript 2.5 Biggest Feature is a Refactoring

Posted on Leave a commentPosted in Concepts of programming languages, TypeScript

TypeScript 2.5 is there! That’s the headline of the tweet sending me to the TypeScript 2.5 announcment. To my surprise, the article described a new refactoring of Visual Studio Code. Did they choose the wrong title? Is this article really about TypeScript, or is it about an IDE?

As it turns out, refactoring is baked into the programming language. In former times, refactoring used to be what IDEs do. Nowadays, refactoring is a compiler feature. At least in the case of .NET languages and TypeScript.

What’s New in BootsFaces 1.1.3?

Posted on 2 CommentsPosted in BootsFaces, simpliying JSF

Two weeks ago, Neil Griffin, the head of the LiferayFaces project, approached us. He asked us to do a few minor changes so the next version of Liferay and LiferayFaces can be shipped with a BootsFaces demo.

That, in itself, is quite a surprise. Liferay has finally migrated to Bootstrap 3. Obviously, BootsFaces wasn’t compatible with previous versions of Liferay. Funny thing is that at the same time the BootsFaces team discusses when it’s time to move on to Bootstrap 4. It seems the Bootstrap 3 version is going to be maintained a bit longer than expected.

So we published BootsFaces 1.1.3 quickly to align it with the Liferay release, which is expected by the end of this month (i.e. August 2017).

BootsFaces Resource Loading Deep Dive

Posted on Leave a commentPosted in BootsFaces

Many BootsFaces developers want to add third-party code to BootsFaces. Usually, that’s a Bootstrap component, a jQueryUI plugin or another combination of JavaScript and CSS. Almost always, these plugins fail to work if they are loaded in the wrong order. So BootsFaces added a fine-grained mechanism allowing you to control the load order.

To my dismay, the resource ordering still causes a lot of trouble, so it’s high time to describe it in detail.


Newsflash: Investing in a Good Corporate Culture Boosts Your Team’s Productivity

Posted on Leave a commentPosted in corporate culture

Basically, this article is simply a pointer to another article I’ve just read. In a way, we all know what happens if we discourage other people in a critical moment, but I can’t help but observe how often we ignore it. Every once in a while, I even meet team making bullying a hobby. John Looney describes the effect of such a behavior in his article. Highly recommended!

Software Testing Techniques in a Nutshell (Part 1: The Human Factor)

Posted on Leave a commentPosted in quality assurance, testing

The previous article in this series explained why it takes so many techniques to ensure software quality. This article explains a couple of these techniques.

Test methods in a nutshell

When I started investigating for this article, I stumbled upon a post resonating many of my thoughts on testing. In the meantime, the post has been deleted. It has been replaced by a Youtube video that’s slightly different (probably better). Be that as it may, the original post of Itamar Turner-Trauring inspired me to draw this picture, covering most of the popular test approaches and summarizing the post.
This image groups software testing techniques into four quadrants, based on whether they can be automated and on whether they are tied to a formal specification. By

Let’s start with the quadrant you probably don’t associate with testing. The green quadrant focuses on the user and on our customer.

Software Testing Beyond Unit Testing – the Bigger Picture

Posted on Leave a commentPosted in quality assurance, testing

Software testing beyond unit testing. Image source: time I write about unit testing, people get angry. So let me explain why I rant about unit tests every once in a while.

First of all, there’s nothing wrong with unit testing. That’s not the point. Usually, I start ranting when I notice people believe in unit tests religiously. Many good developers seem to believe that unit testing is the only test tool they ever need. Both agile programming and continuous delivery make us believe such a nonsense.

There’s so much more to testing than just unit tests. This post gives you a short overview about different test techniques. It’s not an in-depth explanation of these approaches to testing. Instead, it focuses on telling you why they are important. You’ll see there are many important tests that can’t be automated at all. You’ll always need human beings to test your software.

Comparing TypeScript to Java

Posted on Leave a commentPosted in Concepts of programming languages, TypeScript

To my surprise, I saw that many people visit my website after searching for “TypeScript vs. Java”. The question makes sense, so let’s answer it. What’s the difference between the two languages? When to chose which? Do they compete at all?

Why should we compare TypeScript to Java?

At first glance, the answer is simple. TypeScript “lives” in the browser. Java lives everywhere else. So they don’t compete at all. End of the article.

However, TypeScript is an attractive language for people with a Java background. To them, the question is slightly different. Is TypeScript an easy language to learn?

Plus, there’s Node.js. Using JavaScript on the server has become surprisingly popular. TypeScript compiles to JavaScript, so it has become a direct competitor to Java.

When Unit Tests Backfire

Posted on 4 CommentsPosted in quality assurance, testing

Everybody knows that unit tests are valuable. So it’s a lot of fun playing Devil’s advocate as I did some time ago when I raved about the value of compiler checks for keeping up the quality of your program. So here we go: unit tests are expensive. You never know when or if they pay off.

Thing is, my experience shows that unit tests are not always good. Sometimes they even backfire. I’ve seen this in at least two projects. This time, I don’t want to talk you out of using unit tests (maybe another day), but I want to make you aware of the risks.


Reactive Programming with Angular by Example (Part 3)

Posted on Leave a commentPosted in Angular2

In the previous parts of this series, we’ve learned how to work with data loaded asynchronously. Now let’s have a look at some of the advanced use cases. How can we combine multiple REST calls if we need the result of both to start working?

Let’s continue our address example. Let’s assume we want to send a letter to a customer. To send the letter, we need two chunks of data: the content of the letter itself, and the address we want to print on the envelope. We can’t send the letter until we’ve received the response of both REST calls.

Reactive Programming with Angular by Example (Part 2)

Posted on Leave a commentPosted in Angular2

In the first part of this series, we’ve seen how to call a REST service and how to display the result asynchronously. Now we’re going one step further. How to work with data that isn’t really there, but can only be observed as a volatile stream of data events? Because that’s what an Observable is. Reactive programming is stream processing, and the strictest form of reactive programming uses Observables without memory.

Reactive Programming with Angular by Example (Part 1)

Posted on Leave a commentPosted in Angular2

Web applications benefit a lot from reactive programming. The application reacts immediately when the user clicks, even if it takes a couple of second to load the data. In the early days, applications used to stall at this point. The computer froze, and you couldn’t say whether it had crashed or not. So developers invented the progress bar. That’s still freezing but in a more entertaining way.

Modern web applications do a lot better. They show the next page immediately, filling in data a bit later. That approach has many advantages. It gives the user immediate feedback. You can also load the top-most data first and load less often used data later. In most cases, this even means the user can continue their work earlier.

Let’s have a look how to do this with Angular. Reactive programming isn’t difficult, but if you’re not used to it, you have to learn to think outside the box.

Too Old to Learn a New Language?

Posted on 1 CommentPosted in developer productivity, project managment, software design

The other day, a co-worker and I held a talk at the Java Forum Stuttgart. Our topic was the UI techradar we’re currently developing. So much of the talk was devoted to comparing UI frameworks, raving about Angular, about the advantages of programming your smartphone natively in ObjectiveC, and why it’s still a good idea to stick to Java and JSF.

All of a sudden one of the attendees asked a question I wasn’t prepared for. It was a good question, but I didn’t take it as seriously as it deserved. Even worse, I laughed it off. That’s something you must never do. When I noticed my mistake, it was too late to correct it. So I decided to blog about it. It’s a late answer, and I don’t know if it’s ever going to be read by the guy asking the question, but here it is.

The question was:

Angular and React may be great. But do you really expect everybody who’s crossed the 35 years mark to learn a new programming language each year, just to use the UI framework of the week?