JavaFX: Bound functions

Binding in JavaFX is of course very cool, and in most circumstances it makes sense. I thought I would make a quick post to explain what a bound function is, and how you should go about interpreting code that uses this language feature. I want to make this post as simple as possible, so as to not overcomplicate things. Before I begin I must thank the Pro JavaFX Platform book guys – I base this explanation on code from their (highly recommended) book.

A bound function looks like this:

The interesting thing about this function declaration is the bound keyword. Looking at the body of the function, we note that the function makes use of variables y and z from the function, and assigns these to variables u and v respectively. In actual fact, the z argument is never used, but an x value is used. This x value is declared outside the function, and is therefore available to be used by it.

This function can be used as per usual in our code simply by calling f(1,2), for example. The feature that is offered by the bound modifier is that we can bind to the function, and when the x or y variables values change, the function will re-evaluate itself. An example is shown in the code below:

On line 3, c is bound to equal the result of calling the function f(a, b), which will result in c being set to equal 7.0 (as a=4,b=5, and x=3, and f is the sum of a and x).

Line four changes the value of x from 3 to 5. Because the f function is a bound function, and the c variable is bound to the f function, we re-evaluate f(a, b), and assign the new value of a+x to c, which means that c is now equal to 9.0.

Similarly, when the a variable is changed on line 5, the function is re-evaluated, as it has determined that the value of a is relevant to the value stored in c.

As noted previously, the value of b is not used in the function, and therefore when it changes it does not impact on the value of the variable stored in c. Because of this, when the value of b is changed on line 6, c is not re-evaluated, as JavaFX is smart enough to know that this does not matter.

If the c variable was declared as f(a, b) (i.e. it is not bind f(a, b)), then when x is updated, c will not be recalculated. Similarly, if the function declaration for f is not declared to be bound, c will not be updated either. However, both of these permutations are legal syntax – it just results in different outcomes. To have f re-evaluate itself and the value be assigned to c, it is necessary the both the function be declared bound, and the assignment to variable c be bound (using the bind keyword).

I hope that makes sense, and clarifies the purpose of the bound keyword.

JavaFX: Thick TextBox Borders

Being the UI geek that I am, I wanted to look at borders in JavaFX, as I had noticed that there seemed to be some inconsistencies. It turns out that I shouldn’t have been too worried – it appears that only one control looks bad, and it is the TextBox control. Shown below is a screenshot of a demo application I wrote, which has a number of controls placed in it.


Note that the borders of all controls look pretty similar – a single pixel width and all a dark grey. Swing suffered from border abuse and inconsistent border colours, so I am happy to see JavaFX is much better.

As mentioned, the only exception is the TextBox, which in the screenshot says ‘Original’. I think it’s probably agreeable to most people that this control has a border which is too thick (and a font which is not consistent with the font used in other controls). To fix the border inconsistency is actually quite simple, as shown in the TextBox directly beneath the original which shows ‘Fixed’. I think it’s probably agreeable that this fits it better with the other controls.

Finally, beneath the ‘Fixed’ TextBox is the text ‘Invisible’, which is actually also a TextBox with no border being shown. I include this for a reason, which will become clear soon.

Anyway, on to the fix – it’s simply a matter of changing the style by adding a line of CSS. The code for the three text boxes is shown below, in the same order as shown in the screenshot.

In otherwords, to fix the border problem, you need to set the border-width to 0, which doesn’t seem correct – you’d expect a control with a border-width of 0 to have an invisible border. In fact, to get an invisible border is shown in the last TextBox – you have to set border-width to be -1.

So, perhaps this is a bug, or perhaps it’s a design choice. I thought I would document it here so that people searching Google for answers might discover it without having to do trial and error. Perhaps this might be fixed in a future JavaFX release.

Additionally, the TextBox font also seems to be inconsistent, but I won’t bother to discuss this as I would hope anyone reviewing this post will also realise they need to fix the font. Perhaps this may be fixed in a future JavaFX release too.

JavaFX: Let’s clarify public-read and public-init

Coming from the Java world, most access modifiers in JavaFX make sense to me as they have equivalents in Java (although the syntax is slightly changed). What isn’t in Java are the two access modifiers public-read and public-init, and at least to me, it is not immediately clear what these modifiers do.

It turns out that public-read means pretty much just that – that the variable can be publicly read from anywhere, but that it can only be written to within the script which declares it. It is possible to ‘widen’ the write-access by prepending either package or protected before the public-read, but this has no effect on the read-access, which remains at publicly accessible.

The public-init access modifier defines a variable that can be publicly initialized in any package. Subsequent write access, however, is controlled in the same manner as public-read, as detailed above. Because of this, the value of this variable is always readable from any package.

So, in summary, when you see anything declared public-*, you should think that the variable can always be publicly read, but it has limitations on being written to. The ability to write to the variable is only available to code within the same script as the variable, unless it has been modified with package or protected access.

For further information and examples, check out the JavaFX Language Tutorial, particularly the section on access modifiers.

Java desktop links of the week, June 22

Another busy week, especially in JavaFX land. I hope everyone is settled back in to work after the JavaOne distraction, and that conference-driven development can be forgotten for another 9 months. On with the news.


  • Congratulations goes to Alex Ruiz, author of the FEST testing software, on the news that he and his wife had a baby girl this week. This is Java desktop related news only as it has already been decided that Colette will be a Java desktop developer in 20 years time.
  • Josh Marinacci posted a FAQ for the Java Store.
  • Often times when you present time to users, it doesn’t need to be precise. This is becoming more popular, especially on the web. If you want to have similar output for your users, look in to PrettyTime, which is an LGPL3 library designed to display human-readable timestamps like, “right now”, “2 days ago”, or “3 months from now”.




  • Andres Almiray posts about the latest FxBuilder, which has support for JavaFX 1.2, including the new controls, charts, etc.
  • Why do we need JavaFX when we have Groovy?’ is the question asked by They then go on to provide a good discussion around the code to draw a coffee cup in both JavaFX and Groovy. Personally, I don’t think the question is fair – why can’t we have JavaFX and Groovy – it’s not like Sun would ever drop JavaFX to instead support Groovy, and I would suggest that for the time being at least, there are far deeper pockets behind JavaFX than many other languages out there.

That’s it for another week. Keep working hard, and, as a (relatively) local comedian would say: say hi to your mum for me.

Mini ‘Pro JavaFX Platform’ Book Review

JavaFX is a very, very fast moving platform (language and API in particular). Fair enough too – it’s come a remarkably long way since it’s inception, and that can’t be a bad thing (except for the whole ignoring Swing thing). As I was busily using Java and Swing, I applied the ostrich principle and buried my head in the ground. I even kicked up a fuss that there should be a proper Swing 2.0. I still stand by that sentiment, but am pleased with the progress of the Swing Generics project, which has very similar goals to my initial discussion (although it clearly doesn’t go as far as one faction of Swing 2.0 supporters, but that’s another story entirely). Because of this I feel I can at last investigate JavaFX without feeling like I’m abandoning the Swing 2.0 cause.

Unrelatedly, I was fortunate enough to have Sun sponsor me to go to JavaOne in San Francisco this year. The highlight for me was meeting everyone I knew virtually, but had never met in real life before. Three of the people I met at JavaOne were three of the four authors behind ‘Pro JavaFX Platform: Script, Desktop and Mobile RIA with Java Technology‘, namely Stephen Chin, Jim Weaver and Weiqi Gao (the other author I missed is of course Dean Iverson).

As I alluded to in the first sentence, JavaFX is a very fast moving target, and so a book is going to struggle to be useful for very long. With the release of JavaFX 1.2, I would assume that most books are somewhat out of date (based on feedback I’ve heard from other people and Amazon reviews). I was not about to learn an older version of JavaFX, so I was pleased to hear that the Pro JavaFX Platform book was completely updated to be JavaFX 1.2 compatible. It would be nice to know which of the other JavaFX books are current, so if anyone knows, please leave a comment (particularly the ‘JavaFX: Building Rich Internet Applications‘ and ‘Essential JavaFX‘ books, which are also both new releases as of JavaOne).

Apress, the publishers of the book, put out an alpha release of the book. The final release I believe is due around mid July. The authors were generous enough to give me a copy of the alpha ebook to read for my own purposes (i.e. they didn’t ask for a review). I thought I’d be kind and give them chapter feedback, so I hope I’ve helped to improve the book quality a little.

So, the book. It’s very good if you are a Java developer who knows nothing of JavaFX. Even if you don’t know Java, it should still be readable, as chapter two provides a very comprehensive background and introduction to the language. It probably isn’t a book for a person new to programming – they should probably get an intro to programming book first – but then what do you expect from a book starting with the word ‘Pro’? 🙂

Jim (one of the authors) wrote up a good summary of what is in each of the chapters on his blog, so I won’t bother to repeat it here.

What I did want to do however was add my personal opinion of the book. Before reading the book I could ‘hack’ at JavaFX, and of course it was always pretty trivial to read JavaFX code and understand it. Since reading the book I have a better understanding of how to build a JavaFX application properly. I also have a far better understanding of the quirks of JavaFX. As I’ve mentioned elsewhere, JavaFX needs better support for Containers (i.e. layout managers in the Swing world), and whilst JavaFX 1.2 goes some way to helping in this area, the book gives a good introduction to new containers offered in JFXtras, such as the JavaFX port of MigLayout. Finally, it gives a good tutorial as to how you should go about developing a mobile offering of your application.

Some of the chapters are very advanced, so I know that I will be returning to the book when I hit areas of difficulty in JavaFX. In this regard, it doesn’t feel like it’s the kind of book that you read once and then shelve on your bookshelf. It will be a good reference manual for anybody building JavaFX applications.

If you are a Java developer who tends to spend time developing user interfaces in Swing, and want to get to know JavaFX, then I happily and wholeheartedly recommend the Pro JavaFX Platform book to anybody out there. I can assure you that it is a good book, and it will get you up to speed very quickly. It is current as of it’s release (due to the hard work of the authors who pretty much wrote the book 1.5 times), so you need not worry that you’re learning old language and API’s. Apparently, future releases of JavaFX are less likely to be ‘breaking’, in the sense of API and language changes, so now is probably a good time to invest in a good resource to learn JavaFX.

If you’re interested in the book, buy the ebook or the printed version when it comes out.

Finally, this has not been a paid advertisement for Pro JavaFX Platform: Script, Desktop and Mobile RIA with Java Technology, although I wish it was 🙂