David Herron's Blog

Community: JavaDesktop Archives

Scene graph API available under open source

Joshua Marinacci has discussed how Our new Java Scene Graph is open sourced .. and I decided to take a look.

The project is at scenegraph.dev.java.net and it is available under GPL (v2) right now. It's very early, labeled as v0.4, it has basically zero javadoc comments (hopefully they'll fix that shortly as it's a glaring hole), but it's pretty straightforward. Even someone like me who barely knows how to draw graphics can see my way to using this. Josh also has a link to a presentation at Javapolis by Chet Haase giving the high level.

My first thought, though, was to look into testability. Can one drive UI interactions against an animation driven by this scenegraph thingymajob.

My years of building, looking at or using GUI automation tools has shown me one key issue. Where does the tester point the mouse? In AWT/Swing components we have this nice method, Component.getLocationOnScreen, which tells us the screen coordinates. Then by retrieving the width/height you can calculate the midpoint of the component and click there and for most components that's good enough. For some specific components you will have to do special calculations to figure out where to click, but for the most part this is doable.

I had been afraid the scenegraph engine would not have any support for this. But it appears it's there.

JSGPanel is a JComponent and is where you add a scenegraph, thus JSGPanel.getLocationOnScreen tells you its screen coordinates. You set up your scenegraph using a variety of SGNode's doing whatever it is you wish.

While SGNode does not have a direct equivalent to getLocationOnScreen it does have a method localToGlobal. This tells you the corresponding coordinate, within the parent JSGPanel, of a coordinate within the SGNode. I hope (and haven't verified) that it accounts for any transformations applied to the SGNode. For the simple test I just wrote adding the x,y from getLocationOnScreen to the x,y from SGNode.getBounds does result in the correct coordinate to click on the SGNode.

It would be nice, for testability, if there were a convenience method to help with this.

Creating multi-threaded Swing apps that consume web services

Java is (potentially) capable of taking part in the 'Rich Internet Application' game. This is especially interesting as we finish bringing the OpenJDK project to being completely open source (instead of the open-source-but-for-a-few-encumbrances situation we have today) in that an open source Java offers the potential to be an open source answer to Flex.

A question which hovers in my mind is, does the platform truly behave right in regards to being acceptable in the role that Flash/Flex/AJAX/DHTML is filling today.

I just came across this tutorial: Creating multi-threaded Swing apps that consume web services addressing part of this question. An Internet-Aware application would be consuming multiple data services over the Internet and displaying them in an application. So how do you do that and not mess up application behavior?

One thing that seems to regularly trip up Swing developers is the single threaded model. An event listener in Swing executes on the Event Dispatch Thread (EDT) and if the listener takes too long to execute this prevents applications from repainting properly or otherwise feeling very responsive. While it might seem straightforward coding to make database or webservices calls in a listener and then show the result on the screen.. the webservice or database call will require an indeterminate amount of time (due to network traffic vagaries) and during the call the app window will not repaint properly.

The blog entry shows several ways to use SwingWorker to get around this.

A useful testing technique to find deadlocks related to invokeAndWait

Tom Hawtin writes about a deadlock he found in jedit 4.2. As he says: There was, however, a use of invokeAndWait. Sure enough the EDT was waiting on monitor locked by the thread calling invokeAndWait.

What's most interesting is a class he provides to help one automatically find those situations. It relies on a Mustang ability provided through the JMX support to query all held locks. The code looks to see if the Event Dispatch Thread is called with a parent stack frame in invokeAndWait, and then checks the locks. Really cool.

This work is licensed under a Creative Commons License.