How to Wrap BootsFaces (or JSF in General) as a Native Desktop Application

When I showed the draft of my last post (the “Java on the Desktop” survey article), my friends surprised me by saying that nowadays desktop applications are sort of exotic. Everybody’s doing mobile or at least web applications. But the good old desktop has fallen into oblivion. That’s pretty strange, given that most of us do most of their daily work at desktop PCs or decent-sized laptops.
Continue reading

Java on the Desktop

For some reason, the vast majority of developers has accepted the browser as the operation system for their applications. While there are some good reasons for this, I never really bought into it. HTML5 has eliminated most of the pain point of web applications, but I still insist that most customers don’t really want to use a web application. We’ve taught them to accept to open the browser to do their daily work, but there are still quite a few disadvantages to this approach. The “old stagers” among you know how many obstacles we had to overcome before the browser became a really useful operation system for writing applications. Just for the fun of it, let’s start this article summarizing some of them:

  • How to deal with the “back” and “forward” buttons in a web application?
  • How to print a document from a web application? Most developers export documents to be printed as PDF files, but wouldn’t it be nice to be able to print documents without this detour?
  • How to import an Excel file into your application?
  • More generally speaking, web applications run in a sandbox preventing access to low-level resources such as your computer’s file system.

Continue reading

Angular2 Component Libraries

A good third-party component library can give your application development team a boost. This article collects a list of popular UI component libraries for Angular2. It goes without saying that this list can never be complete, so it’s probably going to change and expand over time. If you know of a useful Angular2 widget library, don’t hesitate to leave a comment so I can complete the list.

By the way, this list is just that: a list. I’m adding a short introduction to each library, but it’s not the same as a review. I’ll postpone that to follow-up articles. If you like or dislike on of the library, I’d like to hear from you, especially if you also add a short explanation.

General purpose widget libraries

  • Ionic was already a well-known UI framework in the AngularJS 1.x age. There’s also an Angular2 port. Ionic comes with a CLI tool which simplifies getting started. It also provides its unique layout which blends in nicely with the look and feel of many current mobile devices. There’S a nice tutorial at
  • PrimeNG is an offspring of the well-known PrimeFaces JSF library. It’s an open source project hosted at GitHub. At the time of writing (Oct 07, 2016) I counted some 70 components, providing enough widgets for writing an enterprise application. Like PrimeFaces, PrimeNG is a commercial library. In this particular case, this means you can get the library itself for free, but you can order a support plan. There’s a PrimeNG PRO with commercial support and premium templates like Ultima NG. For some reason, the team didn’t make their pricing public yet, but they told me they already have a couple of very big customers. Judging from the list they showed me I daresay to call PrimeNG a great framework even if I haven’t used it myself.
  • ng2-bootstrap is a component library that combines the grid system and the theming of Bootstrap with Angular2. At the time of writing (Oct 07, 2016) it supports 15 components and both Bootstrap 3 and Bootstrap 4. 15 components doesn’t sound much, but the tool box contains most components you need. A co-worker of mine uses it for their current project and reports that they a happy with it.

Widget libraries providing individual components

Talking of data tables: PrimeNG has a fairly powerful data table. I didn’t compare it to the other data tables in this list, but I think they all play in the same league.

Commercial widget libraries

Since I don’t want to spend money on commercial libraries just to test them, let’s suffice to mention these libraries.

  • KendoUI is the Angular2 offspring of the well-known KendoUI library. So it’s not surprising that it looks fairly complete. Prices start at 999$ per developer license.
  • Wijmo 5 is also a library with a long history. Hence the Angular2 offspring also seems to offer almost everything you need. Prices start at 695$ per license.

Is Java Going to Become Invisible?

In a sense, Java has vanished from the client many years ago. With the exception of Android, the vast majority of Java runs on a server in a data center. From the average user’s perspective, Java has become invisible. When we talk about Java UI programming, most people think of Spring MVC, JSF and Ozark.

I’m still trying to make sense of the new Java EE 8 plans Oracle revealed at JavaOne a couple of weeks ago. My first impression was that the new focus on cloud computing means that Java is going to molt again. The Java EE 8 roadmap proposal indicates just that.
Continue reading

The Rise and Fall of Scala

There seems to be a consensus in the Java community that the Scala programming language is already on the decline. I consider this a pity because I always enjoyed programming in Scala. Actually, I even started this blog to support alternative JVM languages like Scala. But the market has decided differently. Moshe Kranc has written an excellent analysis about the rise and fall of Scala. I found Moshe’s article interesting enough to summarize it and to add a couple of thoughts of mine.

Before I start

However, I’ve also read some of the 169 comments to Moshe’s article, so I’d like to add a few words. First of all, I’m really fond of the Scala language. I’m not trying to write an anti-Scala article. Quite the contrary. I’m following the fate of Groovy and Scala for at least ten years now, and I’m still puzzled why the industry doesn’t adopt one of these languages. In many aspects, both languages are clearly superior to Java.
Continue reading

Newsflash: JavaEE 8 Road Map Proposal

This newsflash is a true “flash”, currently consisting only of a single link to the current proposal of the JavaEE 8 road map:

Proposal of the JavaEE 8 road map as of September 19, 2016

However, if time allows, I’ll either add to this newsflash later or write blog entries covering certain aspects of the shift of the plans. Stay tuned!

UI Roundup 2016: Microsoft UWP and Xamarin

No comprehensive survey about UIs can ever be complete without covering the Microsoft world. Java and JavaScript may be all good and well, but sometimes you need more control over your hardware. Both languages run in a sandbox trying to abstract from the hardware the application is running on. Most of the time you won’t notice, but there’s a major performance penalty, and you can’t access low-level resources. So let’s have a look at what Microsoft has in store for you. Traditionally, the particular advantage of using native Windows programming is the seamless integration with the operating system and – to a lesser extent – with the hardware.

So let’s have a look at Microsoft’s UWP platform and at Xamarin, a framework they’ve acquired in February 2016.

Kudos to my co-author

But before that, I’d like to introduce you to my co-author, Janis Saritzoglou. This article wouldn’t have been possible without him. Janis wrote his bachelor thesis about UWP and dedicated an afternoon to explain UWP and Xamarin to me. He also proofread this article and added a couple of interesting insights.

That said, let’s continue with UWP.
Continue reading

HTML5: Optional HTML Tags

The other day Marco Rinck tweeted something that’s very confusing, almost disturbing. Google’s HTML style guide suggests to omit optional HTML tags. Taking in mind that the page rank of your website is influenced (among other things) by whether your page has a clear layout and a good coding quality, following these guidelines is almost mandatory. Granted, I didn’t check whether this particular style guide is linked to the results shown in the webmaster tools, but you get the idea: if Google publishes a style guide on HTML and CSS, it’s going to have an impact on the market. So let’s have a close look at it.

What are optional HTML tags?

At first glance, the idea of declaring certain HTML tags “optional” and suggesting to omit them makes a lot of sense. Putting it in a nutshell, the idea is to make the code more human-readable. More to the point, the suggestion is to write HTML code the way the average human would write it if they didn’t happen to be a developer. Developers have learned to love clear structures, but that’s not the way most people think. A particularly fascinating property of the human mind is its ability to recognize patterns. Even better, it’s able to infer patterns where there are none.

Basically, that’s the idea of optional HTML tags: you don’t have to write an HTML tag if you can easily infer it from the context.

For instance, there’s no point in writing the <html> tag. The document is shown in the browser, so we already know it’s an HTML document. Similarly, there’s no point in wrapping the <head> tag around the <title> tag, and the <body> around the <for> or <p> tag. Both forms and paragraphs make only sense in the body of an HTML document, so it’s easy to infer the <body> tag.

Cool! But…

Being a human being – and a particularly lazy one – Google’s style guide fills my heart with joy. Mind you: having to end each and every paragraph with a </p> tag before starting a new paragraph is really silly. Actually, it’s the number one mistake when I add a new page to our BootsFaces showcase.

On the other hand, the new style guide is exactly the opposite of what web designers have been taught during the last couple of years. I’m not entirely sure about the version numbers, but as far as I remember, starting with HTML4, XHTML was promoted as the new way to go. Former versions of HTML – or rather, the browser rendering engines – tended to be very sloppy. Or, putting it positively, they mapped the pattern inference capabilities of the human brain. The (then) new standard was to get rid of inference. The idea was to define everything in a clear, concise manner.

What about parsers?

I don’t know why this clean coding style was propagated, but my theory (hey, that’s pattern inference at it’s best!) is that the idea was to make HTML machine-readable. Clean XHTML code can be parsed by an XML parser. In fact, that was what allowed me to write BabbageFaces. JSF usually generates very clean XML code which can be read and analyzed by an XML parser. That’s what I did to reduce the size of the HTML code sent to the browser.

However, I consider BabbageFaces a nice but failed project, basically because hardly any JSF page fulfills the strict requirements of XML. The average JSF page renders code that can almost, but not quite be read by an XML parser. Almost always optional HTML tags are used. Browser vendors always knew that HTML pages are written by human beings, so they introduced pattern inference from day one. So browsers don’t have trouble displaying the HTML code generated by JSF pages. The XML parser of BabbageFaces quickly ran into trouble with the same pages. Which is sort of remarkable, given that the HTML code generated by JSF frameworks usually is a lot cleaner than HTML code written by humans.

We need new parsers!

Far be it from me to resist the new guidelines. Quite the contrary. In recent years, compiler manufacturers have learned a lot. The semicolon that’s required at the end of each Java statement originally was introduced to make it easier to implement parsers analyzing the source code. It took compiler manufacturers a couple of years to recognize that the semicolon can be induced from context.

There are many programs out there analyzing HTML code. I don’t know whether they cope with tag inference or not. Thing is, HTML4 made it official that they don’t have to, while HTML5 officially makes tag inference part of the HTML language. As a consequence, you can’t simply use an XML parser to parse HTML pages. You need a full-blown HTML parser. A short investigation showed that Jsoup may be such a parser, but please don’t take my word for it: neither did I try it, nor did I compare it with other parsers.

Wrapping it up

Actually, the Google HTML and CSS style guide give the best summary itself:

This approach may require a grace period to be established as a wider guideline as it’s significantly different from what web developers are typically taught.

As a human being, I welcome the new standard because it makes both reading and writing HTML pages easier. As someone who sometimes writes programs to analyze HTML pages, I’m not so sure. At least, the idea to simply use an XML parser to analyze an HTML page is doomed.

Dig deeper

HTML5 specification of optional tags
Google’s HTML styleguide on optional HTML tags

Blisk – a Browser to Make Web Programming Easier

Mobile first! Seriously? Do you really optimize your application for mobile usage?

Actually, you can’t. The current state-of-the-art makes it difficult to adopt the “mobile first!” approach seriously. Mind you: that would require you to program your application on the phone instead of using your desktop browser. Until today, I’ve seen such an approach only with iOS programming and with UWP/Xamarin. The application is developed on the desktop, but run and tested on the cell phone or the tablet.

The other day a friend of mine, Dario D´Urzo, showed me another option for web developers. What started as a small JavaScript plugin two years ago has evolved to a full-blown browser in 2016. More precisely, it’s a browser based on Chromium which adds a number of tools dedicated to web designers and web programmers.

Targeting multiple devices

When you open a URL in Blisk you’ll see the web page twice. On the right-hand side, there’s the desktop view you expect. On the left-hand side, you see the same page in a simulated smartphone. As you can see in the screenshot, both views are remarkably different. It’s great to be able to seem both views at a glance. This enables you to truly adopt the “mobile first!” slogan. Even better: if you scroll one of the windows, the other windows scrolls simultaneously. Thus you can compare both the look and the feel of both displays.

Blisk supports a number of devices out of the box. It doesn’t cover every smartphone and every tablet available on the market, but the number of devices seems to cover almost every use case.

Multiple inspect views

Seeing multiple devices at a glance is just a start. You can also open device-specific developer tools and keep them open simultaneously. That, in turn, allows you to find differences between devices a lot faster than with the traditional single window.


Being a browser based on Chromium, I’m pretty sure Blisk has an annoying limitation: it doesn’t simulate the device completely. It only modifies the screen estate the replaces the mouse pointer by a large finger touch point. What it does not do is to simulate the rendering engine. If there’s an incompatibility because – say – Safari implements a feature differently than Chrome does, you’ll still miss it with Blisk. You still need to test your application with the real device.

Automatic reload

That’s another feature I’m told to be very useful. You can configure Blisk to watch certain files or folders. When you edit and save a file, Blisk automatically reloads the page. I suspect that’s one of the features that are useful to some and annoying to others, so probably it’s good news you can also switch it off. However, if your application supports reloading, I imagine that’s a tool boosting productivity.

Code analysis

Currently, that’s only a promise. The module providing static code analysis is still under development. I’m looking forward to it. Integrating code analysis into your browser (i.e. your runtime environment) might make you aware of problems much earlier than with traditional approaches such as SonarQube.

Screen shots

Another feature that’s still under development. However, I doubt that’s a killer feature to me. Tools like Greenshot integrate so nicely into my PC I never considered taking screenshots awkward. So I’m curious – maybe the developers have a clever idea I missed?

Integration with other tools

That’s something offering more potential to boost productivity. Blisk offers to provide integration with third-party tools, such as bug trackers and project management tools. Unfortunately, this is another module still under development.


Blisk has a long licence agreement, but basically it’s free both for commercial use and for personal use as long as you don’t modify it.

Wrapping it up

As long as you are aware on the limitations, Blisk is a great tool for every web designer and web developer targeting multiple devices. At the time of writing, many interesting features are still missing. However, what’s already there looks interesting enough to adopt Blick for development.

Dig deeper

Blick project page
Blick license agreement

Newsflash: Sometimes Using Float is Faster Than Using Int in Java

Performance considerations in the eighties

Time and again, I’m surprised by the performance of modern CPUs. Actually, the speed boost astonishing me most took place a decade ago, give or take a few years. Before that, floating point operations were a lot slower than integer operations. When I learned my first assembly language, the 6502 processor was state of the art. This processor was so simple that you had to write a program to implement the integer multiplication. Multiplying floating point numbers was an even longer program. I’ve forgotten the actual numbers, but as a rule of thumb, multiplying integers was ten times slower than adding two integers, and multiplying floating point numbers was another magnitude slower.

… compared to 2016

Nowadays, x86 CPU multiply four floating point numbers in a single CPU cycle (under optimal conditions). In theory, the fastest possible operation takes one CPU cycle, to it boils down to saying that multiplying floating point numbers is every bit as fast as adding integers. The complexity of the algorithm hasn’t gone away, so this is absolutely stunning. Not only have hardware designers managed to implement the complex algorithm in hardware, they also managed to implement it in a fashion resembling parallel programming. I suppose the final algorithm isn’t that complicated. Actually, I’ve got an idea what it looks like. But it took hardware designers years to get there, so it’s obvious it wasn’t a low-hanging fruit.

What about Java?

As Grey Panther shows in his article, the effect also shows in Java programs. Under certain circumstances, integer operations can be slower than floating point operations. I don’t think that holds true for individual operations, because in this case, the latency induced by the CPU pipeline plays a major role. But when you do a lot of floating point operations, the JIT compiler and it’s optimations kicks in, allowing for an efficient CPU use. The net result is that it may pay to prefer floats over integers.

Wrapping it up

However, what’s more important, is that every data type is blazing fast. You can choose the data type that suits your problem. In earlier times, performance considerations often dictated the choice of the data type. Luckily, this is a thing of the past.

Dig deeper

Benchmarking the cost of primitive operations on the JVM
Intel® 64 and IA-32 Architectures Optimization Reference Manual

Java UIs: State of JavaServer Faces (JSF) in 2016

How to update a popular article that made it to rank 2 on the Google search results? My survey article about Java UIs is three years old, so it clearly needs an update. Instead of rewriting I decided to write a series of short articles each covering a single UI framework. I’ll concentrate on the JavaScript and Java world. On my list are MVC 1.0 (aka Ozark), Angular2, D3.js (even it’s not a general-purpose framework), JavaFX and many others. Maybe I’ll also add an excursion to the Microsoft world. For instance, UWP / Xamarin is an interesting UI framework I’d like to cover.


But let’s start with the framework I know better than most: JSF. As you may or may not know, I’m a contributor to a JSF component library, so you’ll get first-hand information. It goes without saying that it may be a bit biased. That’s the drawback of getting first-hand information. By the way, if you’re interested in a quick summary, you can jump directly to the State of the art (2016) paragraph.

JSF – why should I care?

Don’t be fooled by what you read in the forums. Many developers speak ill of JSF and call it a dead horse. But JSF is still alive and kicking in 2016, especially in Europe and Brazil. Like so many other things in the information science space, JSF frequently becomes a victim of flame wars. There are so many critics of JSF I decided to address them first before explaining what JSF is. Feel free to skip this paragraph if you’re not biased against JSF.

Putting it in a nutshell, there are two sources of criticism. First, the 1.x versions of JSF were really bad. (At least I’m told so, I never used it). But the designers of JSF have learnt their lesson and corrected many design flaws of JSF 1.x. Version 2.0 was a big step forward, and subsequent versions became even better. If you’ve suffered from version 1.x and ran away crying, let me tell you that using a current JSF version is fun.

Second, JSF is an old, even outdated technology. Old by the definition of computer science: it’s still useful, and it still evolves, but you simply don’t need it anymore. Ten or fifteen years ago, it was a good idea to render HTML code on the server side. Simply because there was no other option. HTML and JavaScript programmers had to keep the difference between the browsers in mind, JavaScript was slow and far from being a useful standard, and you couldn’t write UI components. Nowadays, browsers have evolved a lot. There are so many useful UI components in the JavaScript world that it seems ridiculous to generate them on the server side. Even worse, powerful JSF components tend to generate a lot of code, which results in long page load times. Processing input on the server feels like a bad idea, too. It means a lot of network traffic. More often than not, the result is an application that doesn’t feel responsive.

However, that’s only one side of the coin. Under certain circumstances, JSF still has its advantages. For instance, it puts less drain on your cellphone’s battery, and it runs smoothly on old or cheap clients (if optimized accordingly). You know, most readers of this blog live in the United States or Europe, where it’s fairly common to own both a powerful smartphone and access to fast internet, but there are many countries in the world that are far less privileged. In fact, there are many people in your country that can hardly afford internet access. According to this speech, minimum wage workers in India need to work one hour just to access 15 web pages. Even in Germany, minimum wage workers have to work a couple of hours just to achieve the cheapest possible access to the internet. From this perspective, it makes a lot of sense to keep both web sites small and the CPU requirements low. JSF can do this much more efficiently than most applications based on JavaScript. It goes without saying that most JSF applications aren’t optimized for low CPU usage and low network traffic. All I say is if you need to optimize, JSF may become very attractive.

Be that as it may, JSF is still very popular in a variety of countries, in particular in Brazil and in Europe.

I’d like to add a third point. I often feel JSF is annoyingly clumsy. I suspect many developers shy away from JSF because the feel the same. That’s why I contribute to BootsFaces. This framework is dedicated to making a developer’s life simpler.

What is JSF?

JSF is a server-side web-application framework trying to abstract from the peculiarities of the browser. Strictly, speaking, it’s even wrong to say JSF is a web framework. The web is only the most popular target platform. There’s at least one JSF implementation running on JavaFX: Captain Casa. I don’t know about their market share, but the company exists since 2007, and they seem to have found their stable niche. It’s definitely an interesting approach to writing desktop applications.

However, the vast majority of JSF developers develop applications running in the browser. As things go, trying to keep developers from learning HTML, CSS and JavaScript turned out to be an illusion. As a consequence, both the core JSF standard and every popular JSF component framework have options to add JavaScript and CSS. That’s the ugly secret nobody tells you when you start programming JSF: good JSF developers have to be familiar with many technologies and at least two programming languages (Java and JavaScript). From this point of view, programming the browser directly with HTML, CSS and JavaScript seems to be simpler. However, JSF is a mature technology with a lot of industry support. It’s not likely to vanish within the next five years. The average JavaScript framework has a much shorter life expectancy. That’s one of the reasons why I believe JSF programmers are more productive than pure JavaScript programmers. Other reasons are the powerful tool chain and the seamless integration with the Java backend.

Until JSF 2.2, the key feature of JSF were its components. Components are the building blocks of JSF. I’ll list a couple of component libraries in a minute. As you’ll see, the range of components is impressive. There’s everything from simple input fields to full-blown map engines and statistical charts. Unfortunately, many people felt restricted by the pre-defined components, so JSF 2.2 added a second programming paradigm:

  • You can adopt an HTML5 coding style. More often than not, this will result in an HTML-centric coding style that doesn’t need JSF component libraries. Instead, you can use popular client-side components libraries like jQueryUI or Bootstrap. For example, there are two powerful client-side data tables for Bootstrap: Bootstrap-table and The latter works both with or without Bootstrap.
    Following this approach takes most of the sting out of the flame wars against JSF. You still use some of the concepts of JSF, but you’re up to your own to use HTML, JavaScript and CSS the way you like. This approach is very attractive to many developers who are already familiar with web development.
  • You can employ a powerful component library like PrimeFaces or BootsFaces. These components offer a lot of features out-of-the-box, but they are usually a bit opinionated about how a UI should look like. Like said above, components are a mixed blessing. They serve almost every requirement, but sooner or later most projects are confronted with a requirement the component doesn’t quite meet. In such a situation, you’re stuck. JSF has been developer with extensibility in mind, but few developers dare to extend predefined components, so it’s an all-or-nothing game. Even so, the UI component libraries are one of the most compelling reasons to use JSF.

JSF component libraries: GISFaces

Let’s start with a small but exciting player. GISFaces is specialized on displaying maps. Using maps with GISFaces is surprisingly simple. GISFaces uses a number of maps services that are available publicly and for free, so I suppose you can use the maps in your own applications, even if you publish them on the internet1

Unlike most other JSF libraries, GISFaces is closed source. Plus, you need to register yourself before you can use it. But according to Chris Duncan, that’s not a big deal. His comment below has a lot of additional information on the registration process in particular and GISFaces in general.

JSF component libraries: PrimeFaces

These days, PrimeFaces is the most popular JSF component framework. It offers a rich set of components, including such exotic components for statistical charts and flowcharts. PrimeFaces also simplifies AJAX. Recent versions of PrimeFaces added support for mobile devices, accessibility (e.g. screen readers) and responsive design.

From today’s perspective, the default theme of PrimeFaces looks a bit old-fashioned. But that can be helped with a wide variety of predefined or custom themes. PrimeFaces supports Themeroller, so it’s easy to create a theme yourself. Or you can by a thema from PrimeTek, the company backing PrimeFaces, or a third-party vendor.

PrimeFaces is an open-source library published under an Apache V2 license. Only support and bug-fix releases cost money.

Cutting a long story short: PrimeFaces is highly recommended. Even if I’m the contributor to another JSF component framework that seems to be competition, I’m very impressed by PrimeFaces, and it’s always a lot of fun to use it.

JSF component libraries: BootsFaces

BootsFaces is a slightly smaller component framework build around the Bootstrap framework. In other words: responsive design and support for mobile devices where built in from day one. Originally designed to be a small framework concentrating on the layout, it rapidly grew to a full-blown JSF component library offering roughly 70 components.

BootsFaces generates much more compact HTML code than most JSF frameworks. Most components of BootsFaces generate a native Bootstrap component. Usually, that means compact HTML code. Most of the rendering takes place on the client, relieving the server from having to care about every aspect of the UI.

Other notable features are the advanced search expressions and the AJAX framework. Both have been inspired by PrimeFaces, but go far beyond. The general idea of BootsFaces is to simplify JSF. The innovative approach to AJAX is an example of this.

Like PrimeFaces, BootsFaces is published under a business-friendly Apache V2 license. Despite its low version number, it has attracted a lot of attention. The 2000 downloads-per-month mark has been crossed in May. That’s a much smaller market share than PrimeFaces has, but the figures keep growing, and BootsFaces has been designed with compatibility to PrimeFaces in mind. The goal of the team is not to replace PrimeFaces, but to allow cherry-picking.

JSF component libraries: ICEFaces and RichFaces

These are two early JSF component frameworks that used to be popular but have almost fallen into oblivion since then. If I’ve followed the new correctly, the development of RichFaces has been canceled this year (2016).

ICEFaces still seems to be an active project, but it’s lost much of its popularity in recent years. Among other things, there was some commotion when ICEFaces copied a lot of the source code of PrimeFaces without telling. Strictly speaking, this was legal (the Apache V2 license is very liberal), but the JSF community didn’t appreciate that. Be that as it may, ICEFaces added a couple of very interesting concepts to the JSF world. “Automatic AJAX” detected the changes of the JSF tree, allowing for much more efficient usage of the network. ICEFaces also was a pioneer in exploring push technology with JSF.


Talking of automatic AJAX, it might be interesting to mention BabbageFaces. That’s project of mine bringing automatic AJAX to the greater JSF world. BabbageFaces was very successful in the lab, but it didn’t work as well in the real world. It only works if the HTML code generated by your JSF page is valid XML code. That’s hardly ever the case, so I consider BabbageFaces an interesting but failed project. Plus, advances in network technology reduced the need for such a framework.


Another canceled experiment of mine – but one that’s used by a small group of developers in production. The idea of AngularFaces was to eliminate AJAX request by moving the logic to the client. More specifically, the client uses AngularJS, which is very similar to JSF.

By the way, AngularFaces is not a component library. It’s designed to be a plugin to every other JSF framework (though it has only been tested with Mojarra and PrimeFaces).

AngularFaces attracted a lot of interest in the JSF community. In particular, developers working on JSF frameworks were fascinated. Developers just using JSF frameworks were a lot less fascinated. Most developers shied away from having to deal with both the complex lifecycle of JSF and AngularJS. In my eyes, the integration was successful enough to take the scare out of it, but since the general experience of software architects is to keep things simple, AngularFaces never took off. In a way, that’s a pity: it’s a good tool to migrate from JSF to AngularJS.

The next version of AngularFaces (if it ever materialized) will target Angular2 and – possibly – AngularBeans.


That’s a very active project targeting a highly specialized market: Liferay. As to my experience, it’s better to program Liferay natively (i.e. by using JSP and Spring MVC), but LiferayFaces offers an interesting bridge to the JSF world. It’s suffering from the same problem as AngularFaces: both Liferay and JSF have a complex lifecycle, and it’s not easy to integrate them. That’s not a small achievement. And it works: I’ve successfully developed JSF applications with LiferayFaces. There’s a major developer productivity penalty, but if you are already using Liferay for some reason, the advantage of LiferayFaces is that it integrates your JSF pages seamlessly with the AlloyUI theme of Liferay.

JSF component libraries: ButterFaces

ButterFaces is another component framework based on Bootstrap, but for some reason, it’s almost orthogonal to BootsFaces. It focused on components, neglecting the layout. In theory, that makes it the ideal companion framework to BootsFaces, but currently, it’s still a bit tricky to integrate the two frameworks. The teams are working on that.

Although this has little to do with the features and shortcomings of the framework itself, I’d like to point out the innovative interactive showcase of ButterFaces. It allows to manipulate the attributes of the ButterFaces components and to see the effect in real time.

JSF component libraries: HighFaces

HighFaces is a highly specialized JSF libraries focusing on charts rendered on the client side by Highcharts, a JavaScript library bringing interactive charts to the browser.

HighFaces is published under a business-friendly Apache V2 license. However, the underlying Highcharts JS library is not. It’s free for non-commercial use, but both commercial usage and support cost money.

JSF component libraries: TieFaces

TieFaces is a very similar library. It focuses on charts. Plus, it delivers Excel support. You can turn your browser into a spreadsheet using a few lines of JSF code.

Proprietary frameworks

There are also a couple of proprietary JSF frameworks. I won’t cover them not only because they aren’t open source, but because I’m under the impression that they have a limited market share. Suffice it to say they exist.


Honestly, I can’t think of a JSF project without OmniFaces. OmniFaces is the Swiss army knife of the JSF world. At the same time, it’s a most unusual JSF framework. OmniFaces doesn’t bring many visual JSF components. Instead, it’s sort of orthogonal to other JSF component frameworks. It adds what’s seems to be missing in the core JSF framework. Notable examples are predefined universal converters, lazy loading of JavaScript libraries and much more. The developers of OmniFaces are members of the JSF 2.3 EG, which allows them to add popular features of OmniFaces to the JSF standard.

By the way, virtually every JSF developer knows one of the developers of OmniFaces by his nickname BalusC. He’s the helpful soul answering countless questions about JSF on StackOverflow.

State of the art (2016)

Putting it in a nutshell, JSF is an old technology. Many developers even consider it outdated. Plus, JSF isn’t a simple framework. It takes some time to master it. But that doesn’t mean it’s a bad framework. Quite the contrary, once you’ve mastered the learning phase, you can write JSF application surprisingly fast. JSF is particularly well suited to large-scale applications, i.e. the enterprise market. It’s not optimized for small applications or games. But it really shines in the class of application it’s designed for.

The advantages of JSF are its rich set of powerful component libraries, it’s sophisticated lifecycle, its built-in validation framework and its seamless integration with JaveEE2. The drawbacks are the component libraries, the lifecycle, the validation framework and the integration with JavaEE. Each of these features may stand in your way. For example, many developers try to combine JSF with Spring. That’s possible, but there are so many drawbacks that I’d call it a stupid idea. If you insist on using Spring, you’re better off with Spring MVC.

Uncertain future

Currently, there’s a lot of uncertainty whether Oracle is going to continue to support JavaEE 8 as it was planned a couple of years ago. There’s a major shift towards cloud computing, and in theory, this might result in Oracle dropping JSF. But I suppose the JSF community is vivid and strong enough to survive such a move. Countless companies use JSF. If Oracle were to stop JSF development, there’s probably a successor in no time. Plus, most of the progress of JSF is driven by the component libraries. But until JavaOne 2016 all this is speculation. The official statements of Oracle state they continue supporting JavaEE 8. That should include JSF. That’d be good news: a lot of effort already went into developing JSF 2.3.

Wrapping it up

Regardless of what they tell you, JSF isn’t dead yet. I’m not sure I’d base a new project on JSF (unless it’s based on BootsFaces, of course). But if you do, you don’t do anything wrong. JSF is a mature technology with a lot of freely available documentation, and it’s still evolving. Maturity may seem boring at first glance, bit it also means superior toolchains, high developer productivity, long-term support, and happy customers.

However, I’m not sure I’d start a major JSF project in 2016. Client-side frameworks and ecosystems like react.js and Angular2 are rapidly catching up, so maybe it’s time to migrate to JavaScript or TypeScript. However, the development in the JavaScript world is still so fast it’s difficult to choose the right framework if your application needs to be maintained five, ten or even twenty years.

  1. I recommend double-checking the license nonetheless. Many lawyers have specialized in charging people publishing maps, more often than not involuntarily violating copyright laws. That’s why I don’t publish screenshot of GISFaces here.
  2. This applies to JSF 2.2 and to JavaEE 7 and above.

How to Use Advanced Search Expressions with Mojarra, MyFaces or OmniFaces

I consider the advanced search expressions of PrimeFaces and BootsFaces tremendously useful. In particular, @next and @previous make it a lot easier to move input fields around on the screen or from one screen to another during the prototype phase of your project. The only problem with the search expressions is that they only work with PrimeFaces and BootsFaces components. If you also use the base components like <h:inputText />, you back to using ids and the four search expressions defined by the JSF standard (@form, @this, @all and @none).

JSF 2.3 may change that. It’s not settled yet, but there an ongoing discussion to include a similar search expression framework in JSF 2.3.

But what about now?

That’s a bright look-out. Problem is, most of us live don’t live in the future. Quite the contrary, from a technical point of view, most of us developer live in the past. I know many projects currently developed with JavaEE 6, a technology presented seven years ago. In other words: even if Oracle is going to accept our proposal in JSF 2.3, that doesn’t help many developers before 2020. So the challenge is to find a way to add the search expressions to JSF 2.0, 2.1, and 2.2.

How to do it

Cutting a long story short: I’ve found such a solution. It’s not exactly elegant, but it does the trick. The nice thing about my solution is that you don’t need to add the BootsFaces library to your project just to use the search expressions. You only need a single package of BootsFaces. Most likely I’m going to publish this package on Maven Central after running some more tests.

Actually, it’s fairly simple to use the search expressions in non-BootsFaces components. Every attribute of a JSF component supports EL expressions. This includes the attributes for, render and execute. So I’ve defined a JSF bean allowing you to resolve the advanced search expressions:

<h:message for=
 "#{searchExpressionResolverBean.resolve(component, '@previous')}" />

Of course, that’s a far cry from what we really want:

<h:message for="@previous" />

Luckily, there’s a second option we can use to simplify things. JSF allows us to register a “facelets decorator”. This class is called when the XHTML file is loaded and parsed. The facelet decorator can modify each facelet and replace it with another facelets. That’s how the HTML5 friendly markup of JSF 2.2 has been implemented. The JSF 2.2 recognizes an HTML input tag and replaces it with a JSF h:inputText if there’s an JSF attribute. We can use the same trick to replace the string "@previous" by "#{searchExpressionResolverBean.resolve(component, '@previous')}"". In other words, our decorator translates the search expressions to something core JSF can understand at load time.

How to activate the search expressions

Unless you’re already using BootsFaces, copy the folder to your project. This folders contains the entire search expression resolver library, and it also contains the decorator in a subfolder.

If you want to benefit from the simplified syntax of the decorator, you have to activate it by adding a few lines to your project’s web.xml. If you don’t use BootsFaces, that’s:


If you use BootsFaces, chances are you also want to benefit from the full power of the relaxed HTML5-like coding style of BootsFaces. If so, you have to register a different, more powerful decorator:


Limits of the decorator

I encountered a surprising limitation of the decorator when I tried to use it with f:ajax. Both the render and the execute attribute are translated by the decorator, but they are ignored – at least by Mojarra (I didn’t try MyFaces yet). That’s fairly annoying because it forces you to use my first, verbose proposal. You can abbreviate the long name of the JSF bean SearchExpressionResolverBean by deriving a bean with a shorter name, but there’s no way to reach the simple syntax we really want.

Still, being able to use advanced search expressions with frameworks like Mojarra, MyFaces, RichFaces, or ButterFaces that haven’t been designed to be extended that way is nice.

Benefits for users of BootsFaces and PrimeFaces

Every once in a while, even users of such huge libraries like PrimeFaces (157 components) and BootsFaces (68 components) need a component that’s not part of the library. A popular way to build components is to build them from scratch using the base libraries. Another popular way is to add a library like OmniFaces, that’s not aware of the search expressions, either. But it does contain components like <o:commandScript /> that may benefit from the search expression.

By the way, if you prefer PrimeFaces over BootsFaces, you can also use their search expression framework. I didn’t prepare code to use it, but it’s fairly simple. The source code is at The key class is the SearchExpressionFacade. There’s no facelets decorator, but I’m sure you’ll be able to migrate the BootsFaces facelets decorator to PrimeFaces within a few hours.

Benefits for the rest of the JSF world

Well, that’s fairly obvious: you couldn’t use the advanced search expression before. Now you can. More likely than not, you don’t see the use case use. But that shouldn’t stop you. Just give @next, @previous, @parent, @after, and @styleClass(.) a try. Before you know, you’ll be addicted. Using fixed ids may be the most efficient way with respect to CPU usage, but at the same time, it’s very inflexible and limited if your JSF views are changed frequently. The advanced search expressions of PrimeFaces and BootsFaces make moving fields from one panel to another or from one view to another a breeze.

Wrapping it up

JSF is very flexible. So it’s possible to add search expressions to JSF using a couple of tricks. However, the f:ajax facet of JSF seems to ignore the changes of the facelet decorators, so the result isn’t as nice as it’s intended to be. But still, it’s nice to able to use the advanced search expressions in JSF 2.2 or below.

What’s New in BootsFaces 0.9.0?

Fork me on GitHubAfter seven weeks of hard work, we’ve published BootsFaces 0.9.0. It’s a major improvement over BootsFaces 0.8.6. Unfortunately, a little error slipped through our QA gate: It seems we’ve involuntarily published a Java 8 version. If you are using Java 6 or 7, you’ll have to wait until 0.9.1 comes out in a few weeks, or you may use the developer snapshot on Maven Central. It was a small bug, easy enough to fix it within a day.

While BootsFaces 0.9.0 is more than a bug-fix version, it clearly concentrates on polishing BootsFaces, removing bugs and finishing things we had started in previous versions. That’s not a small achievement: Fork me on GitHub the number of commits on GitHub went from 856 (BootsFaces 0.8.6) to 1028. And that’s only the base library. The showcase has improved a lot, too. And we’ve managed to finish a component many developers desperately need: <b:dataTable />. What makes this component unique in the JSF world is that it is rendered on the client. That makes it feel a lot faster and much more responsive than traditional server-side data tables. We’ve already received a lot of bug reports and enhancement requests, even during the development phase. Thus I’m sure the data table will remain in our focus during the new few updates of BootsFaces.

A more liberal license

Probably the most important point of BootsFaces 0.9.0 is the license. Now, BootsFaces is available under an Apache V2 license being a lot more liberal than the old GPL V3 license. For example, you can use BootsFaces in commercial products without further ado.

Continue reading

Newsflash: OmniFaces 2.4 has been Released

OmniFaces 2.4 has been released. This time, the new version concentrates on bug fixing and polishing. There is only a handful of new features, the most notable being <o:url />, which bring the old <o:url /> of JSF 1.x back to the JSF 2.x world. There are also improvements to the FullAjaxExceptionHandler and better support for logging. As usual, the team has written an exhaustive blog post covering the changes, so I won’t repeat their description. Instead, I suggest you follow the links below.

JSF 2.3

Maybe more important is that the OmniFaces team brought a couple of features from OmniFaces to the upcoming JSF 2.3 standard. That’s exciting because it puts the commotion about Oracle’s presumed withdrawal from JavaEE into perspective. Even if the rumors we to come true and Oracle were to stop their efforts on JavaEE, it wouldn’t be the end of the Java world. If need be, there are other developers ready to contribute suggestions, improvements, code and documentation.

Dig deeper

Announcement written by BalusC
What´s new in OmniFaces 2.4?

Newsflash: Comma Separated Json

Recently I noticed how cumbersome Json becomes if it’s used to describe large quantities of simple data. Have a look at the definition of the Coffee Wheel created by (no pun intended!) Jason Davies. On the one hand, Json is a great and simple format to describe the wheel (see the source code). On the other hand, writing your own coffee wheel description is another story altogether. You have to count curly braces, square brackets, commas, and quotation marks meticulously. It almost drove me nuts.

This shows another problem of Json. It’s not well suited for stream processing. Json objects are JavaScript objects, so they have to be parsed completely before you can start working. That’s one of the few area XML has an edge of Json. Since 2004, XML stream processing is an official part of JavaSE.

So I became curious when I stumbled of the CSJ API of Kirit Sælensminde. I didn’t try it, so I can’t say anything about the quality of the implementation, but at first glance, it looks both well-thought and promising. In many cases, the Json stream object is just as simple as a traditional CSV file you can import by Excel, but it offers much more flexibility.

By the way, CSJ wouldn’t simplify the coffee wheel description. The coffee wheel is a recursive data structure, so it doesn’t benefit from stream processing.

Progressive Web Apps

The other day, we had a discussion in the office. Is HTML5 the solution to every problem, or are native apps the way to go?

For a long time, I was very reluctant to force our users to use the browser to do their work. At the time, we had a nice Java applet running in the browser, which seemed to be a nice compromise to me. We could offer a rich user interface, and every user who had access to the internet could install our application. But installing the applet soon turned out to be above the skill and will of the average user, causing a lot of hotline calls. Plus, developing simple HTML pages was cheaper. That tipped the scales. We kissed Swing goodbye and never looked back.
Continue reading

HTML Includes

Almost every programming language offers you an option to use the content of another file in the file at hand. Basically, it’s a very old idea. Sooner or later programs become large and larger, so developers started to split the files into smaller building blocks. First, they invented subroutines, later procedures, and functions. Later they invented higher-level building blocks like modules, classes, and packages. One of the early ideas was to include the content of another file. To a certain extent, that’s always been possible in HTML. You can include CSS files by writing <link rel="stylesheet" href="myFavoriteCSSFile.css">. Similarly, you can add JavaScript code stored in an external file by writing <script src="myFavoriteScript.js">.

Funny thing is there’s no way to include the content of an HTML file into another HTML file.

That’s very strange because it’s such a useful feature. Server-side languages like PHP fix the problem by providing server-side includes. Probably that’s why the HTML standardization team didn’t add HTML import prior to HTML5. Even so, a quick glance at is a bit disappointing. You can use the official W3C standard on Chrome, Opera and Android. A second closer look reveals that this particular HTML5 standard is still in the “draft” stadium at the time of writing (June 2016).

What may be in store for you

Let’s start with the current W3C draft which may or may not see the light of the world. To my surprise, it’s not a simple HTML include, but requires some JavaScript code. So, the recommended way to use HTML includes seems to add the include statement – which turns out to be a <link /> – in the header of your HTML page:

  <link rel="import" href="myFavoriteInclude.html">

The next step is to define a div in your HTML page which is going to contain the include file:

     <div class="put-include-here">
        This message is going to be replaced by the include file.

Finally, you put the content of the include file into that div:

    var link = document.querySelector('link[rel="import"]');
    var content = link.import;
    var el = content.querySelector('.put-include-here');

This is a bit cumbersome, but of course, it’s much more flexible than a simple HTML include. You can do anything with the file loaded by the import link. When I tried this feature, I was even able to load different files by changing the href of the <link /> tag from JavaScript. A write access to the href was enough to make the browser load the file.

Still, this version is a bit disappointing because I’d prefer a simple way to include HTML code. Fiddling with JavaScript is a nuisance. It’s nice to have the option, but it’s annoying you can’t do without. But then, modern HTML5 is flexible enough to write a simple polyfill providing the feature I’m looking for:

     <include-polyfill href="myFavoriteIncludeFile.html" />


AngularJS comes close to my ideal solution:

<body ng-app="someApp">
   <div ng-include="myFavoriteIncludeFile.html"></div>

There are only two drawbacks. First, you have to use AngularJS. That’s fine if you want to use it anyway, but it’s a no-go otherwise. Second, AngularJS cares about security. It goes without saying that security is a good thing, but in this case, it means many tags are ignored by <ng-include />. In particular, you can’t include JavaScript code. If you want to do such a thing, you have to write some additional code to make AngularJS forget about security.


I didn’t try this one, so I can say little about it, but it appeared on the front page of my search result, it looks nice, and it comes from a source I consider trustworthy, so chances are that w3IncludeHTML is a good alternative for you. Using it seems to be pretty straightforward:

<!DOCTYPE html>
    <script src=""></script>
    <div w3-include-html="myFavoriteIncludeFile.html"></div> 


I take it most of you use jQuery, so using jQuery to load the include file is little to no overhead. As usual, jQuery isn’t activated by an HTML directive like <w3-include-html />, but it’s activated by a single line of JavaScript code:


Wrapping it up

When I started this article, I wanted to rave about the simplicity of the new HTML5 standard. Along the way, I learned that the new HTML5 standard isn’t as simple as I expected it to be: it requires a little help from JavaScript. Adding insult to injury, it’s not exactly a standard. It’s supported by Google Chrome, which may be a very popular browser, but which isn’t the most popular browser in the enterprise world, at least not in every country. So a substantial fraction of readers needs an alternative. Luckily, there’s an abundance of alternatives. Searching for “HTML include” reveals no less than 650 million search results on Google. So I’ve picked three arbitrary solutions: AngularJS, jQuery or a W3Schools library for those who don’t want to use nor Angular nor jQuery.

Still, I wonder why such a simple feature hasn’t made it into the HTML standard yet. Probably that’s due to the “good enough” principle. Most web designer and web developers can use another solution, such as PHP server-side includes, so they don’t need HTML includes.

Newsflash: Material Design with Materialize.css

This morning I became aware of a nice CSS library: Materialize.css. In many respects, it reminds me of Bootstrap. Among other things, there’s a similar grid system, which is even slightly simpler and more logical than its Bootstrap counterpart. The class names are shorter, there are only three screen sizes, and my first impression it’s easier to learn “s, m, l” than “xs, sm, md, lg”.

Community support (speculative until confirmed by further research)

What caught my attention was the ambitious translation of the huge showcase. The German translation is pretty good, and my quick survey showed that the Spanish and French translations aren’t bad, either. Granted, the major part of the showcase is yet to be translated. But some time ago, I’ve started to translate the AngularFaces showcase to German. I didn’t manage to finish it because I ran out of time. So offering a large part of the Material.css showcase in ten (!) languages is no small feat. To me, that’s a good sign: I don’t think the four team members speak ten languages, so I render it likely that there’s a broad community support for Materialize.css.

Virtually every component you’ll ever need

The other thing that caught my eye is the large list of components. At first glance, everything you need to write a business application seems to be there: input fields, combo boxes, radio buttons, and checkboxes, just to name a few. Check boxes come with a nice twist: they optionally have an “indeterminate” style, which looks very intuitive to me. This makes Materialize.css one of the few UI libraries offering a convincing approach to three-state checkboxes. Another nice twist is the labels of input fields, which may optionally be displayed as watermarks until you enter your input. That’s one of the things difficult to explain but easy to show, so I recommend you follow this link to have a look yourself.

Wrapping it up

I’m big into Bootstrap, but even I have to admit that Google’s material design already has a big impact on the UI market. My crystal ball is currently slightly undecided, but chances are that Material Design is going to be one of the big things in the future of UI. Materialize.css isn’t the only Material Design implementation, but it’s clearly an interesting one.

BootsFaces 0.8.6 has been Released

Fork me on GitHubThis weekend, we’ve published a new version of BootsFaces. Basically, BootsFaces 0.8.6 is not a big deal. It fixes half a dozen bugs. The most annoying bug that has been fixed was compatibility with Internet Explorer.

The other important change is a breaking change correcting another breaking change introduced with BootsFaces 0.8.5. Starting with BootsFaces 0.8.6, the process attribute of AJAX request now is 100% compatible with its PrimeFaces counterpart. We didn’t feel comfortable with introducing a second breaking change within merely two weeks, but at the end of the day compatibility with PrimeFaces was more important. We want you to be able to use PrimeFaces along with BootsFaces, and that means we should try to align our APIs as much as possible.

Another error we’ve fixed was basically caused by our documentation. Until 0.8.1, you could use <b:image /> with both the src attribute and the name attribute. BootsFaces 0.8.5 added the standard JSF resource library, which changed the meaning of name from “ignored” to “points to a file within the resources folder”. This, in turn, broke the application of at least one developer. Since BootsFaces 0.8.6, the src attribute has priority. Plus, we’ve corrected the documentation. Now it doesn’t claim the name attribute was necessary.

There are a few more bugfixes, as you can see in our release notes. If you’ve already adopted BootsFaces 0.8.5, we recommend updating to 0.8.6. If you haven’t, we recommend updating to 0.8.6, too, because the new version contains a lot of improvements and bug fixes. In any case, we don’t expect any migration effort, with the possible exception of the process attribute.

Like always, we’d like to thank everybody who’s reported a bug or a feature request on our bug tracker or on You’ve contributed to the success of BootsFaces, making it an even bigger success story than it already is!

Having said that, there’s only one word left to say:


When Your Framework Gets in Your Way

These days, my framework of choice got spectacularly in my way. Don’t get me wrong: D3.js is a good framework. It was the right tool for the job. But it slowed my progress nonetheless.

You know, I wanted to write a particularly fancy presentation. Everybody knows PowerPoint slides by heart, and even a nifty presentation framework like reveal.js has become boring. But there that nice little framework I always wanted to play with. And there’s this nice interactive sunburst diagram. What about converting it into an interactive presentation? And while we’re at it, why don’t you translate the code to TypeScript?

This turned out to be a stupid idea. Luckily I’m not in a hurry, so I don’t mind, and the result is impressive indeed. But with a tight deadline it had been a disaster.

It’s not the first time I experienced this. Even the best framework comes at a price.
Continue reading