What is AngularJS 2.0 Going to Look Like?

At last week’s ng-conference in Paris the AngularJS team gave us an early impression of how AngularJS 2.0 is going to look like.

Maybe you remember me writing in an earlier article that AngularDart is a preview on AngularJS 2.0. It wasn’t my own claim. I found it at the AngularDart web site. When I was jotting it down I couldn’t help but wonder how this might be done. AngularDart benefits largely from classes, annotations and an optional type system. This can’t be ported to Javascript, I thought?
Continue reading “What is AngularJS 2.0 Going to Look Like?” »

Java 8 Named Method Parameters

I was very surprised when I read Adam Bien’s blog post on named parameters in Java 8.

Named parameters? Well… not quite. At least not the kind of named parameters we know from languages such as Visual Basic, Groovy and many others. But it turned out to be an interesting read nonetheless. The article is about the Java 8 improvements of the reflection API.
Continue reading “Java 8 Named Method Parameters” »

Newsflash: AngularJS 1.3 Released

Oct 15, 2014. AngularJS 1.3 aka “superluminal-nudge” has been released two days ago. AngularFaces will support AngularJS 1.3 starting with the next version (AngularFaces 2.1).

According to the AngularJS blog, AngularJS 1.3 contains 400 bug fixes, a lot of performance improvements – both concerning speed and memory consumption – better support for users with a handicap and much more. An improvement I particularly like is ng-messages, a directive that simplifies the tedious chore of adding error messages (even if it’s still a far cry from the ease of use of <pui-message /> of AngularFaces):

<form name="myForm">
<input type="text" ng-model="field" name="myField" required minlength="5" />
<div ng-messages="myForm.myField.$error" ng-messages-multiple>
  <div ng-message="required">You did not enter a field</div>
  <div ng-message="minlength">The value entered is too short</div>

Code cited from the documentation of ng-messages

AngularJS also contains an improved model binding engine. For instance, AngularJS 1.3 supports one-time binding, a feature that’s already familiar from AngularDart. If you don’t want to update a value once the page has been loaded, one-time binding improves performance considerably. Another nice feature ng-model-options, which allows you to fine-tune the model updates. For instance, you can restrict model updates to certain events, such as leaving the field:

<input type="text" 
       ng-model-options="{ updateOn: 'blur' }" />

This feature comes in handy if you’ve got a circular dependency of fields containing calculated values that can be modified by the user (just think of three input fields, displaying a simple equation such as a = b + c).

According to the blog, using a short-hand dependency syntax often blocks minification. To notice such errors during development time, AngularJS 1.3 introduces an optional strict DI mode.

Dig deeper:

Announcement on the AngularJS blog

Newsflash: Ceylon 1.1 published

Yesterday (Oct 9, 2014) Ceylon 1.1 has been published.

For those who don’t know Ceylon yet: Ceylon is one of the interesting emerging JVM languages introducing many interesting features. For example I reported about Ceylon’s interesting approach to get rid of NullPointerExceptions some time ago. Ceylon is developed by Red Hat’s Gavin King, who’s already well-known from his work on Hibernate and Seam.

As far as I can see, the language itself hasn’t changed much. Instead the team concentrated on performance, the SDK, the Eclipse IDE and the libraries.

Dig deeper:

Gavin King’s Ceylon 1.1 announcement
Reddit discussion on Ceylon 1.1

Newsflash: Java Decompilers

Nowadays everybody seems to pull their libraries from Maven Central, which encourages to upload both the binaries and the source code of a library. Most developers follow the guidelines, so nowadays it has become painless to read the source code of the open source libraries you use. Debugging such a library usually is pretty simple. You don’t have to look for the source code, it’s just there.

Still, every once in a while you’re looking for a bug occurring in a library without source code. In such a situation a Java decompiler comes in handy. It analyzes the Java byte code and tries to reconstruct the original source code.

This article covers three decompilers in some (limited) detail and provides a link to an article covering a dozen more decompilers.
Continue reading “Newsflash: Java Decompilers” »

What’s New in PrimeFaces 5.1?

After two consecutive major, quite revolutionary releases it’s time for consolidation. Çağatay Çivici and his team seem to think the same and call the new release of PrimeFaces a minor version (5.1). It’s not that small, by the way: I’ve counted 660 commits, Granted, many commits deal with the new showcase, some deal with PrimeUI, but what remains is still impressive. According to the PrimeFaces blog the new version brings 225 filed improvements and more than 140 bug fixes.

So what’s new in PrimeFaces 5.1?
Continue reading “What’s New in PrimeFaces 5.1?” »

TomEE-Based JavaEE Counterpart to Spring Boot

Spring Boot stirred up the Java world. Developers always put up stoically with slow server start-ups, long deployment times and difficult server configurations. Those times seem to come to an end. There’s only so much coffee you can drink during the breaks.

The disadvantage of Spring Boot is it uses Spring, excluding roughly half of the Java community. As far as I know you can’t use CDI on Spring Boot. Even if you were to find a way how to do it, it’s questionable if it’s wise to use two different dependency injection frameworks simultaneously.

So what about the JavaEE world? The TomEE team are currently exploring what needs to be done to implement a JavaEE counterpart to Spring Boot. These days Alex Soto published a surprisingly simple prototype (complete source code here).

At the moment it’s only a sketch which can run servlets and REST services. Spring Boot goes far beyond that: just think of the amount of effort that went into monitoring. Alex Soto’s prototype has a long way to go yet to become a real competitor. In any case he has announce to publish more source code soon on GitHub.

Be that as it may, even the current prototype can already be useful. In an earlier article (Application Servers are dead!) I’ve sketched how to embed Jetty or Tomcat in a JAR file. TomEE is much more complete. Embedded TomEE also brings CDI, EJBs, JSF and the rest of the JavaEE stack. Of course documentation is still sparse, but an adventurous developer should be able to implement a full-blown JavaEE application on the 70-lines prototype.

By the way, this isn’t the only project inspired by Spring Boot. After finishing the article I stumbled about a similar, less ambitious project. If you’re interested only in CDI and REST services, forseti may be worth a look. It’s a tiny project running on Jetty.

Dig deeper:

Alex Soto’s announcement
BeyondJava.net’s running copy of the source code
How to run JSF and PrimeFaces on Spring Boot
Application Servers are dead! (Sort of)

How to Modify the JSF 2.2 Component Tree Safely: TagDecorators, TagHandlers and PreRenderViewEvent

Earlier this week Rudy de Busscher published an interesting article about JSF TagHandlers. Today I’d like to go a step further. Let’s have a closer look at them and discuss a second class of JSF tree manipulation classes: the TagDecorators. And, while I’m at it, I’ll also cover to system events, PostRenderViewEvent and PostAddToViewEvent, that can also be used to manipulate the JSF component tree.

Putting it in a nutshell, TagDecorators create JSF tags, whereas a TagHandler can be used to modify tags that already exist. Every JSF application can implement its own TagHandlers or TagDecorators. However, you hardly ever see one of them in the wild.

Obviously most people consider these classes a fairly advanced topic. You can work a long time with JSF without ever seeing one of them. But every once in a while, they come in handy. Rudy’s example is pretty impressive in that regard: sometimes even an everyday task like enforcing user input in capital letters can be implemented simpler and more safely using a TagHandler. AngularFaces uses both TagDecorators and TagHandlers a lot, and JSF 2.2 itself made TagDecorators popular by using them to implement the new HTML5 friendly markup style.
Continue reading “How to Modify the JSF 2.2 Component Tree Safely: TagDecorators, TagHandlers and PreRenderViewEvent” »

Final Version of AngularFaces 2.0 Published

Fork me on GitHubIt was a hot summer day when I was sitting in the garden and started to dream. Wouldn’t it be nice to add AngularJS to JSF?

Today it’s a sunny day too, I’m sitting in the garden again and AngularFaces 2.0 is finished (it’s even available on Maven Central). Now it’s possible to use AngularJS without abandoning JSF. Even better: it’s very simple, and AngularFaces 2.0 has much more in store for you. It adds a couple of features beyond AngularJS, such as bringing the Bean Validation annotations to the client and helping you to target an international market by reducing the boiler plate code needed to translate an application. AngularFaces is worth a look if you don’t want to involve yourself AngularJS programming.

Continue reading “Final Version of AngularFaces 2.0 Published” »

AngularFaces 2.0 RC4 Published

Fork me on GitHubThe final release of AngularFaces 2.0 is coming near! The latest – and possibly last – release candidate RC4 has been published today. Here’s what’s new and noteworthy about the version:

  • Reduced requirements on the Java version: Java 6, 7 and 8 are supported. The binaries in the distribution folder are compiled with Java 6.
  • You can now use traditional JSF AJAX requests with AngularFaces (although it’s not advisable to do so, because AngularJS doesn’t seem to support this).
  • Improved compatibility to Internet Explorer 11 (and probably older versions as well, but since I’ve updated my PC to the latest version, I can’t really tell).
  • Several common HTML tags can now be used without preceding “h:”.
  • <input> can now be used without “type” attribute. The type is derived from the JSF bean. This isn’t exactly a new feature: AngularFaces supports the same feature for <h:inputText> since a long time. The news is that also the native HTML5 <input> is supported.
  • Client-side error messages use the PrimeFaces design in PrimeFaces views (and the simpler Mojarra design otherwise).
  • AngularFaces input fields can now display boolean JSF bean attributes (and are displayed as checkboxes).

Work on the manual on AngularFaces.com is also progressing nicely. The same applies to the demo applications.

As usual, you find the updated jar file and two demo war files on the AngularFaces dist folder on GitHub.

Java 8 Update 20: String Deduplication

Remember my last April prank? I span a yarn about the great way Oracle managed to squeeze every conceivable String into a 64-bit number. Funny thing is my vision comes sort of true. Of course, not the way I claimed. That was nonsense meant to be easily seen through (“There are only so many Strings a gal or a guy can think of – so everything you have to do is to assign them a 64-bit number”). But it’s true that a lot of work at Oracles’ is dedicated to optimize String management.

Java 7 Update 6 improved the speed of String.substring() by sacrificing a little memory efficiency (see my article Recent Improvements of Java’s String Implementation). Java 8 Update 20 takes the opposite approach: it sacrifices a little CPU efficiency in order to reduce memory footprint. On the long run this should reduce the strain on the CPU, too. In other words: most real worlds programs should run faster.

Everybody who’s analyzing a Java program in a profiler can’t avoid noticing: Java programs create incredible quantites of character arrays. Most of them are part of String objects. Java represents its String as objects, meaning there’s a pointer to a character array. That’s not exactly the most efficient way to represent a sequence of characters. It’s just what you get if you want to represent a String as an object instead of defining it as a native primitive type. However, the developers of Java got aware of the problem a long time ago, so they invented the String.intern() method. In general, it’s a bad idea to call this method by yourself (because you’re trying to outperform the JVM’s optimization), but sometimes it reduces your application’s memory footprint tremendously.

Putting it in a nutshell, String deduplication is a clever way of calling String.intern() as part of the garbage collection. Since Java 8 U20 the garbage collector recognizes duplicates String and merges them. As mentioned above, this costs some CPU power, but it shouldn’t be much of a concern because the garbage collector runs in its own thread. Plus, on the long run the reduced memory footprint makes the garbage collector run faster.

There’s a discussion on reddit indicating String deduplication really works, but sometimes you have to adjust the JVM parameters. I suppose that’s one of the reasons why the feature isn’t activate by default yet. You have to activate manually by starting the JVM with the parameter

-XX:+UseG1GC -XX:+UseStringDeduplication

Still, I sometimes wonder why a Java String has to be an object. Back in the seventies or the eighties, when the first languages became powerful enough to represent a String by means of the language instead of defining it as a primitive type, it quickly become a fashion to do so. Probably there are other reasons, but I always had the impression language designers considers this a sign of their language’s maturity. But being able to express a String as a library object doesn’t mean to have to do so. If Java were to use zero-terminated character arrays (the way BASIC does) or if it were to use a character array with a preceding length byte1, hardly any developer would notice. But the implementation gets rid of a pointer, simplifying memory management and garbage collection. The only convincing advantage of making Strings part of the language libraries is the ability to derive custom classes. Sadly, the Java developers prohibited this very early in the Java history by making String a final class. They did it for a good reason – but still, it’s a pity. Groovy’s GStrings show what you can do when you allow to derive from Strings.

That said, I’d like to point you to Java Performance Tuning Guide. They’ve written an in-depth article about Stringdeduplication.

Dig deeper:

Java Performance Tuning Guide on String deduplication
discussion on reddit on the topic (well, one of them – possibly the most interesting one)

  1. or a 64-bit word in the age of Gigabyte memories – and the characters should be at least 16-bit to support UTF-16. I used “byte” and “character” as a figure of speech. Is there a catchy word for 16 or 32-bit integers?

JSF 2.2 HTML5 Cheat Sheet

I’ve read a lot about the new JSF 2.2 HTML5 input fields, but until today I didn’t realize I hadn’t read a comprehensive introduction about this feature. I used to be happy with the short examples I was presented at conferences. However, there’s more than just <input type="text" jsf:value="#{my.favoriteBean.attribute}" />. As it happens, the documentation hides in plain sight. The JavaEE Javadoc tells you everything you have to know about the Mapping between HTML tags and JSF components. For the sake of convenience, this article summarizes the key points.

The general idea is to enable a web designer to design your JSF page without running a server. So it’s native HTML, and it should display nicely in a browser if opened as a simple HMTL file. Putting it in a nutshell, renaming a JSF file from *.xhtml to *.html doesn’t modify the design of the page.
Continue reading “JSF 2.2 HTML5 Cheat Sheet” »

AngularFaces 2.0.0 RC3 Published

Fork me on GitHubRelease candidate 3 of AngularFaces 2 has been published. Basically, it’s a bug fix release. Here are the release notes:

  • Bugfix: compatibibility with PrimeFaces <prime:datatable>
  • Bugfix: AngularFaces now copes with bean attributes, even if they are Strings (quite a funny bug, if you take in mind Strings are usually tested first).
  • Improved translation support (now includes the attributes “header” and “headertext”)
  • Bugfix: Labels and messages aren’t added automatically if the JSF view designer already defined a label an/or a message
    • In addition, I’ve started to write a tutorial. To read the tutorial, go to AngularFaces.com. The example projects accompanying the tutorial are on GitHub. At the time of writing, the first two steps (“Bootstrapping” and “Labels and Messages”) of the tutorial are finished (plus a couple of sketches of the remaining chapters).

AngularFaces 2.0 Embraces Both HTML5 and PrimeFaces

Fork me on GitHubNow that’s a surprise: AngularFaces becomes more powerful by getting rid of it’s widgets. Quite a development for JSF widget library.

Instead of defining its own widgets AngularFaces 2.0 pimps up widgets provided by other widget libraries. In particular, it adds AngularJS to the new JSF 2.2 HTML5-style widgets. But of course it doesn’t stop there. It’s also compatible to the widgets of Mojarra and MyFaces and to many PrimeFaces widgets. Plus, it allows AngularJS to modify almost every JSF attribute.

Update Sept 16, 2014:
In the meantime I’ve released the final version of AngularFaces 2.0, so you may also be interested in the announcement of the final version.

What’s in store for you

You may already have guessed it: AngularFaces underwent a profound overhaul during the last three weeks. Now it’s much more versatile and much more “Angular”. Let’s summarize the key points of AngularFaces 2.0:

  • It integrates AngularJS and JSF seamlessly. The difference between the two technologies becomes blurry. It doesn’t matter if you modify an attribute on the server side or in your AngularJS code. Both options are available to you. You can even do both, if you insist.
  • In particular, JSF bean attributes are mapped into the AngularJS model. The mapping works in both directions, of course: the next request transfers changes made on the client side back to the server. After processing the user input the server update the AngularJS model again.
  • Bean validation attributes (JSR 303) are evaluated on the client side by AngularJS (resembling the Client Side validation of PrimeFaces).
  • Labels and error messages are added automatically to your input field (unless you tell AngularFaces otherwise).
  • AngularFaces 2.0 makes internationalization much less scary. Translating your application into another language becomes very simple.
  • AngularFaces 2.0 takes a new approach to AJAX. Mind you: you don’t need server side rendering when you’re using powerful Javascript widgets, so I reduced the AJAX responses to the attribute value updates, making them fast and slim.
  • Every AngularJS attribute is treated as a pass-through attribute. You don’t have to declare it explicitly as a pass-through attribute. For instance, ng-show, ng-hide and many more can be used in the JSF file the way you’d use it in a pure AngularJS application.

As a result, AngularFaces views are pretty fast, contain very little boiler-plate code and may look almost like a native AngularJS page. Everybody coming from Javascript programming will get to speed in virtually no time. However, transition from JSF is smooth: you’re free to write a traditional JSF page with a few AngularJS additions.
Continue reading “AngularFaces 2.0 Embraces Both HTML5 and PrimeFaces” »

JSF 2.2 and PrimeFaces 5 on Spring Boot

Fork me on GitHubRecently I reported about Spring Boot (see Application Servers are dead! (Sort of)), an interesting approach to embed your application server into your application instead doing it the other way round.

However, Spring Boot is a fairly new technology, so the documentation is still work in progress. Most of the documentation is great, but there are still sentences like

Applications that are not already Spring applications might be convertible to a Spring Boot application, and the guidance above might help, but your mileage may vary.

Most JSF applications clearly fall into this category. So I’ve prepared a JSF template project to spare you some of the mileage. Currently there’s a simple simple PrimeFaces project and a more advanced project demonstrating Spring and JSF scopes.

To make things more interesting, I added Gradle and JSF custom scopes to the equation.
Continue reading “JSF 2.2 and PrimeFaces 5 on Spring Boot” »

Newsflash: Java, UTF-8 Surprises and Character Encodings

Did you know characters don’t always fit into chars?
Did you know String::length() does not always return the number of letters of the String?
Did you know you can’t reliably read a text using a ByteArrayInputStreamReader?
Did you know many characters have more than one Unicode encoding?

The latter you should know, at least if you’re concerned about writing a secure web application. Hackers sometimes hide their malicious code by using ambiguous UTF-8 encodings. If the request is interpreted correctly, it simply contains an odd character. But if your application interprets the request as simple ASCII code, it contains executable Javascript code. The “<” sign can be hidden as a modifier to a unicode character, so a (careless?) firewall doesn’t recognize it as the start of malicious code.

Before leading you to McDowells great “guide to character encoding”, I’d like to show a couple of interesting characters to you:

  • The letter A is encoded in UTF-8 as 0x41. That’s simply good old 7-bit ASCII code.
  • The french letter é (as in écouter) is part of many 8-bit extensions of ASCII. In UTF-8 it’s encoded as 0xE9.
  • However, it also can be constructed as a combination of “e” and the accent “´”. That amounts to 0x65CC81 in Unicode. That’s the first example of the three byte representation of a character.
  • Characters can become as complicated as क्तु. That’s a 12 byte encoding in UTF-8: E0A495 E0A58D E0A4A4 E0A581. As far as I can tell, that’s a base character followed by three modifiers.

The last character doesn’t fit into a Java char, and "क्तु".length() yields 4 – albeit it’s considered a single Devenagari letter.

There’s a lot more information on Java character encoding on McDowells “exhausting, but not exhausting” article Java: a rough guide to character encoding.

Useful PrimeFaces DataTable Events

I always used to skip over page 167 of the PrimeFaces 5 manual. That’s too bad: it’s an exciting page. It’s a list of the events a <p:dataTable> can fire. That’s no less than 19 interesting events.

Quick reminder: what are JSF events?

Chances are you already know the concept of JSF events from the <f:metadata> section of your JSF applications. Strictly speaking, the core JSF events I’l describe next belong to a different family than the events fired by the data table. They’ve got a different API. But still, both concepts are similar enough to mention them in the same article.

A standard JSF event, preRenderView, is frequently used together with view parameters. Doing so, your parameterized JSF page can be stored as a bookmark in the browser, much like Amazon allows you to simply copy the link of the book review you’re currently reading and send it to your friends:

        <f:viewParam name="keyword" value="#{catalogController.keyword}"/>
        <f:event type="preRenderView" listener="#{catalogController.doSearch}"/>

Continue reading “Useful PrimeFaces DataTable Events” »

How to Run the Eclipse Formatter From the Command Line

Today I’ve dug out an Eclipse 3.2 article that’s seven years old and is still valid. Considering how much Eclipse has changed since 2007 that’s pretty astonishing. So, if you want to know how to format an entire Java Eclipse project in no time, you may ask Peter Friese. Of course you’re invited to read on instead and learn some additional hints.
Continue reading “How to Run the Eclipse Formatter From the Command Line” »

Microservices – The New Silver Bullet?

Recently microservices are getting popular in the Java world. The general idea is our applications have become too complex. Better split them into smaller chunks, small enough to swallow for a small team or even an individual. They have “to be small enough to fit in your head”.

Actually, this idea is far from being new. When functions, classes, modules, portlets, SOA services and business processes were invented, people used pretty much the same words to advocate the new idea. Microservices add a new twist in that they contain the GUI, and in that every microservice uses it’s own database. The application is sliced vertically (as opposed to the horizontal slicing imposed by the MVC model). The result is a small library that can be deployed independently. The application consists of a collection of largely independent microservices working together.
Continue reading “Microservices – The New Silver Bullet?” »

Application Servers Are (Sort of) Dead!

Recently it crossed my mind there’s something wrong with Java application servers. You know, our team is still using them the way they’re meant. The way they were originally meant. We’ve got many applications running on a common application server that’s managed centrally.

I’m told we’re one of the last companies to do so. These days, most companies dedicate an entire application server to a single application and put them in a virtual machine.

In other words, application servers have become part of the application. Originally, it was meant to be the other way round, and that’s why Eberhard Wolff claims application servers are dead. His JAX talk was a real eye-opener, by the way. He expressed the thoughts that ware already lingering in the subconscious part of my mind. As usual, I’ll mention a few key points of his talk in this post, plus a few thoughts of my own. If you’re interested in the entire talk, have a glance at his slides. He also published an article in the Java-Magazin 7.2014 (in German language, and as far as I know, only available in print).

So what’s wrong with the original idea of applications servers? Let me put the question differently: Have you ever seen an application server that runs out of the box, without being modified?
Continue reading “Application Servers Are (Sort of) Dead!” »