Posted by editor
on December 12, 2007 at 8:11 AM PST
Java2D gets a scene graph... also:
Java Today: Scene Graph project unveiled, using Runnables, and JSR-322 (Java EE Connector Architecture 1.6)
Weblogs: Scene Graph importance, adding GlassFish to app server comparison, and GlassFish book review
Forums: GlassFish update center plugin contest extended, remote participation in ME developer days, and CodeMash 2008
Java2D gets a scene graph
So, why are we making a big deal about scene graphs today, with both a Java Today and a Weblogs item? Well -- bias alert -- I just think they're really handy. With all the complaints about Swing's complexity (wasn't it just last week that we had a forum question about
revalidate()?), it's nice to move further up the stack and give the application developer the ability to say "OK, take this image, make it this large, put it here, and make it the top of the z-order stack. And I don't want to have to deal with it again."
A consistent scene graph across multiple applications may even allow for higher level abstractions. How about if we just define the graphics and UI with markup? With a good scene graph, the mapping of markup elements to graph nodes can be straightforward. I'm thinking of SMIL and SVG and their relations, but I'm sure there are even better examples.
But enough generalizations. Let's get to the news.
The Java Today section starts off by linking to the new Scene Graph project from SwingLabs, which supports JavaFX by providing a scene graph at runtime. By their definition, "a scene graph is a hierarchical representation of graphical objects in a scene. Scene graphs can handle input and they can be rendered, so Swing is an example of a simple scene graph. JavaFX Script defines a more general scene graph model, one that supports effects, arbitrary transforms, and animation. The new com.sun.scenario package provides the runtime support needed by JavaFX Script and it's a useful library for Java applications as well."
Josh Marinacci points out the value of this in his weblog Our new Java Scene Graph is open sourced :
A scene graph saves you the headache of caching, dealing with repaints, worrying about clipping rectangles, and many other annoying details of writing graphics code. It lets you focus on what your code should do, not how it does it. This makes writing graphically rich applications much easier. The scene graph also has built in support for filters like blurs, glows, and shadows. And it works seamlessly with Swing components.
He also explains the specific value of this implementation:
Java has needed a scene graph for a while. There have been several open source ones but not of them were terribly fast, and none of the could take advantage of pipeline hooks for hardware acceleration. Project Scene Graph, on the other hand, is built by the guys who work on Java2D, and we have the potential for all sorts of great acceleration (think pixel shaders). Since this scene graph supports the new JavaFX runtime, and my job is writing tools for JavaFX, I'm happy that it will be as fast as possible.
Josh has more in his blog, introducing both the ideas of scene graphs, and the importance of this particular project, not the least of which is the fact that it is being open-sourced from the start. So, if you're graphically-minded, do take a look.
And no, this isn't actually his big announcement. That's later in the week.
Also in Java Today ,
a recent Core Java Tech Tip by John Zukowski looks at Using Callable to Return Results From Runnables . He notes that while "the
Runnable interface has been around since the beginning of time for the Java platform," it doesn't provide a straightforward way of getting back a value from the threaded
run() method. The Tech Tip shows you how to use the
Callable interface, introduced in J2SE 5.0. "Instead of having a
run() method, the
Callable interface offers a
call() method, which can return an
Object or, more specifically, any type that is introduced in [a] genericized form."
Sun has submitted JSR-322 , Java EE Connector Architecture 1.6, to the JCP for consideration. "The purpose of the Java EE Connector Architecture 1.6 specification is to address areas in J2EE Connector Architecture 1.5 where further support has been requested by the Connector expert group and the public." The new spec intends to offer a generic inflow context, make general improvements to the 1.5 spec (possibly including quality of services, failure handling, message batching, and more), and developing helper classes to improve ease-of-development. Expert Group balloting for this JSR ends on December 17.
Further down in today's Weblogs ,