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.

The SAF is dead, long live the AF?

After attending the sessions at JavaOne, and in the time leading up to it, it has become clear that poor old Alexander Potochkin is overworked. In all, he leads the technical side of the Swing team, developed the JXLayer library (which is integrated in Java 7 as JLayer), is one of the people involved with SwingLabs, and also is the leader of the Swing Application Framework (SAF). There is more that I probably don’t know about.

I don’t mean to be rude to Alex, he is a cool guy who is doing a great job with a great team (I met a number of them at JavaOne, and they all assure me they are coming to New Zealand for a sunny holiday 🙂 ). I just can’t imagine he can properly do all of these jobs without a project falling by the wayside. It is my opinion that, given current circumstances, it is the SAF that is missing out on Alex’s attention. Or, if he is giving it the necessary attention and time, he is failing to get the necessary community feedback to see it through to completion.

The other issue is that it is impossible to create a SAF that’ll please everyone. There is simply too much Swing history and convention to get past. There was no pleasing the people at the SAF BOF at JavaOne, and the questions Alex was asking were trivial (e.g. do you want @Action or to simply write ActionListeners manually?). In addition, a number of people were unclear of the scope of the SAF. People were wanting docking frameworks, validation, beans binding, etc. The response was always that SAF does not currently intend to support any of these requests.

The SAF is going around in circles. How can it get out of its funk? As one person suggested in the BOF, it needs an expert group to drive it forward. Personally, I would be very careful in suggesting this. It is important that the expert group be tasked with just the pragmatic development of a SAF API. It should try to do this rapidly and clearly document the API and the reasoning. After public discussion, this should be the API that is implemented.

Right now, if the SAF project doesn’t pull finger, sort itself out and take ownership of the public discussion, it is heading towards the junk heap. If that happens, I imagine there will be a jointly developed JavaFX and Swing application framework to be developed in it’s place. This framework will fill the gap that is in the JavaFX niche, and will as a by-product also support Swing. It will be developed by people who can get past the politics of developing an application framework, which may entail reduced public consultation, and instead the development may be sprung on a somewhat unsuspecting public.

Of course, this may not be bad – look at how old Swing is compared with JavaFX. JavaFX is still at the stage of its life where standard approches are still being defined.

So, what’s it going to be – we get behind Alex and help progress a Swing-centric application framework, or we wait for that to fail and a JavaFX/Swing application framework to rise up behind it? As always, comments are welcome.

JavaFX, backwards compatibility, and the path forward

JavaFX at JavaOne impressed me. It is the first time I saw how things could come together to allow for the easy development of applications with both enterprise and consumer user interfaces alike. The combination of the Caspian look and feel, the components, and the team sold me a compelling package. To be clear, JavaFX isn’t ready to be used in many circumstances, as the number of components is too bare, but I am satisfied that this will be rectified in the coming months.

This being the case, and given that JavaFX has been blogged to death, I want to instead cover my opinion on how I believe JavaFX should proceed. I discussed this with a few people from Sun, and I wanted to get the pulse of the (JavaFX) nation on this issue. Let’s be clear – Sun read blogs where there is discussion. I know for a fact the Swing 2.0 discussion from a while ago was heavily discussed internally. I would very much like to see what kind of discussion we get out of this post.

The general question is which path should the JavaFX API take ? Anyone who knows me knows that I like clean APIs, simply for the sake of code cleanliness. You should therefore be able to easily work out my preference 🙂 The options are below, but if you have any other suggestions, please post a comment.

Option 1: Evolve the API over a number of releases, but never remove methods

As demoed in James Gosling’s Toy Show, there are now apps out there using JavaFX, and JavaFX is a publicly available API with a lot of marketing behind it. There are books in production and already released that explain the API as it currently is. To set the API in stone now would give people more certainty that they should start to commit to JavaFX in their systems. This doesn’t stop the API from growing, or for old methods to be deprecated. This is what we have in most API’s – and it is possible that the end result is a hugely convoluted API (need I do the *cough*Swing*cough* thing, or was it too obvious anyway?).

Option 2: Clearly state the API is undergoing change, but promise API stability for a future release

This is what I call the ‘Google Collections’ approach, as it is what Google have done with their collections API. In this approach, Google has been very, very clear that their upcoming 1.0 release will be a 100% stable API that will not change. They have also been very, very clear that releases leading up to the 1.0 release will potentially have huge API changes. The benefit of this approach is that when 1.0 is released, the public can be certain of a completely stable, and clean / polished API. The downside of course is that early adopters are burnt on releases.

My preference is for the later. I want a clean API that is going to last for a long time. I want to see Sun publicly announce a roadmap for the next x months which will culminate in a stable, rock solid, and clean API that will last for the foreseeable future. As things stand, there is no clarity on what will happen next with the JavaFX API, and I think that is at least partially because the public has not yet spoken. If we don’t speak up soon, it’ll be too late.