Newsflash: Angular 1.x and 2.0 Integration Allows Seamless Upgrade

A lot has been complained about the hard cut between AngularJS 1.x and AngularJS 2.0. In the early days of AngularJS 2, the Angular team announced to have started a complete rewrite of AngularJS, without trying to remain compatible. The reaction of the community was harsh: many developers turned away from Angular.

Maybe this has been to early. Today, the Angular team announced to plan a surprisingly tight integration between the two versions. According to their blog, you can

  • mix Angular1 and Angular 2 in the same application
  • write views displaying Angular 1 and Angular 2 components simultaneously
  • inject services between the two branches of the framework
  • and they say even databinding works across Angular 1 and Angular 2.

The Rise of TypeScript?

I’ve made up my mind to start a series of AngularJS 2 articles. As you may or may not know, AngularJS 2 is not being developed in JavaScript, but in TypeScript, a language compiling to JavaScript. While it’s perfectly possible to write an AngularJS 2 application in pure JavaScript, it’s made for TypeScript (and maybe Dart). My bet is that TypeScript is the language of choice if you’re serious about AngularJS 2.

So, starting a series of Angular 2 articles inevitably includes a number of articles about TypeScript. already published such an article some time ago, but that was before the release of TypeScript 1.5, so it’s time to deliver an update. During my research I stumbled upon an interesting article: The rise of TypeScript?”. I wasn’t even aware that TypeScript is on the rise, but since I’ve read the article I guess the author can safely omit the question mark. He gives a number of good reasons why TypeScript has an opportunity to lift off.

Let me pick out one interesting aspect of the article: the time is right for a language compiling to JavaScript. How is that possible?
Continue reading

Comparing JavaScript to ECMAScript 6

Not long ago, the specification ECMAScript 6 – the successor of (guess what) ECMAScript 5, more commonly know as current JavaScript – has been finalized. Already browser developers are busily implementing ECMAScript 6 features into their browsers. So it’s interesting to compare the two versions of the language. As to my impression, ES6 is much more concise, legible and accessible to developers coming from classical object oriented languages.

Ralf Engelschall compiled a nice comparison of typical snippets of the two languages.

There’s also a comprehensive compatibility matrix. It’s interesting that at the time of writing even the best transpilers don’t exceed 59% (Traceur) or 71% (Babel+core.js) compatiblity (according to the compatibility matrix). On the other hand, the most popular desktop browsers – which are targeted at the mass market and can’t afford to implement features speculatively, only to remove them later – support ES6 already remarkably well, most of them exceeding the 50% mark.

Continuous Query Language – Processing Data in Real Time

The other day I learned about Odysseus, a framework to process data in real time. Truth to tell, I know little about the topic, but I consider it interesting enought to share it with you. Most of you are familiar with relational databases, SQL, O-R-mappers, transactions, the ACID principle and things like this. Working with streaming data is similar – and at the same time, it requires a major shift of mind. The more you look into it, the bigger the differences.
Continue reading

Selenium Dreams

Last week I’ve blogged about Cucumber and Selenium. In the meantime, my enthusiasm has cooled down considerably. I ran into a host of problems. Browsers simply aren’t intended to be controlled remotely. Quite the contrary. A remote control for your browser is a hacker’s dream. As a consequence, browsers tend to resist the remote control. However, Cucumber and Selenium are still the best tools I know, so I continued to work with them, and by the look of it, they will continue to work with them next week.
Continue reading

An Alternative API to JSF AJAX

As BootsFaces gains traction, people start to ask for AJAX capabilities. We’ve implemented some rudimentary AJAX support, but obviously that’s not enough. Developers need the full power of JSF 2.2 AJAX.

Funny thing is they demand it precisely the way JSF 2.0 defines it. It was a really clever approach when it was introduced. But I think in 2015 we can do better. I was always puzzled by the slightly counter-intuitive approach of JSF AJAX. Why do we have to use a facet to activate AJAX? Why do we need so many ids? And what does the attribute name execute mean, for that matter? For execute doesn’t execute anything. Instead, it defines which data to send.

The tradional JSF approach to AJAX

   <h:inputText id="name" value="#{}">
   <h:commandButton value="Welcome Me">
      <f:ajax execute="name" render="output" />
   <h:outputText id="output" value="#{helloBean.sayWelcome}" />	

The PrimeFaces approach

PrimeFaces shows us how to do thing better and more concise. Actually, AJAX and the superior search expressions are the two top reasons why I’m so fond of PrimeFaces. PrimeFaces allows for a very compact definition of AJAXified command buttons:

   <h:inputText value="#{}" />
   <p:commandButton value="Welcome Me" 
                    process="@previous" update="@next" >
   <h:outputText value="#{helloBean.sayWelcome}" />

We’ve got rid of the facet, we’ve got a powerful expression language allowing us to get rid of the ids and we’ve got much more intuitive keywords to define which inputs fields to send and which region of the DOM is to be updated.

Unfortunately, even PrimeFaces uses verbose event facets for almost every other AJAX event:

<p:inputText value="#{userBean.firstname}">
     <p:ajax event="keyup" 
             update="@next" listener="#{userBean.onKeyUp}"  />
<h:outputText value="#{userBean.firstname}" />
<p:inputText value="#{userBean.lastname}">
     <p:ajax event="blur" 
             update="@next" listener="#{userBean.onBlur}"   />
<h:outputText value="#{userView.lastname}"/>

The BootsFaces approach: a proposal

Now, let’s go one step further. Most interactive BootsFaces components already have quite a few JavaScript callbacks: onclick, onchange, onblur and so on. Why don’t we use precisely these callback attributes to define AJAX behaviour?

<b:inputText value="#{userBean.firstname}" 
             onkeyup="#{userBean.onKeyUp}" update="@next" />
<b:outputText value="#{userBean.firstname}" />

<b:inputText value="#{userBean.lastname}" 
             onblur="#{userBean.onBlur}" update="@next" />
<b:outputText value="#{userView.lastname}"/>

Note there’s a double use of the JavaScript callbacks. The general idea is to act differently according to the type of the onblur and onkeyup methods. If it evaluates to a string, it’s a Javascript method. If it evaluates to a method, it’s a JSF method.

This way, you’ve got a simple, intuitive API allowing for very concise code. Using the callbacks you even veto (i.e. prevent) the default action from taking place – a feature that’s lacking in the JSF world for some reason, but has always been possible in the Javascript world by simply returning false.

What about you?

If the majority of you, dear readers, doesn’t feel comfortable with the double use of the callback methods, we could also introduce additional callback methods. For instance, we could call the callback methods onClickJava, onBlurJava, onChangeJava, onDragStartJava and onDropJava. Personally, I don’t think that’s necessary, but it’s you who count, so I’d like to hear from you. How do you like the idea? Which implementation would you like to see in implementation? Do you prefer the standard JSF way using event facets? If so, why? Or why not, for that matter?

Cucumber Meets Selenium – How to Make Testing Web Applications Fun

Do you know anybody who loves to test their code? I don’t. Granted, there are those guys raving about the test first approach, but I always wonder which drugs they take. Maybe I’ve found the answer. Maybe its a simple Cucumber.

No, I’m not talking about the green stuff some of you grow in your garden. (Don’t even try to smoke it!) I’m talking about a framework that makes testing a lot more fun. I use it together with another interesting test framework, Selenium, which in turn builds on WebDriver, which is a remote control for your browser. You end up with a series of commands in plain – if slightly stilted – English that test your web application in a real browser. How do you like this test case?

Given I am on the BootsFaces start page,
When I navigate to "Getting Started" / "PrimeFaces",
Then I can read that "BootsFaces plays nicely with PrimeFaces."

That’s not a high-level description of the test in a Word document. It’s executable code. Eerie, isn’t it?

Like so often in the world of programming, it stops being eerie once you’ve started to look behind the stages. Which is what we’ll do in this article.
Continue reading

Using Grunt in Mixed Java and JavaScript Maven Projects

In recent years, JavaScript is becoming more and more popular – even in Java programs. It’s hard to evade the temptation to pimp up your Java program with a bit of JavaScript here and there. Or a jQuery plugin. Before long, you’ve got a lot of JavaScript code. Now, you’ve got Maven to manage your Java builds. What about the JavaScript part of your application?

Why should I use Grunt?

Grunt is one of the most popular JavaScript build tools. It’s really powerful. Even the plain vanilla tasks are interesting enough: combine and minify both JavaScript and CSS files. But Grunt doesn’t stop there. It can also minify images, or compile LESS and SASS files to CSS. Another interesting option is to run JSHint, a tool detecting potential errors in your JavaScript code (following the Lint tradition).

By the way, I expect this article to grow over time as I gather experience with Grunt. Feel free to leave comments to foster this growth :).
Continue reading

Newsflash: Compiling Java to Javascript

These days I stumbled upon Dukescript, which is a very innovative and ambitious approach to bring Java to various client platforms: traditional desktop applications, iOs devices, Android devices and the browser. Two of these target platforms – the desktop and Android – run Java natively (at least after installing a JRE in the case of desktops). Running Java on iOS is a brain-twister, but RoboVM takes the scare out of it, I’m told. Which leaves the browser, and that piqued my curiosity: Dukescript uses Bck2Brwsr to compile Java to Javascript.
Continue reading

How to Detect a Page Reload in JSF

One of our customers wants to reload everything from scratch when they hit the F5 key. Many web applications work like that, so customers have learned over the years that a page reload gives you fresh data. Usually that works because the web application doesn’t cache data in the session or view scope.

Unfortunately, some of our database queries take a long time, so we need caching. Reloading everything from scratch during each request is not an option. So we need to detect the F5 key. Plus the browser’s reload button, plus the reload command of the browser’s context menu.

At first, I didn’t think it wasn’t possible to accomplish this. At least not in a generic way. You know, the F5 button simply causes a GET request. The challenging part is to find out that the user has not clicked a button before.

After some investigation on the web, I came up with a clumsy solution. When I implemented it, I realized that there’s also a simple solution. The only problem is, I don’t know yet why it works (which makes me skeptical).
Continue reading

Eclipse Code Recommenders

Roughly a year ago, I attended a talk held by a very charismatic Marcel Bruch. Why, he asked, don’t we use the collective brains of the Java developer community? The Eclipse plugin written by his team does just that: Eclipse Code Recommenders observes what developers are doing to provide better code completions.

Eclipse autocompletion drives me crazy!

The idea is simple. Sooner or later, probably every developer gets nuts because Eclipse autocompletion suggests the same odd completions over and over again. For instance, some AWT classes are frequently at the top of the list. When I joined the Java world – that’s a long time ago, when Java 1.2 was new – AWT has already been legacy, having been superseded by Swing. So why does it appear in the list at all? Let alone at the top?
Continue reading

AngularFaces 2.1.7 published

Fork me on GitHubI made it a habit to publish a new version of AngularFaces every couple of weeks. Today I’ve published AngularFaces 2.1.7 on Maven Central. It should also arrive on JCenter within the next few days. The new version brings a couple of features that make it more apt for big applications.

AngularFaces in the wild

This week I spent a couple of days at a customer’s project, which happens to use AngularFaces. It’s a big project – several hundred JSF views, if I’m not mistaken, so it was really exciting to see how AngularFaces works in such a scenario. The good news is: it works just great. JSF applications become much more responsive with a little help from AngularFaces and Bootstrap. As things go, the sheer size of the application brought a couple of shortcomings of AngularFaces to the light of the day. AngularFaces 2.1.7 addresses an important part of that. I decided not to wait until I solved every point of my backlog, but to publish the version early. The improvements of the current version are clearly worth it.

Download coordinates

Add these lines to your project’s pom.xml:


Add this line to your project’s .gradle build file:

compile 'de.beyondjava:angularFaces-core:2.1.7'

Continue reading

How to Use Mockito to Test JSF Components

There are two strategies to write JUnit test for JSF applications. The first strategy uses a tool like Arquillian to start both an application server and a browser that runs a JSF application. Yeray Santana Borges used this strategy to contribute a couple of JUnit tests to BootsFaces.

This approach has many advantages. It runs on a real application server, and it runs on a browser that can execute Javascript. In other words, it’s a very close approximation of the real world. You can test a lot of things, including behavior and AJAX requests.

The big disadvantage is performance. It takes a while to start an application server. That’s bad if you want to run hundreds of JUnit tests on every build. Usually projects prefer to define a dedicated Maven profile to run this kind of tests. By default, the tests are skipped by the build. They are run only during a nightly build.
Continue reading

What’s New in BootsFaces 0.7.0?

Fork me on GitHubBootsFaces 0.7.0 now is available at Maven Central. And in a couple of days it will arrive on the jCenter repository. It’s an update bringing you a host of new features. By the way, don’t get confused by the small version number: We’re convinced that BootsFaces is ready for production. It’s just the Unix tradition that makes us stick with small version numbers.

Download coordinates

BootsFaces is available in two different flavors. There’s the regular version at Maven Central, and there’s a highly-optimized version at GitHub. The optimized version is 50 KB smaller and should be a bit faster. Both versions are compiled with Java 1.6. Alternatively, you can check out the repository from GitHub and build BootsFaces from source.

Add these lines to your project’s pom.xml:


Add this line to your project’s .gradle build file:

compile 'net.bootsfaces:bootsfaces:0.7.0'

The BootsFaces project comes with both a Gradle build file and a Maven build file. The Maven pom.xml is an easy way to get started, but if you want to tweak and optimize BootsFaces, you need the Gradle build.

In any case, the URL of the repository is

The showcase application is also available at Maven Central. It’s a war file you can simply deploy in a Tomcat. It’s the same application that runs on The source codes are also available on GitHub.

Continue reading

Updating To Mojarra 2.2.11+ May Break Your Spring Boot Application

One of our BootsFaces users surprised me by reporting that his application ceased to work after updating to Mojarra 2.2.11. After some investigation, I found out that the Mojarra team had implemented something that looked like an optimization. It works fine on a traditional Tomcat, but it doesn’t on Spring Boot.

What happened?

After reporting the bug to the Mozilla team, I learned two things:

  • Spring Boot is not officially supported by the Mojarra team. They’ll accept your bug fixes happily, but they’re reluctant to fix bugs related to Spring Boot themselves. Now, that shouldn’t come as a surprise. Spring considers itself as a competitor to JavaEE, so it’s just a happy coincidence that it’s possible to combine Spring Boots and JSF.
  • There was a good reason to implement the breaking change, and it wasn’t performance.

Continue reading

Vagrant Makes Installing MediaWiki Simple and Painless

One of our customers wants me to document our application in MediaWiki. I’m not too big into working remotely, especially not when I’m working with a tool that’s new to me. So I thought by myself, it would be nice to install MediaWiki on my desktop PC.

But… the installation manual is such a big book!

Easier said than done. You need an Apache, you need PHP with a couple of plugins, you need a database and I’ve read something about installing Ruby. I didn’t want to install all this stuff on my computer just to run a short-lived experiment.

Vagrant to the rescue. Last week I reported about a couple of tools that are popular in the Continuous Delivery community. The main goal of these tools is to automate the installation process of complex software. Now if someone already had taken the trouble to prepare a vagrant box… Bingo! A quick internet search revealed a vagrant box, and guess what? I found it on the MediaWiki homepage. Clearly a good sign.

Vagrant up!

I already had installed a virtual machine – VirtualBox – and Vagrant on my machine. So all I had to do was to clone a GitHub repository, run a setup.bat file and start MediaWiki by typing “Vagrant up” on the command line. The first start takes a lot of time (maybe half an hour if you’re on a fast network), but it runs unattended. When I returned from my jogging trail, MediaWiki was up and running.

Risk-free installation

The nice thing about it is, that all the gory details of the installation are sandboxed in a single directory on your hard disk.1 There’s hardly any risk of running into compatibility problems with the software you already have. Plus, you can reinstall your MediaWiki installation by simply calling “Vagrant destroy” and “Vagrant up” consecutively.

Dig deeper

MediaWiki-Vagrant documentation

  1. A co-worker of mine told me that this is not exactly true. There are at least two directories: the vagrant folder and the virtual machine. However, the bottom line is that both directories have nothing to do with your operation system. For instance, the sandboxed MediaWiki installation doesn’t register DLLs with your desktop PC’s Windows operation system.

Newsflash: Will Java 9 Break Your Code?

Developers should plan some extra time to migrate to Java 9. According to Nicolai Parlog, the new module system of Project Jigsaw will hide many internal APIs that have been visible for years. While this is a good thing on the long run, it may break existing code. Another possible source of incompatibilities are modified URLs to access resources within class files.

Read the fully story at Nicolai Parlog’s article.

Getting Started With Continuous Delivery

Basically, Continuous Delivery is simply a clever idea to make software development more simple, more reliable and more efficient. Sounds like simply tweaking the development process here and there, doesn’t it? But when you’re an experienced developer starting with Continuous Delivery, you’ll be surprised to meet a whole bunch of new tools you’ve never heard of. I found this pretty confusing: CD is a development process, but when I asked how to employ CD in my company, all of sudden people started to talk about tools. Worse, you’ll even learn new vocabulary, and you’ll have to acquire a lot of knowledge that’s previously been the exclusive domain of your operations department.

On second thought, that’s not surprising: One of the key ideas of Continuous Delivery is to make developers and operations collaborate more closely (an idea commonly known as “devops”). Operations departments have always been using their own tools, and will continue to do so for good reasons, so developers have to make themselves familiar with the tools of the operations department. In particular, they have to get familiar to Unix shells, which is quite a chunk to swallow if you’re a visually oriented developer like me.

Adopting Continuous Delivery has at least three challenges:

  • The development process changes.
  • The cultural shift. Both developers and operations have to learn about each others job, and they have to do tasks they could previously delegate to “the other department”.
  • Your team has to install and use several tool they wouldn’t need without CD. Expect to invest in courses and trainings.

Sparkling Services

WebServices and REST services have come a long way in Java. Nowadays, it’s very easy to create a webservice. Basically, it’s adding an annotation to a method. All you need is a servlet container, such as Tomcat. But then, configuring and running a servlet container isn’t really simple. Chances are you think it’s simple, but that’s because most Java programmers have been using application servers for years. They already carry everything they need in their toolbox. But from a newbie’s point of view, things look a little different.

Spark is a nice alternative making it really easy to write a REST service:

import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");

That’s all you need to implement a web server that serves a single REST service. Start the program, open your browser and enter the URL to test your REST service:


Notice that this is a main method. You don’t have to deploy a war file. Instead, Spark follows the idea popularized by Spring Boot: it embeds Jetty in a jar file. When I tested the code, Spark took virtually no time to start. That’s the nice thing about embedding Jetty: it has a really small footprint. I started to use an embedded Jetty for my web applications years ago. It’s a really fast alternative if you don’t need a full-blown application server.
Continue reading

Non-Object-Oriented Java

Hardly ever have I seen code reuse in business-related code. That’s a puzzling observation, given that Java programmers are expected to write object-oriented programs for many reasons, code reuse being an important reason. My puzzlement even grew when I started to analyze my former company’s SAP programs. They aren’t object oriented. Quite the contrary, the coding conventions discourage using ABAP objects. Does this make the ABAP code any worse?

I don’t think so. The average ABAP program is focused on business code. Plus, ABAP programmers usually prefer customizing over programming. SAP delivers a framework covering most of the technical issues, so there’s no point in creating your own class hierarchy of business classes. It’s better to take the data structures and objects SAP gives you and to customize them. More often than not, the result violates requirements concerning cognitive ergonomics, usability and performance, but that’s not today’s topic. SAP’s ABAP framework allows for efficient programming, and it’s perfectly possible to write huge programs without resorting to object orientation. Dropping OO is even a sensible choice.
Continue reading