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:

<dependency>
    <groupId>de.beyondjava</groupId>
    <artifactId>angularFaces-core</artifactId>
    <version>2.1.7</version>
</dependency>

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:

<dependency>
    <groupId>net.bootsfaces</groupId>
    <artifactId>bootsfaces</artifactId>
    <version>0.7.0</version>
    <scope>compile</scope>
</dependency>

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 https://github.com/TheCoder4eu/BootsFaces-OSP.

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 http://www.bootsfaces.net. 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:

http://localhost:4567/hello

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

OmniFaces CombinedResourceHandler Gives Your Application a Boost

OmniFaces 2.1 is soon to be released. Time to present a useful OmniFaces component which has been improved in version 2.1: the CombinedResourceHandler.

The CombinedResourceHandler reduces page load times significantly by combining the countless resource files of a JSF page into one or two larger files, which can be loaded and processed much more efficiently. Since version 2.1, these files can optionally be cached on the server side, giving the application another boost. Server side caching reduces the time needed to display the BootsFaces showcase by a second. If that doesn’t sound much: believe me, your customers will notice the difference. It’s a difference if the page takes one or two seconds to display.
Continue reading

Type Erasure Revisited

You can’t beat type erasure, they say. Information about generic Java data types is lost during compilation, and there’s no way to get it back. While that’s absolutely true, Mahmoud Ben Hassine and I found a tiny loophole which allowed us to improve Mahmoud’s jPopulator framework tremendously. Under certain circumstances, it’s possible to find about the type which is supposed to be erased. So jPopulator is able to populate not only simple beans, but also complex generic data types.

Mahmoud agreed to write an article about the ups and downs of our investigation. You’ll see it wasn’t exactly easy-going. Along the way, you’ll learn about the loophole allowing us to beat type erasure.
Continue reading

How Static or Dynamic Typing Affects Your Coding Style

Erik Osheim has written an excellent article comparing dynamic and static typing. More precisely, he compares Python to Scala. What makes his article interesting, is that he focuses on the consequences of the type systems. The article you’re currently reading is a (not so) short summary of Eriks article, plus a few thoughts of mine.
Continue reading

Should You Avoid or Embrace “Static”?

More often than not, the keyword static confuses Java programmers. As a consequence, Ken Fogel asks his students never to use static in Java unless explicitely told to do so. While that’s a good hint for starters, it’s only part of the story.

Funny thing is, I recommend to use static as often as possible. There’s a twist: Never use static variables, but always use static methods.
Continue reading

Creating Annotations is Fun! Too Much Fun?

Once again Lukas Eder has written an article I mostly agree with – but not completely. Lukas claims Annotations have become an antipattern.

The nice thing about annotations is you can define your own annotation. It’s easy, and it’s extraordinary popular among framework designers. So we see annotations in the bean validation API, in JPA, in CDI, in JSF, in EJBs, WebServices and Rest and much more.

Annotations – a programming language of their own

While I absolutely love these annotations, there’s a problem: they are starting to become a programming language of their own. What do you think about something like this?

@NotNull
@Size(min=6,max=10)
@Pattern("[a-zA-Z]+")
@Inject @UserID
@Column(name="userID")
private String userID;

@Valid
@ManagedProperty("#{customer.account}")
@OneToOne
private Account account;

Continue reading

Newsflash: Java to Scala Converter

JavaToScala.com may help you to learn Scala. It takes an arbitrary Java class and converts it to Scala.

Naturally, this approach emphasizes the similarities between the two languages. The few examples I tried were converted into solid Scala classes, but nothing out of the ordinary. The converter won’t introduce a case class or a trait if it seems fit. However, emphasizing the similarities is not a bad thing: many Java programmers are scared away from Scala after seeing advanced code.

The core of the converter is another project available on GitHub: Scalagen is a Maven plugin converting Java source code to Scala. The project home page states that the converter isn’t perfect, but may introduce errors for certain Java constructs, so I take it the same applies for JavaToScala.com. But still, it’s an interesting way to get familiar with Scala.