Joshua Marinacci's Blog

J2SE 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 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.

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

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.

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

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.

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!

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 Rachel Hill.

Rockin' 2007

Well, the new year has come and my vacation is over. I the last three weeks I gave a way a bunch of projects, released the JXMapViewerApplet, I had my entire family fly to Oregon from all over the country, and got married to the beautiful Jennifer Greenup. I even got to stop for some coffee (see photo below). Not bad for a supposed vacation.

So what does 2007 bring? For me personally, a lot less moving. I'm settled in Oregon now (still have to get a new license) which means that I can get back to SwingLabs and cool open source projects.

For the Java world, 2007 is going to be an exciting place. Over the next year the community will begin to explore the possibilities revealed by open sourcing Java. I can't wait to see what happens. I'm also personally involved in several cool projects that we will develop and reveal over the course of this year. Here's just a quick preview of what's coming.

Big changes in Swing Labs. I won't say any more. Instead I'll let Rich take the lead on this.

Finishing up Painters and the JXMapViewer. This are both subprojects in Swing Labs that I have been very passionate about over the last year. As we put the final touches on version 1.0 I hope you will find some interesting things to do with them. I am particularly intrigued with the JXMapViewerApplet. If we can control the applet using Javascript then many interesting hacks become possible.

I proposed several sessions for Java One, including a Birds of a Feather talk on Flying Saucer. This year I've taken a different approach. Rather than discussing how Flying Saucer works I will show how to use it in some real world applications; with PDF generation as the focus.

Top notch support in NetBeans for JSRs 295 and 296, the Beans Binding and Application frameworks. We are homing in on final designs for a suite of new features that will make building client apps a breeze in NetBeans. Look for new builds over the coming months as we approach JavaOne.

A top secret project. There's an idea I've had for a while that will finally come to fruition this year. This project is the reason I have been clearing my plate of other code and projects. I really feel the idea is so good it warrants spending all of my free time on it.

Speaking of clearing my plate, there is one last code drop to give away. Look for it next week.

So lets say goodbye to 2006 and look forward to all of the great things coming in 2007. It's going to be an exciting year!

- Josh

A Mapping Christmas Present

You may get several Christmas presents this year so I'd like to give you all mine first. Best to be early than late and forgotten. :) You can scroll down to the screenshot and link if you want, but if you prefer some delightful Christmas suspense begin reading here. You might want to grab some egg nog first. In fact, adding a splash of rum might help too. We've got a lot to go through.

As you may know from reading my previous blogs we have been working to move the mapping component from our Aerith demo into the new SwingX-WS project. Our goal has been to make mapping easy; so easy that you can drag and drop a component into your Swing app and have something that works with no extra configuration. Sadly.. reality often diverges from our wishes.

Our Christmas Wishes

The JXMapViewer, our new mapping component, is still to hard to use. You still have to build too much of your own code and configuration to get it to run. For many applications you just need a map of the world. Right now, when you create a new map component, you get nothing at all. Nada. Zip. Zilch. Nil! Surely we can do something useful by default!

We need a stable data source. The WMS server from my previous examples has been up and down a lot, so we could never guarantee that it would be there when you need it. I've had some trouble finding a reliable server that would give us good performance. Something stable enough that we would feel comfortable setting that server as the default. That's asking a lot.

It would also be nice to have a prefab application or applet with no Java coding required. One of the great strengths of Google's AJAX offerings is that you merely need to paste a snippet of HTML and Javascript into your webpage to get started. We really need to be that easy!

Three Christmas Presents

So for Christmas we wanted to solve all three of these problems. They aren't perfect yet but you can see where we are going and maybe even help out.

JXMapKit. We've recently added the JXMapKit class. It's a composite component that bundles up a JXMapViewer class with common things you are likely to want such as zoom buttons, a zoom slider, and a mini map. It also pre-configures the map component to use a known stable map server. Which brings us to..

maps.swinglabs.org. We need a stable map server. Nothing I've found so far fits the bill, so we thought: why not make our own! For serving up satellite data it's actually quite easy. We took one of NASA's large Blue Marble images and chopped it up into little 256 pixel square tiles. Currently the server is set to maps.joshy.net, but it will be renamed to swinglabs.org soon. We are using a relatively low resolution bitmap right now (a mere 5600x2700 pixels) but we will upgrade to higher rez soon.

Of course our own server can only deliver so much bandwidth and we don't have the disk space for a full set of ground level satellite photographs. That's why we've been talking to some engineers at NASA. They are very interested in working with us and sometime soon we hope to have direct access to the same map servers that power NASA's super-awesome 3D WorldWind client.

JXMapViewerApplet: The only thing better than writing no Java code is not having to compile it either. We have put together an applet that embeds the JXMapViewer right into your webpage without needing to write anything at all. You will be able to drop an APPLET tag into your webpage, hit reload, and have maps immediately available.

So here it is. Our first mapping applet from Swing Labs.

Merry Christmas!

Run the JXMapViewerApplet
requires Java 1.5

A word of warning: This applet is not optimized in the slightest and the JXMapKit itself still has many bugs. This means it takes longer to download than it should (much longer because I haven't stripped the jars yet) and there are several problems with repainting and keeping the map views in sync.

New features coming next year:

We've got more plans for the JXMapViewer in 2007 and we need your help. Here are just a couple of the things we want to work on in the new year

Applet features. While it's not currently working, we plan to let you add waypoints and configure the applet using PARAM tags or Javascript. No Java coding or compilation required. We'd like to hear from you what kinds of things you'd like to do and what sort of API would help.

Get rid of the jar signing. If at all possible we will make the applet load from the same host as the tile server so the applet won't need to be signed. You won't need to host the jars any more. Just link to our jars and go

Performance, performance, jingle bells, and performance: Stripping the jars will help with loading time but the real improvements will come from completely rewriting the image loading / threading / caching routines.

New data sets NASA has a variety of map sets we could use. What would be most useful to you?

New features that you want!. Ultimately we write code that you want to use. What cool things would you like to do with maps?

Happy Holidays

That's it for me for 2006. I'm having my entire family in town for Christmas and then three days later getting married. It's going to be a busy and fun week. Have a Merry Christmas and a Happy New Year everyone. See you soon!

Free Projects Part 3: SketchPad

Last week's project

So far the response to my free projects has been positive. There was a question about why I put the strange requirement of having to create a project to get the code. The simple reason is because I thought it was funny. I have no way to enforce that anyone does anything with the code. As with all of my open source work, I simply hope that something useful comes out of the effort I put in. So if you like the code just drop me an email saying so. That's really all. And with that, here is the code to the stacked editor.

Now, on to this week's project:

SketchPad: A Generic Reusable Tookit for Building GUI Editors for Building Graphical Products

Okay, I seriously went waaaaay to meta on this one. What I actually built with it is two visual editors. One is a Swing GUI builder with some experimental ways of configuring the constraints using magnet like controls. The other is a simple drawing app with grouping abilities. But hey! It's got a nice scrolling ruler! I'm sure that could be used for something cool!

Drawing program with ruler

Swing Layout program with magnet grid controls

What could you do with it?

The toolkit API itself is a mess. I wrote it over several years while I was learning more about API design and I hadn't done much with reflection yet. I wouldn't try to build further apps with it. I think the code generation and on the fly compilation parts might be useful. There are several components within it which might be reusable, like the scalable ruler. I think there are also some interesting interaction ideas here, such as the magnet layout and the simple drag for shapes.

NetBeans 6.0 update

Just to let you know what we are up to, here is a screenshot of the latest Action Property Editor dialog. This dialog lets you select any action, update it's properties, or create a new one either in the current class or application wide. It still needs lots of tweaking and may look completely different by the type 6.0 goes final, but this will give you an idea of where we are headed.

Action Property Editor dialog

Czech Photos

More photos for your enjoyment.

Enjoy. More code and screenshots next week.

Free Projects Part 2: the Stacked Image Editor

The Stacked Image Editor

The Stacked Image Editor is a little program I wrote and posted on my blog a year and a half ago. It is used to draw a certain kind of diagram very easily. In this case, I had a need to show something composed of layers, with each layer broken out visually so you could see how they stacked. I was learning more about how the hardware accelerated affine transforms worked at the time so it seemed like a good example app. You just add images as layers. The app will draw them sheared on an angle with transparency so you can see each layer distinctly. Once you've tweaked all of the settings you can save the whole thing out to an image.

The Stacked Image Editor in action

The application runs and works, though undoubtedly with many bugs (I recall some cropping issues with the generated PNG). As with the previous app, I built this program on top of an early proprietary application framework which has been superceeded by JSR 296. It should be pretty easy to replace.

future features

I'd like to see it support more output formats and visual tweaking options. And of course redo the interface using Matisse. I'd also be nice if you could drag and drop an image on to the app rather than using the 'add' button. Positioning of the images would be good too.

So that's the app. Let me know if you want it.

Daily Czech Photos

Secret Project Update

No updates today due to the holiday. More coming soon

Musings on the new opportunities that Open Source Java brings

I have often said that I don't love Java because I'm at Sun. I'm at Sun because I love Java. I love Java so much that I wanted to work at a place where I can do the most good for the Java community, and Sun is definitely that place. Now that Java is open source I think it means only good things.

The big announcement today: Java will be open sourced under the GPL. I think it makes a lot of sense because it protects Sun's interest in preventing forks and also the community's interest in knowing that Java will forever be available in the public sphere. The GPL has always provided an option to fork just in case someone takes the code in a bad direction. Historically having this option available ensures that it never needs to actually be used, letting the community grow and thrive.

So what does this actually mean? What is the benefit to open source Java? How will things change? Here's what I think will change and what won't. I say this as my own opinion, not an official statement from Sun. I also say this as someone new to Sun, coming to Sun two years ago from an open source background. I'm sure that engineers with more experience than I will have different opinions. So with that, let's hear it:

How will open source change Java

• Real bugs will be fixed faster and non-bugs will be closed faster than ever.
• Java won't fork. Few developers will have incentive to fork Java. It's a lot of work for little gain. Branches for new features or new platform support: yes. A true fork: no. Not even MS has much to gain from this anymore.
• The JCP will grow and change. As before, big decisions about the future of Java will go through the Java Community Process. However, with more interested developers the ranks of the JCP will grow and change in some very good ways.
• Java will have first class support on Linux, Free-BSD, and other 100% open operating systems. This is huge. Hugely, huge. I'm hoping we'll finally get a KDE look and feel as well.
• NetBeans will open the entire JDK sources all at once. It's true, we're working on it for NetBeans 6. With the new editor infrastructure this will be possible. You might not actually want to do this, but it should be possible if you've got enough memory.
• We will see lots of small crazy experimental versions of Java that add different things. Imagine a JDK with Find Bugs, MySQL, SwingX, JDIC, JInput, JOGL, Java3D, Tritonus MP3, jSDL, KDE-Java, Gnome-Java and a bunch of other cool libraries pre-integrated. We might even see an entire downloadable VMWare virtual harddrive with Ubuntu + Super JDK + NetBeans preinstalled for the ultimate prefab development environment.
• More adoption of Looking Glass. Now that Java can be freely run on Linux desktops out of the box, there is incentive to ship Looking Glass bundled in with the OS. There's a lot of good 3D cards out there. Let's use'em!
• More 3D Java Games for all platforms. I expect that people will start shipping an optimized copy of Java embedded in their applications. The end user will never need to know that Java is involved. JOGL + Java3D is now available for Win, Mac, and any copy of Linux with the right X configuration (which is more common than ever).
• Burnable Java. Imagine a tool that burns a photo slideshow application preloaded with your photos, plus a copy of Java, straight to a CD. Hand the CD to your Mom, she pops it into her computer, and the photo slideshow starts right up. You'll never need to worry about the version of Java because it's shipped with your app. You don't need to worry about the OS because you code against Java, not against native APIs. (hmm. perhaps 'burnable java' isn't the right name for this. :)
• Java will grow to fill every available computing niche and finally achieve the goal of total world domination.

Okay, so maybe that last one is a stretch, but it's true that this will help to bring More Java to More Places.

So now we have a free runtime, competition between three groups to make the best IDE in the world, and a language that scales from cellphones to desktops to super-cluster-matrix-grids-thingy's. It's a good time to be a software developer!

My first two weeks at Netbeans

Greetings from Prague. I've been at Netbeans for about two weeks now and it's been quite a busy time. I think I'm really going to like it here. Everyone is very friendly, the city is beautiful, and they have excellent and cheap beer (cheaper than soda!). I know you are all busy, so for the speed readers in the group I've bolded the important bits.

So what have I been working on? For starters, I have fixed my first two bugs in Matisse: Drop target is painted on the wrong order for Flow Layout and Improve retrieval of BeanInfos. Fixing a few bugs has been a great way to learn the codebase and get to know the team. When you click on the bug links be sure to note the new look of the website. Being a fan of good design I'm very happy that the pages look so much cleaner.

So what will I be doing for NetBeans? While I will no doubt be poking my head into lots of areas, my main task is working on Matisse. In particular, I am helping to add support for the Swing Application Framework, aka: JSR 296. I was already on the JSR expert group so that made me a perfect fit to work on Matisse. I'll have another blog with details on what we are doing, but for now I'll just say that this will make the common tasks of dealing with resources, strings, and actions ridiculously easy. In particular I will be working on the new Actions support, so look for design discussions over the next few weeks.

I should mention something at this point. It's ironic that I now work in NetBeans because until the last year or so I hated IDEs. As a diehard text editor user I started with Pico, graduated to Emacs, and eventually JEdit (when I figured out that no one hacks on Lisp anymore). I never liked IDEs because it felt like the got in the way, hid important details, and didn't really let me do anything new. Debugging is what println's are for. All of that changed when I first saw Matisse, the NetBeans visual GUI builder. Matisse let me build screens that are qualitatively better than anything I could ever do with GridBagLayout or other layout tools. Not only does it make the screens look better by using proper insets, I can also produce layouts in a tenth the time. This means that I am more likely to improve the layout, taking it through several iterations and show the results to other. This is what makes it such a great tool.

After getting hooked on Matisse I began trying other features of the IDE. Refactoring in particular impressed me. I have played around with the new editor and refactoring tools coming in NetBeans 6 and I'm very excited about them. A lot of long standing problems will be fixed, and most importantly the NetBeans 6 editor will be very fast!

Well, I've got get back to work on some design docs. In the meantime I'll leave you with a few photographs from my weekend trip to Cesky Krumlov (sp?) with the NetBeans evangelist team. Since I don't want to bore you with a constant travelog I think I'll just include a few photos in each blog entry until I run out. Since I've already taken about 800 shots, I've got a lot of blogging to do.

Enjoy!

- Josh

A quick intro to HttpClient

The following is a techtip I wrote which wasn't used. Since I turned out pretty well I thought I'd post it here. Let me know what you think. Would you like more of these small self-contained tips?

A Quick Introduction to HttpClient

Java is great because it has classes for almost everything. For example, if you want to open a webpage you can do it with the java.net.URL class. But what if you want to use a POST instead of a GET request? What if you have a bunch of parameters that need to be properly parsed? What if you want to deal with cookies? The URL class simply isn't up to the task. However, in Java, you are always just a single jar away from the solution. In this case, you can use the HTTP Client library from the Apache commons project here. You will need to put the commons-httpclient.jar and commons-logging.jar files in your path.

To use the HTTP Client import the org.apache.commons.httpclient package and get started:

This is how to do a simple POST request

import org.apache.commons.httpclient.*;
...
// initialize the POST method
PostMethod post = new PostMethod("http://myserver/page.jsp");
post.addParameter("parameter1", "value1");
post.addParameter("parameter2", "value2");

// execute the POST
HttpClient client = new HttpClient();
int status = client.executeMethod(post); 
String response = post.getResponseBodyAsString();

You can set up all of your parameters using the PostMethod class and then execute the POST with the executeMethod() on the post object. After the post has completed you can read the body of the response into a string or look at the HTTP status code. The classic 404 error is an example of an HTTP status code. The example above posted with a set of parameters. If instead you want to just post an entire document, say an XML document or SOAP request, then you could do something like this:

StringBuffer content = new StringBuffer();
content.append("");
content.append("information");
content.append("");
post.setRequestBody(content.toString());
client.executeMethod(post);

Now lets say you need to list the cookies set by a website. That's also very easy to do. The HttpClient object acts as a miniature browser. It will preserve all state about the current HTTP session, including cookies, in an HttpState object. After you have connected to the website through a get or post you can look at the cookies set by the webserver like this:

        int status = client.executeMethod(get);

        HttpState state = client.getState();
        for(Cookie c : state.getCookies()) {
            System.out.println("cookie = " + c.getName() + "=" + c.getValue());
        }

Since HttpClient maintains state about the HTTP session you can also use it to log into secure sites. For example, if I wanted to show the file listing my secure webdav server, the same way a real browser would see it, I could log in like this:

	// create credentials to log in
        Credentials cred = new UsernamePasswordCredentials("myusername","mypassword");
	// set the realm to null, meaning use these credentials for all websites
        client.getState().setCredentials(null,cred);

	// get the html doc
        GetMethod get = new GetMethod("http://files.myserver.com/secretprojects/");
        int ret = client.executeMethod(get);
        System.out.printlin("a browser sees = " + get.getResponseBodyAsString());

The HttpClient library is very powerful, enabling you to perform almost any HTTP task such as GETs, POSTs, getting and setting cookies, handling redirects, going through HTTP proxies, and even HTTPS authentication. And best of all, it is freely available under Apache License. You can download the HttpClient library at

http://jakarta.apache.org/commons/httpclient/

Java people in Prague

If there is any other Java people living in the Prague area who would like to go out for dinner, drinks, or do some general site seeing then just let me know. I'm going to be here for three more weeks and I don't know anyone yet. I'm reading through my Rough Guide book and it looks like there's lots of cool things to see here.

Thanks!

I'm getting married, leaving the Swing Team, and flying to Prague

It's true. I'm leaving the Swing team. But don't worry, I'm not leaving Sun. I'm joining the Netbeans team, flying to Prague, moving to Oregon; oh, and I'm getting married!

I asked the wonderful woman named Jennifer Greenup to marry me last night, and amazingly she said yes! I will be moving up to beautiful Eugene, Oregon as soon as I get back from my trip.

So. After a great two years on the Swing team I've decided that the core libraries are pretty good and now we need to focus on tools. And what better tool is there than NetBeans. I will be working on Matisse, the app framework, and probably many other things. I think my Swing expertise will bring a lot to the team. I also think they will have a lot to teach me about tools and module design. Most importantly I will get to work on a tool that will have the biggest impact on Desktop Java. Flex, AJAX, and .NET are getting better and better.