Java 8 method references

Java 8 is finally out officially and it brings probably the biggest change to the Java platform ever; lambda’s. Lambda’s are a very powerful technology which will have major influence on the way API’s in Java will be written, but the first critical sounds also are heard already.

Lambda’s in Java have two main aspects; one is the powerful stream API, where all kinds of processing is chained and in that way multicore processing is easily made possible. The other aspect is the replacement of the anonymous inner classes scaffolding, and that is probably the thing people are exited about first, when discovering lambda’s in Java 8. Let’s take a peek using my latest hobby project as an example.

In the previous blog I’ve written about CircularPane; a way to layout nodes in JavaFX in a circle. Below is an example of how some tests in CircularPane look (the green circles are debugging hints):

CircularPaneRectanglesAndCirclesDebug

One of the latest additions is that nodes can be animated into their positions. The example below shows that the left two CircularPanes animate their nodes into place “over the arc”, the right two “from origin”.
circularPaneAnimation (more…)

Continue ReadingJava 8 method references

Round and round she goes

JFXtras has a TimePicker that uses a number of Sliders to represent hours, minutes and seconds. And even though this is functionally an OK user interface, it is visually not very appealing.

TimePickerHM

Recently I upgraded to a new phone and ran into this Android TimePicker, which I liked better than my slider UI. So I figured I would try and create something similar.

android-calendar-time-control-1

The first thing that is needed to create a UI like this, is to layout nodes in a circle. That turned out not to be too difficult, but the implementation was very specific for the circular time picker I was working on. And I figured it would be nice if the circular layout was reusable, so I got side-tracked in creating CircularPane. (more…)

Continue ReadingRound and round she goes

Named queries are evil

  • Post category:JavaJEEJPA

The JPA specification has the concept of named queries which is an attempt to ‘Don’t Repeat Yourself’ (DRY), but in my opinion it is more a ‘Mistake By Specification’.

The fact that a query is written as a string, and therefore is not compiler checkable, is a missed chance (solutions like QueryDSL offer great alternatives here), but not the point I would like to make. My issue is with the ‘named’ part.

The link to named queries above has the following example:

@NamedQuery(
    name="findAllEmployeesByFirstName",
    queryString="SELECT OBJECT(emp) FROM Employee emp WHERE emp.firstName = :firstname"
)

What you see here is that there is a definition of a query (usually located at the top of the Entity class) and somewhere else the query is used to read employees from the database, like so:

Query queryEmployeesByFirstName = em.createNamedQuery("findAllEmployeesByFirstName");
queryEmployeeByFirstName.setParameter("firstName", "John");
Collection employees = queryEmployeesByFirstName.getResultList();

The problem is that the named query in no way enforces or even specifies the parameters it requires. In this case it requires one, and its name of course suggest that, but this is a very thin and unstable relation, and not something I would like to base the stability of my code upon. After all, we all know how easy the name may go out-of-sync to the contents of the query. (more…)

Continue ReadingNamed queries are evil

The Java 9 named parameter pitch

  • Post category:Java

In the previous post Daan van Berkel again made clear that a fluent API is so much more readable than the “regular” API’s. Unfortunately a lot of projects do not have the luxury of being able to convert their code to the fluent paradigm. But there are some easy improvements possible, one of them would be the introduction of named parameters.

Let me first start with a simple example:

    component.show(false, true);

Well, there is nothing wrong with that code, except as an outsider you have no clue what it is doing exactly. What do the two booleans indicate? This can only be solved by a round trip to the documentation. A fluent API would fix this:

    component.modal(false).centered(true).show();

(more…)

Continue ReadingThe Java 9 named parameter pitch

To comment or not, that is the question

  • Post category:Javaunittest

Recently I worked my way through the “Effective Unit Testing” book. A nice read, nothing too complex or difficult, but it is always good to read the opinions of someone who really put some effort into a certain topic. One point was the question if code should contain comments or not, mainly because comments can have a negative impact because they can be incorrect and misleading. So the proposed solution was to write code that does not require comments at all; write “self documenting code”.

In my current project I run into similar situations on a daily basis; my idea on how code should look differs from the most of the other developers. I see people writing tons of code without a single comment in them and declare them “self documenting”. The problem is that for some reason I do not seem to be able to get comfortable with that code, and I’m really starting to wonder if I’m getting old, and am missing out on the “new and improved way” of doing things. But I’m not one to accept that without an effort, so I gave it a shot.

Below is an example of a simple unit test. Please do not spent too much time on this, because it is the “before” example. But the test is ok, there is nothing technically wrong with it, it just can be written better.

    public void testVerifyGroupThenAddClient() throws ValidateException {
        // group starts off not verified
        GroupCare assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());

        // add client
        groupCareManager.addClient(groupCare, client.getData(), groupActivity.getData(), user);

        // group is not yet verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());

        // verify the group
        groupCareManager.verifyGroupCare(user, groupCare);

        // assert that the group is verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNotNull(assertGroupCare.getVerifiedAt());

        // add new client
        groupCareManager.addClient(groupCare, client2.getData(), groupActivity.getData(), user);

        // group is no longer verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());
    }

(more…)

Continue ReadingTo comment or not, that is the question

FXML builders detection

When you’re in the custom control business, you need hooks into the main framework to get the controls supported well. One of the features of JavaFX is the FXML UI notation format, it allows the coder to define (parts of) a scene with more ease and readability. FXML already is a pretty flexible and open technology, using reflection and the Java Bean standard (aka setters and getters) to try and automatically setup a control according to the values in the FXML file. But there are always situations that don’t fit.

One of those situation is the JFXtras CalendarTextField control and then specifically the date format properties. In the Java API these properties take instances of DateFormat, either a single one, or even a whole list. FXML at the moment does not know how to convert a string to DateFormat. So the dateFormat and dateFormats attributes below result in errors.

<?import javafx.scene.control.*>
<?import javafx.scene.layout.*?>
<?import jfxtras.labs.scene.control.*?>

<VBox xmlns:fx="http://javafx.com/fxml">
    <children>
        <CalendarTextField dateFormat="yyyy-MM-dd HH:mm:ss" dateFormats="yyyy-MM-dd, yyyy-MM, yyyy"/>
    </children>
</VBox>

(more…)

Continue ReadingFXML builders detection

Using CSS in JavaFX to keep the API clean

  • Post category:JavajavafxUI

As a notorious skeptic, the usage of CSS for styling in JavaFX to me was something of a “yeah, nice, but we’ll see how it works out.”. There are some doubts in how CSS will work out when complete skins (like Synthetica for Swing) are created, in combination with third party controls. But last week I had a situation that won me over to the “it’s good” side.

A user of one of my controls, CalendarPicker in JFXtras, came to me and told me about their usage of the control. They had integrated it in their application and styled it Windows 8 alike using CSS. But, he said, our graphical designer wants the arrows of the month and year selector to be on either side of the value, and the value centered instead of left aligned. Shown below is the default UI for CalendarPicker and as you can see, it is not as the designer wants:

calendarpicker_usa

(more…)

Continue ReadingUsing CSS in JavaFX to keep the API clean

Supporting JSR310 (Jodatime) in JFXtras

Probably everyone is exited that Oracle is finally picking up the highly dubious date time implementation in Java called Calendar. It is interesting to see that large companies like Sun really have problems getting something as seemingly simple as date and time implemented correctly. Of course there are two sides to the problem, first there are all the intricacies of date and time, like time zones and other more or less subtle problems (this is where Date went wrong). And secondly there is the implementation aspect, where for 99% of the usages a date or time is considered an immutable value, like a number, easy to use for a developer (this is where Calendar went wrong, just take a look at the output of toString()).

Now, there are reasons why there is a CalendarPicker and not a DatePicker in JFXtras. And the primary reason is that Calendar has a notion of locality, which Date has not; for example in Germany the week starts on a different day (Monday) than in the USA (Sunday).

calendarpicker_usa

calendarpicker_de

Calendar actually is pretty decent when it comes to the domain of dates and times, Jodatime is added to Java 8 is because the implementation, the API, is bad. (more…)

Continue ReadingSupporting JSR310 (Jodatime) in JFXtras

Layout in Android (and JavaFX)

One of my clients allowed me to write an Android application. I have done Java and mobile development before, so it basically comes down to learning the new framework. And that’s something Java developers do on a fairly regular basis. There were some special things, like connecting to a bluetooth barcode scanner, but nothing that some coding-by-googling wouldn’t fix. The application initially was aimed at Android 2.2+ and phones, but in the meantime it’s been upgraded to Android 4.0+ and 10″ tablets, because it needed a stronger visual screen (with loads of images) and the screens of the phones were simply too small.I’d like to share some of the experiences I had with this project.

ReindersAndroidScreenshot_2012-12-10-10-56-39

(more…)

Continue ReadingLayout in Android (and JavaFX)

JavaFX layout, a silver lining?

  • Post category:JavajavafxUI

As described in the previous post, I believe that JavaFX’s layout mechanism is not as good as it could (should) have been. Naturally it is one thing to complain, another to offer improvement suggestions, but the best is to provide alternatives. First there is MigPane, which is a very powerful layout manager, but it is also possible to ‘slap’ on a different API onto existing layout managers. And that is what is being attempted in the JFXtra’s drop-in replacement layout managers. These layout managers extend the existing one, but add a different style.

The basic idea is that instead of writing:

VBox lVBox = new VBox(5.0);
Button b1 = new Button("short");
lVBox.getChildren().add(b1);
VBox.setVgrow(b1, Priority.ALWAYS);

You can write:

VBox lVBox = new VBox(5.0);
lVBox.add(new Button("short"), new VBox.C().vgrow(Priority.ALWAYS));

(more…)

Continue ReadingJavaFX layout, a silver lining?