JavaFX Scene Builder Released


The new JavaFX Scene Builder graphical tool for editing FXML has been released.

You can read the announcement here:

There is a download here:

Looking forward to using this on some of the new JavaFX projects we’re working on.

Did you like this? Share it:

What I Learnt about JavaFX Today


In case you haven’t heard, JavaFX 2 is the new Desktop / web / client framework for Java. It’s had a considerable overhaul since JavaFX 1 (which was frankly not that impressive). Out has gone the custom scripting language, and instead you can write it using standard Java and an XML-based language for the actual UI presentation.

So today, a friend and I got together at one of our places to teach ourselves a bit of JavaFX. Here’s what we learned, starting with some of the yak-shaving we had to do:

  1. First of all, install the JavaFX developer preview – get it here
  2. You have to unzip it, and place the resulting directory somewhere sensible, chown’d to root.
    • I put it in /usr/local/javafx-sdk2.1.0-beta/
  3. Next, you’ll want an IDE to go with that
    • Netbeans is the IDE which is the most advanced and usable with JavaFX 2
    • You want Netbeans 7.1 RC2
  4. To get this to install on a Mac, you need JavaForMacOSX10.7.dmg – no lower version of official Apple Java will do, and an OpenJDK build won’t work either (even if it’s the correct version or higher)
  5. Once it’s installed, Netbeans will work fine with other JREs (I was mostly running it against the Java 7 Developer Preview)
  6. To start new JavaFX projects, you need to tell NetBeans where to find JavaFX. For this, you need to create a new JavaSE platform profile, and add the JavaFX dependencies in manually.

Once it was installed, we started working with JavaFX properly. Our project for the day was to try to replicate some of Victor Grazi’s concurrency animations in JavaFX – both to teach ourselves the JavaFX technology, and also create some teaching tools as outputs.

  • JavaFX uses Application as the main class to subclass
  • The API docs are here

If you’ve done any Flex development, JavaFX will seem very natural. E.g.

  1. The FXML file provides the UI and layout
  2. The top level FXML element has a fx:controller attriubte, which defines the Control for this View
  3. FXML elements are bound to members contained in the controller class which have been annotated with the @FXML annotation
  4. The fx:id property is used to define the name of the member that is being bound to the FXML element
  5. Binding also occurs to methods. E.g. buttons bind use an onAction handler, like this: onAction="#isFutureDone"
  6. The #methodName syntax is used to say which method should be called when the button is pressed.

From this it’s very easy to get started with building up a basic application. Some things that we found:

  1. The UI thread can be quite easy to tie up. Don’t ever call a blocking method directly from the Control object, as triggering this code path on the UI thread will cause the display to hang.
  2. Be careful of exception swallowing.
  3. If you have a method in an object which is updating a UI element, but which is not annotated with @FXML, then you seem to need to call requestLayout() on the UI element after updating it. We’re not sure we got to the bottom of why – please enlighten us if you know why.
  4. The framework seems to use custom classloading to transform the FXML file into a “scene graph” of objects, seemingly a bit like how Spring does it.

On the whole, we were quite impressed with our short hack session. The APIs seem clean, and the overall design of the framework seems sound. There were a few stability issues, but this is bleeding-edge tech on Mac – both the JDK and the JavaFX runtime are Developer Previews.

We’ll definitely be back to do some more with JavaFX, and look forward to seeing it mature and become a fully-supported OSS framework for client development in Java.

Did you like this? Share it:

The OpenJDK as the default Java on Linux


Hi All,  (this post is x-posted from Martijn’s personal blog and the ljc blog)

Recently I’ve received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it :-) 


Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source “Operating System Distributor License for Java” (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle’s Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve ‘official Java’ for all of us.

I want the Oracle version!
Linux users who need to use the proprietary parts of the Oracle JDK 6 or Oracle JDK 7 binaries can of course as usual simply get the gratis download at under the same terms as users on other platforms. However, if it is due to a ‘bug’ that is discovered I strongly encourage those users to submit a bug report to the OpenJDK project, so that any issues can be fixed for all of us.

Opinions and further comment is welcome!

Did you like this? Share it:

Manipulating Files in Java 7


Manipulating Files in Java 7

The following is a modified snippet from a draft of The Well-Grounded Java Developer. It gives you a quick taster of how much easier it is to manipulate files in Java 7 than in previous versions. By using the new Files class and its many utility methods, you can perform the following operations on files with only a single line of code:

  • Create
  • Delete
  • Copy
  • Move/Rename

TIP A quick note on Path. This post assumes you have some passing familiarity with the new Java 7 Path class, if not here’s a quick introduction! Path is the logical abstraction of a location on the file system, e.g.  c:\ is a Path as is ../foobar.txt

Let’s start by looking at the creation and deletion of files.

Creating and Deleting files

By using the simple helper methods in the Files class you can create files and delete them easily as well.

TIP If you are running the code snippets in this section, replace the actual paths with ones that match your file system!

The following code snippet shows basic file creation, using the Files.createFile(Path target) method.

Path target = Paths.get("D:\\Backup\\MyStuff.txt");
Path file = Files.createFile(target);

More often than not you want to specify some file attributes on that file for security purposes as well as knowing whether the file is being created for the purpose of  reading and/or writing and/or executing. As this is file system dependent, you need to utilise a file system specific file permissions class and its helper.

For example, PosixFilePermission and PosixFilePermissions for a POSIX compliant file system. An example of setting read/write for the owner-group-all in a POSIX file system is as follows.

Path target = Paths.get("D:\\Backup\\MyStuff.txt");
Set<PosixFilePermission> perms 
    = PosixFilePermissions.fromString("rw-rw-rw-");
FileAttribute<Set<PosixFilePermission>> attr 
    = PosixFilePermissions.asFileAttribute(perms);
Files.createFile(target, attr);

The java.nio.file.attribute package contains a list of provided FilePermission classes. File attribute support is also covered in further detail in chapter 2 of The Well-Grounded Java Developer.

WARNING When creating files with specific permissions, do be aware of any umask restrictions or restrictive permissions that the parent directory of that file is enforcing. For example, you may find that even though you specify rw-rw-rw for your new file, it is actually created as rw-r–r– due to these restrictions.

Deleting a file is a bit simpler and is performed by the simple Files.delete(Path) method.

Path target = Paths.get("D:\\Backup\\MyStuff.txt");

Next up a quick overview on copying and moving files in a file system.

Copying and Moving files

By using the simple helper methods in the Files class you can perform your copy and move operations with ease. The following code snippet showcases a basic copy, using the Files.copy(Path source, Path target) method.

Path source = Paths.get("C:\\My Documents\\Stuff.txt");
Path target = Paths.get("D:\\Backup\\MyStuff.txt");
Files.copy(source, target);

More often than not you want to specify some options with the copy operation. In Java 7 you can use the StandardCopyOption enum to specify these options. The next example uses an overwrite (that is, replace existing) option.

import static java.nio.file.StandardCopyOption.*;

Path source = Paths.get("C:\\My Documents\\Stuff.txt");
Path target = Paths.get("D:\\Backup\\MyStuff.txt");
Files.copy(source, target, REPLACE_EXISTING);

Other copy options include COPY_ATTRIBUTES (copies over the file attributes) and ATOMIC_MOVE (ensures that both sides of a move operation succeed or the operation gets rolled back).The move operation is very similar to the copy operation and is executed using the atomic Files.move(Path source, Path target) method.

Again you typically want some copy options to go with that move, so you can use the Files.move(Path source, Path target, CopyOptions...) method (note the use of varargs).

In this case we want to keep the attributes of the source file when we move it as well as overwriting the target file (if it exists).

import static java.nio.file.StandardCopyOption.*;

Path source = Paths.get("C:\\My Documents\\Stuff.txt");
Path target = Paths.get("D:\\Backup\\MyStuff.txt");
Files.move(source, target, REPLACE_EXISTING, COPY_ATTRIBUTES);

As you can see, the new NIO.2 API for file manipulation is simple to use, we hope you enjoyed this little taster and our apologies for the long wait between posts!

Did you like this? Share it:

Lambda Syntax Alternatives


The discussion on the lambda-dev mailing list has started to address the issue of what the Java language syntax for lambdas / function literals ought to look like. Let’s look at a slightly non-trivial example and try to tease the issues out.

The Perl people have a nice example of something which uses function references in a somewhat functional way – they call it the Schwartzian Transform (but I believe it’s originally a Lisp trick sometimes called decorate-sort-undecorate). As there are just us JVM chickens here, I rewrote it in Clojure (it’s actually one of my examples in Chapter 9 of the book).

Here’s a snippet of Clojure code which defines a function to perform the Schwartzian transform. Basically, it provides a very simple way of sorting a list based on an auxiliary function (called a “keying function”) provided by the caller.

(defn schwarz [x f]
  (map #(nth %1 0)
       (sort-by #(nth %1 1)
                (map #(let [w %1]
                     (list w (f w)) ) x))))

The code is doing three separate steps – creation of a list consisting of pairs (the original values paired up with the value obtained by applying the keying function to the original values), then sorting the pairs based on the values of the keying function. Finally a new list is constructed by taking only the original value from each pair in the sorted list-of-pairs (and discarding the keying function values).

What might this look like in the various proposed Java syntax variants? Let’s take a quick look at each one (note that because Java’s type system is much more static, a lot of our type declarations are more than a little long-winded):

// Strawman, with round brackets for single-expression lambdas
public List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {
return map(#(T w)(makelist(w, f.apply(w))), x)
       .sort(#(Pair<T, V extends Comparable<T>> l)(l.get(1)))
       .map(#(Pair<T, V extends Comparable<T>> l)(l.get(0)));

// Strawman, with braces for all lambdas
public List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {
return map(#(T w){makelist(w, f.apply(w))}, x)
       .sort(#(Pair<T, V extends Comparable<T>> l){l.get(1)})
       .map(#(Pair<T, V extends Comparable<T>> l){l.get(0)});

public List<T> schwarz(List<T> x, Function<T, Pair<T,V>> f) {
return map({T w -> makelist(w, f.apply(w))}, x)
       .sort({Pair<T, V extends Comparable<T>> l -> l.get(1)})
       .map({Pair<T, V extends Comparable<T>> l -> l.get(0)});

// SotL
public List<T> schwarz(List<T> x, Function<T, Pair<T,V>> f) {
return map(#{T w -> makelist(w, f.apply(w))}, x)
       .sort(#{Pair<T, V extends Comparable<T>> l -> l.get(1)})
       .map(#{Pair<T, V extends Comparable<T>> l -> l.get(0)});

// Redmond
public List<T> schwarz(List<T> x, Function<T, Pair<T,V extends Comparable<T>>> f) {
return map((T w) -> {makelist(w, f.apply(w))}, x)
       .sort((Pair<T,V extends Comparable<T>> l) -> {l.get(1)})
       .map((Pair<T, V extends Comparable<T>> l) -> {l.get(0)});

How to evaluate them? My criteria are:

  1. Needs to start with a visible identifying mark, so that lambdas stand out from the surrounding code. The # is a handy character for this.
  2. Needs to use the {} delimiting syntax. Closures are a kind of block, so they should be block-like in code.
  3. Needs to be all in one piece, so the syntax has a visual consistency and the lambda appears as a single unit.
  4. Preferably, needs to have a specialized short form for function literals which take no parameters (nullary lambdas).

Based on these criteria, Redmond is the worst possible choice for me – and my experience writing Scala for the book bears this out – I found Scala’s function literals much harder to use without problems than those in other languages. BGGA is a little better, but I don’t like the lack of a simple identifying mark that tells me “Hello! I’m a lambda”.

This brings it down to a choice to between SotL and Strawman with always-brace. The choice of these two is somewhat arbitrary. Strawman-always-brace looks, to my eyes like a true Java method declaration, but with the “magic name” # – whereas SotL is genuinely new syntax, but feels closer to the Redmond and BGGA styles – so could well be an acceptable compromise for developers who are comfortable with those forms.

Pulling it all together, my preferred choices are:

  1. SotL
  2. Strawman-always-brace
  3. BGGA
  4. Strawman-single-expression-round
  5. Redmond

Please use the comments to tell us what you make of this issue. Of course, this won’t be in Java 7 – but it’s not too early to start thinking about Java 8 and the future.

Did you like this? Share it:

Why Ben has been nominated for the Java SE/EE Executive Committee

No Comments

As many of you will have heard, Ben will be representing the London Java Community as a nominee for one of the open seats on the Java SE/EE executive committee!

This is a great opportunity for a Java User Group to have a direct say in the future of Java 8, 9 and the overall ecosystem. I know Ben will be a great representative for the LJC and for all Java developers around the world.

The LJC is trying to get all questions/responses in one place, so for more more details see


Did you like this? Share it:

Ben and Martijn are interviewed at Javaworld

No Comments

The interview is live here

Did you like this? Share it:

Some insights from Oracle on the their plans for Java

No Comments

Ben Evans and I recently spoke at the Scandinavian Developers Conference on Java 7 and polyglot programming on the JVM. We also had a fun afternoon on a panel discussing “Whether the community or the corporations will control Java in the future”. That discussion probably deserves it own blog post, but more interestingly we spent a long time talking to Henrik Stahl from Oracle.

Henrik is Oracle’s director of Java platform strategy – and an official spokesperson from Oracle, able to pronounce on behalf of Oracle regarding Java. Henrik was able to give us the following insights (some of which you may have heard before):

  • Oracle is very committed to Java and sees it as essential to their future.
  • An open, vibrant community is an essential part of that future, in fact it’s the community that’ll determine what standard technologies and techniques should go into the std platform (SE/EE).
  • The JVM will remain open and free forever, and additional technologies will be incorporated and open-sourced as appropriate.
  • Oracle is looking for willing partners in the community to engage and be part of the conversation – and they are listening.

Some other points:

  • Oracle is a much larger company than Sun and will not rush out any communication which is “half-baked”. This leads to much longer response times, and so the community should not jump to conclusions just because Oracle hasn’t responded yet. They’re aware of the problem here and are trying to fix it.
  • Oracle are trying to unify the licensing position around all Java products. This is taking time because Oracle do not have as many lawyers per capita as Sun did. Sun used several different licenses and disentangling is hard. Oracle are trying to simplify and be more open. The fun quote here was that “Oracle does not have enough Lawyers.”
  • Oracle wants the JCP to evolve – the current form is being revised. There are some new JSRs coming which alter the JCP itself. For example, one of the changes that’s already been announced is that Expert Group discussions (except for the procedural arrangements of who’s free at what time / place for physical meetings) must be conducted in public.
  • A lot of *really* neat JRockit technology is coming to OpenJDK. It’s going to take time, but some of the stuff which is coming is going to make the VM better than ever.
  • Oracle are hiring in a number of areas, including people to work on the core language, VM and overall strategy.

Hopefully that helps you understand some of Oracle’s strategy going forward.

If you’re London based:

We’re hoping to get Patrick Curran (JCP Chair) to come and speak at an LJC event and kick off a practical program where _you_ can get involved in determining the future of Java and its ecosystem and help influence Oracle to make decisions that will benefit all of us in our working careers. Patrick will be able to speak specifically about the JCP in more detail – as that’s his specific area.


Martijn & Ben

Did you like this? Share it:

Official Java 7 for Mac OS X – Status


Hopefully, by now, everyone knows that Apple joined the OpenJDK project last year. What does that mean?

  • Apple will contribute the code that they used for their private Mac Java builds as GPL code to OpenJDK
  • Oracle will take over the stewardship of the Mac port of Java
  • Over time, the Mac platform will become a completely first-class citizen in the Java world

This is good news for Java developers who want to develop on Mac. It’s also good news for Mac users – as it means that, for example, the native Aqua look-and-feel will continue to be supported – so Java desktop apps on Mac will look lovely. I, for one, can’t wait to see what Nimbus look-and-feel will look like under native Aqua.

Over the last few days, there have been some developments – for example this wiki page, detailing the progress of the Mac port, has appeared. Buried at the bottom of the page is a link to a page where the open bugs for the Mac port are being publicly tracked (as they’re ported across from Apple’s internal system).

Development is focused around JDK 7 – the basic idea is to take a fork of the community-maintained BSD port, and add Apple’s code to it, to produce a Mac-specific port. Relevant bug fixes should be able to go both ways between the two related ports, where possible.

All of this is likely to take time, however. The official line from Oracle is that JDK 7 will GA with Windows, Linux and Solaris as first-class supported operating systems, and the Mac will release as soon as possible after, with the hope that at some point in the future updates for the Mac version will be released at the same time as other OSes.

This applies to the Oracle-supplied binary builds. Of course, the OpenJDK code (which Oracle regard as the reference implementation) will be available (and GPL) for anyone who wants to build their own binary.

Here at, we think that we could be looking at roughly a 3 month gap between Java 7 GA and a Mac release – so maybe October 2011 if all goes well. For now, we’re pretty happy running the community-provided OpenJDK builds. There are occasional problems with non-fatal X11-related exceptions clogging up standard out – due to some of the Mac’s uniqueness, but on the whole, it’s not bad at all for a pre-release product.

Have you tried any of the community builds? Let us know what you think in the comments.

Did you like this? Share it:

Method Handles & invokedynamic – on by default

No Comments

Quite a significant milestone today – The change request to switch on Java 7’s MethodHandle and invokedynamic features by default is in. Once this propagates into the OpenJDK repositories, we will see one of the largest features of Java 7 finally land ready for use.

The details of the CR are here.

MethodHandle and invokedynamic are covered in a brand-new chapter of the book “Classfiles & Bytecode” – which will be coming to a MEAP near you very soon.

Did you like this? Share it:

Older Entries