Joshua Marinacci's Blog

Community: JavaDesktop Archives

JavaFX Innovations: Inline Examples and Screenshots

One of the innovations in the JavaFX toolchain is our new javafxdoc tool. Rather than producing a set of html files like regular 'javadoc' does, we produce a single large XML file representing the entire codebase's API. This lets us easily add extra processing steps, such as producing semantic wellformed XHTML as you see today. It also lets us do a few other things. I think I've mentioned before the custom doclet tags for things like default value and read only attributes. Now we've added inline examples.

Before today if you wanted some example code with a screenshot in your docs you had to mark up the code manually (assuming you wanted any syntax highlighting), then copy the code into a separate project, compile it, run it, then save a screenshot of the running app. And finally you must copy the screenshot back into your docs. This system is really bad for several reasons:

• It's time consuming, so we do less of it.
• The repository becomes polluted with screenshots
• The sample code may not compile if the API changes before you release the SDK
• The screenshots can get quickly out of date
• The code snippets aren't syntax highlighted

Inline Examples

With our new inline examples system all of these are taken care of. Just use the @example doc tag and the rest is handled for you. The doc tool will compile and run your code into a buffered image. Then it will insert nicely syntax highlighted code back into the final page along with a link to the screenshot.

Here's an example:

@example
import javafx.scene.geometry.*;
import javafx.scene.paint.*;

ShapeSubtract {
    fill: Color.BLACK
    a: Rectangle { width: 100 height: 50 }
    b: Ellipse { centerX: 100 centerY: 25 radiusX: 50 radiusY: 25}
}

Will produce the page you see here:

Live page here

That's it. No muss! No fuss. Everything is taken care of for you.

So what doesn't work?

Well, there are a few rough edges still. Specifically:

• The syntax highlighting is very primitive. Essentially just a couple of quick regex's.
• The text the code: and produces: are generated, rather than being text the author specifies.
• There is no good way to know when the @example ends. For the time being I'm hacking it by marking the end with another doc tag @endexample.
• You can't have nicely formatted and highlighted code without also getting a screenshot.
• This won't work for non-graphics classes.
• This won't work for animation.

So there's still lots to do. In a future version I'd like to produce running applets rather than just screenshots, but I think that will have to wait until after the preview SDK. This is enough that we can get on with the task of writing great docs.

Stay tuned for more documentation improvements in the future.

JavaOne Exhaustion (with links!)

So another JavaOne has come to an end. This time I think I finally tried to simply do too much. I'm lucky I didn't get the Moscone flu. Still, all in all, I think we had a good showing. I'm disappointed that the JavaFX SDK had to wait until July, but I'm glad we made the decision to put quality above meeting a conference deadline. Plus, there's a whole lot more to JavaFX than what's in the forthcoming SDK, which I'll discuss later this week. I've also been collecting links and cool demos to feature on our new website. You'll see some of them go up in the following months.

The video blogging went well. We even got an interview with Fabrizio Giudici in both english and italian (fortunately Rachel Hill, our video blogger, knows italian). I simply said "grazie". Look for this interview and more coming up soon in Rachel's blog.

Joshua Smith, a nice guy I met in the pavilion, has been working on some cool JavaFX demos that he showed in his session. Here's an article about his demos.

A shout out to Bruno. I'm sorry I forgot to ask before using your picture in the Connected Life demo. I promise to create fake friends for my fake user in the future. :)

JavaFX is getting favorable coverage in the news, here, here, here (video), and from RedMonk here , all despite my demo crashing.

By the way, I'd like to state for the record that my demo really did crash due to network congestion in Moscone. Or rather, there was a race condition in my (Java) threading code which only became a problem when the network is slow. That's why my demo ran fine a few hours earlier when Moscone was empty. Most importantly, the new Java browser plugin did exactly what it was supposed to do. When my app seg-faulted it didn't take down the browser. We just hit the refresh button and the applet came back. That's the strength of our new plugin and it makes all sorts of things possible. I have since rewritten the offending code in my demo so you can expect to see a live version of it later.

In other news, there's been a lot of interesting discussion about what an RIA is and if it makes sense at all (vs. pure thin solutions like AJAX). Check out my discussion on the JavaOne Pavilion floor with Hani, Carlos, and Pete.

Well, that's it for now. I've noticed some confusion about JavaFX and it's availability, so look for some more info from me later this week. See you soon.

JavaFX Doodle #3: A Paper Cutout Demo

I just flew back from Australia where I spoke at the Sydney tech days and boy are my arms tired. Actually, it's more my legs than my arms, and technically I arrived before I left which is pretty weird... but anyway, I'm back now. I'm exhausted and don't have my photos in order yet so the Sydney post will have to wait until next week. For now, however, I thought I'd share with you Doodle #3, which is one of the demos I showed in Sydney.

A Paper Cutout is a style of application common in the Flash world. It has a character of some sort with a bunch of pieces of clothing or other accessories next to it. You can think of it as the modern equivalent of a paper doll or Mr. Potato head. One of my favorites it the South Park character builder. You can run my humble little version of it here.

Paper Cutout: run it

I built this demo in about an hour. I spent 10 minutes writing the code and 50 minutes badly drawing the artwork in Photoshop. When you run the demo you can move the pieces around and drop them on the canvas. Notice the drop shadow below the piece when you drag it. The code to do this is very simple. Each of the pieces is just a PNG image drawn in Photoshop. To add the movement I subclassed ImageView to create the Cutout class.

class Cutout extends ImageView {
    attribute x: Number;
    attribute y: Number;
    attribute url: String;
    attribute movable: Boolean;
}

attribute Cutout.movable = true;
attribute Cutout.image = Image { url: bind url };
attribute Cutout.transform = bind translate(x,y);

The code above is pretty straight forward. The subclass adds x and y attributes which are bound to the transform, meaning the transform will update whenever the x or y coordinate changes. The image is bound to the url, so when you set the url attribute the real image will be loaded automatically. Now we just need some event handlers:

attribute Cutout.onMousePressed = operation(e:CanvasMouseEvent) {
    this.filter = ShadowFilter { distance: 10, radius: 10, opacity: 0.7 };
};
attribute Cutout.onMouseReleased  = operation(e:CanvasMouseEvent) {
    this.filter = null;
};
attribute Cutout.onMouseDragged = operation(e:CanvasMouseEvent) {
    if(movable) {
        this.x += e.dragTranslation.x;
        this.y += e.dragTranslation.y;
    }
};

When the mouse is pressed it will turn on a shadow filter. When the mouse is released it will turn the shadow off. When you drag the mouse it will update the x and y attributes. The JavaFX API saves you from the pain of coordinate conversion by providing a pre-converted dragTranslation point. Just add it to the x and y attributes and you are off to go. Notice the if(movable) test. This is to turn off dragging if necessary, which is required for the image of the main character in the code below.

Now just combine them in a MainCanvas group and you are done.

class MainCanvas extends CompositeNode {  }
operation MainCanvas.composeNode() {
    return Group {
        transform: [translate(50,60)],
        content:  [
            Cutout { x: 200, y: 0, url: "paperdoll/frog.png", movable: false  },
            Cutout { x: 5, y: 0, url: "paperdoll/hat.png" },
            Cutout { x: 5, y: 80, url: "paperdoll/patch.png" },
            Cutout { x: 5, y: 140, url: "paperdoll/moustache.png" },
            Cutout { x: 40, y: 190, url: "paperdoll/goatee.png" },
            ]
    };
}

So that's doodle number three. Almost entirely declarative and quite simple. See you next week.

   - Josh

Resources

• NetBeans project
• Java Webstart link

JavaFX Doodles: Doodle #1

About four years ago when I started my blog I created a series of posts called Swing Hacks. This series eventually formed the basis of my similarly named book with Chris Adamson and led to my job at Sun. I think the series was successful. I still get an amazing number of hits to Swing Hacks 4, the Universal Right Click.

I wish I had carried the series longer, however, since there was probably much more I could talk about. So this is why I'm starting a new series for JavaFX that I'm going to call JavaFX Doodles. Each doodle will be a small example of code snippet that does something compact but useful. I will cover only JavaFX Script initially, then add mobile and designer tools later. Also note that I am using the currently available interpreter version of the JavaFX Script syntax. I will switch to the compiler version with a slightly different syntax when it becomes available (which shouldn't be too much longer).

I hope this series goes well and produces easily usable samples that will improve your own code. Let me know if there's anything you'd like to see a Doodle of. Here goes!

JavaFX Doodle #1

This is a simple demo I often use in my presentations. It uses basic binding and animation to create a grid of fading red cells.

Cells.fx in action

Most of this code is boilerplate. It declares a subclass of Rect called Cell which adds two attributes (the JavaFX Script term for properties): red and col. Then it creates a subclass of CompositeNode called RolloverGrid which returns a Group of 300 cells in a 30x10 grid. That's all pretty straight forward. I'll explain the interesting bits below.

package simpledemos;
import javafx.ui.*;
import javafx.ui.canvas.*;
import javafx.ui.filter.*;

import java.lang.System;
class Cell extends Rect {
    attribute red : Number;
    attribute col : Color;
}
attribute Cell.x = 0;
attribute Cell.y = 0;
attribute Cell.width = 20;
attribute Cell.height = 20;
attribute Cell.red = 0.0;

//bind the red component of the color to the red attribute of the Cell.
// this will be auto-updated when ever the red attribute changes.
attribute Cell.fill = Color {
    red: bind red, green:0.0, blue:0, opacity: 1.0};

//animate the red attribute from 1 to 0 over 5 seconds, in 0.05 increments.
attribute Cell.onMouseEntered = operation(e) {
    red = [1.00,0.95 .. 0.00] dur 5000 linear; };

class RolloverGrid extends CompositeNode { }
operation RolloverGrid.composeNode() {
    var cells: Cell*;

    for(j in [0..10]) {
        for(i in [0..30]) {
            //insert a new cell into the cells list
            insert Cell { x: i*21, y: j*21 } into cells;
        }
    }
    return Group{ content: [Rect { x: 0, y: 0, width: 31*21, height: 11*21, fill: black},cells] };
}

Canvas { content: RolloverGrid { } }

There are two interesting parts to this code which do all of the work. The first is the initializer for the fill attribute (in bold above). It says that the fill attribute will be set to a Color composed of red, green, blue, and opacity components. Notice that green, blue, and opacity are set to constants (0,0 and 1, respectively). red, however, is set to bind red. This means it will be bound to the red attribute of the enclosing class, Cell. Because of this bind operation the red component of the fill attribute will be automated updated whenever the red attribute of Cell class changes.

The second important part is one line further down where the code sets an onMouseEntered handlers. In this operation it creates a animation for the red property. The code red = [1.00,0.95 .. 0.00] means 'make red go from 1 to 0 in steps of 0.05'. The dur 5000 part means to take 5000 milliseconds. The linear keyword says to animate linearly rather than with the default, which is a smooth in and smooth out (I'll describe these keywords in greater detail in a future blog).

Whenever the mouse enters a cell it will kick off an animation for that cell. The color will go immediately to bright red and then fade back to black (since the other components of the color are already 0). That's it! These two lines do all of the hard work to create an interactive animation.

Limitations

You may have noticed a problem with this code. If you move the mouse in and out of a cell repeatedly within 5 seconds then then a new animation will start. There is no way to know if the animation is already running and optionally stop it. This is a limitation in the current animation system that is currently being overhauled by the compiler team. When the new syntax is ready I'll show you how to update to it.

To try out this code just paste it into an open JavaFX Script buffer into NetBeans 6 with the latest plugin (instructions for setting up NetBeans here)

Biblioteca

• Swing Hacks 4, the Universal Right Click.
• JavaFX Plugin for NetBeans

A JavaFX Christmas Demo

Another Christmas will be here soon and it promises to be a good one

I received my Christmas present early when JavaFX and the Consumer JRE (now Java SE 6 Update N) were announced in May. I immediately joined the new JavaFX tools team and started hacking on our new designer tool. The new tool is proceeding smoothly and I can't wait for the day we unveil it; but today is not that day, nor any other day soon (sorry guys!). However, I'm also spending some of my time learning JavaFX Script and working on new demos. So here is my new Christmas demo, which I hope to make an annual occurrence.

Santa Stats: click to launch

The concept of this demo is that Santa needs software too. But of course his software would be beautifully built by master elfin interaction designers. This demo has two components. The clickable pie chart indicates the breakdown of children into naughty and nice, as well as showing the breakdown into sub-categories like bad, evil, and malevolent. The second demo is a snow simulator (click on the black area to make it start). I imagine that this is the streamlined version Santa has on his laptop. The master control center would probably have hundreds of widgets like these to measure everything from monthly toy production to maple syrup viscosity and candy cane accretion levels.

The Piechart

This is my first attempt at building reusable components entirely in JavaFX Script. The pie chart is nice because you can simply insert some value objects and it will do the plotting for you. If you click on a pie piece the chart will do a nice transition into a breakdown of that section. I plan to do some more work on the title positioning (it's manual now), but this proves JavaFX Script can be used in more business-like settings. Perhaps this chart is useful enough to put in some sort of community driven component library.

Here's the code which sets up the pie chart you see in the screenshot above.

var chart = PieChart { 
    size: 160,
    backgroundColor: rgba(255,0,0,0),
    transform: translate(20,15),
    values : [
    ChartValue { title: "Naughty", value: 50, color: white, x: 40, y: 40, textColor: black ,
        breakdown : [
            ChartValue { value: 20, color: red, title: "Evil", x: 120, y: 60, textColor: white },
            ChartValue { value: 50, color: green, title: "Bad", x: 35, y: 25, textColor: white },
            ChartValue { value: 50, color: white, title: "Malevolent", x: 60, y: 120, textColor: black }
        ]},
    ChartValue { title: "Nice", value: 20, color: green, x: 105, y: 120, textColor: white,
        breakdown: [
            ChartValue { value: 20, color: white, title: "Angels", x: 85, y: 40, textColor: black },
            ChartValue { value: 50, color: green, title: "Not yet bad", x: 35, y: 100, textColor: white },
        ]}
]};

chart.rebuildChart();

The Snow Simulator

The other component is the Snow Simulator. I think the motion effects turned out well, but the simulation is very heavy on the CPU. I suspect I'm not using a terribly efficient algorithm. That's another thing I will have to revisit.

Everything else in this demo is very straight forward code you've seen before. The candy canes are a reusable class similar to the StripePainter from SwingX, combined with a subtle gradient for the shading effect and a clip rect. All text and backgrounds are created with translucent rectangles and layered text. You can download the entire NetBeans project here.

Learning Experiences

One thing I've noticed when building my demos is my development style. It's totally different than when writing Java programs. When I code Java, I think first about the objects and interfaces, create empty .java files, and then start writing the implementation. When I write JavaFX script using the preview mode in NetBeans my style is completely different. I immediately start throwing up shapes and UI components, constantly moving code around and renaming things. Once I have something solid only then do I split it into separate classes. It's definitely a less rigorous but more fluid development experience. And, dare I say it, more fun!

So that's it for this year. I can't wait to see you in 2008 when we will ship the new Java 6 update, see the first release of the new Scene Graph, and of course give you your first peek at the designer tool.

Merry Christmas everyone!

Competition and the Java Ecosystem: why Sun launched the PDF Renderer and Scene Graph projects

I'd like to take a second out of my usual technical blogging to discuss something important. Sun recently launched two new open source projects: the Scene Graph and PDF Renderer projects. In both cases some readers wondered why Sun felt the need to start new projects rather than contribute to or recommend existing open source and commercial projects. Is Sun opposed to commercial Java software vendors? Do we insist on reinventing everything ourselves? The answer is an unequivocal no. Each new project inside Sun goes through a rigorous vetting process to determine what projects to start and how. Today I'd like to let you see inside our brains and find out why we launched these new projects.

the code came first

I'll start with the PDF Renderer. There are many existing PDF renderers out there, some open source and some closed; some written in Java and some in C. So why did we decide to start a new open source renderer when there's already a bunch out there? The answer is: we didn't!. We didn't sit down one day and decide to launch a new difficult project. The reality was much different, and stranger. The code came first.

Several years ago researchers inside Sun Labs created a PDF renderer because they needed an all Java PDF viewer for content created by Open Office. The library had to be written Java instead of a C wrapper because it had to work on every platform (and JNI wrappers have their own problems). It had to work under a license compatible with Sun's internal projects, so GPL was out. It also only had to read Open Office output so writing it would be easy (isn't that how they always start!). Given these constraints it made sense to write a new library.

Now fast forward a couple of years. Sun Labs has finished the internal project and doesn't need this library anymore. Since it was graphics related they asked the Swing team if we would like to use the code for our own projects or open source it. Richard Bair and I immediately said: yes, we want it! We had received numerous requests for a PDF renderer as part of SwingLabs (I think Rich even started on his own library at one point).

For two years Rich and I worked to get the code released, following up on all possible patent issues and finding resources to support the new project. Because we specifically didn't want this to be another "throw the code over the wall and forget it" exercise we decided to launch only if we could find a non-Sun employee to run the project. If there was enough interest for the community to run it, then we would open the code. If there wasn't enough interest then it was best to just let it die. Fortunately, Tom Oke from Elluminate expressed both a professional and personal interest in the project, so a few weeks ago I went back to the approval board and received the official go-ahead.

I don't expect the PDFRenderer project to compete with some of the high quality commercial solutions already out there. Many have done a terrific job of supporting every PDF file and feature they can get their hands on. There is enough room for more than one PDF library in the Java ecosystem. In fact, diversity and creative competition is what makes the Java ecosystem thrive. I wouldn't change it for the world.

the need came first

While the PDF Renderer was created because the code came first, the Scene Graph library was created because the need came first. The need was JavaFX Script (which is targeted toward a different audience). While I love the fact we have open sourced the scene graph and can code against it with Java, the primary reason for it's existence is JavaFX Script.

In the world of scene graphs there are many options. In fact JavaFX Script was originally built atop one of them: Jazz. We considered continuing to develop Jazz or it's successor Piccolo, but decided against it because they didn't fit the following constraints:

• Have a clear history of all copyright and patents in the library so we can indemnify Sun's customers.
• Have a license compatible with eventually moving it into the core JRE (which we hope will happen one day).
• The ability to transform Swing components, both input and drawing.
• Be smaller with an API tuned to the needs of JavaFX Script.
• Have internals compatible with the heavy duty graphics tuning we have planned (think pixel shaders). We need something very high performance to compete with the other emerging RIA platforms.

It turns out that the initial implementation of a scene graph isn't very difficult. You could build an initial version in a few days thanks to the support provided by Java2D. The tricky part is getting the API right. Even though we didn't adopt the code from Jazz or Piccolo (or even the NetBeans Visual Library), we did learn a lot from their APIs and how people use them. There are clear influences. It was not our intent to supersede those existing projects. We built what we needed for JavaFX Script. In the future, I hope that enterprising developers will build bridge layers allowing existing programs to use a new implementation built on the Scene Graph.

So there you have it. Two different open source projects created for two very different reasons. In both cases we actively support diversity and competition in the Java ecosystem. It's what makes Java great. Have a happy 2008!

The big secret revealed! A PDF viewing library!

Last week I told you we had a secret new open source project to release. Think of it as an early Christmas present. A project that you've never heard of and has nothing to do with JavaFX (which is partially untrue, but I'll get to that in a second). Well, it's almost the end of the week so here is the secret. You can listen to MP3 announcement (played on stage at the JavaPosse's JavaPolis session), or simply read on. We are releasing an

Open Source 100% Java PDF Renderer/Viewer

That's right, a 100% Java library which can parse PDF files and draw them to the screen. It's (creatively) named the SwingLabs PDF Renderer, and hosted at pdf-renderer.dev.java.net. It's the same license as the rest of SwingLabs (LGPL) so you can easily embed it in your own applications. Several of us inside the desktop Java team here at Sun have been working hard on getting this released and now it's finally here. Go check it out at pdf-renderer.dev.java.net.

So, you probably have a few questions. First of all:

Why should I care?

You should care because PDF is one of the formats that makes the web go 'round. Soon to be an ISO spec, PDF is the standard way of exchanging non-interactive documents on the web. Everything from tax forms to clip art can be stored in PDFs. Mac OSX makes heavy use of PDF both as an asset format (the many widget images found in Aqua) and also as an ideal archive format using AppleScript workflows. PDF is everywhere.

Once a PDF is created you know with great certainty that it will display and print exactly as you want on any platform. Hmm. Write a PDF once and run it anywhere? Sounds like a good fit for Java! Combined with PDF writing libraries (like iText), you can do pretty much anything you want with PDFs.

What can I do with it?

Anything you want! You can embed a PDF in your Swing app, draw on top of it, and even render to places other than the screen (like PNG images). The awesome guys over at Project Wonderland have even started experimenting with projecting PDFs into their 3D shared universe. Most importantly, we know you'll come up with things we never thought of. That's why we are open sourcing it.

Experimental Project Wonderland support

As another bonus, we plan to use this library to build a PDF imported for the designer tool that I'm working on. So, technically, this does have something to do with JavaFX, but that's not the focus. The focus is general PDF support for Java.

Where did it come from and Who is running it?

The SwingLabs PDF Renderer was originally written in 2003 by researchers at Sun Labs for an internal collaboration tool called Sun(TM) Labs Meeting Suite. It was originally targeted at output from OpenOffice, so you will find it can support most OpenOffice PDF exports.

While the original code drop is from Sun, we want to get the community heavily involved. To make sure that happens we have recruited Tom Oke from Elluminate to run the project. He will act as project owner and lead architect. He is rapidly becoming an expert in the code and looks forward to discussing features with other contributors. And speaking of other contributors..

What about iText and JPedal?

JPedal uses the GPL license, making it non-viable for certain applications. We think that the LGPL is a better fit for a library like this. iText is not a viewer/renderer. iText generates PDFs, it doesn't view them. This makes iText and the SwingLabs PDF Renderer great partners. I look forward to seeing how people combine them.

What are the limitations and how can I help?

As I said, we originally targeted OpenOffice exports, so a few things are missing. It implements most of the PDF 1.4 spec but is missing transparency, fill-in forms, and certain font-encodings. We hope that interested developers in the community will help us fill in these missing features.

If you want to get started then head over to the PDF-Renderer project website, download the code, and join the mailing lists.

Our new Java Scene Graph is open sourced

Today Sun announced the open sourcing (GPL) of the new Java scene graph that underlies JavaFX script. And I'm very, very excited about it.

What is a Scene Graph?

First, you may be wondering: What is a scene graph? It's a retained mode API. This means that you pass shapes and other graphics objects to the library and let it draw them on screen whenever a refresh happens. The API retains the graphics objects. This is different than Java2D which is an immediate mode API. This means that your code is called whenever the screen must be refreshed and you must invoke graphics drawing operations which draw to the screen immediately.

So why is one better than the other? Well, 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.

And finally, because so much of the graphics is abstracted away, the implementation can perform many interesting optimizations in the future, like preloading textures and primitives up to the graphics card. In short, it's a higher level of abstraction, just like going from assembly to C. You can still get down to the assembly level when you need to, but most of time you work at the higher levels.

Why this is good?

First of all, 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. You don't have to use JavaFX Script, though.

Second, I'm very excited that we are open sourcing this code right from the start. It hasn't been included in a shipping version of Java yet, but instead of waiting (sometimes for years) we are open sourcing it before it ships. This is huge, and another example of Sun (my employer) doing open source right. (A fact that I'm thrilled about, as you can imagine).

Third, this is a Java API. While it's initial purpose was to support JavaFX Script you can (and I have) code directly in Java. This means the API is useful not only from JavaFX and Java applications, but also from Groovy, Python, Ruby, and any other JVM based language.

Zeroth of all, scene graphs are awesome. I've been wanting one for ages. They are a great way to build up interactive graphics. They let you focus on what your app does and let the API do the heavy lifting. I've been playing with it for a while and I'm positive we are going to see some really cool apps coming out of this. In fact, I've got a few cool demos up my sleeve which you'll see soon.

So go to scenegraph.dev.java.net and check it out. Also read the PDF presentation from JavaPolis,

BTW, this announcement has nothing to do with the secret I told you about last week. You've still got to wait a few more days for that.

LightsOut, a JavaFX Script game

Since I joined the JavaFX team a few months ago I have spent some of my free time creating demos and learning the language. Most of my demos have been simple single class applications that highlight a particular language feature or graphical effect. After a while, though, I decided to write something bigger to prove it could be done and really stress test the language. As a result of feedback from me (and many other dedicated early adopters) we have some great improvements coming down the pipe.

Writing this game really taught me the Zen of JavaFX Script (hmm... sounds like a good book title). I often have to fight my procedural Java instincts and instead use binding and triggers wherever possible. It's really a different way of thinking, closer to Lisp or Prolog (and even a bit of SQL), but quite powerful. I'm sure I didn't get it perfect and I bet I could rewrite it in a few more months using a better style, but this is a good start.

So I'd like to share with you my first real JavaFX Script application. It's a simple puzzle game where you click grid cells to turn off the light. As you click each cell the adjacent cells flip as well. You win the game by turning off all lights (hence the name :).

Losing badly at Lights Out

I had planned to release it earlier but decided to wait until NB 6 was final in case there were any last minute changes.

You can run the program using Java WebStart or download a zip of the NetBeans project. I went through the code this morning to clean up a few things and add documentation. Let me know what other demos you'd like to see.

My First Screencast: Visually build an RSS reader using NetBeans 6

With NetBeans 6 beta 2 out (and the final version going into High Resistance-"thou shall not break things" mode) I thought it might take the opportunity to show you some of the cool things you can do with it. I am a client guy, of course, so I'm very excited by the new features we've built to let you create and deploy desktop applications easily and quickly. I also wanted to try experimenting with screencasts. Since development of client apps is so visual I think a visual way of explaining them is good. This is my first screencast so please provide feedback of what you like and don't like.

The key to getting the most out of the new client tools in NetBeans 6 is the use of beans. Not just visual beans like Swing components, but also non-visual beans. When you wrap your functionality up as beans you can visually attach them together very easily.

In this screencast I will show you how to use a simple RSS reader bean to build a feed reading application with almost no code. The screencast is 12 minutes long, but I could build and deploy the app in about 4 minutes if I wasn't talking. That's how productive NetBeans 6 can make you.

Visually build an RSS reader with NetBeans 6, by Josh Marinacci

Here is the NetBeans project with all of the source and support jars.

The votes are in.

I've got a free moment here at the MidWest Tech Days (and if you are in the MidWest you should be here too!) so I thought I would tally the votes generated by my previous blog: You vote for your favorite article and I'll write it!

Before I get to the results themselves I must say that I was quite surprised by the response. 34 comments with some very good suggestions. I'm glad to see that there is such passion in these topics.

So here's the breakdown (and please correct me if I miscounted) :

• Graphic Design for Engineers: 18
• Intro to Painters: 14
• JavaFX Script: 10
• JXMapViewer: 8
• Swing App & Beans Binding in NetBeans: 7
• Nice feedback with Drag and Drop in Java 6.0: 2
• 1 each for JNLP'd Derby driven app and some stuff with lucene / solr / hibernate

I'm surprised that the JXMapViewer was so popular, and that the Swing App Framework and Beans Binding in NetBeans was so low. Most of all, however, I'm quite surprised to see the graphic design article score so high. Clearly "making GUIs that don't suck" is a high priority for a lot of you.

Thank you all for your feedback. It looks like I've got some writing to do. Keep watching for new articles coming soon.

UltraSparc T2 launch: [keanu] Whoa! [/keanu]

I know this isn't really Java related, but I just got an email that Sun's UltraSparc T2 launched today. Even though I'm not a hardware guy and I've forgotten most of my CompE classes from college, I'm still interested in the changing state of the art chip design.

It simply amazes me how things have changed in the decade since I was in school. The priority has shifted from single threaded speed to slower but massively multi-threaded CPU cores. Case in point, the new T2 has 8 cores in a single chip, with 8 simultaneous threads per core; (not to mention dedicated floating point and crypto units that I have no idea how to use). That's incredible! When I was in school the idea of getting to code for a dual CPU system was considered exotic. Now I could haul out my old Java applet raytracer and render 64 lines at a time! Yes kids, my first official Java program was a very slow sphere-only raytracer applet on my 486 33mhz SX! If only I'd had Hotspot then. :)

Even more of a change, the focus in CPU design has gone from pure performance to performance per watt. I didn't realize this until recently but, thanks to changes in both the CPU and energy industries, it can cost more to power your server for a year or two than to buy the server in the first place. That really changes how people thing about building out data centers. Air conditioning is more expensive that your hardware. Perhaps we should all build our datacenters in Greenland.

So here's a more Java related question to my readers. Now that a 64 thread machine is available (and probably cheaper than you'd think), and many laptops have multiple cores now (as nowcrash becomes reality more each day). So here's my question: if you had a massively multi-threaded CPU what sort of client applications would you write? I know that most (all?) of these new T2s will go into massive app-servers or Ebay-like search engines, but I'm a client guy and I care about client stuff. What sort of really cool desktop apps could we do with massive multi-threaded CPUs?

Java FX updated, and a visit to the future of client Java

Open JFX updated

OpenJFX, the open source version of Java FX, was just updated. It has lots of improvements and demos, but the biggest thing is the first compiler, which will compile Java FX Script directly into bytecode rather than interpreting it. This is huge, because it makes FX Script a first class Java language, as well as being several orders of magnitude faster than interpretation.

Another big feature of this release is the better integration with NetBeans. FX Pad can now run directly inside NetBeans, further cementing NB as the Emacs of the 21st century. Now we just need a mail reader and mp3 player. :) I won't go into all of the new features, you can check it out for yourself here. Be sure to take a look at the SVG converter and chat client demo app: Casual. Lots of cool stuff in there.

The future of client Java

I've spent the last week in the bay area at secret clandestine meetings secretly planning the amazing top secret future of client Java and Java FX! Okay, that makes an endless week of meetings sound a lot more interesting than it really is, but there's some truth to it. We promised a lot of things at JavaOne, from designer tools to the consumer release of the JRE, and based on what I've seen in the last week I can say that we are really making all of this stuff happen. In fact, I'm going to come out here and make a bold (and not approved by my employer) statement:

2008 will be the year that client Java starts taking market share from Flash.

There, I said it. By JavaOne we will have completely re-energized client Java. And I mean client Java, not just desktop Java. Everything will be faster, prettier, easier to use, and easier to deploy. We will be better in the browser. We will be better on the desktop. We will be better on the phones. Existing technologies are being updated and new technologies will see their debut at JavaOne, if not earlier.

I'm not going to spoil things by telling you what's coming up. I'll just say that I have never been this excited about the direction client Java is going. Never! Exciting times are ahead for the Java community!

Flying Saucer R7 is out

The Flying Saucer team is proud to announce that we have just released version R7 Final.

Flying Saucer is an open source XHTML renderer I started a few years ago here on Java.net. It can render any XHTML + CSS 2.1 document as a Swing component. With the right stylesheet you can actually render any XML document directly. And you aren't just limited to Swing. Some developers are using it to render images and PDF files. I recently wrote an article that describes how you can render full PDFs with pagination, headers, and page numbers.

Release 7 has major, major improvements over the previous release. We've got almost full CSS 2.1 support now; including rewritten floats, tables, and pagination. We also have a brand new CSS parser that is faster, smaller, and more spec compliant (and paves the way for CSS 3 support). You now need only a single jar file, core-renderer.jar, and with Pack200 it's only 345K. If you leave out the entity files and DTDs then it's only 131K with Pack200! There has even been some work to combine Flying Saucer with HTML preprocessors (like JTidy) to render real websites out there in the wild. (minus the Javascript and dynamic layout). Take a look at the screenshot below.

CSS Zen Garden, fully spec compliant

Flying Saucer really is a fantastic way to render XHTML content. It has taken off far beyond what I originally thought when I started it three years ago. I'd especially like to thank Peter Brant for all of his code improvements and to Patrick Wright for taking over as project leader when I had to devote time to other projects.

A Response to GUI Building: tool vs hand coded

The debate of hand coding your GUI screens versus using a tool has come up again. I suspect that Stuart wasn't expecting quite the volume response that he got. For some of you this is old hat and I suspect we aren't going to come to any conclusions here. I would like to say one thing, however. We need to split issue into two separate items that are actually independent, though related.

We like to say it's a matter of writing your GUI by hand using GridBagLayout (which is the one layout manager always discussed) vs. using an proprietary opaque visual tool like NetBeans GUI Builder or Apple's Interface Builder (even more opaque). I think this is wrong. There are distinct issues here that should be handled separately.

Visual Tool vs Hand Coding

First there is the issue of using a visual tool instead of hand coding your GUI. I think there really is nothing to decide. Laying out your GUI is a visual task. Use a visual tool! End of story. I wouldn't design a newsletter without a visual tool like Quark Express. I wouldn't edit photos without a visual tool like Photoshop. Why should I design my GUI without using a visual tool like NB? That's madness!

Now notice I didn't say that you have to only use a visual tool. It's perfectly acceptable lay out your GUI initially using NetBeans and then add tweaks afterwards. In fact, I do this all the time. NetBeans will create an uneditable method initComponents() called from your form's constructor. initComponents() does the initial layout but you can then customize it however you like after that. You've got field references to every component. You can use them to do all sorts of cool things like adding painters, tweaking the layout of certain components, changing defaults, adding bindings, and pretty much anything else you want to do with hand code. It's not one or the other. You can use hand code and the GUI builder.

But what about the noneditable code? It's too complicated to understand! Why yes, that's right. It is complicated (though actually fairly straightforward, if verbose). However, you are never supposed to edit that code. That's why it's in an noneditable block! :) The form XML file is the definitive representation of your GUI. The generated code is simply an implementation detail with a few nice side benefits (like not needing to have NetBeans running to compile your code with Ant). We could just as easily generate bytecode directly and never show you the Java at all. Or we could parse the XML at runtime instead of compile time. You should never have to deal with that generated code just as you should have to directly deal with the bytecode generated by javac.

Proprietary vs Standards based

This is the other big thing I see mixed up in the hand code vs GUI builder issue, but it is an entirely separate issue from the previous one. I agree that standards are better because you do not want to be locked into a tool. Imagine you tried to move away from Visual Studio for your .NET apps. You'd find it pretty difficult to modify VS's form files. But the solution here is not to throw away visual tools. The answer is to use a tool that saves in an open and hackable format, preferably with open tools.

NetBeans is an open source product (and has been for many years). The GUI builder (formerly called Matisse) has even been ported to Eclipse. The form files generated by NetBeans are straight forward XML files that are actually pretty easy to modify by hand when necessary. So you can see that NetBeans's GUI builder is not the lock-in with proprietary specs that some people might think it is. It's actually quite open and hackable.

So we have reduced the problem to one a lot smaller. The only downside to NetBeans GUI builder is that it's not a standard format, meaning it hasn't been documented and there is no DTD. The format could change in the future as we add new features. Opening up the form.xml format would be a great thing. This is an issue we are aware of and hope to address in a future release of NetBeans. [Disclaimer. I'm not the keeper of the NetBeans roadmap and I'm not saying that we have immediate plans or that it's scheduled for NB 6.0 (it's not). I'm simply saying that it is on our horizon and something we would like to do. Everything in this post is my opinion only.]

Conclusion

So I hope I have split the issue successfully into manageable parts and cleared up some misconceptions (you'd be surprised how many people aren't aware the form files exist and think that NetBeans would read back their changes if only they could edit the 'blue' code blocks). Please send us you feedback. We really do listen and we really do want to hear what the community wants.

Thanks, Josh

Glossitope BoF slides

Due to a deluge of requests (both of them) here are the slides for our Awesome BoF 5000.

You can see them as a PDF or a QuickTime movie. I recommend the QuickTime if you can as it contains the rad transitions and animated jokes.

• QuickTime 7.4MB
• PDF 2.6 MB

Enjoy

-- Josh

JavaOne: Another One is Done

It's Friday morning and I'm watching the James Gosling keynote from the bean bags in front of the big screen. I'd say this was the most exciting JavaOne I've ever been too. We really saw desktop Java in full force. Perhaps we shouldn't call it desktop anymore, since a form of Java SE is going to be available on phones and other non-desktop computers. So really this was the JavaOne for client Java. Since I've spent most of my professional career pushing the limits of desktop Java I'm very excited about the possibilities of doing cool things on phones and TVs.

So that's the overview. I'll leave it up to the many great bloggers here to give you their take on JavaOne and all of the sessions. I'll give you a quick at what I did before I drive home and sleep for the next few weeks.

Swing Application Framework: JSR 296

The biggest surprise for me in our Swing App Framework session was the incredible attendance. Our room held 500+ people and it was completely full. People were milling around in the back looking for seats. This tells me that quality Swing applications really are important to a lot of people.

The talk went pretty well. Everyone laughed at our bad jokes and the live Flickr demo was a big hit. It's always fun to type in random words on stage and see what bubbles up out of Flickr. We will have the code for the demo as well as screencasts in a place where you can download them soon.

AB5k / Glossitope BoF

So we had a few glitches with our website, including having to completely rebuild the site yesterday morning. Since we think a lot of people have trouble registering on the website we have decided to have another contest soon, giving everyone an opportunity to compete. More details coming soon.

The session went well, I think. We have 35 people, which is pretty good considering we were in at 10PM on the last day of the conference, opposite the After Dark party with free beer and battle bots. We had a few glitches with the projector and audio but overall we were well received. Everyone loved the comic book jokes on the slides as well as our unique brand of humor. I'll have a link to presentation soon. In the mean time you can see our video here.

Your Moment of Zen

And speaking of our video. It was shown on the big board here in front of the bean bag chairs. How cool is that?!

Until next time, keep on Swingin'.

AB5k has a new name, and a JavaOne contest

The AB5k team is proud to announce that we are changing names to Glossitope. We have a new website up at www.glossitope.org where you can download new builds, see our promotional video, and play with the new graphical effects we built for JavaOne.

We are also holding a developer contest so that everyone who can't come to JavaOne can still participate in our BoF session Thursday night. All you have to do build your own widget and submit it to our new web gallery. We will show the widgets on stage at our session and let the attendees vote on the best. The top three winners will receive cool new Glossitope T-Shirts in the mail. If you are actually attending JavaOne then please come by our BoF 1575, Thursday at 9:55, in MC North Mtg Rm.

Thanks:
Josh, Robert, and the rest of Glossitope Team

update

I've fixed the links on the site. You should be able to try out Glossitope now. To submit a widget you must register on the site. If it doesn't work then just email me the widget at joshua at marinacci dot org.

- Josh

AB5k has a new name, and a JavaOne contest

The AB5k team is proud to announce that we are changing names to Glossitope. We have a new website up at www.glossitope.org where you can download new builds, see our promotional video, and play with the new graphical effects we built for JavaOne.

We are also holding a developer contest so that everyone who can't come to JavaOne can still participate in our BoF session Thursday night. All you have to do build your own widget and submit it to our new web gallery. We will show the widgets on stage at our session and let the attendees vote on the best. The top three winners will receive cool new Glossitope T-Shirts in the mail. If you are actually attending JavaOne then please come by our BoF 1575, Thursday at 9:55, in MC North Mtg Rm.

Thanks:
Josh, Robert, and the rest of Glossitope Team

JSR 296 Session Success

Another quick update. Hans and I did our session on JSR 296 today and it was a huge success. We were completely packed, over 500 people I think!

More coming soon.

update

Here is John's coverage of our session. Thanks John.

NetBeans day success

Hey guys. Real quick. I just thought you'd like that we (the NetBeans GUI Builder team) showed Open Street Maps on stage at CommunityOne in front of about >400 people. We did a demo where we built a database application live on stage that combines famous sites in London with photos from WikiPedia and the JXMapKit running Open Street Maps. And we did the whole thing with only a single line of actual code. Everything else was visually assembled in less that 5 minutes. I told the audience that we were using OSM which is "literally created by guys on bikes with GPS trackers. It's amazing". Everyone was very impressed. We'll have screencasts up once we finish JavaOne.

More updates will come as the week continues. We've got our JSR 296 talk and then the launch of some cool stuff for AB5k.

Beans binding rocks!

I was working on one of our NetBeans demos for Monday's Matisse session and it occurred to me. I was actually having fun putting together a little program! I grabbed some of our cool little beans from SwingLabs then wired them up to some text fields using zero code. Just binding expressions created visually using NetBeans M9. It was really easy and kinda fun. Beans binding makes the beans we've assembled in SwingX-WS in particular a whole lot more useful.

I'm starting to think that we may just have something here with the Beans Binding and Swing App Framework JSRs. They really are going to make building Swing apps a lot more enjoyable. And the demo we are pulling together will show you how to do some pretty powerful stuff with almost no code. I think you'll really enjoy it.

Okay, back to coding up demos.

Too busy to blog

I've been too busy to blog for the past couple of weeks. Sadly this will continue for two more weeks until JavaOne begins. Don't worry, though. It's all in a good cause as you will see some great things shortly. In the meantime I leave you with a quick comic that actually made me laugh out loud.

Back from the demo

It was completely exhausting but it went quite well. Just to catch you up, last week I drove nine hours down to Santa Clara, CA to spend three days working on my demo then show it to the demo people. Here's how it works:

Every year we all rush around trying to make the coolest demo ever, hoping to get into the coveted few demo slots for JavaOne keynotes. We show the demo to the team of people who decides these things, including James Gosling, then the best of the bunch are chosen to make it into one of the keynotes.

Two years ago we (the SwingLabs team) built Joplin, an MP3 player app with effects and realtime music visualization. Last year we made Aerith, the 3D Flickr/ Google Maps mashup. Not only was it a super cool demonstration of Java but most of the technology has since migrated into other SwingLabs technologies like the JXMapViewer, SwingX Painters, and Timing Framework.

This year I'm submitting AB5k as my demo. The competition is fierce and having seen what Jasper and Rich cooked up for SwingLabs and what Ken is working on for JOGL I can say that no matter which demos get in you'll be very impressed.

After showing AB5k to anyone who would listen, getting some great feedback from some Swing and Java2D guys, and implementing a slew of new features and eyecandy; I gave the demo Wednesday afternoon. I think it went pretty well. I got a lot of questions, even though my slot was at 4PM and the review team was probably quite tired (one demo every 15 min since 9AM == a lot of demos). Also, James gave me a thumbs up so that's always a good sign.

I won't know for a while if we are in the keynote but in any case it was a lot of fun and greatly improved AB5k itself. Even if we don't get into a keynote you'll all get to see what I've been working on at the AB5k Birds of a Feather session and in videos that I will post online.

Okay, back to work on bugs and getting NetBeans ready for M9. Thanks everyone.

update

We announced AB5k in a Java Posse Roundup session a month ago in Colorado. The audio from that session is now available for download here.

Yahoo Widgets 4 is released

Yahoo Widgets 4 was just released today and I must say it looks pretty cool. They added a dock mode with mini-widgets and auto-widget updating. Part of me is frustrated because this is one of the things we have that they didn't until today.

Another part of me is happy because it means we were right to include those features.

And yet another part of me is excited because it means the widget market is heating up and getting more overall exposure with more users for everyone.

And the last part of me is getting really hungry for some lunch. I think I'll go get some food.

Before I go I'll ask, are there any cool features of the AB5k container you'd like to see? Any other widgets you think we are missing?

Thanks,
Josh

AB5k Widgets in Depth

Well it's been two weeks since AB5k was released and the response has been, well, interesting. Some people really love it. Others have complained it's slow and buggy (which it is), and still others ask "why make another widget system, but this time in Java?". We got somewhat panned at JavaLobby in particular. So, two questions to answer: too early and why Java?

Too Early?

So did we do the right thing by releasing it so early? Maybe. Our real target for a quality release is JavaOne, but there's only so much two people can do. To make this a success we need the support of a community, even just for bug finding. I think it's better to release open source projects early and often. Perhaps this was a bit early, as the code is certainly rough, but I really wanted to get feedback as early as possible, and get people building on it.

Why Java?

I think the answer to my other question is more important: Why Java? Do we need another widget system? What does Java bring to the table? Well, quite a lot I think.

Mac's Dashboard, Vista's Sidebar, Google's Gadgets, and Yahoo's Widgets. All of these existing systems are proprietary, not open source, don't run on all operating systems, and don't have good support for multiple languages (both human and programming). Java is better on all counts. It's a standard and now open source. It runs pretty much everywhere (including older operating systems that Microsoft no longer supports). Java has always had great support for multiple locales and languages, and now Java has great support for multiple programming languages. Java really is a great system for a widget platform.

However, to compete with the established players we need to use Java's strengths to our advantage. So that means support for multiple languages, integrating with native resources, and leveraging Java2D. To that end we have several people who've starting building desklets using Jython and Javascript, we have plans for native shaped windows, and I've just started building a new WindowManager API that will let us buffer the desklets into images and add really cool effects. I hope what you see by the time of Java One will look a lot better than what we have today.

Quick AB5k updates:

We've put up more docs on our wiki including a tutorial on building your first desklet, an architecture overview, and some descriptions of how we use Maven and how to set it up in your own desklet. Oh, and we've also added desklet auto-updating and Augusto contributed a patch to speed up painting.

On another cool note, it looks like we may become a standard! :)

Helping out

So if you'd like to help out, first download AB5k and try it out, then join the developers group. After that we could really use some help on:

• Building more desklets. Try building a desklet. Some cool little program that you always wanted to build.
• file bugs on the standard desklets make the existing desklets look prettier and be bug free. What we built to start with is just that, a start. I'd like nothing more than to see them be completely replaced.
• Design a new website If you are a graphic designer or simply handy with images and css, we could use a redesign of our website. What we have now is just a prefab template.
• JNI Know C code? We really need some JNI help on system wide hotkeys, avoiding overlap w/ windows (docking) and setting up native shaped windows.

So that's what we've been up to. Be sure to keep up with AB5k on the blog and the developers group. If you have any questions feel free to email me.

thanks guys

update

Help on the first checkout of the code: the project uses NetBeans ant files so you should be able to build the container and the desklets without running NetBeans. The first time you check out the code, however, you will need to open up the project in NetBeans to resolve the references to the jars and to pick up the 1.6 JDK that you have installed (since different betas call 1.6 different things like "JDK 6", "JDK 1.6", "JDK_1.6", etc. After you set the references you don't have to use NetBeans anymore.

Back from the Java Posse Roundup

Now that I've had a week to recuperate, and heal from my poor attempts at snowboarding, I can tell you about where I was the week before last. From the 5th of March to the 9th I was in Crested Butte Colorado for the Java Posse Roundup.

A quick bit of background. The Java Posse is a podcast (an internet downloadable radio show, essentially) devoted to Java. It is run by Joe Nuxoll and Carl Quinn (formerly of Sun, now of Apple and Google respectively), Dick Wall of Google, and Tor Norbye of Sun. They have steadily built their readership over the last year and now have enough listeners to support their very own conference. Rock! The Java Posse Roundup is a small conference they organized in Crested Butte, Colorado (a very small town in the mountains, think South Park. We just need Tom's Rhinoplasty :), with planning and assistance from Bruce Eckel, author of Thinking in Java. The Roundup was an un-conference following after the Open Spaces concept. This means it was not structured like a traditional conference and had no pre-planned sessions. Sessions are proposed and decided on the first day and can change over time. Most sessions were very open ended, starting on a particular topic but usually finishing on something else. The week was chaotic but very very fun. With only 30 people in attendance I was able to spend a lot of time with the other attendees and learn a lot about how people are using Java (and will use Java) in the future.

Also in attendance were Brian Ehman, the Java Posse intern; Robert Cooper, a friend of mine from way back when in Atlanta and author of the soon to be released GWT in Practice; and our illustrious Java.net editor (and another longtime friend from Atlanta), Chris Adamson.

Our days were structured but flexible. From 8am until noon-ish we have three session slots with an average of 3 sessions per slot to choose from. After noon we break up into groups for lunch and then have free time. Some days we would do something active like skiiing, hiking, or going to the store to purchase food. Other days we would have geek time for emails, fixing bugs, and helping others out with their code. I did a lot of the latter, of course. We would all meet again around 6 for a big dinner and discussion, followed by lighting talks in the evening where we would give five minute demos on cool things that find our interest; Java or not.

Overall I had a great time and feel that I got a lot out of the conference. This was an opportunity to connect with a lot of great people. I made quite a few additions to my address book and now have a lot of followup to do. I stayed in a rented house along with the Java Posse guys and two others. Not only was the house huge and a great place for people to come in the evening, it was significantly cheaper per person than a hotel, saving my gracious employer quite a bit of money. :)

Here is a brief overview of the sessions I attended along with my notes. All sessions were recorded by the Posse and will be up on the web soon. I'm sure I missed a couple and can fill in once the recorded sessions jog my brain.

intro:

We all learned about how an un-conference works and got settled in.

AB5k

Robert Cooper and I announced AB5k, our all Java widget system project, and got some feedback. It was a small session (everyone else was inthralled in the Dynamic Languages on the JVM talk in another room) but I got a lot of great feedback. The biggest thing I took out of it is that I must focus on Java's strengths. Because AB5k is written in Java it has some great advantages over the other widget systems. Cross operating system and cross operating system version support, I18N, 3d/2d integration, multi-language support, and a robust security system are all advantages we need to leverage.

JNI: what's up with that?!

JNI is too hard to use, too slow, not well supported. Many specific issues were mentioned, including Dick Wall's problem with the JVM not using hardware accelerated trig functions but JNI is too slow to implement it yourself. This is something the JVM must do but multiple JSRs to add support for it have been shot down. Perhaps now that Java is open source someone could do it.

Flex and rich webapps / what's wrong with applets:

This went all over the place but the general consensus is that the Java plugin itself is the problem with applets and must be fixed. Flash's VM beats the Java plugin in pretty much every metric. Some interesting and crazy ideas were proposed like:

• Get the open source community to write a new Java plugin
• letting the Flash plugin talk to the Java plugin to take advantage of Java features
• make Java compile to Flash files, similar to how GWT compiles to Javascript
• write a JVM in Flash so we can run applets in Flash's vm.

Flex apps:

In sort: Flex does some very powerful things very easily, and Apollo will let you write Flex/Flash apps that run on your desktop. Adobe has some serious people working on this and it looks great. This is something the Java community needs to take seriously, either by competing or working with it. Flex and Apollo are going to change the way people write desktop apps over the next five years.

Media support on the JVM

This was Chris' talk about the state of media on the JVM, the failure of JMF and Java sound, how Quicktime is going away, and what to do about it. The general consensus was that media, especially content creation, is very important and we must address is soon. Some ideas include wrapping some of the cross platform open source tools in Java. Things like VLC and GStreamer were mentioned.

Java Properties:

This is Joe's Nuxoll's proposal for Java properties (originally proposed to JavaSE several years ago when Joe worked for Sun). It seems like a very clean and simple way to add properties and events to the Java language with as little breakage and non-intuitive syntax as possible. If we decide to add properties to Java we really need to look at this proposal. This was a well attended session and most people agreed that we should add properties to the language. (I'm a huge fan.) Other suggested this should be left to other languages that run on the JVM like Groovy and Scala.

Java.net vs Google code vs Source forge vs others:

I kicked off this session to discuss the relative strengths of the various project hosting sites. None of them came out on top, though I learned a lot. Google code is doing a great job at providing tools but not at providing a community. I plan to take a lot of this information back to the Java.net planning meetings during Java One. Google's issue tracker in particular is much, much better than Java.net's.

Lighting Sessions

The evening lighting sessions were a ton of fun. I showed off several demos I've been working on over the last year including:

• NetBeans JSR 295 & 296 support.: I explained what the two JSRs are and how NetBeans is supporting them. Everyone really liked it.
• NetBeans menu support: I showed off the menu designer work I've been doing.
• JavaDocs from the year 2020, a mockup of what totally redesigned Javadocs would look like.
• JOGL utils: utility classes to let you quickly make 3d animations. I showed off a 3d photoviewer that shows a Flickr photostream. It only took me about 4 hours to build.
• JXVideoKit: a set of utility classes for SwingX that will let you use JMF to play H.263 (YouTube quality) video, complete with overlays, hackable drawing code, frame capture, and the ability to drop a video into a 3d scene.
• SMS support: I showed how to use a JNI library to hook into the Sudden Motion Sensor in my laptop and use it to scroll through a 3d list of photos. I must confess this was done on a dare by the aussies from Cenqua. They 'threw down the gauntlet' which means I simply had to do it. Thanks guys. You rock.

Code for the above demos will be forth coming if people are interested.

Other sessions of note include:

• Scala, a very interesting and unusual language that runs on the JVM. It makes pattern programming very easy.
• Yahoo Pipes: Ido from Yahoo showed how to use Yahoo Pipes to combine and mix RSS feeds with other datasources. Some really cool stuff. My only complaint is that they really should have called it Yahoo Tubes!
• Flex demos: James Ward, a former Java guy now working for Adobe, showed off some amazing Flex demos including a 3d album cover viewer ala. iTunes, and a 3d book with translucent pages you can flip using your mouse. Flex is very powerful and their development tools let you do a lot of cool things that look great with very little effort. And Apollo is going to do some amazing things. We desktop Java guys need to keep an eye on Flash.
• Cenqua: The Cenqua guys have some amazing tools for working with your code: clover for testing, fisheye for giving you a dashboard view of your code, and crucible for doing team code reviews. I urge you all to check them out.

Posse Brain Dump: JavaDocs from the year 2020

At the Java Posse Roundup last week we had some wonderful evening sessions called Lighting Talks. During these sessions each participant had 5 minutes to give their entire presentation. This necessitates, of course, brevity and clarity above all. And of course, since this was the evening, we were all sitting around munching on BBQ, drinking beer, and laughing away during the proceedings. So in short, it was a lot of fun. Some of the talks were Java related at all. Ido Green from Yahoo introduced us to the sport of orienteering and Joe Nuxoll from the Java Posse gave several presentations about the physics of race car driving. Fascinating stuff.

Anyway, back to what I came to talk about. What I'm about to show you is several demos that have been sitting on my harddrive for a while. I pulled them out and showed them to the Roundup attendees with a warm reception. This convinced me that some of you might like to see them too.

I want to state at this point that these are not SwingLabs projects. They are simply demos to try out ideas. However they all have the potential to be great SwingLabs projects. If you think they would be a good project and would like to help run it then please email me and Rich so we can get you started. Thanks.

No on with the show! I'll send out a different blog with each of these. Here's the first:

JavaDocs from the year 2020

This was an experiment in what we could do with Javadocs now that most browsers support Javascript and CSS very well. The code is pretty simple: a custom doclet which produces XML, then run through XSLTs to produce HTML which uses custom CSS and Javascript. All as spec compliant and clean as possible. The design of the new interface is both prettier and more functional than standard javadocs. It shows off lots of interest ideas like:

click to view live

• organizing docs by category using tabs
• grouping properties into a single unit
• conditionally hiding advanced and deprecated methods
• collapsing inherited methods into open/close strips
• pinning common features to a fixed header at the top
• reducing the vertical space used to show more docs at once.
• better styles for the overview and code snippets
• rollover/tooltips to show the full classname

Note that I've only done the classes themselves, not the class list or package level docs, so that's very spare right now.

Let me know what you think. More coming soon.

- Josh

Quick updates: Desktop Matters, Java Posse Roundup, AB5k, and more

I got back from the Java Posse Roundup yesterday. Due to complications with my flights I was forced to spend an annoying Saturday night in a hotel in Denver. Still, the conference overall was worth it. I've got a bunch of things to share with you over the next few days so I'm just going to give you a few quick updates today.

Nimbus

At Desktop Matters SwingLabs announced the Nimbus Look and Feel, a Swing L&F based on the GTK theme created for the Java Desktop. It looks really good and may be included in a future JRE. In the mean time you can download the jar from SwingLabs. Here are some screenshots (1, 2, 3. I just ran SwingSet2 with it and it looks great. Try it with webstart here

AB5k

We've been fixing lots of bugs in AB5k. In particular the shaped internal frames should work properly on Windows now. I've also added a simple guide to building your own desklets, a FAQ, and fixed the DNS so that ab5k.org and ab5k.com all go to the same place. Cooper also just added our first try at automatic widget updating.

I think AB5k is coming along quite well. We've gotten notice on Artima and Java Lobby; though that last discussion had at lot to say about AB5k's lack of maturity. I agree that it needs work, but that is why I decided to release it early. I wanted to get the community involved as early as possible. To that end I'm asking everyone interested in widgets on Java to join the discussion group and contribute their thoughts. Thanks!

Java One

Our AB5k talk isn't in the JavaOne PDF catalog but it is in the searchable catalog; so don't worry, we'll be there. There should be a new PDF out at some point.

Coming soon

A menu designer, 3d utilities, 3d video, lessons from The Roundup, 1and more AB5k updates. Oh, and of course, lots of photos!

updates

Added link to Jasper's blog entry with a webstart link to the Nimbus demo.

AB5k: our all Java widget system is released

I'm attending the Java Posse Roundup right now and won't have a chance to post in detail about this until next week, but since the news is out I wanted to make sure I let you all know what's up.

Robert Cooper and I have been working on a secret project for the last few months called AB5k. It's a widget/gadget container built entirely in Java 6 letting you run widgets on any operating system.

You can try out AB5k using webstart from our website at:

At www.ab5k.org you'll find the widget container, a few extra widgets (6 are pre-installed) and follow the links to get the code and join the development group. If you will be attending JavaOne you can see it in action at my AB5k BoF session!

Currently we don't have a developers guide, tutorials, or even screenshots because we are busy fixing bugs and adding new features. Next week I'll talk in detail about how it works and why we think you'll like it. But for the time being please try it out and let us know what you think.

Thanks!
'Josh

Updates

We've been mentioned on Artima.

We've just pushed up a bunch of bug fixes. Please read the details on our AB5k blog. We'll post most news about AB5k there so please subscribe to it.

My Java One Talks

Just a quick post as I'm rushing to be ready for the Java Posse Roundup conference next week.

When Chris, our eloquent Java.net editor, mentioned that the JavaOne 2007 acceptance and rejection letters have gone now I realized that I hadn't blogged about it.

Yes it's true, a BoF for my secret project that I've been working on with Robert Cooper has been accepted, so if you don't make it to the Java Posse Roundup next week where we officially release it then try to come to JavaOne or just keep checking my blog for more details.

So that's the big one, but what about my other talks? Every year I submit about 5 and only one or two get in; and this year is no exception. My talk on using Flying Saucer to easily generate PDFs was not accepted, alas, so I think I'll have to write an article on that at some point. Also my Painters talk was not accepted, so I will probably contribute some content to the Extreme GUI Makeover or SwingLabs sessions. (though I may not need to as Painters are a heavy supporter of my secret project).

Finally, my other talk which did get in is JSR 296 with Hans Muller. We will show how JSR 296, the Swing Application framework, functions and how you can use the new features in NetBeans 6 to make your life a lot easier. My goal by the end of the talk is to show you how you can build an entire deployed rich client application in under 60 seconds. Hans says I can't do it. I guess we'll see!

Also be sure to come see me at NetBeans Day (the day before JavaOne starts) where we will be showing off lots of cool new NetBeans 6 features. NetBeans day also has the advantage of being slightly cheaper than JavaOne (as in completely free!)

Oh, and some quick teaser screenshots. Big stuff is coming!

Netbeans M7 and the amazing new Web Start plugin

Milestone 7

Milestone 7 of NetBeans 6.0 recently came out and I tried it out for the first time today. Now I know what you are thinking: "Don't you work on NetBeans? Don't you work for NetBeans?!" Well yes, I do. But I'm working on a branch that hasn't migrated to the 6.0 codebase yet. It will in the future (and I'll have blogs on it) but for now what I see every day looks pretty much like NetBeans 5.5. Trying M7 is my first taste of NetBeans of the future (other than my own highly excellent work, of course. but more on that later :) .

So what do I think? Well, it's pretty. There's a new color scheme with new icons and I think it looks pretty good. IDE's are never known for their fantastic user interfaces but I think the designers did a good job on this one. It has a new sense of consistency that I really like. And it looks halfway decent on my Mac, which is something IDEs are almost always bad at!

So on to the new features. There's a new editor in there which I haven't played with much but it does feel faster to me. I don't know much about the EE features (since I don't do web programming) so I'll cover something that's very important to me: Java Web Start.

A New Java Web Start Module

In the past there were several Java Web Start modules available for NetBeans that were all quite horrible. One of them even generated JNLP files that would core dump on Mac! I've been wanting good Web Start support in my IDEs for some time and now we've finally got it.

Milan Kubec has been working on a new Web Start module that fully integrates with the project system. All you have to do is create a desktop application and click a checkbox in a new Project Properties pane. Then hit run and it'll do the right thing. Here's a screenshot to show you what I'm talking about:

The Application preferences panel

The Web Start preferences panel

How it works

There are two new panes. The first one lets you enter standard application attributes that are useful for any desktop application. Things like the name and splashscreen. The second pane is for Web Start specific properties like the icon and codebase attribute. All you need to do in order to enable Web Start is click the appropriately titled Enable Web Start checkbox and it will do the rest. When you hit build the module will generate a JNLP automatically, including the jars in your classpath and the location of your main method. That's it.

I love this module because it does the annoying work for you. The IDE already knows what jars I need and where my main class is. Now it can put all of that information to good use! Building a syntactically correct JNLP file without me lifting a finger. (Well, maybe just my mouse clicking finger).

What I love about this module is the ability to get a running application up on a website very, very quickly. You can create a new project, put together a form, then press build to assemble everything in the dist directory. This includes the jar, .jnlp, splashscreen and icon images, and any support jars. It's a dream. I've even heard from the developer that he hopes to add support for deploying the Web Start app directly to your webserver. (no promises though)

A note on Subversion

One thing to note about NetBeans 6.0 M7: the Subversion module requires Subversion 1.3 or greater to be installed on your computer. I upgraded to 1.3 manually several months ago, but the system default on Mac OS X 10.4 is still 1.2, so that's what NetBeans found. Rather than trying to modify your system wide path variable you can tell NetBeans the location of Subversion (or the correct version of Subversion) using the Subversion panel in the general options/preferences dialog. It's under Miscellaneous/Subversion. And thankfully you don't have to go to the advanced options to set it!

So go check it out. Excellent Java Web Start support, new icons, and tons of other stuff. NetBeans 6.0 M7.

Tricked out maps and a new tile provider.

In previous blogs I introduced the JXMapViewer and JXMapKit, all part of the SwingX-WS project. We're still working on improving these classes and have more good stuff coming. I recently added support for non-rectangular maps, which makes the 1:2 Blue Marble map tile properly. I also added variable size tiles which allows the JXMapKit zoom out further. These are all nice improvements, but don't really matter if mapping isn't important.

I've been blogging about the JXMapViewer for a while now and some of you may wonder: why do I do this? Why does mapping matter? Well, I think it matters a great deal because maps are the way that we interact with the world on any scale larger than a few blocks. Maps let us find out where things are, and visually show information to others. In short; maps are an important way of visualizing information; and that means Java needs great support for mapping.

The problem, however, is that we currently only have access to some NASA imagery, which some people feel isn't very useful. Well, I have two answers to that:

Doing cool things with NASA's Blue Marble images

The best way to show people that maps can be pretty and useful is simply to do it. Here is a screenshot of a JXMapKit that has been tricked out with Painters and the Timing Framework. It is a simple travelog showing various points on the globe that I have visited, along with some descriptive text. The screenshot is pretty but you really need to see it live to get a feel for how the animations and rollovers work.

Fancy JXMapViewerApplet. Run it live

Though the data in this demo is hard coded it could easily be specified using applet parameters. This would let non-programmers embed it in their webpages, showing their own travelogs! All of the effects you see here were done using stock Painters and the Timing Framework, all part of Swing Labs.

But what about the second part....

Getting a new free map source: Open Street Maps

We can now view street maps from the Open Street Maps project! If you haven't heard of this project before you should really check it out. It is a map put together by individuals tagging and uploading GPS traces to a shared database. They only have a few cities so far (mostly in Europe) but they are growing every day and could use more help. A simply amazing project! Here's a screenshot:

JXMapViewer showing Open Street Maps of London

To get Open Street Maps in your own application use this provider:

        final int max = 17;
        TileFactoryInfo info = new TileFactoryInfo(0,max,max,
                256, true, true,
                "http://tile.openstreetmap.org",
                "x","y","z") {
            public String getTileUrl(int x, int y, int zoom) {
                zoom = max-zoom;
                return = this.baseURL +"/"+zoom+"/"+x+"/"+y+".png";
            }
        };
        info.setDefaultZoomLevel(1);
        
        TileFactory tf = new DefaultTileFactory(info);
        JXMapKit map = new JXMapKit();
        map.setTileFactory(tf);
        map.setCenterPosition(new GeoPosition(51,30,25,0,7,39)); // the center of London

And that's it. Street maps in your own app.

But of course, the best thing to convince others that the JXMapViewer is worthwhile is quite simple: get people to build more apps! So lets build some more. If you have any application you've written using the JXMapViewer please email me or post it here. We'll highlight it on the SwingX-WS webpage and try to get it into the JavaDesktop.org project spotlight.

Thanks everyone!

- Josh

Postscript: here is the source to both the applet demo and the OSM tile provider. The required jars are included.

First release of JSR 296

Hans just announced the first prototype implementation of JSR 296, the Swing Application Framework. I'm very excited about this because it will make Swing applications a lot easier to build and more maintainable. I'm even more excited because we will have top notch support for JSR 296 in NetBeans 6.0. I know this because I'm one of the developers working on it.

Our current work in NetBeans isn't very usable yet, but I thought I'd give you a few screenshots to let you see how it's developing.

Using JSR 296 you can create actions from plain methods by using the @Action annotation. Once you have done this NetBeans can search through your application to find all actions and then let you edit them.

There are three ways to work with Actions. First, you can select from a list of known actions in the property sheet (Fig 1)

Fig 1: the Action Property Editor in the property sheet

Second you can press the '...' button to open the full Action Property Editor dialog.(Fig 2)

Fig 2: the Action Property Editor Dialog

And finally you can use the global action list to see all actions and edit them. (Fig 3)

Fig 3: the Global Action List

Coming soon, more Swing Labs updates!

Free Projects Part 4: an LCD Controller

My sincere apologies. I completely forgot to post the code from the last free project, sketch pad, so here it is. I also forgot that I have one more project to give away, one very different than anything else I've ever done. This one involves some hardware.

Another crazy idea

You see, every so often I get a crazy idea for a startup, put some effort into it, and then realize that I know nothing about hardware or how to start a company. That means my harddrive is filled with interesting and bizarre company ideas, some of which are more developed than others. This is one of the more developed ones.

My idea was that when you play a full screen game or are doing something else which takes you full attention it would be nice to have a little LCD screen which would sit next to your computer and show you ambient information such as the time, weather, or the currently playing song on your MP3 player. If the gadget had buttons then you could use it to switch tracks, change the volume, look at different weather settings, or anything else you wanted to with it. Showing instant message alerts, for example.

There would be software on your computer which controlled this little gadget and had a set of plugins for doing different things. Since this would be written in Java you could easily write your own plugins to look at cool webservices or hook into native applications and system resources. The possibilities are endless!

Of course the possibilities are always endless, and I spent endless amounts of time playing around with it before I went on to other things. Maybe it's still a good idea. After all, this gadget seems to be selling, and mine would have been better. It's blue! Anyway, there is still a lot of interesting code hiding in here so it might still be useful to some of you.

The LCD controller

First of all, I purchased and wrote a little Java device driver for the Crystal Fontz 631 LCD display (the 601 as well, I think). It is a two line LCD display with four buttons and a USB connection. Given the poor state of USB in Java I had to install a USB to Serial device drive on my computer and then connect to the LCD as if it was a real serial port with the RXTX serial library.

Once I had access to the serial port I wrote some Java code to implement the LCD's packet protocol. This drove me crazy for days because I could get the word NOON to show up just fine but the word MOON would not. I finally figured out that the C code I was working from was written for Linux and assumed a little endian processor. Since Java is big-endian (which, like gravity, is the right way), my code only worked when the text happened to be symmetric! *sigh*. Bugs like these were the reason I stopped writing C code a decade ago.

Here is what the desktop control app looked like:

The clock plugin

As you can see, it has a simulation of the real LCD panel which shows you what the plugin or animation will look like when it running. You can configure each plugin and set which ones the panel will cycle through. The LCD lets you define custom glyphs, which is how I created the fake large font for the time numbers.

weather plugin

The app also had a really bad glyph editor which you can see here:

glyph editor

But it did let you do some funky animations like this:

funky animation in progress

The code you are probably interested if you want to hack on this particular LCD panel is the CF601LCDPanel and Packet classes in the net.joshy.lcdbrick.serial package. There is interesting code in the plugins packages for reading weather, getting the current DHS threat level, and checking for new email. There is also some Mac specific code for controlling iTunes, getting the current battery level, setting the system volume.

So if you want it, let me know.

NetBeans Action Property Editor update

And to tide you over until we have something more to show, here is the latest screenshot of the Action Property Editor for JSR 296. It's a bit cleaner than the previous one and now you can edit icons! Let me know what you think.

Update: code download

The code is available here

Tag! I'm it

Some of you may have seen the five things you don't know about me meme going around. The idea is that someone tags you, you post to your blog five interesting things that people don't know about you, and then you tag five more people who must do the same. Romain Guy got it a few days ago and linked to me, so now it's my turn.

Where I live, my job, and my recent marriage are all things that you do know about it because I blog obsessively, so here are a few things that you hopefully don't know. If you already do know these things then please send a stamped self-addressed envelope to "I already knew that" Springfield NT, 956789", for a full and complete refund.

I have driven across the US continent an average of once a year since I was 18, including 4 trips driving by myself and two trips on a Greyhound bus. The longest was a two and a half month trip in 2001. The shortest was a bit less than three days, including a 27 hour stretch from Amarillo, TX to Atlanta, Ga when I narrowly made it through a blizzard in western Texas. Later that same year I suffered through a '95 degrees at midnight heat wave', also in western Texas.

Due to my driving travels I have been through almost every state. The only one's I'm missing are Alaska, Hawaii, and Maine. (actually, I may have hit Maine. Andy?) I have also traveled outside the US to Italy, Japan, and the Czech Republic, all in the last three years.

I'm talented visually in a family of performers. My parents met while training to be ballroom dance instructors, one of my sister's was a dancer for several years and the other was an actress in Hollywood (ever see Road Trip?). Any everyone sings. I, on the other hand, am horrible at singing, dancing, and acting. I've always been more attracted to painting, photography, and origami. That probably explains why I care so much about visual design and desktop Java.

I don't like to watch sports on TV, but I love to attend a game in person. Especially hockey, which is fortunate because Jen is a huge fan. I don't really care about who wins or loses over a season, I just enjoy a good game. The food, the crowd, the sound of the puck on the ice. It can't be beat! Oh, and thanks to my new home I do have to root for the Oregon Ducks. Go Ducks!

I hate class action lawsuits with a passion. I feel the benefit only the class action lawyers (on both sides), provide little to the plantiff class, and raise prices for everyone. Whenever I win a settlement I give the money away. Fortunately Sun is very generous and matches my charitable donations dollar for dollar so I was able to donate almost a thousand dollars last year to the Katrina Victims on Allstate's behalf. :)

I'm a libertarian and a huge proponent of nuclear power. The only magazines I subscribe to are Wired, MacWorld, and The Economist. I voted predominantly Republican in every election since I was 18 except for this past November. I am pro-choice, pro-capital punishment, pro-gay-rights, pro-gun-rights, pro-drug legalization, and anti-farm subsidies. In general I believe free trade of capital and labor is good, and that people should do what they want as well as take responsibility for their own actions. Or in the words of the great ones: Be excellent to each other.. and party on dudes!

So who's next? David Herron, Chris Adamson, Kirill Grouchnikov , Robert Cooper, and for you non-Java folks, my actor/geek sister