JavaFX links of the week, July 26

Another week, another bunch of good links right across the JavaFX ecosystem. Let’s dive right into the links of the week!

So, in general, a week of impressive links, with some new releases, and interesting discussions and demonstrations. Keep it up folks, and I’ll catch you all again in a weeks time.

Sébastien Stormacq
ListView Multiple Selection

ListView Multiple Selection

One of the things that would be really nice to have in the virtualised ListView and TreeView JavaFX controls, not to mention future controls like TableView, is multiple selection. Certain kinds of apps just can not exist without multiple selection in fact.

So, unsurprisingly, today I got an email from a user of JavaFX, who claims to be a fan of FX Experience (hi Keith!), who was needing multiple selection for his work. I didn’t actually think it could be done very easily (and one of my main jobs is working on these controls, so I should know), but I spent a bit of time looking into it, and it turns out that it’s actually quite possible, with a number of warnings and rough edges, and also the use of a little bit of unpublished API. As long as you’re promising to not tell anyone, I thought I’d share this code….but just with you, so shhh 🙂

(more…)

JavaFX links of the week, July 19

Well, what an interesting week we had in the JavaFX world. It started off with Kirill Grouchnikov posting his thoughts that JavaFX is a train wreck. This created a number of threads around the web discussing this. At the same time Stephen Chin posted his petition to open source JavaFX. So much controversy, so many (sometimes anonymous) comments – what a week! For what it’s worth, I’m just reporting the news here, not endorsing or disagreeing with any of it 🙂

Whew! What a week. Catch you all again in a week.

JavaFX links of the week, July 12

A good week of JavaFX links this week – some exciting releases, and interesting blog posts exploring / announcing interesting work. Let’s get right into it!

That’s us for another week. Thanks to everyone for your hard work in the community, and for sharing your knowledge with the rest of us 🙂 Catch you all again in a weeks time!

Sequences Performance Tip

Sure, there are plenty of tips discussing how to use sequences in JavaFX, but the one I wanted to cover quickly today is regarding the fact that sequences are immutable. That is, once you create them, their content can’t change.

You lie!‘ I hear you all shout, running off to your IDE’s to show me the following fully legal and compiler-friendly code:

[jfx]
var seq = [ 1, 2, 3 ];
insert 4 into seq;
insert 5 into seq;
delete 1 from seq;

println(seq);
[/jfx]

If you run this code, the output will be [ 2, 3, 4, 5 ], as expected. It’s understandable if you think the sequence is being updated in-place – it certainly looks that way from where we’re all standing – except that under the hood it isn’t, and there are performance implications we need to be clear on. To get straight to the point, the insert and delete instructions create a brand new sequence instance, but fortunately they also ensure that the seq variable always refers to the new instance, quietly leaving the old instance to get garbage collected.

Of course, as I just noted, from a developers perspective we can treat seq as a reference to a sequence instance and be oblivious to these ‘behind-the-scenes’ sequence shenanigans. There is nothing wrong with this, but it’s important to know that creating sequences isn’t free, and certainly minimising the amount of sequences we create is a smart idea.

To be slightly more technical, I should note that there are some exceptions to this ‘sequences are immutable’ rule when dealing with non-shared sequences of specific types, but I don’t want to muddy the point of this blog, which is….

Use the expression language features of JavaFX to reduce the number of sequence instances you need to create.

For example, you might have code that looks like the following:

[jfx]
var seq:Integer[];

for (i in [1..MAX]) {
insert i*i into seq;
}
[/jfx]

I hope, with this blog post firmly at the forefront of your mind, you can now see why perhaps this isn’t such a great idea: we’re creating MAX sequence instances, one for each iteration of the for loop – ouch. Importantly, this example isn’t far-fetched and made to prove a point: I just found a very similar example in my code the other day (which I promptly fixed up), and even found a few blog posts on this site and other sites that use this approach. What you actually should do is something like the following:

[jfx]
var seq:Integer[];

seq = for (i in [1..MAX]) {
i*i
}
[/jfx]

In this case rather than create MAX instances of the sequence, we’re creating only one – the result of the for expression. This is considerably more efficient, and can lead to huge performance gains, depending on what you’re doing. In my case it made the difference between my code being usable and being jittery. Obviously in my case this was a very critical for loop, and it may be similar in your use cases also.

I hope that this helps you eek out a little more performance from your apps. Now, go forth and optimise your sequences 🙂