Embedding Swing components within JavaFX 2 scenes

Mario, Robert and myself spent some time during the last evenings casting some black coding magic and here’s the result:

This is a JavaFX scene graph, and inside it a SwingView JavaFX component that hosts a JButton, that you can actually click, etc.

Watch out for a JavaFX related project that we are about to launch soon.

Reliable UI testing using FEST Swing and Cacio

I made some progress on the Cacio Testing Framework today.

  • I added keyboard support to Cacio’s RobotPeer, which means you can now test how your components react to keyboard input.
  • I added two test runners, CacioTestRunner to automagically run a test inside the Cacio Testing Framework and CacioFESTRunner to run the test both in the CTF and the FEST GUITestRunner, which takes screenshots of failed tests and stores them as PNG.

The advantages of using Cacio Testing Framework over the normal toolkits are:

  • No windows popping up, and no messing with mouse/keyboard/focus when running the tests. This can be very annoying when running longish test runs on your desktop.
  • Easy deployment on continuous integration servers like Jenkins or similar (put the cacio libs in your Maven pom and annotate your test with CacioTestRunner and off you go).
  • 100% reliable testing of UIs. User interface tests tend to be unreliable for reasons outline in my earlier post. With CTF this is no longer an issue, because all painting and graphics is done in a synchronous fashion, no queues, drivers or users etc in the way to mess up stuff.

This project is 100% open source/free software. LadyBug (our company currently in foundation) offers commercial support and few extra features like monitoring and integration as a nice package. If you like to use this in a production environment, we encourage you to contact us :-).

Securing Java code – Exceptions

Here’s a little tip to improve security of your software. One little issue that is often overlooked. It is pretty well known that you need to validate your inputs. It’s also clear that you need to be careful with your output, so to not expose any sensitive information. However, one area that is commonly ignored or not understood in the context of security is exceptions. I often heard people say we need to put more information in exceptions to make debugging problems easier. For example, when a FileNotFoundException occurs, put the file that hasn’t been found into the exception message or such. In the context of software security, you need to understand that exceptions are a common attack vector and one of the most valuable sources of information for the attacker. Feed bogus input into the application until it crashes with an exception, then analyze this exception to find useful information about the application or the system that it’s running on.

As an example, I recently wanted to order something in an online shop. For some reason, after entering my address, etc, and clicking submit, I was presented with an exception. It was a PHP exception, but that doesn’t really matter. The exception message gave me the following information:

  • The location of the PHP script that failed
  • The name and table where the script tried to insert data
  • The exact query that failed (e.g. insert into order (customer_name, ..) values (‘Roman Kennke’, …), essentially telling me the structure of that table
  • The name of the function that failed (pg_query … from which I can guess that it must be a PostgreSQL database)

From this point, crafting a little SQL injection shouldn’t be that difficult, for example, I could enter “Roman’,…); SELECT * FROM order; –“, if the input validation is as crappy as I expect, this would dump me the whole orders table.

Takeaway lesson: when you want to put some interesting information in an exception to make your debugging life easier, think really hard to restrict the amount of information as much as necessary and to not expose any information that could be used by an attacker. It might be just as useful to use a debugger. Ah and while I’m at it, don’t ever expose sensitive information like accountย  numbers or passwords or similar in exceptions. Exceptions are one of the most important windows into your application, at least from an attacker’s point of view.

Cacio for UI testing

I became quite a fan of FEST recently. It’s a very good framework for unit testing user interfaces written in Java/Swing. However, I always struggled to get it to run reliably on a continuous build/test server. As far as I could figure out, this is due to the following reasons:

  • UI tests are inherently using the computer’s desktop. If more than two test processes run in parallel or if a user is interacting with the same desktop, things get messed up.
  • Many UI stacks are behaving asynchronously. I.e. when calling drawLine() and the call returns, there is no guarantee that the line has actually been drawn, the drawing command can still be waiting in paint command queue.

On Unix, both problems can be addressed to a certain degree by using Xvfb and enabling some debug flags on the X server to perform synchronous roundtrip communication with the X server. I tried that, and it still did not give me 100% isolation of tests as I wanted. On a Windows server, this is a complete nightmare (as is to be expected).

Last week we implemented a solution based on Cacio. This is a Java graphics backend that let’s Java not draw on the computer’s screen at all, and instead render into an offscreen buffer. Mouse and keyboard events are driven solely by java.awt.Robot (which is exactly what you need for testing UIs). Each testing process can have it’s own virtual screen (or even multiple virtual screens for testing multiscreen applications). The size of the screen can be configured. Even screenshots can be taken (using java.awt.Robot). Using this framework, each unit test runs fully isolated from other tests and from user or system interaction, thus making them perfectly reliable. The implementation is done 100% in Java, and comes as a JAR file that you simply plug into your classpath as any other testing framework.

Mario and I are in the process of setting up our own little company. We will extend the website soon, and when we’re at it, setup a project website for Cacio and IcedRobot as well. The Cacio testing framework (or if you prefer more buzz-fluffy words, Cacio Testing Cloud ๐Ÿ˜‰ ) will be our first supported product. So if you are interested in using it in production environment and need support for doing so, you are welcome to contact us.

JavaFX 2 — The new Swing ? (!)

JavaFX 2 has been released a couple of days ago. Of course, as a long time Swing hacker, I was curious if it would deliver what was promised, no more than becoming the next generation Swing. So here is a quick analysis based on some playing around with demos, tutorials and studying the documentation:

  • First of all, it is Java. Not that aweful JavaFXScript thing that plagued JavaFX1. JavaFX 2 is just yet another Java API. This is important because it allows businesses to preserve their investments into Java technology. JavaFX comes as a JAR file that you include in your classpath like any other extension library. Just like Swing should have been. I just hope they keep it that way (i.e. modular) instead of including it in SE and inevitably creating crossdependencies. Since JavaFXScript is just one of the many languages supported by the JVM, you can still use it to write JavaFX app, but more interestingly you can use Scala, Groovy or whatever is the current hip JVM language. Ah, and the API is not based on AWT or Swing or any other legacy thing (one of the biggest factors that eventually hindered Swing from going forward).
  • JavaFX scenes can be integrated into Swing apps. I haven’t tried how well this works, but generally speaking that’s a huge plus. It provides a migration path for corporations to gradually move their apps to JavaFX. Unfortunately the opposite – embedding Swing panels in JavaFX apps – has been dropped. That could become a migration hurdle. Corps often have specialized Swing components that would take months or more to rewrite in JavaFX.
  • What used to be the Swing Look and Feels can now be done with CSS (at least most of it). I never understood why Sun invented their own funny XML format for this (the Synth L&F) when there is CSS already widely used. Using this, a corporate design that is used for webpages etc can easily be adopted to Java apps. The default skin looks reasonably pleasing (I’d say it’s a copy of a popular UI toolkit of a computer brand that’s inspired by fruits). I don’t really understand the reasoning to not look like the underlying platform though. Swing made this mistake, now JavaFX does it again. This means Java will keep looking alien. But at least better than Swing ๐Ÿ˜‰
  • JavaFX has a real browser component based on webkit. How long have we been waiting for that! Nothing to add.
  • The threading model seems to be similar to Swing: all UI interactions must be done on one thread, the EDT or however it is called in JavaFX. There are small differences, for example you may manipulate inactive components (those who are not linked to any live scene) in different threads. The API also sports an invokeLater() alike (Platform.runLater() ) method, but no invokeAndWait(). I think that’s good because invokeAndWait() was horribly deadlock prone. There also comes a worker API similar to SwingWorker, but more powerful from the looks of it. The EventQueue is not publicly accessible. I think that’s good, there was far too many public APIs in Swing with which people could screw up all the world.
  • There’s also an API to access the document base and, call the enclosing browser’s JavaScript, etc, similar to what the applet API provided. There’s not much to see there. When running as JNLP application, you would have access to javax.jnlp as well, which provides a relatively powerful API instead.
  • UIs can not only be written in Java but also in an XML format FXXML and loaded at runtime. This will finally solve my single biggest complaint with the Netbeans GUI builder, that it’s generating both a .form file and the corresponding Java code, which of course tends to get out of sync, especially when people on the same team use a different IDE. I never understood why Netbeans does that though, why not simply load the .form file at runtime? Good they fixed this.
  • The drawing and animation capabilities are really impressive. It doesn’t take much to implement fairly complex graphics with all sorts of effects and animations. And it doesn’t take messing about with paint() methods and threads and the EDT to get even the simplest animation to do something, not even talking about doing it correctly. Very nice.
  • JavaFX includes support for charts. While this is a nice touch, I also find this a little odd. I would have been glad with a very core-ish API that is JavaFX and extension packages like JFreeChart and friends to provide extensions for specific purposes. If I were to write a game in JavaFX I don’t need charts. But that’s just a minor nitpick.
  • My biggest complaint is, of course, that it is not free/open source software yet and not yet available for Linux or anything else than Windows for that matter. Last thing I heard was end of 2012 (!!) for that to happen. WTF is that?? JavaFX is already late in the game, it might actually be too late already, so I cannot understand why they don’t simply put it out for the community to help? There are experienced developers out there (including me and others I know) that would be glad to make it happen earlier. Oracle do you hear that? Free manpower! ๐Ÿ˜‰ Of course, you still need to learn how to deal with that thing called community…

So.. overall I am very impressed. It seems like since a long time, Oracle is getting client side Java right. The basics are all there and all good. Some implementation details are not yet perfect, but hey… that’s a .0 release. If Oracle now gets the remaining parts right, most importantly, learns how to do this community dance, and actually open sources it very soon (developers will love it twice as much just because of it), this could actually get Java a foot in the client market again. It comes quite late, and it might actually be too late already, but there’s hoping…