Joshua Marinacci's Blog

J2SE Archives

Introducing the JFXStudio

Today I'm pleased to announce a new experimental site a few of us have been working on called the JFXStudio (www.jfxstudio.org). It's a site specifically for sharing your JavaFX creations. The JFXStudio is not meant to be an app-of-the-day kind of site, or a showcase for polished apps. It's a place where you can show off your doodles and works in progress. And it's a place where you can get great feedback on your JavaFX creations. Think of it as a Flickr or DeviantArt for JavaFX instead of images. Go check it out at www.jfxstudio.org. We've pre-seeded the site with creations from 6 prominent JavaFX bloggers (like the one below) and we can't wait to have more submissions.

Visualizing Sub-Prime Losses, by Chui Tey

The JFXStudio is a community driven site that is starting small but will grow over time. It is currently hosted on wordpress.com, which is technically limited (no applets or javascript are allowed), but we plan to move it to a better content management system in the future as the site grows. (and we would love recommendations on CMSes to use).

So please check out the site, then share some of your own JavaFX creations.

WidgetFX: Glossitope reinvented

I always hate it when I get so busy that I can't finish an open source project I started. On the other hand, I absolutely love it when someone likes an idea I came up with but feels they can do it better, and then does. Case in point: AB5k aka Glossitope aka a new widget system for Java. I started this about two years ago, showing it off at JavaOne 2007. Alas, it ran into technical difficulties right at the time I started working on JavaFX, sucking away all of my time. Thus, the project is dead and the domain turned to dust. Or has it .... ?

Earlier this year Stephen Chin emailed me about the AB5k code base, asking if the project was still going. I said no, but that the code was still available for anyone to pick up if they so chose. I also recommend using JavaFX instead of straight Java, since JavaFX has already solved a lot of the problems I was struggling with (like transparent windows and virtualizing components). Thus, Stephen started a new project: WidgetFX: The JavaFX Desktop Widget Platform.

The project is still in its infancy, but being built on JavaFX it looks pretty good right out of the gate. It has transparency, a dock, and draggable widgets from day one, something which originally took me a month to do. Stephen and the crew are working very hard, with many new features yet to come. They could definitely use your feedback so please go try the latest JNLP build here, and the join the project and mailing lists. There's even a new Hacker Getting Started guide.

It's fun to see people doing such interesting things with JavaFX.

screenshot of latest WidgetFX build

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. I think that NetBeans is the tool that will make building desktop Java apps as fast, reliable, and pretty as anything those other guys can build.

To start my new role off right Sun is sending me to Prague in the Czech Republic for four weeks. By the time you read this I will most likely be somewhere over the North Atlantic. Next week I will meet the team, show them what I've been doing for Swing and the SwingLabs, learn more about the innards of NetBeans, and of course spend some time enjoying central Europe.

Don't worry. My transition from Swing to NetBeans won't change anything here on Java.net. I will still be heavily involved in SwingLabs (particularly Painters and Animation) and will continue to work on my blog. It does mean my article writing and other projects will slow down (more on that in a future post).

As always I will have two blogs. One here for all of my Java and geeky writings, and my personal site at http://joshy.org, which exists primarily for my mom and dad to know where I've flown to this week. Since I have always had a desire to be a better photographer, both for the satisfaction of creating pretty photos and also to learn useful skills for designing attractive UIs, I have finally purchased a better camera. Last week I bought a new Nikon D50 SLR camera along with an amazingly crisp 50mm fixed lens. So far the photographs are great (there's a few here on my Flickr site) and I look forward to seeing what it can do in Prague.

So stay tuned. More great stuff is coming.

- Joshua

update

As requested, here's a recent photo of us picking out pumpkins. It was bright out!

Update on Bug 6477341,the '...' Windows Combobox bug.

Thanks to the hard work of several teams inside Sun (the development, testing, integration, and approval teams) combined with the persistence of the outside Java community, I am happy to say that the bug 6477341 will be fixed. More importantly it will be fixed in Java 6 final, not in an update release. The fix was just integrated into b103, which should be going up soon.

I'd like to thank all of you in the community to helped drive this bug to be fixed. Especially those of you who voted for it in the bug database. It really does help!

I also want to ask you all to go download Java 6 b103 when it's available. Even with a small change like this there is still a chance of a regression. I certainly hope it won't happen, but it's possible. People subclass Swing components in all sorts of weird ways. And on this note, I have to acknowledge the fact that this fix is conditional on it not causing any new regressions. At this late stage in the release, the most likely solution to a new regression is the removal of the code that caused it. So let's get all the extra testing we can, as soon as possible!

There are two lessons that we can learn from this. First, that I need to be more careful when working on multiple bugs that touch the same file. I have recently taken to creating sub-child-workspaces. This means I check out a workspace to fix the first bug. I then make a child of that workspace to fix the second bug. This makes merging a seamless process and avoids these kinds of conflict errors. It of course requires a version control system which supports an arbitrary hierarchy of workspaces. That's why we are very carefully evaluating what system we will use for the open source release of Java.

The second thing we can learn from this, I think, is that the system works. We have an open development model right now (not yet open source, but that's coming soon). We found this regression because lots of people had been downloading Java 6. Without the help of early adopters like you we wouldn't have found it until Java 6 shipped. The other half is that we wouldn't have been able to classify the bug as a showstopper and get it into the final release without readers and bloggers like you complaining about it. We really do listen to the community. We read the blogs, bugtrack votes, forum threads, and SDN comments. When it became clear this was a showstopper to the people who matter, you, we were able to officially classify it as a showstopper and get it fixed.

I think this was a definite success for our open development model and I know it will get even better once Java is completely open source. I feel very privileged to work on such a great product in a great, open community. I don't think I'd feel the same way if I was working on, say, Vista or Leopard.

NASA Maps in your Swing App

Short short version:

Not Awesome

Awesome!

Short version

You can now embed some NASA map servers into your own Swing apps using the JXMapViewer component in SwingX-WS.

Long version

For the Aerith demo we showed at JavaOne we build a component that can embed Google Maps into a Swing application. Using the Google service in the way we were doing violates their terms of service and though Google would like to work with us it would be difficult to change the licensing on the map data to fit our needs. This is why, in my previous blog, we shipped the JXMapViewer component with a dummy TileFactory and showed how to plug in your own local data. This is interesting but not very useful. There is no conversion between local tiles and lat/long coordinates so you can't draw waypoints over the map in any meaningful way. Shipping a component which doesn't do anything useful out of the box does not make for a compelling library. It's time for that to change.

I have been investigating how to hook into one of NASA's map servers for quite some time. They use a completely different mechanism for retrieving images and, quite frankly, I don't really understand how all of this mapping stuff works. Mapping involves a lot of complicated equations that project real world data, ie: maps and photos of the earth, onto a flat surface of some kind. We created this component to specifically hide the complexity of mapping, but someone has to write that component and those people were Rich, Romain, and I. I created the mapping equations for the original demo by looking at examples on the web. I copied and translated the code but I didn't really understand them. Finally, last weekend, I figured it out. Thanks to these two great weblog entries by Kyle Mulka and Charlie Savage I can now hook NASA's server into the JXMapViewer component.

How it works

Google's map server divides the entire world up into equal sized tiles which you reference with an x/y coordinate. This is Google's own design and it makes the client side of mapping very easy, pushing all of the hard work onto their servers (I've heard they have quite a few of them:). NASA uses a map server specification called Web Map Service or WMS. Instead of using tiles, WMS lets you request a rectangular image of the world expressed as two lat/long coordinates. The JXMapViewer thinks in terms of tiles, so if you can convert between the two systems you can show the NASA data in the map viewer. And that is exactly what the new classes below do:

WMSService wms = new WMSService();
wms.setLayer("BMNG");
wms.setBaseUrl("http://wms.jpl.nasa.gov/wms.cgi?");
TileFactory fact = new WMSTileFactory(wms);
map.setFactory(fact);

The WMS web service is represented, creatively, by the WMSService class. You can set the BaseUrl for the web service and the layer with properties on the WMSService instance. The BaseURL is the URL where the service resides minus any parameters. The layer represents a particular portion of the data available from this map service. In general, these two pieces of information are all you need to connect to a WMS server.

Most WMS servers have several layers, usually a single base layer and several data layers. The base layer usually covers the entire world and the data layers are transparent data sets which can overlaid on top of the base layer. This demo just uses the NASA base layer, often called the Blue Marble. In a future version of the API we will add support for multiple layers at a time.

Once you have the WMSService instance you can wrap it in a new WMSTileFactory and set it on the map. That's it! The WMSTileFactory knows all about the Mercator projection that will convert WMS requests into the tile based coordinate system that JXMapViewer understands.

If you want to try it out take a look at this webstart app.

Just before I posted this app I started having problems connecting to NASA's server. I will continue working on the problem, but in the mean time I have set it to connect to the map server at wms.lizardtech.com, which contains the same data set

In this application I have loaded up the NASA map and then overlaid three waypoints. Each waypoint represents a weather station. Using a library I wrote a while back (available in the weatherlib project on Java.net) you can easily get the weather from any weather station in NOAA's weather.gov network. There XML feeds also provide the lat/long of most weather stations, which makes it easy to draw them on the map. In this example application I have added a waypoint for the airport weather stations in Atlanta, Georgia; San Francisco, California; and Eugene, Oregon. The code looks like this:

    WaypointMapOverlay overlay;

    /** Creates new form MainFrame */
    public MainFrame() {
		 // .... set up the gui here
        overlay = new WaypointMapOverlay() {
            protected void paintBackground(Graphics2D g, JXMapViewer component) {
            }
            protected void paintWaypointSummary(Graphics2D g, 
					JXMapViewer map, Waypoint waypoint) {
            }
        };
        map.setMapOverlay(overlay);
        try {
            addWeatherWaypoint("KEUG");
            addWeatherWaypoint("KSFO");
            addWeatherWaypoint("KATL");
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
    
    class WeatherWaypoint implements Waypoint {
        private Weather weather;
        public WeatherWaypoint(Weather weather) {
            this.weather = weather;
        }
        public GeoPosition getPosition() {
            return new GeoPosition(weather.getLatitude(), weather.getLongitude());
        }
        public Weather getWeather() {
            return weather;
        }
    }
    
    private void addWeatherWaypoint(String station) throws Exception {
        final Weather weather;
        weather = WeatherFactory.newInstance().getWeather(station);
        overlay.getWaypoints().add(new WeatherWaypoint(weather));
        map.repaint();
    }

In the code above there are two things to notice. First, I have created an instance of a WaypointMapOverlay which adds nothing to the drawing, but inherits the default drawing code for waypoints. (I admit this is cumbersome. The overlay API needs an overhaul). The other thing to notice is the addWeatherWaypoint(String station) method which creates a new waypoint for the requested station. To get the weather it just calls WeatherFactory.newInstance().getWeather(station), where station is the four character name of the weather station. (see this page for a full list of available stations. Note that some stations don't have lat/long data available).

With this code it will draw a circle for each weather station. Just drawing a circle isn't very interesting, however. It would be much nicer to actually show the current temperature with a transparent overlay. You can do this by adding a WaypointRenderer:

        overlay.setRenderer(new WaypointRenderer() {
            public boolean paintWaypoint(Graphics2D g, JXMapViewer map, Waypoint waypoint) {
                // make a copy of the graphics object
                g = (Graphics2D) g.create();
                // convert to map space
                Point2D center = map.getTileFactory().getBitmapCoordinate(
                        waypoint.getPosition(), map.getZoom());
                Rectangle bounds = map.getViewportBounds();
                // translate 0,0 to be the center of the waypoint
                g.translate(center.getX()-bounds.getX(), center.getY()-bounds.getY());
                
                // get the weather
                Weather weather = ((WeatherWaypoint)waypoint).getWeather();
                // draw the waypoint
                g.setColor(new Color(255,255,255,175));
                g.fillOval(-20,-20,40,40);
                g.setColor(Color.BLACK);
                g.drawString(""+weather.getTempF(),-15,5);
                return false;
            }
        });

Caveats and known issues.

First some caveats about NASA's map server. This particular server only has data within a certain range. If you zoom in too far you will start to see pixelation. Also the component itself and the WMS conversion still need some work. The tiles are slow to load and sometimes fail completely. There is some distortion at the top-most zoom level and the tiles along the edges of the map fail due to some rounding errors. Clearly there is more work to do, but this is a good start. (hint hint, consider joining in and contributing patches). Most importantly, we can ship a component that does something useful right out of the box.

So what is it good for?

In addition to the photo demo we created in Aerith, there are lots of cool things you can do with easy to use geo-mapping. The overlay API lets you draw anything you want on top of the map, including waypoints and geo-polygons, so we can imagine applications like:

• show the timezones of the world graphically
• show the trails that you have hiked with your gps receiver
• manually draw a trail on the map and produce a list of geopositions out of it
• draw zipcode and area code boundaries of your local area
• show where photos were taken and make it searchable to show by date or keyword (I think that Fabrizio is working on something like this)
• combine with census data to show population by zip across the US
• show active volcanoes and black bear popuplations. (yes, you really can download datasets for this stuff.)

Basically any set of lat/long coordinates can be drawn on top of the map. With the power of Java2D at your fingertips you can make rollovers, translucent region overlays, or any other crazy visualization imaginable. And because the WMSService class works with any WMS map server you can hook it up to many different map sources. Some creative Googling turns up lots and lots and lots of WMS servers out their, each with their own data. I can imagine some very interesting applications made by combining several WMS sources with other kinds of webservices.

We help and ideas

Don't just download the demo. Try out the component in your own apps and let us know what you think. If you make something interesting then please send us a link and let us know if we can mention it on our website or feature it on Java.net. Please also join the forum and mailing list. We need patches, feedback, and new ideas.

You can find the JXMapViewer and other great Swing tools for working with web services at the SwingX-WS project. The new WMS support is in CVS on the new_tile_provider branch.

GIF will finally be free!

I just read this. The last patent on the GIF format will expire on Sunday (October 1st, 2006). At long last the GIF format will be free. Of course we should all be using PNGs for everything, but thanks to lackluster IE support that's not always possible.

Interestingly, I was recently helping someone with a Java Web Start app. They wanted a shaped/transparent desktop icon for their app, but they also needed it to work under Java 5, which doesn't support PNGs for icons (that was added in Java 6). I used Photoshop to convert it to a 256 color GIF with transparency and an adaptive palette. It worked great and I almost can't tell the difference. I guess there is life in GIF still. :)

Introducing Painters II: filters, shapes, and the builder

Introduction

Welcome back. Last week I introduced a cool new technology we've been working on in SwingLabs, Painters, and described how they work. If you missed the first blog you should go read it now. Don't worry. We'll wait.

Back now? Great. So lets dive a bit deeper to Painters. This week I'm going to cover Filters, Shapes Effects, and the visual builder.

Filters

The Painter interface only defines the single paint method, but all of the built in painters actually subclass AbstractPainter which provides a bit more. AbstractPainter has several methods for controlling rendering options like antialiasing and interpolation as well as caching support.

When you turn on caching the drawing operations will be stored in an intermediate buffer, which will in turn be used for all screen painting. This way your code doesn't have to be called on every repaint if nothing has changed. If your painting is slow, or if you are painting a bunch of times quickly (as with an animation) then using the cache will greatly speed up your application's drawing performance. In a second you see why this is so important.

One addition feature of AbstractPainter is support for Effects. An Effect is an object which transforms an image in some way. Currently there is only one concrete implementation of the Effect interface: ImageEffect. ImageEffect will apply a BufferedImageOp to your image. Some common examples of BufferedImageOps are things like Gaussian Blurs, brightness and constrast adjustments, and drop shadows. Perhaps an example is in order:

Suppose we want a drop shadow on some text. As before we will put a text painter on top of a matte painter, but this time we will add a shadow filter using the setEffects method.

    
TextPainter textPainter = new TextPainter("Painters Rock!",
    new Font("SansSerif",Font.BOLD, 36),Color.RED);
textPainter.setEffects(new ShadowFilter());
MattePainter matte = new MattePainter(Color.WHITE);

JXPanel panel4 = new JXPanel();
panel4.setBackgroundPainter(
    new CompoundPainter(matte, textPainter));

The setEffects method actually accepts multiple filters using the varargs notation in Java 5, so you can apply multiple filters at the same time. The code above would look like this:

If you change the effect to a CrystallizeFilter and set the text to green it would look like this:

The two examples above use filters that from JH Labs released under the Apache License. To see a more sophisticated use of painter effects take a look at Romain's blog entry which shows more shadows and a generated wood texture

Shape Effects

Filters are great but they can be slow because they must operate on every pixel, even the ones you don't see. The drop shadow, for example, calculates the pixels in the middle of each letter, not just the edges, even though that will always evaluate to black. Because of this Filters look cool but in practice are usually too slow for realtime work. To address this problem we've come up with ShapeEffects.

A ShapeEffect is a vector based effect that can be applied to any Shape class. Because it uses Java2D vector code rather than pixel level manipulation it can be many times faster than an equivalent Filter. Shape effects are modeled after the Layer Effects in Photoshop. Currently you can use inner and outer glows and shadows. They are all the same effect but you can configure them by changing offsets and drawing colors.

Here's an example of using an inner glow to create a mild embossing effect.

The ShapeEffect API is still under active design and bug fixing. (note the clipping on the right edge of the 'S'). There is only one concrete implementation right now, but in the future we will expand this to a general interface for all sort of shape effects.

The Painter Visual Builder

This is the part of painters I am most excited about. The only thing better than reusing your own code is not having to write code at all! The Painter Visual Builder (needs a better name) is a graphical tool that lets you build sets of painters by setting properties and dragging around treenodes. The finished painter set can be saved to XML and then loaded into your application using the URLPainter. Lets try an example:

This is what the builder looks like when you start it up.

First delete the ShapePainter by selecting it in the tree and pressing the Delete button. Next, select the TextPainter and use the property sheet to change the paint property. This will open a dialog to choose a color or gradient. Create a gradient that looks like this:

Close the gradient dialog and check the snapPaint property. Without this the gradient would be a fixed size, regardless of the component the painter is attached to. With snappaint turned on the gradient will always stretch across the component at runtime, even if it's a resizable component. snapPaint will also snap to the eight compass points so you don't have to worry about drawing your gradients perfectly straight. Now the painter preview should look like this:

Now change the background color of the MattePainter to be black.

Now that your painter set is done you can save it as an XML file with "Save" menu item. With the painter set stored as XML you can load it into your application using a URLPainter like this:

    
JXLabel label5 = new JXLabel("Painters Rule");        
URLPainter painter = new URLPainter(
     new File("/Users/joshy/Desktop/test.xml"));
label5.setBackgroundPainter(painter);

You can try out the painter builder yourself with this webstartable version.

The Painter Visual Builder is still very alpha software, and as such is very buggy. We hope to improve to support for more of the core painters as well as shake out bugs in the new JXPropertySheet, the Outline view (a possible tree table replacement), and the JXGradientPicker.

Get Involved

If Painter Technology is something that interests you then please join the SwingLabs mailing list and get involved. The API and implementation are very much in flux and we could really use your feedback. Please tell us what you think!

Introducing Painters

One of the temptations of design is to not show your work until it's ready. Not until every edge is smoothed and every bolt is tightened should anyone be allowed to see it. While this might be okay for paintings or sculpture, in the world of software it often leads to bad APIs. An API is the user interface for other programmers. I'm a firm believer that user interfaces must be tested with real users, and as early as possible.

I had planned to wait until the Painters were more polished and my tools had their bigger bugs squashed. Sadly, finishing up Java 6, a Java 5 update, business trips, and a recent illness have kept me from working on it. Recent friendly pokes reminded me of this. (thanks fred) So today, rather than keep waiting until it's perfect I'd rather share. After all, desktop Java is about community; a community of developers who care about the desktop user experience. So with this in mind it's time to pull back the curtain, pop open the hood, and turn on some bright lights to take a first look at Painters.

If you've been following the work we've been doing in SwingLabs, the Aerith demo in particular, you may have wondered how we do all of these cool tricks. We've documented the mapping and 3D parts elsewhere, but we've never discussed the custom components. If you've seen Romain's recent presentation or read his blog you may know how we do it: Painters. Painters are the key to most of our recent graphical effects. The translucent panels in Aerith were normal panels with painters. The fade in effects where just animated painters. We hope that painters will enable developers to build better looking applications easily and quickly. Not only that, we hope to one day integrate painters into the core API. So with that in mind: just what are painters?!

What are Painters?

This is a painter

This is also a painter.

More correctly, these are components (JXPanels, to be precise) with painters attached to them. Painters are just encapsulated Java2D drawing code. Think of them like event listeners. If a listener is a component's delegate for handling events, then:

a Painter is a component's delegate for drawing

There are three ways to use painters.

• Implement the Painter interface
• Reuse one or more of the standard painters in SwingX or 3rd party painters
• Build a painter set graphically

Implement the Painter interface

At it's simplest, a painter is a class which implements the Painter interface. It can then be set on any painter aware component with the setBackgroundPainter() method.

Let's start with a simple example. If you wanted to create a panel which draws blue circle in a light blue background you could do it by overriding the paintComponent method of the panel.

        JXPanel panel = new JXPanel() {
            protected void paintComponent(Graphics g) {
                g.setColor(Color.BLUE.darker());
                g.fillRect(0,0, getWidth(), getHeight());
                g.setColor(Color.BLUE);
                g.fillOval(0,0,getWidth(),getHeight());
            }
        };

With painters you could do the same thing by implementing the Painter interface and attaching it to the panel, like this:

        Painter bluePainter = new Painter() {
            public void paint(Graphics2D g, JComponent component, int width, int height) {
                g.setColor(Color.BLUE.darker());
                g.fillRect(0,0, width, height);
                g.setColor(Color.BLUE);
                g.fillOval(0,0, width, height);
            }
        };
        
        JXPanel panel2 = new JXPanel();
        panel2.setBackgroundPainter(bluePainter);

Why use Painters?

Since these use roughly the same amount of code, you might ask why you should use painters? Well, for the same reason you would use an event listener. You can separate the drawing code from the component. This will make your application source code cleaner. It also means you can reuse the drawing code, even across multiple components. Since painters are designed to be stateless you can attach them to several components at once. In Aerith, for example, we use the same translucent round rect painter for the tool panel and the popup waypoint editor. We also use one painter for both the Save and Preview buttons.

Aerith Waypoint Editor

There is an even better reason to use painters besides separation of concerns: You can use other people's painters! Why write your own effects when someone else can do it for you! SwingX contains built in painters for gradients, pinstripes, images, shapes, and text.

For example, if I wanted to create a blue round rectangle on a blue pinstripe background, I could use code like this:

       
// create a light blue background
Painter matte = new MattePainter(new Color(128,128,255));
        
// pinstripe with lighter blue at 45.0 angle, 8px stripes
PinstripePainter pinstripe = new PinstripePainter(
        new Color(155,155,255),  45.0);
pinstripe.setSpacing(8);
pinstripe.setStripeWidth(8);

// a rectangle with 20 pixel insets, 30 pixel rounded corners        
RectanglePainter roundRect = new RectanglePainter(
        20,20,20,20,   30,30,   true, // rounded = true
		 // gray bg with 3px dark grayborder
        Color.GRAY, 3, Color.DARK_GRAY); 
// turn on antialiasing
roundRect.setAntialiasing(AbstractPainter.Antialiasing.On);
        
// combine the three painters into one
CompoundPainter compound = new CompoundPainter(
        matte,pinstripe, roundRect);
        
// set on the panel
JXPanel panel3 = new JXPanel();
panel3.setBackgroundPainter(compound);

Each painter above is simple declarative code. The important thing to notice here is the CompoundPainter. It lets you combine multiple painters into a single object that you can set on the panel. This is the end result:

constructed from standard painters

In the future I'd love to see us create a web-based gallery of painters where developers can share code and screenshots of their favorite painters.

What I'm presenting today is just the beginnings of an API and toolset to help you build painters. If you want to play around with it you need to check out the painter_work CVS branch from swingx.dev.java.net. I'm posting this today to open the discussion and get feedback. Please join the SwingLabs forum and dive in. We need your help.

That's it for today. Next week I'll talk about filters, shape effects, and how to use the painter builder to avoid writing any code at all. Until then, here's a teaser screenshot:

LA-stravaganza

One of the great things about my job is that I get to go speak to customers and other groups of Java developers. Even more amazing than the fact that Sun pays me to do this is that people actually show up to listen to me. I'm sure you've all had those times where you feel like you are still the dumb kid who just graduated and somehow you have to make everyone around you think you actually know what you are talking about. While I know that I'm a Java expert and have interesting things to say, a little part of me is still scared. What if I say the wrong thing? What if someone asks me a question that I can't answer. What if I walk into a room full of SWT lovers?! The agony!

No one? Hmmm. Maybe it's just me. :)

Anyway, last week Richard Bair and I drove down for a cheap, whirlwind tour of LA to visit five customer sites and two Java Users Groups. I am pleased to say that our trip went very well. We had an engaging and exhausting week meeting with some great Java developers, dispelling myths and out of date information about desktop Java, and seeing how people use desktop Java in the real world.

I won't go over every stop we made, but I will cover the highlights and lessons we learned.

• Our presentation got better as we went along. This is no surprise of course, but interesting. Our last presentation of the week: to the OC JUG, was much better than our first: to the LA JUG. After giving it seven times we knew the material, knew what to focus on, and most importantly knew what to skip over.
• Java 5 adoption is going great! When I spoke at the LA JUG a year ago I saw about 25% using Java 5 and 75% using 1.4. Last week the numbers were reversed.
• A lot of people don't know about Java Web Start. This surprised me because I've known about it for years (and written several different articles on it), but at most sites the developers didn't know about Webstart or only heard a few details. Clearly we need to do more to get the word out.
• Developers who use WebStart love it. At one customer site, where they use 1.5 and WebStart for everything on the desktop they said "Java Webstart has been a huge win for us". The developers are in LA and the customers are in New York. They can fix a bug in the afternoon, push out a new version that evening, then the customers are updated the next morning. That's what we like to hear!
• Most people don't know about Matisse for Netbeans 5.x. A lot of developers had tried Netbeans in the 3.x series and never touched it again. We demoed Matisse running in Netbeans 5.0 and really turned some heads. I think we are making headway.
• Developers want two way editing of GUI code. Matisse, like every successful GUI builder I have ever seen, saves the UI definition to a non-editible store of some kind. Several developers asked about two way editing of existing code. This is a question for you guys: is two way editing really what you need, or would a standard, cross-tool, XML format address your concerns?
• Trusted Solaris is cool! I've never heard of this product, but apparently we (Sun) make a version of Solaris that is very secure and can isolate applications from each other based on their security level. You could have one window that is classified as Secret and another as Top Secret. It can even manage what you type and copy to ensure you don't accidentally give out classified information (assuming I understand how this works). Obviously this is not something most people need, but if you need then it you really need it, and we make it.
• Everyone loves Aerith. Aerith is probably the best demo we've ever done. Everyone we show it to loves it and wants to learn more about how to do these types of tricks. It's really turned a lot of heads.
• I need to learn Flex. On several occasions someone mentioned Flash/Flex. We have a lot to learn from them.
• Swing is making headway. The speed, look and feel fidelity, and feature improvements (like SwingWorker) in Swing are being noticed. We don't see SWT making the inroads that it was a couple of years ago. This is a sign that we are doing the right things.
• We should do more road trips. It's exhausting but rewarding work. I wish we could take more trips like this to meet with developers in the real world. But then we'd never get any real work done. Always a balance, it is.

So I'd say the trip was successful. We received lots of great feedback and made people excited about desktop Java, Netbeans, and Java 6. So where should we go next?

Source to the Magnifying Glass Hack

In response to my Meet the Engineer interview on Sun.com a reader asked for the source to my magnifying glass component (originally detailed in this blog). I haven't given it out because it was meant to be part of a larger framework for managing the glasspane and implementing other cool hacks. Alas I have simply not had the time. Java 6 and Java 5 updates combined with my SwingLabs and community work simply have taken up all of my available resources.

It can be tough sometimes, to admit with I can't do something; but I would rather admit I don't have the time for this rather than have the code rot on my harddrive. So, here it is:

The source to the Magnifying Glass hack and the beginnings of a glasspane manager.

Please dig into the code and let me know if you find anything useful. If anyone is interested in turning this into a full fledged glasspane framework for SwingLabs then please let me know. We'll get you set up ASAP.

Okay, back to work now.

Thanks! - Josh

The best is yet to come

Yes the best is yet to come, and won't it be fine...

It's true. I have been remiss in my blogging. The last few weeks I have been slammed with some fixes for a Java 5.0 update and then a roadtrip with Rich to visit two Java Users Groups in Los Angeles and several customers. Don't worry. Now that my travel is over for the next few weeks I'll have a chance to get back to posting about Painters and Windows Look and Feel improvements, along with a summary of our trip to LA. To tide you over here's an interesting photo you might enjoy.

We visited a defense and aerospace contractor in LA (which appears to have an entire defense and aerospace district) and this is the front of their building. Notice anything missing? :)

Windows L&F Bugs: Part 2

Welcome back to the Windows Look and Feel Show!

In this segment we'll dive right into some of the bugs directly. In this series I won't cover all of the bugs because some of them involve structural changes that didn't directly fix visible bugs. For example, the XPStyle class was significantly changed by adding enum support. Enums let us more closely model Microsoft's UXTheme API and it's list of part constants. Also, I'm only covering bugs that were fixed. There are quite a few bugs which were closed as not reproducible or no longer a bug because they were fixed by another fix or simply can't happen any more because of other code changes under the hood. With that in mind, let's take a look at a few.

4515765 Win L&F: Disabled menu items should show highlight

In Windows, but not in some other operating systems, you can highlight a disabled menu item. This means when you move the mouse over that item it will have a rollover, though you still cannot select it (because it's disabled). This is especially important for keyboard users because without it the keyboard focus would appear to go off into oblivion when you encounter a disabled menu item. This fix also affects the high-contrast modes which are important for disabled users (who are more likely to be using keyboard only navigation).

While this fix is only for Windows, I implemented it in a way that lets us use it in any Look and Feel by using a defaults property (MenuItem.disabledAreNavigable). In general we try to fix things this way so that future improvements will be easier and safer to implement.

5019334 Win L&F: Selected color mark of JCheckBox & JRadioButton are not same as native

The selected color of the actual check and circle of the checkbox and radiobuttons are off slightly. They should be black instead of gray. Actually, they are foreground color of the component, rather than the darkShadow color. For most themes you won't notice this bug in highcontrast modes like green on black your checkboxes could completely disappear!

Can you see the difference?

6190801 XP L&F: No rollover effect on the JSlider component

This is another minor one, but even the little things matter. The slider thumb of JSliders has a slight rollover effect on XP. Now we support this. (Eventually this will be animated on Vista as well).

6300582 Focus indicator is missing on buttons in JToolBars in windows look and feel

We originally removed the focus rectangle on buttons because in Windows you don't have them in toolbar buttons. That's not because the don't have them, however, but because toolbar buttons aren't supposed to be focusable at all. You can't navigate between them with the keyboard, for example. A properly written Swing app won't let the toolbar buttons be focusable either, however some apps do allow it. For the most part this isn't an issue. The problem arises like this: if a user starts tabbing between components and the toolbar buttons get focus then the focus rect will disappear. A toolbar button will have the focus but the user won't be able to see it. We decided that in this case native fidelity would hurt usability so we have reverted to the old behavior and now let toolbar buttons draw their focus rects (if they are focusable). You should still make sure your own toolbars aren't focusable, but if they are then it will look right.

5011712 XP L&F: FileChooser toolbar icons when enabled not same as native file dialog

This very subtle bug was caused by converting the alpha channel of certain icons to 1 bit transparency in certain circumstances. It causes slight jaggies on the edges of these icons. By fixing the way we load bitmaps from Windows it fixed this and several other bugs.

notice the jaggies on the 'new folder' icon.

5013152 XP L&F: FileChooser toolbar icons when disabled not same as native file dialog

Microsoft doesn't document how they generate grayscale versions of their icons, but it clearly wasn't how we were doing it. The solution was to create a new algorithm that more closely models the grayscale op they do, which is less linear than ours.

Look at the disabled 'up one folder' icon

5013564 Win L&F: Cancel button in JFileChooser dialog should not have mnemonic

The cancel button in a native file chooser doesn't have a mnemonic when you hold down the alt key. I don't know why, but it doesn't, and now neither do we.

Well, that's it for this edition. Keep trying out new Mustang builds to see if we've missed anything. Thanks!

Painter Trailer

Coming soon! Hard hitting, action packed, and full of effects you probably never asked for.

It's Painters Extreme!

Okay, so maybe making a Painter trailer isn't such a good idea. Why do they call them "trailers" anyway, if they come before the movie?

Painters are a new technology for skinning your Swing GUI and it's going to let you do lots of cool things. Soon we'll be showing the new Painter APIs from SwingLabs, complete with tools, examples, and many opportunities to sit in code review meetings!

Until then I want to give you a sneak peak of what we've been up to. Hint: everything below was made without any code. Enjoy!

The Big One

So you have probably wondered where I've been. It has been quite some time since my last post and I have been very lax in talking about what's going on. Well, the big news is that we are almost done with Java 6. Not really, of course, since there still emergency fixes that could go in, but we've hit our final build of main development. This means that my work is mostly complete for Java 6 and I can start working on the update releases and Java 7. However, scheduling and builds is not what I'm here to talk to you about.

I'm going to warn you right now that this post is a bit goofy. I'm exhausted from the L&F work but excited to talk about it. If dire goofiness offends, you may conveniently press the back button now. We'll wait.

Java 6 contains lots of great new features, from the new Desktop API, to multiple gradient paints, to a built in Javascript interpreter. But I'm not here to talk about features either.

I'm actually here to talk to you about a set of bugs. Bugs so great and awesome that the fixing of them is itself a feature. Yes. That's right. Unh-huh. I'm going to talk to you about the Windows Look and Feel. Solid!

Some Background on the Windows Look and Feel

For those of you who don't know, there is this operating system called Windows, the most recent incarnation being called Windows XP and a forth-with-coming version known by the name: Vista. ('cause it's big, right?) Despite the fact that Java is cross platform, something like 90% of desktop Java users are on Windows. (perhaps because 95% of computers are Windows PC? Hmmm.) Now this matters a great deal because we provide a Windows native look and feel for Swing. Some will debate the merits of having native look and feels. "No one cares about apps looking native". There is some truth to this argument, but I think that no one will deny the fact that if we are going to have a native look and feel then it had better be a damn good one! Thus fidelity is an important issue. Every time someone says they went with .NET, Visual C++, or SWT for their desktop app instead of Swing/Java they almost always give the same two reasons: speed and Windows L&F fidelity. So clearly we have a big job to do. Speed is pretty good with Java 5, so that just leaves one thing.

In the past we duplicated Windows drawing code in Java. We were not getting any resources from the OS other than a list of system colors. This worked fine in the Win95-Win2k era, but with XP the standard widget themes became more complicated. XP has a themeing API within it that lets users choose from one of three theme variations. This was not a public API but developers like the guys who make StyleXP reverse engineered it. Soon the community started hacking out new themes by the dozen. (and I want you to know that I've tested many of them, even the super-ultra-ugly ones, but more on that later). Clearly we couldn't duplicate every theme in the world. Even just duplicating XP's built in themes would be a tough job. Thus in an earlier version of Java (1.4.2 I think) we introduced changes to the Windows Look and Feel which would parse the XML theme files and extract theme information. This worked. For a while.

As the release of Vista came near (then Longhorn) we realized that the parseable XML theme files were going away, to be replaced with binary blobs. Fortunately Microsoft has decided to officially support themeing via their UXTheme API, an API which exists on both XP and Vista. Sweet! Early in the Java 6 development cycle Leif Samuelsson rewrote a good portion of the Windows Look and Feel to use this new API, giving us full access to the underlying themeing engine. This is really the only way to properly support theming on Windows and it ensures that any theme, not just XP's built in Luna themes, will work. We still don't officially support third party themes, but we do our best to make sure they work. (Especially the ugly ones!) In fact, many of the bugs I fixed for the standard XP themes also fixed bugs with certain extra themes as well. A win-win situation.

So where are we now:

First, a caveat. I cannot claim credit for all of the great work done here. I started working on the Windows Look and Feel in March of 2005, around the build 30 timeframe. Leif Samuelsson did all of the initial work and I've received lots of help from Igor Kushirskiy and Richard Bair. Their work has been invaluable.

Second. Some of the bugs we've fixed or are on the process of fixing are Vista specific. I won't cover those here since Igor has done most of that work. Maybe we can convince him to do some blogs about it once he's done. (How about it Igor?! :)

Now on with the show.

First: the bad news.

We didn't fix everything. There are many, many bugs to be fixed and not enough time to fix them all. In a perfect world we wouldn't ship Java 6 until everything was perfect, but the real world needs shipping products so some fixes were deferred to Java 7 or later. If your personal favorite bug wasn't fixed please rest assured that we fixed other, higher priority bugs instead. We'll get to yours as soon as we can. And if you really feel passionate about it please consider submitting a bug fix through the JDK project. At this point fixes won't get into Java 6, but they could go into an update release or Java 7.

Some things weren't fixed even though we had the time. The reason is backwards compatibility. It is very, very, very important that an existing application won't break when the user updates their version of Java. Some bugs couldn't be fixed without breaking backward compatibility so we didn't implement those. In the future (Java 7 most likely) we will have a compatibility API that allows developers to choose between old and new behavior, but for now we just have to live with these bugs. The most widely known is the context menu for text fields. This is the menu that has cut/copy/paste actions in it. We could have easily added this but it would have interfered with existing applications that already have menus or other mouse listeners attached to the text fields. For this reason we left it out. Some of these fixes are really simple things, like making the font of JTextArea not be fixed width, but again we couldn't do it. Some applications use text areas as code editors and count on the font being fixed width. Since these are bugs that developers can address using their own code (or the great winlaf project) we decided to hold off on them.

Okay, so that's the bad news. What about the good news.

Well, we fixed a lot of bugs. A quick query reveals that I have 80 bugs in the Fixed Delivered, Closed, or Fix Available state. Wow! I didn't realize it was that many. Sure, some of them are invalid bugs or things that were fixed by other patches, but still. That's a lot of bugs! And that's just mine. It doesn't count what other Swing developers have done. Rawk!

The other good news is that we are still working on new fixes. There's more good stuff to come. Some fixes may go into update releases to Java 6, so keep an eye out. And, as always, submit your fixes to the JDK project.

Okay, so that's the good news. But what about some GREAT news?!

The great news is that a good portion of these Windows Look and Feel fixes have been backported to the recently released Java 5 update 8, and more should be coming in the future. These fixes are risky because there is always the danger of a regression (and in fact one has already been reported and a fix is in progress), so please test these heavily and give us feedback. Regressions are always a top priority and we'll do our best to fix'em.

Great, Great, fine! Enought with the chit chat. How about some pictures! Where are the bugs! Show me!

As I mentioned, I've closed 80 bugs over the last year and a half. I'm not going to cover all of them but I will cover a lot. I'm just not going to cover them right now. Over the next couple of weeks I will post a series of blogs discussing the new fixes along with screenshots for comparison. Maybe this is really only interesting to a pixel pusher like me, but it's my blog and I can do what I want to. So there!

To whet your appetite here's a screenshot from my testing app that shows build 10 (figure 1, almost 2 years old now) versus build 94 (figure 2, which I think is public now). Note that all textbox-ish components have the same height, the fonts are the same, and the password field has bullets now.

Figure 1: Java 6, build 10

Figure 2: Java 6, build 94

See you all next week!

I need help tracking down a bug with the WindowsTableHeaderUI

Chances are no one reading my blog will be able to answer this question but hopefully in the future someone will run across this post in Google and respond with the answer.

Have you ever experienced a NullPointerException with the stack trace below or something similar to it? This bug is caused by a particular third party Windows XP visual style (theme) and has been reported in many locations on the web (see this Google search) but I have been unable to recreate it because no one has mentioned the theme they were using! I have hacked some of my own themes to remove the ContentMargins property (which I suspect is the culprit) but I get a different error. I have a patch which should fix this error in either case, but I'd like to recreate the error before I fix it so that I know I'm fixing the real cause.

Officially we only support the built in XP visual styles but we try to support 3rd party ones as well when we can. Since this is a bug that actually crashes programs it's a high priority for me to fix it.

So: If anyone has experienced this error please post to this blog and email me (joshua.marinacci@sun.com) the name of the theme you are using (or a copy of the theme itself if you have it).

Thanks! - Josh

java.lang.NullPointerException
at javax.swing.border.EmptyBorder.<init>(Unknown Source)
at
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.ge=
tTableCellRendererComponent(Unknown
Source)
at javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderRenderer(Unknown
Source)
at javax.swing.plaf.basic.BasicTableHeaderUI.getHeaderHeight(Unknown
Source)
at javax.swing.plaf.basic.BasicTableHeaderUI.createHeaderSize(Unknown
Source)
at javax.swing.plaf.basic.BasicTableHeaderUI.getPreferredSize(Unknown
Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at javax.swing.ViewportLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at javax.swing.ScrollPaneLayout.layoutContainer(Unknown Source)
at java.awt.Container.layout(Unknown Source)
at java.awt.Container.doLayout(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)

Do We Need Databases on the Desktop?

Recently Simon Morris posted a blog called In defence of the desktop where he asks :"If SE is truly the edition of Java aimed at the desktop, and most real desktop applications (browsers, players, word processors, video editors) are not database heavy, why is Java DB being included in the SE JDK?". I'd like to challenge the idea that real desktop applications don't need databases. They may not be database heavy (in that storing data is not their primary function) but I do think that there are a lot of desktop apps which use databases, or could be improved by doing so.

When it comes to desktop apps I don't think of a database as "table based storage for relational data accessed by SQL". I prefer think of it as "reliable and search able storage", since that's what it really means to desktop apps. When I wrote my two part series on using Java Persistence in desktop apps, that's what I was thinking.

So do desktop apps need a database? Rather than say yes and describe why this is so, I thought I'd simply go through the applications installed on my computer and speculate about which ones have or could have a real database inside.

Here is the contents of /Applications on my MacBook running Mac OS X 10.4:

• Address Book Well, duh. It's a big searchable list of data with well defined fields. Okay, next one.
• Adium and iChat and Skype These are instant messenging or audio chat applications. The actual storage of contacts is either done in a flat file, derived from the aforementioned Address Book, or stored on the server. Thus the contacts probably don't use a database. However, the chat logs certainly could. You've got lots of records, organized by date and participants, and fast searching is highly desirable. Certainly a good candidate for a local database.
• Adobe Photoshop CS, Adobe Reader 7.0.7. I can't see many direct uses here.
• Automator This is a Mac specific development tool for building scripts that control other programs. While the scripts themeselves are stored as flat files, the list of available bindings for every applications certainly need to be stored and searched quickly, even if the underlying storage is XML files in the relevant apps. Much like other development tools Automator (could) parse the application bindings into a local searchable storage cache. Yes on the DB.
• Bugster is a Sun app which searches the bug database. While it's normally searching a remote database, I can see how you would want to use a test database while developing the software. Still, it's not using a local database at deployment time so it doesn't count.
• Calculator. It's a calculator. It calculates. Doesn't really need a database.
• Camino, Firefox, Safari: webbrowsers. You might not think that they need databases but they do have two things that need to be stored and searched: history, and bookmarks. Both of those could greatly benefit from using a real database underneath.
• Brood War, Chess, Snes9x, Starcraft: games. No direct need for a database.
• Cyberduck, Fugu, LimeWire, Democracy: file transfer or media downloading applications. They could use databases for searchable records of what you've transfered and when. (none of them do currently, however)
• Dictionary : a dictionary is a database. 'Nuff said.
• Font Book : while it does search through a dataset, the data comes live from installed fonts so it probably wouldn't benefit from the database.
• LEGO Digital Designer, Google Earth: these are both interesting examples. They are both very non-traditional applications. They are both very graphics heavy. And they both store local searchable caches of networked data. I think they could both benefit from internal databases.
• DVD Player, HandBrake 0.7.0, MPlayer OS X 2, Image Capture, Image Tricks, ImageWell, Preview, Photo Booth, QuickTime Player, RealPlayer, VLC, Windows Media Player: These are all straight up media playing and manipulation applications. Some of them include a list of tasks they have done before (DVDs ripped, for example) but none of them really take advantage of databases
• Audio Hijack Pro, Audio Hijack: this is an interesting case. These are media manipulation apps but they are used constantly and can produce a lot files which need to be managed. A good case for a database.
• Mail: tons of searchable records going back years. Definitely has a database in it.
• MarsEdit, NetNewsWire: These are applications for posting and view weblogs and other rss feeds. They both need detailed records of transactions (what you've posted and read) and keep extensive caches of network stored data. Definitely a need for a local database.
• Microsoft Office 2004, Swift Publisher, TextEdit, Stickies, RapidWeaver. Word processors, page layout, and text editors. Nothing very databasey in these other than integration with external databases.
• NetBeans, jEdit 4.2: these are both text editors at their heart, but being development tools they need lots of cross references for managing classpaths and doing code completion. They typically scan the classpath at startup or install time and store the results in a structured cache. That cache could very easily be an embedded database (and would be a lot easier to maintain).
• Mori and OmniOutliner are both list managers that could very easily use a database for storage. Lots of entries to be searched, though it's not quite a structured as something like iTunes. Lucene might be a better choice than SQL, or perhaps the combination of the two.
• Parallels. OS Virtualization software. No real need for a database
• PostgreSQL and SQL-Ledger these are actual database tools so they don't really count.
• Quicken 2006 pretty much is just a database with a very fancy front end. It stores, searches, and reports on financial data. I'd say that's a yes.
• Quicksilver, iTerm.app, VPNClient, Internet Connect, System Preferences, iSync, Missing Sync for Palm OS, Sherlock : these are all system utilities. With the exception of the syncing programs which have large datasets to deal with most of these don't really need databases.
• iCal, OSX's system wide calendar database. The actual storage is part of the OS rather than confined to a single app, but this only makes the case for using a database even stronger because reliability is even important.
• the iApps: GarageBand, iDVD, iMovie HD, iWeb, iPhoto, iWork '06 These are the famous iApps that Apple sells. Most of these can use an internal database for managing the media they work with. iPhoto in particular has thousands of photos to search through.

And the granddaddy of all local database apps

• iTunes: this is the quintessential example of a local app with a database. Megs of structured data with high performance searching. I can't think of a better use for an embedded database. And many, many people use it.

Conclusion

Databases are used, or could be used, in many more desktop apps on my laptop than I expected. I further expect us to come up with new applications in the future. Back in 1999 I didn't think of either iTunes or iPhoto. What will the next seven years bring?

One place I see room for improvement is that Java Persistence isn't as useful for remote databases because you'd have to give direct access to the database over the internet to a locally downloaded application, which could be easily reverse engineered and hacked to manipulate anything in the database. If there was a way to proxy the persistence calls through a system that could filter and control access then Java Persistence would be even better.

Getting started with the Aerith Mapping Component

A few days ago we released the code to Aerith, our JavaOne demo that combines photos, mapdata, and 3d effects. We worked very hard to get the code out to you and let you see how everything works. However, if you've downloaded the code you may have noticed that the code for the map parts is missing. Only the binaries are provided in the JXMapViewer.jar file. That's because the map component has a brighter future than just a JavaOne demo. It is now the first component in our new SwingLabs project: The Swing Web Services components, or SwingX-WS.

I'm really excited about this. Doing interesting things with web services has always been our dream for SwingLabs, and Desktop Java in general. Now we have a place to put it all. And the JXMapViewer is only the beginning. We want to have all sorts of components in there for things like Flickr, Del.icio.us, and RSS/Atom feeds. It's a good time to be a client developer!

Okay, so on to more immediate things. How do you use the map viewer? Just add it to your panel and you are ready to go. If you add it to your NetBeans palette you can just drag it into your form, hit F6, and see it come up. It'll look something like this:

What? Where's the map?!

Okay, I lied. So there is a bit more you have to do. The JXMapViewer uses a TileFactory implementation to retrieve the actual tiles. By default it uses an EmptyTileFactory which gives you the result you see here, which isn't very useful but can be helpful when testing code. For something more interesting you can provide your own TileFactory implementation, or use the DefaultTileFactory.

The DefaultTileFactory implements the basic tile loading and geometric transformation behavior required for your typical tile based map server like Google Maps and Yahoo Maps (and presumably others, though I haven't tested it). You just need to provide information about the server to the DefaultTileFactory and it will take care of the rest. You do this using an instance of TileProviderInfo. For example, you could connect to an internal tile map server using something like this:

TileProviderInfo info = new TileProviderInfo(
   0,    // minimum zoom
   15,   // maximum zoom
   17,   // total zoom levels (only 0 - 15 can be viewed)
   256,  // square tile size - 256x256
   true, // x increase to the right
   true, // y origin is at north pole (not the equator)
   "http://myserver.com/getmap.jsp?" // tile server base URL
   "x","y","z" // x,y and zoom URL parameter names
);
TileFactory fact = new DefaultTileFactory(info);
JXMapViewer map = new JXMapViewer();
map.setFactory(fact);
map.setZoom(7);
map.setAddressLocation(new GeoPosition(37.392137,-121.950431));

The first four numbers to the TileProviderInfo constructor represent the minimum zoom, the maximum zoom, the total zoom levels, and the tile size. The two booleans are used to indicate if the x coordinates go left to right or right to left and if the y coordinate goes from top to bottom or out from the equator. The rest of the parameters are for the base url and the name of the http parameters in the get request to fetch tiles. Once the TileProviderInfo is create you can build a DefaultTileFactory, install it on a new JXMapViewer, then set the starting zoom level and location. The GeoPosition above is the latitude and longitude coordinates of my office (give or take a few hundred feet. :).

That's pretty much all you need, but the zoom levels may take some explaining. A tile based map is essentially a pyramid of square bitmaps. At the top level you have a single bitmap with a certain size, in this case 256 x 256 pixels. In the level below that there are four tiles, also 256 x 256 each. On the third level there are four tiles for each tile in the second level, for a total of sixteen. When you continue on down the number of tiles grows by a factor of four. As you can imagine this creates a lot of tiles! The total zoom levels is the number of levels in your tile pyramid. The minimum and maximum zoom levels are the limits placed on the user navigating within the levels, since you might not want the user to go all the way to the top or bottom (maybe because you don't have real tiles there). In any case, you can customize these to match your own tile server and then let the DefaultTileFactory handle the details.

At JavaOne we demonstrated the JXMapViewer, as part of the Aerith demo, with a TileProviderInfo class that pointed at Google's tile server. This was relatively easy to do, since the REST web service they provide is straightforward. We have not published the settings for using that server because we have not yet received formal approval for doing so from Google. JXMapViewer is a generally useful component for displaying large tiled images from any source. We didn't want to suspend its release until we'd gained approval for demonstrating it with Google's tile server, however we hope to do so in the future.

The World of Warcraft maps

Here's a working example. The guys over at MapWow.com have created a map of the World of Warcraft using data from actual players. It uses an api similar to Google Maps so it's very easy to plug into:

//wowmap version
TileProviderInfo info = new TileProviderInfo(0,8,9, // 9 levels, navigate from 0 to 8
    256, true, true, // tile size is 256 and x/y orientation is normal
    "http://mapwow.com/gmap/zoom",
    "x","y","z") {
        public String getTileUrl(int zoom, TilePoint tilePoint) {
            return this.baseURL + zoom + "maps/"+
                   tilePoint.getX()+"_"+tilePoint.getY()+"_"+zoom+".jpg";
        }
    };
map.setZoom(6);
map.setAddressLocation(new GeoPosition(50,-80));

The code above looks pretty similar to the previous example except that I have to override getTileUrl with a custom version. That's because the MapWow urls don't use a format compatible with default version. Their urls use the zoom variable in two places so I create a two line method to generate the proper url. When you run the map it will look like this:

WoW Map

Or you can run it right now if you have Java 5 or higher installed.

Using a single tile

Now lets supposed instead of a big remote map composed of a bunch of tiles you'd like to just use a single image stored locally, say a satellite photo from Nasa. You can do that too using a different TileProviderInfo. You just need to override getTileUrl() to return the base url without any parameters. Then set all of the zoom parameters to 1 and the tile size to the size of your image.

//single square file version
TileProviderInfo info = new TileProviderInfo(1, 1, 1, 640, true, true,
	"file:/Users/josh/Desktop/world.small.square.jpg",
   "x","y","z") {
		 public String getTileUrl(int zoom, TilePoint tilePoint) {
        	return this.baseURL;
        }
    };

Single 640px NASA image of earth

Making your own tile images from NASA photos

Lets say you have a gigantic NASA image that you'd like to navigate through. (There are tons of great images here.) First you'll need to convert the image into a pyramid of tiles and then construct a TileProviderInfo to load the images from disk. To convert the images you need to chop up the main image into 256x256 tiles, save them to a directory according to a particular naming scheme, scale the image to half the size, split *that* image into tiles, and repeat until you have only a single tile left. It'd sure be nice to have a program that does this for you. As it happens I created just such a program.

The ImageTileCutter

The tile generator will take any image readable by ImageIO, scale and pad it to become a square, and then start generating tiles. Most of the parameters are hard coded right now (tile size, directory names, etc) but that could be changed in the future. Using this program I was able to create a tile set that looks like this:

the top most image of the cloudless earth image stack

I should mention that this program is horribly naive and not efficient at all. If you deal with large images you will need to increase the memory you give it on the command line with something like: -Xms600m -Xmx600m. I was able to chop down a NASA photo at 5400x2700 pixels in about 30 seconds on my dual-core 2ghz MacBook. I haven't tried anything larger yet but I'm sure the task will scale exponentially. In the future I'd like to see a toolset that uses ImageMagick or Java Advanced Imaging for fast non-interactive scaling. (perhaps there's a java.net project idea in there?!)

You can get the source to the tile generator as a netbeans project here

Once you have a directory structure full of tiles you need to load them into your map. My set uses 5 levels of tiles stored in the format: basedir/tiles/zoomlevel/outputimage.zoom-x-y.jpg. The TileProviderInfo to load them looks like:

//local 5 level tile set of the globe produced by ImageTileCutter
TileProviderInfo info = new TileProviderInfo(
        0, 5, 5, 256, true, true,
        "file:/Users/joshy/projects/java.net/ImageTileCutter/tiles", "x","y","z") {
            public String getTileUrl(int zoom, TilePoint tilePoint) {
                return this.baseURL + "/"+zoom+"/"+"outputimage."+zoom+"-" + tilePoint.getX() + "-"+tilePoint.getY()+".jpg";
            }
        };

and the finished map looks like this:

If you'd like to try it online you can connect to some tiles that Hans Muller created from a Hubble image at http://download.java.net/javadesktop/hubble/tile_row_column.jpg:

        // hans tiles
        TileProviderInfo info = new TileProviderInfo(1, 1, 7, 200, true, true,
            "http://download.java.net/javadesktop/hubble/tile_",
            "x","y","z") {
                public String getTileUrl(int zoom, TilePoint tilePoint) {
                    return this.baseURL + tilePoint.getY() + "_" +
                            tilePoint.getX()+".jpg";
                }
            };
        map.setZoom(1);

With tiles that look like this:

Conclusion

The JXMapViewer is a powerful component that can be modified to talk to any map server. In this blog I have only scratched the surface of what this component can do. In a future blog I will dig into the Overlay API that lets you add waypoints, paths, and draw on top of the map, and the Yahoo Geocoder that converts street addresses into lat/long coordinates.

the JXMapViewer is functional but it has a lot of bugs and limitations. In particular the viewer assumes tiles are square, there are repaint glitches, the threading code is overly complicated, and the lat/lon conversion only works with certain kinds of mercator projections. Please join the new SwingX-WS project to play with the components, help fix bugs, add features, and contribute new components.

Links

• the SwingX Web Services project on java.net
• the Map World of Warcraft project.
• the Map Wowdemo webstart link
• The full source code for the map demo
• The source to the ImageTileCutter

Aerith Code is Go!

It look more work than expected (doesn't everything?) but at long last we have released the source code to Aerith, our killer 2d/3d/webservices mashup demo that we showed at the JavaOne 2006 keynote, and later in the SwingLabs booth and at the Apple BoF. The response to the demo was very positive so we made a commitment to release the code ASAP. Finally that day has arrived and it's today. Go download the code at the new Aerith homepage.

Aerith is available under the BSD license to give you maximum freedom to learn from the code and pull parts of it into your own applications. The mapping component has been moved into SwingLabs and will become part of new as-yet-unnamed webservices components project. I'll have more details on the mapping component in an upcoming blog (and when you look at the maps in the demo you'll have a surprise ;)

A word of warning. Aerith requires a fast machine and a recent copy of Mustang. This is to support the 2d/3d integration that was a key component of the demo. Also, the code is rather crufty and not all parts may work. If you'd like to fix some of these bugs please download the code and get involved on the mailing list. This is a demo, not a real product, so we can't spend much time polishing it, but we always welcome outside contributions.

I'm excited to finally have the source code to a JavaOne demo available. We often put many long days and nights into these demos so it's nice to be able to share them with others. Enjoy and please let us know what you think.

Java One, Future Projects, and Back to Work

So you have probably wondered where I've been. Possibly even missed me. Or maybe you haven't and are glad I haven't wasted any of your precious packets during the last month. In either case: I'm back with lots of interesting things on the way. I've been on vacation, traveling, spending time with family, and then back on the job working on Aerith and getting Mustang ready for Vista. So let's dive in to the good stuff:

JavaOne

I haven't blogged since JavaOne, and even then I didn't blog much. Not like the year before. That's because I consciously chose not to blog. We had a lot of great java.net bloggers this year covering the conference, and they had more time than I did, so I decided to let them do it. I particularly enjoyed my friend Cooper's coverage of the EE stuff. I spent most of my time working at the booth, doing prep for the Aerith demo, and actually attending sessions for a change (I only made it to one last year).

I won't try to recap everything I saw, but I will mention the following highlights:

• The JavaPosse BoF: lots of fun. I had no idea they were so popular. Plus we got a shout out as the Applet of the Week.
• The Sun Spot Hands On Lab. Cute devices with an SDK. Even though the libraries and APIs are completely different I am amazed at how much existing knowledge transfers over. Device programming in Java is much, much easier than working in C.
• The Apple BoF: we got Aerith running on OSX, they committed SWT support, and they announced a recent mustang build for PPC. What more could you want in 50 minutes?!
• Shannon's Drag and Drop talk: I'm amazed at how many people asked great questions and have genuinely novel uses for the DnD apis and the new Mustang additions.

We had lots of people come by the Swing Labs booth and the response to Aerith was great. (more on that below). So overall I think it was a very productive and well attended JavaOne. Of course now I have to figure out what we are going to do next year? What would you think of a session on using Java EE Persistence in client apps?

Aerith

As I said, Aerith was very well received and it has always been our hope to release the code. We now have approval to do so, but haven't been able to work out all of the details with Google yet, so the initial version will have a dummy TileFactory that produces empty tiles. The first thing we'd like to get the community to work on is an implementation that uses NASA's satellite data. More on that when we release the code, which will be very soon, I promise.

Mustang and the Windows Look and Feel

I have a slew of fixes for the Windows Look and Feel (my *actual* job, though that's not what I usually blog about) that will go into Mustang builds over the next month. I'll more on that next week, but for now I will say that our native fidelity is much improved and all of the most egregious bugs have been fixed. Plus there's a surprise coming, but more on that later.

So that's it for today. I'll be back next week with more information on Aerith and the Windows Look and Feel.

Aerith Updates and the End of Java One 2006

I just arrived home after a both grueling and exciting week of JavaOne. I'm taking the next two weeks off, though I will be blogging a bit and answering the occasional emails. Don't be surprised if I'm a bit slow to respond though as I'll be in Oregon most of the time sipping coffee and enjoying the beautiful outdoors.

Once things settle down I'll have a bunch more blogs with photos, interesting things we learned at the conference, and discussions about the effects we did in Aerith; as will Rich and Romain. In fact, Romain just posted an FAQ which should answer all of your immediate questions. Essentially: yes we will release the code (all of it that we can, anyway) but it'll take a bit of time. This was a demo that combined a lot of different cutting edge technologies and we worked right up till the end. We'll need some time to clean up the code.

Oh, and there's a video of the keynote up already (Real Player, alas). Go to about minute 20 for the Aerith demo.

Oh, and I've got a couple of good articles in the pipeline that you'll see this coming week or next, so look out for those.

Now if you'll excuse me, I have to go sleep for a couple of weeks. :)

update: fixed typo in title. must sleep!

Aerith: live from the floor

I'm sitting in the audience watching Tuesday's keynote where Romain Guy and Richard Bair are on stage showing the new Swing demo we built called Aerith. It's a roadtrip slideshow builder that combines Google Maps, Flickr, and Yahoo Geocode to let you make your own slideshow of photos you took on your trip. Once you are doing setting up the slideshow you can share the trip with your friends as an applet.

Aerith really shows off the power of Swing, Java2D, and JOGL when you combine it with webservices and applets. With Desktop Java you can do things you couldn't ever do in AJAX. And most importantly, it looks great!

We will have the code up soon and parts of it will be going into SwingLabs, but you can see the screenshots and join the mailing list today at: aerith.dev.java.net.

Pretty Pictures

I'm doing lots of pre-JavaOne work right now and I could easily bore you with details of our Java.net Community Leaders meeting on Saturday, but instead I'll tease you with our demo.

Rich, Romain and I put together a really great demo application using Desktop Java and a lot of cool APIs. We showed it at Licensee Day this morning and it went swimmingly so I have high hopes for the full presentation tomorrow during the Tuesday morning General Session. I can't tell you any more details, but you'll know it when you see it. After the demo on stage we'll activate a page on java.net for you to get a closer look.

Okay, so that was another tease. To tide you over until tomorrow I'll show you some screenshots of a new framework I'm working on for SwingLabs. Called the Overlay Framework, it will make a lot of complex effects ridiculously easy. Want to draw a translucent badge on top of any textfield with invalid data? Just stuff a painter into the ValidationOverlay and it will take care of the rest. Want to do drag and drop with translucent previews? It'll be just a couple of lines of code with the GhostDragOverlay.

For a couple of years I've been playing around with this idea of a magnifying glass that would work on any application. Well this weekend I finally sat down to write it. I think it came out pretty well. What do you think:

Yes, it is really magnifying anything in the frame under the glass. Yes, Swing apps really can look good! All of this code and more will be available in SwingLabs just as soon as JavaOne is over and I take a week of rest. Until then, keep watching the blogs!

Swing Hacks in Japanese Ships

I'm going to be a complete nerd for a second and expound upon how amazingly cool it is that something I wrote has been translated into Japanese. I mean, writing down words that someone else pays for is cool and all, but it's even cooler when someone else translates my words into another language. The book even looks cooler. It's a tad smaller and has a very nice book jacket. The paper has a very different feel from the english printing; manga-esque actually.

Many thanks to Yuka Kamiya from Sun's Japanese division for sending them to me and Chris. Extra special thanks to Miyagawa-san and the rest of the folks at O'Reilly for publishing such an excellent translation.

Okay, back to your regularly scheduled english reading.

How to get code completion with Javadocs in Netbeans on Mac OS X

I'm sure I'm the last Mac Java developer here to figure this out so I'm posting it not so much for you but for future generations intrepid googlers to find.

How to get Netbeans code completion with Javadocs to work in Mac OS X

Netbeans is a great IDE and I'm really starting to warm up to it (starting to warm up to IDEs in general, actually). One of my big complaints so far has been the lack of Javadocs in the code completion popup window. Since I had some extra time today I thought I'd finally figure it out.

The reason Netbeans doesn't have javadoc code completion on the Mac, but does on other operating systems, is that Apple doesn't ship the src.jar by default. This is the jar which contains the source code to Java (at least the public APIs, go to the jdk project for the rest), and more importantly: all of the Javadocs. No src.jar, no javadocs. So the simple remedy is to install them. Here's how you do it:

1. Download the J2SE 5.0 Documentation bundle from Sun at http://java.sun.com/j2se/1.5.0/download.jsp
2. Unzip the downloaded file and place it wherever you want to store your documentation.
3. Open netbeans and go to the Tools -> Java Platform Manager menu.
4. Select the default platform (you may have only one), select the Javadocs tab, then press the Add Zip/Folder button.
5. In the file chooser navigate to the docs directory and select the api directory.
6. Pat yourself on the back. You now have code completion with javadocs.

Sweet!

Swing Hacks goes East

I'm always amazed by how big the Java ecosystem is. It really is a global community. When Chris and I wrote Swing Hacks we did it out of love for Swing, not to sell a lot of copies or make a lot of money. I'm always amazed when someone will pay for something I've written. When we hit an Amazon score of under 1000 (for a couple of hours anyway) I was bowled over.

Well today I'm amazed again. One of my co-workers from Japan, Yuka Kamiya, just told me that the Japanese translation of Swing Hacks is coming out this week. She blogged about it here, and while I can't read any japanese I'm pretty excited. Yuka said that translations into japanese are often done poorly, but O'Reilly's translators really did a good job with this one; which makes me very happy.

So to all of our readers in Japan: Chris and I will be at JavaOne again this year so if you are going to be attending please bring your copy of the book and we'll sign it. Cheers to the global Java community!

In other news I got an email from Amazon suggesting a book I might like. I guess it's true I really did write it for myself! :)

I hope to see you all at JavaOne!

The Summer of 1998

Some time ago I wrote an article for Slashdot discussing Be, Apple, and the future of operating systems. The mention of Be should indicate just how far ago this was. The other day I decided to try to find the article both to find out if I was at all correct in my conclusions, and to see if my writing has improved at all. Well, I couldn't find the relevant article, as Slashdot's archives are not complete (and their search engine even less so) but as I was going backwards in time I ran across some articles that are quite interesting today. I suppose it's odd to think of something as recent as 6 years ago in an historical context, but in Internet years it must be centuries. So let's dive in:

It was the Summer of 1998

The now defunct Australian Erasure-esqe sugar pop band Savage Garden had the top rated rock (??!) song of the year: Truly, Madly, Deeply. Google had yet to reach it's historic stock prices and the bubble was still in full swing. I was fresh out of college and had just finished nine months as an intern at Xerox PARC. Fresh from the high of having been in a joint published research paper I was ready to tackle writing something on my own! Okay, in reality I just was a 22 year old code monkey for the real researchers, but it was a fun time and I got to soak up some PARC history. So here is what I wrote:

Remembering the Star.

After seeing an on screen demonstration of the last functioning Xerox Star computer I was struck both by how primitive it's hardware was (though rather advanced and expensive for the time) and by the things it got right that we still get wrong. I quickly wrote up this article based on my observations. I also started a short lived 'Simple Linux' initiative that died when I lost interest (as did most of my projects from that era).

In terms of writing I think I did fairly well, though I'm much better about not having run-on sentences today. I've also learned about these far out concepts like "the outline" and "listening to your editor" which have greatly improved my final drafts.

So what else was going on in The Summer of 1998?

Inevitable Microsoft Decline. While Windows may be collapsing on itself, Microsoft doesn't appear to be going anywhere. UI wise I think that Vista is going in the right direction. Heck, just renaming Outlook Express to Mail is worth an upgrade by itself. The XBox is certainly doing well, and now there's even a Palm Pilot that runs Windows CE. I'd say MS is fine.

The Myth of the Fall of SGI I don't really have much to add here. Ummm.... apparently it wasn't a myth.

Apple and Rhapsody x86. Ah, back in the days when we foolishly believed Apple was going to release Yellow Box, the code name for the NextStep API developer toolkit on Windows. Oh sure, it would have been crufty, slow, and not made any money for Apple at all; but it certainly sounded cool. I'm glad that I just bought a tangerine iBook three years later instead. :)

In other news

Well, that's it for now. In other news I've been working with Rich and Romain to build a truly killer demo that you'll get to see at JavaOne. I'm also working on some cool stuff with Painters that you'll see very soon.

Have a good week
  Josh

All hail the PropertyChangeListener

Often times when you are building an application you need to hook multiple components together in such a way that when one component changes others must do something. When you are building custom components there is often the temptation to build a custom set of listeners to go along with it. This seems like good component etiquette; after all this is how most of the javax.swing.* components are built. Still, that's a big pain to create new listener types that must be implemented, just for observing simple changes. Plus it tightly couples your classes which can make your code brittle when making changes later. There must be a better way. And there is!

PropertyChangeListeners

All Swing components implement the property pattern, meaning that there is an addPropertyChangeListener() method on all subclasses of JComponent. There is even a special version which lets you listen to just a particular property by passing the property name into addPropertyChangeListener() along with your listener. Most component properties are already set up to send events when they change. This includes things like the text of a JTextField and the background color of a JButton. JComponent also has a firePropertyChange() method which lets your custom Swing components send their own change events without ever having to much with event classes. The result is a very easy way to hook components together with a minimum of new code, and no new interfaces or classes.

Here's an example. I was working on a tiny bitmap tile editor. There is a "+" button which lets you make the grid a bit bigger. When it's pressed the grid editor panel needs to make itself bigger. When the grid becomes bigger a small label needs to reflect the new size of the grid. You can see a chain of events here that have to be implemented. I could create custom events (like GridSizeChangeEvents or something equally horrendous), but that's a lot of work for what boils down to "update yourself". Let's see how it would work using the PropertyChangeListener instead.

First, I create the editor. It is a custom JPanel with a method called setGridwidth(). Each time the grid width is changed it rebuilds the internal grid data and then fires a property change event about it. Chose to set the property from true to false, though it doesn't really matter what I send as long as it's different. I just want to indicate that a change has happened. I have un-creatively named the property "grid" and anyone else can listen to it. Here is what it looks like:

public class TileBuilderEditorPanel extends JPanel {
...

    public void setGridwidth(int gridwidth) {
        this.gridwidth = gridwidth;
        rebuildGrid();
    }
    private void rebuildGrid() {
        int[][] newgrid = new int[gridwidth][gridheight];
...
        this.gridcells = newgrid;
        repaint();
        firePropertyChange("grid",false,true);
    }
}

Back in my main class I want to update the label whenever the grid size changes. This is simple with an anonymous listener class like this:

editor.addPropertyChangeListener("grid", new PropertyChangeListener() {
    public void propertyChange(PropertyChangeEvent propertyChangeEvent) {
       viewer.repaint();
       grid_size.setText(realeditor.getGridwidth() + " x "
			 + realeditor.getGridheight());
    }
});

Notice that the addPropertyChangeListener takes an argument to specify the property to listen for. By telling the component that I only want grid events I don't have put a check for the property name inside of my listener. Since I don't actually care what the grid changed to, just that it changed at all, I don't need to mess with the PropertyChangeEvent (though the information is there if I want it).

Now I can create an action listener on the "+" button that will make the grid width one cell bigger whenever the width_plus button is pressed.

private void width_plusActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
    editor.setGridwidth(realeditor.getGridwidth()+1);
}

Note, the width_plusActionPerformed method is generated by Netbean's GUI builder and then attached to the actual width_plus button behind the scenes, which means I have even less code to write.

Now when I press the button it will call editor.setGridwidth() which will update the internal data structure, repaint itself, then fire a grid property event. An anonymous listener will look for the event and then update the label. It's that simple!

Here's what the (currently unfinished) application looks like:

For more on PropertyChangeListeners you can read the javadocs here or this section of the JavaBeans tutorial.

Get Swing Hacks for Five bucks

I just got an email from my co-author and looked up the Fry's ads for the San Jose Mercury news. If you live in the Bay Area (or San Jose, at least) then you can get a copy of Swing Hacks for 20$ minus a 15 dollar rebate, for a final cost of 5 bucks. Supposedly it's even cheaper in Atlanta. I don't know what stores this applies to so be sure to check out the ads for the local Fry's in your area. So if you've been wanting to get the book it's on sale. Also be on the look out for a new article feature more Swing Hacks material that didn't make it into the book.

Thanks!
-- Josh

Using Java2D to to build a Stacked Image Editor

Brainstorm!

Every now and then I get the idea to build a cool program that does something interesting. Sometimes I get an idea by seeing another program, or seeing an interesting API I've never noticed before. Sometimes both. A few weeks ago I was thinking about how close to 3D I could get while still using the Java2D APIs. There's no perspective transforms in Java2D but you can fake a lot of 3D with creative use of the standard affine transforms. Around the same time Romain complained about having to draw some 3d diagrams using Photoshop. It wasn't hard work, just tedious.

Brainstorm! Build a stacked image editor in Java!

Of course, every time I get one of these ideas I then think "well, I've got to make a build file, and set up my environment, and build some base classes, and ...." Eventually I go back to what I was doing and forget about it. The overhead sometimes doesn't make it worth it. Even if I do write the core code I never develop it into an app that someone else can run. It just becomes a hack that sits on my hard drive until I delete it for more space. Well not this time...

I've been working on some framework stuff for SwingLabs and one of the offshoots is a zip file which contains a prefab project zip. Inside the zip is a ready to go build file, src and lib directories, and some custom tools to build double-clickable jars. With this zip file I can dive right into the code I want to write and not worry about the overhead. (Don't worry. I'll be releasing this project zip in the future with the framework.) With my project.zip file I hand I got to work and wrote a stacked image editor in a few hours.

A Stacked Image Editor

Here's the basic idea. I have process or system I would like to diagram. It can be represented as a series of images floating above each other, usually at an angle so you can see how they all fit together. The program needs to let you select images, layer them on top of each other, and then tweak the display settings until you like what you see. Here's an example:

Suppose I have a frame, panel, and text field in an application I'm writing about. Here are screenshots of each component:

A JXPanel

A JXFrame

A JTextField

I want to make a stacked diagram to visually show how they all nest together. Here's what the editor will look like:

Stacked Editor

Each image is loaded into the editor and has it's own settings for a border and transparency. You can also change the shear of the images, which is was makes them appear to be in 3D. A shear is really an affine transform with no perspective (meaning the back will be as big as the front), but for close up objects it's a pretty convincing illusion. Especially when you adjust the inter slice distance and horizontal offset to make it appear more isometric. You can save the resulting diagram as a PNG image but there is no native file format to store the slice settings. I figured the app will usually only be used once per diagram so it didn't matter too much. Perhaps I could add it later. After using it for a bit I added the match sizes checkbox since you often want to make your images congruent.

The entire application runs as a double clickable jar that you can find here. (note. It's 5 megs because there's a lot of junk in there I haven't stripped out yet. Oh, and it probably requires 1.5.).

Try it out and tell me what you think. Thanks,

- Josh

Fold N' Drop

This has to be one of the coolest frame hacks I've run across. I also think this is a great use of a gestural interface techniques. The idea is that you can fold windows down to access what is behind them. They have a small java application (54k) that does everything.

Java One Lessons : The book

Java One Lessons

The highlights for me were our session for Swing Hacks and meeting with customers at the JDIC and JDNC booths (more on that in my next blog). It's great to interact with developers (my "customers" essentially) and get some real feedback.

The session for Swing Hacks went quite well. I was incredibly nervous (I've never spoken in front of more than 50 people before), but calmed down once I got going. I sure drank a lot of water though! The talk was well attended (about 75% full) and we had quite a few people hang around afterwards to ask questions and sign copies of the book. Very exciting.

The book finally went up on Amazon during the conference so we can finally see what the sales ranking is (4kish, last I checked). It was originally supposed to be shipping from Amazon on the 22nd but there was a last minute glitch with the printing and we had to scrap a lot of books. Some pages near the front (all of the preface, I think) were missing the purple headers and chapter numbers. Since this was the printer's fault (not O'Reilly's) they had to scrap them all and rush to print up new ones. For the first few days the bookstore at JavaOne was the only place you could buy the book, which is why it didn't show up on Amazon until later in the week. We kept a few of the misprints to give away to the audience and other attendees, but all of the ones for sale (both at JavaOne and at other traditional sellers) are the correct copies.

We started getting our first few reviews in. The one on Amazon was very positive. The one from elliotth was pretty negative. Well I knew not everyone would be happy with the book. It's a bit of a departure from the other hacks books but I think it turned out pretty well. I think the biggest issue with the book is that it's not for everyone. If you are a super advanced Swing developer then some of the techniques will be things you already know. (Also, being in the hacks format we don't always have room to fully explore an idea, just show it's possible and suggest where it could go in the future.) Now if, on the other hand, you are a newer Swing developer who knows the basics but wants to push the envelope then this book is for you. Either way, read the reviews and tell me what you think.

One thing that worries me is that both reviews mention visual problems with the beginning of the book which makes me wonder if they got one of the misprints. If you purchased the book (rather than a freebie or promotional copy) and don't have a purple (headers, chapter numbers, etc) in the preface then please let O'Reilly know.

If you do want to buy the book I suggest you get it from Amazon. First, it'll save you 10 bucks off the coverprice that you can go spend on a nice frost beverage or three. Second, the sales numbers on Amazon are probably more important than from anywhere else and it gives us better feedback than browsing in a store. (Of course, if you really want to check out the book in a physical store and buy it there we certainly don't want to discourage you! :)

Enough about the book. I'm glad we wrote it and I hope you like it. If you have any questions feel free to email me. If you don't have the book (or don't have it yet :) you can read several of the hacks up on the official Swing Hacks site for free. If you have your own Swing related hacks you'd like to contribute then you can send them here.

Thanks for all of your support. Without your positive feedback here on Java.net we never could have written the book.

- Josh

Exhausted

JavaOne: Day One

Watching the keynote. Nice to see a reference to Morgan and Edison. We often forget our technology roots.

Note to Moscone. You need about 4.8 billion more power plugs scattered around the convention center. Everyone here has a laptop and they need juice! (Insert conspiracy theory about Tesla's wireless power technology being squashed by Big Coal).

Working at the SwingLabs / JDNC Booth

People are really excited about JDNC, our opensource extended Swing components. Our new demo app looks great (thanks to all the JDNCers for helping to make that happen on such a short timeframe), and we've been able to show of Joplin (our new music player) a little bit too. Very impressive stuff. The biggest thing I've gotten from talking to attendees is that they like the fact they can get it now. The new stuff in Mustang is great, but they want new components they can put into their applications and ship now. This is a really powerful thing for them. Looks like we've got to get 1.0 out ASAP.

Working at the SwingLabs / JDIC Booth

George has been working really hard on JDIC and it's paid off. People are amazed to see a real native instance of Mozilla running inside of a Swing app. The two things people seem to want to do is show generated reports and hook into legacy web-apps. I'm interested to see what other things people will do with the technology.

Session Prep

Chris and I met to go over our session, fix up the demos, and do our technical rehearsal in the room where we will be presenting. It's, um, a bit larger than I realized. We could have somewhere in the neighborhood of 500+ people seeing the talk. I'm a bit nervous, but after going over our material I feel better about it. If you are interested in desktop Java and are free at 4:00 tomorrow, then be sure to come see us in room 135 E. We will also be doing a book signing at the O'Reilly booth at 12:30 tomorrow. for those of you who aren't here we will get the presentation and source code up on the web as soon as we can.

JavaDoc BOF

This was an interesting one. Javadocs are, quite frankly, boring. It's a tool that does it's job well but has only received minor updates since it was invented (mainly to support new language features). JSR 260 is a big update that will introduce a lot of new features, especially categories and views. I was surprised to see how full it was. Apparently a lot of people care about documentation and making it better. I have my own set of ideas for improving Javadocs, but it's good to hear other ideas. Some of the cool ideas from other attendees include generating javadocs directly from source on the fly (in the IDE) instead of shipping static html with the source; validating the html docs authors type into the code, using CSS to style the docs instead of HTML layout, provide hooks for your IDE to show you only

My car!

As I already knew, San Francisco is no place for a car. The garage where I parked my car closed at 9:00. I discovered this at around 11:30! D'oh!. Fortunately I could take the F street car down to my cousin's house to spend the night. Unfortunately all of my clothing was still in my car. After making my way to bed, I hopped into the shower, on to F, headed back to Moscone to retrieve my car and get the day started. Sadly this means I missed the keynote, but at least I'm ready for Day 2.

We're #2

I promise I won't shill too much, but Chris just told me that our book was the number 2 seller yesterday according to the list posted by the book store! To our readers we send a heartfelt thanks!

- Josh

Getting ready for JavaOne: The Day of the Desktop

Well. Here I am getting ready for my first real JavaOne. Actually, I attended back in 1999 and had the rare fortune to see Douglas Adams speak, but this is the first time I will be speaking as an author and attending as a Sun employee. It's going to be exciting. And since most Java developers can't attend JavaOne (where would they all sit?) I expect these Java.net blogs to light up like a Christmas tree during the next week. There's going to be all sorts of cool stuff going on, but don't just pay attention to the highlights. Some of the best things will be in the BoFs, smaller sessions, and especially the simple person to person talks over a good beer. (This is what we called P2P in the old days before they invented music, computers, and light.)

I'm personally excited about this JavaOne because I feel like my passion, Java on the Desktop, is finally coming into it's own. Somehow the twin worlds of desktop and web software are colliding right at the time Java's desktop features and performance are getting really, really good. I don't know what it all means (perhaps next week will shed some light on the subject), but it can only mean good things for desktop Java developers.

I'm going to be at the conference all week, so if you see me be sure to say hi. My big presentation on Swing Hacks with Chris will be Wednesday at 4:00 in Hall E, rm. 135. The rest of the time I'm likely to be in the JDIC or JDNC/SwingLabs booth answering questions, showing off our new demos, and getting ideas. I will be posting from my iBook throughout the week as often as I can, plus taking notes for the future. If you have any questions, ideas, or just want to chat, then please drop by. We'll be waiting!

- Josh

The Power of the Desktop Java Stack

Big Brother, a screenshot client + webservice

The last year or so has seen a lot of growth for Java on the Desktop. The peformance, features, and deployment story is getting a lot better, but to what end? So we have a killer platform that lets you build cool desktop applications. So what? What can you do with it? More importantly, what can you do with it that you can't do (or can't do as easily) with another client solution like .Net, C++. What about webapps? What can we do with Java that we couldn't do easily with Perl, ASPs, PHP, Javascript and HTML? Well, this is sort of a trick question. I've asked: what can we do that is better than other client side or server side technologies allow. The answer is to be on both sides at once.

I've built an example application to show you what I mean. It's called Big Brother and it watches you. More specifically it takes captures of your screen, generates thumbnails, then uploads the images to a webservice that lets you link to the image from another webpage. It contains a webservice with a simple REST-y API (basically one POST and one GET) and a JNLP launched application to take the screenshots and do basic configuration. Here is a live view of my own desktop, updated every 10 seconds. When I'm not logged in then the thumbnail is still there (on the webserver), but won't be updated until I log in again.

A live view of my desktop

Easy for Developers

My goal was to make it as simple as possible for both programmers and end users. As a programmer you get a simple API that you could call from any language, not just Java. However I've provided a Java client that looks pretty good and will cover most needs. You can retrieve images using another GET call and submit then with a POST (with the image Base64 encoded). There are usernames but no passwords since I wanted to make this as open as possible. It's just a technology demonstration so it should be easy for new developers to get started. There's a great set of posts on O'Reilly, here and here about how to make APIs as open (and sucessful) as possible. I highly recommend you read them if you plan to make your own publically accessible web service.

Easy for End Users

For the end user, it's an auto-launched application that has as few options as possible. It tells you where your thumbnails will be stored, allowing you to embed the image in your own homepage with just a link. The user doesn't need to know about programming or how the webservice works. Just drop a link in your homepage and you're done. Couldn't be easier!

Easy to develop

The most amazing thing about the app isn't what it does, but how easy it was to build. BigBrother took me four hours to make. The vast majority of this time was figuring out how to safely get a binary file to a servlet using a post (I found a single class implementation of Base64 encoding that did the trick very nicely). I have since spent time tweaking the UI, adding features, finding graphics, and making a website; but the app itself was up and running very quickly.

With Swing, Java Web Start, and Java2D on the client, Servlets and JSPs on the server, and great network classes inbetween, we have a complete development stack. Everything you need to build a killer app is right there. You don't need to use another language, and almost any missing feature can be found in an easily integrated 3rd party jar. And because the Java stack has such great standards support you aren't restricted to just Java either. You can write the client or server portion in another language that supports the usual webstandards of XML, HTTP, HTML, etc. I could even embed a scripting language into my app, letting other developers hack on it.

Application Ideas

If rich clients are going to replace (or, more likely, enhance) existing web applications then they need to do things that webapps can't. I've been thinking along these lines for a while, looking for interesting applications I could build which would leverage the strenghts of Java on both sides of the NIC and make something new. Some sort of a hybrid application. Here are some idea's I've come up with. These are just play things, but get us thinking in the right direction.

• Control iTunes remotely from the web. We've got the hooks already.
• Deploy a pre-configured VNC client with an SSH tunnel to let me fix my mom's computer.
• make an iCal like app for ToDo lists. Publish the lists via FTP, WebDAV, etc. You can edit your lists using the rich client, and then share them using a web page or a rich client.

To find out more about Big Brother go to the home page. To Launch Big Brother right now using webstart (it's signed and needs system access to take the screen shots), then start it here.

The obligatory screenshots:

A Hi-Rez Future

I've been working from home in Atlanta since I started at Sun. I have two homes under renovation and a lot of things to take care of before I can move out west, so working from home for a few months seemed like the best solution. The problem is I only own a laptop, my new iBook. Coding and writing for 10 hours a day on a 1024x768 screen really is no fun. I've got a USB hub, mouse, and keyboard to make it feel more like a desktop, but nothing can replace having a good screen. Today I bought a flatpanel.

It's the NEC LCD 1735 NXM, a 17inch, DVI + VGA input, 1280x1024 flatpanel with cute little speakers on the side. So far, I love it.

First thing: I've got to say that this is the best analog LCD connection I've ever seen. I don't know if it's because NEC did a great job with their filter, or because OSX does really great screen smoothing, but it looks almost as crisp as digital. No blur at all. Maybe it's just that the technology has gotten a lot better since I last used an external flat panel, but I'm quite impressed. I'm sure it will look better when I switch to digital, but it's great for now.

Second, it's big. 17" on a flatpanel really is 17 inches, not the old count the unusable glass to inflate the numbers days of CRTs. 17 inches is really quite big.

Third, it's native resolution is higher than the 1024x768 I've been using for so long. Having the 1280x1024 is great, especially when it's on a second monitor. I got addicted to dual monitors with my thinkpad last year, so it's good to have it again.

So now what?

So, as I sit here gazing at my huge visual setup, I'm thinking: What does this mean for the future of software?. This isn't just idle thoughts. It's a real question. If you have a world with different sized and different resolution screens you start to have a very wide DPI range. Combined with the fact that you will probably sit closer to a laptop than a larger desktop screen, we start to see that our software just doesn't cut it anymore. We'd like to think we all code with resolution independent toolkits, but we don't. Every toolkit (Swing included) has certain assumptions about the size of a button or menu item. These assumptions start to break down as screens leave the range our toolkits were originally designed for.

Here's an example. My mother uses bi-focals. She has a CRT iMac that can go up to 1280x1024, but on a 15 inch that's too small for her to see. Instead she goes back to 800x600. Not to get a better refresh rate, but because the widgets are bigger! Clearly something is wrong here. Why can't the software (or toolkit or OS) just make the buttons bigger. Take advantage of the higher resolution to show the same amount of information in the same space, but with greater clarity. Put those extra pixels to use!

Here's a different example. We've spend the last 10 years making web documents scale with the browser width, screen resolution, and desired font size. Yet our supposedly more powerful desktop applications can't do the same. If I use a control panel that takes up 800 pixels it takes up 800 pixels, no matter what my screen is. If I'm lucky I might get a scroll bar. If I use a resizable window I can resize it's dimensions, and the contents will stretch but not reflow in the web sense of the word. Even with a word processor only the text I'm editing will reflow. The widgets are still the same size. Why is this? Why do we assume static standard screens?

These two examples don't even cover non-traditional desktop screens like redirecting output to a PDA or software that is designed to run on a 30foot projected wall. Standard software fails in these areas. Good software to handle these cases always involve tremendous custom code.

Surely there is a better way

I think, in order to solve this problem, we need two things:

1. First the underlying toolkit needs to be resolution independent. You should be able to get the actual screen DPI and a Virtual DPI. The on screen widgets will then be scaled appropriately. A virtual 800x600 screen will still appear as 800x600 even on a 1600x1200 physical screen, it will just look sharper. The same transformations would apply to both a highres projector and a low-res PDA.
2. Second, we need a new metaphor for describing how widgets should be positioned in a possibly dynamic DPI environment. The web was able to reuse the existing document layout metaphor from the world of print. Things like margins, headers, and paragraph reflow make sense in when you are dealing with lots of text. The web added dynamic features that enabled (after years of development) authors to create pages that look great on every screen, no matter what the size or resolution. We need something like that for the desktop application world.

Another thought. When you use Expose on OSX 10.3 to switch applications it creates a shrink-ed version of every window. These aren't just bitmaps. Each window is updated live. It really shrunk the windows without the app being aware. I wonder if Apple is looking into truly resolution independent rendering of their applications?

About 8 years ago, when I was an intern at Xerox PARC, I saw a prototype display with a 270 DPI. It was gray scale and didn't have the best contrast or refresh rate, but it was a glimpse of things to come. One day these displays will be everywhere. Will our software be ready?

The Portable MiniApp: Mortgage Calculator

Hey guys. A while back I started talking about something called a MiniApp and presented several examples (Weather, Christmas, Storm, and RSI Buster). I wrote another installment some time ago but never got around to finishing it because other projects (namely the book) took precedence. Now that Chris and I have turned in our final draft (yay!) I have more time to finish up the next MiniApp.

And don't worry. I'm going to have a big post addressing my last weblog on Swing issues.

Thinking about Java on the desktop I have been looking for things that Java does well but other technologies don't. What are the competitive advantages of Java and how can we exploit them? Something that I've always thought would be really cool is to have something in a webapp that I could take home with me. Something that exists on the web, but that I can pull off the web and use later, perhaps on my desktop or even pull it into a pda, cellphone, or mp3 player. With this in mind I present a combination Applet and Java WebStart MiniApp called Mortgage Calculator.

It's a simple mortgage calculator (I did a re-fi recently) that works as both an Applet embedded in the webpage and as an Application. Both versions use the same code base and they don't really care which environment they run in thanks to a clever base class that hides the differences (part of an application framework I'm working on).

Here is the applet:

And here is the webstart link (obviously you need a recent (1.4+) version of the JRE including Java Web Start.

(you must have Java WebStart installed)

Now, what would be really cool, is a button in the program itself that lets you download the webstart app directly. The concept here is that you can show a cool application in your webpage, and then, if the user likes it, they can launch it again via webstart and keep it.

Now of course it would be really, really cool if you could not only take the application down to your desktop but also to your PDA as some sort of MIDP application. This would be a little more difficult (due to the API differences) but not impossible. Of course most cellphones don't let you install MIDP apps directly from your computer, but the concept is there.

Any other ideas for MiniApps?

New MiniApp: Storm Drain

While playing around some more with this miniapp idea, I came across geographer Tyler Mitchell's weblog post about hurricane tracking using Web Map Service urls. I thought this would make an interesting MiniApp and give me a good opportunity to play with a few webservices. Starting from his base (and with some greatly appreciated clarification emails from Tyler), I've created StormDrain, a simple program that loads WMS data and displays it graphically. Here's what it looks like:

Storm Drain: Jeanne Data

WMS data services give you access to lots of useful information. It can render storm data for any geographic area and resolution you want, returned in a variety of image formats. It also has a discovery mechanism that lets you programmically find out what storm data is available. http://dev.gomoos.org/cgi-bin/wms_nhc?request=getcapabilities will provide you with a XML list of every request and format the service understands.

In my program you can left click to recenter and zoom, and right click to zoom out. The Storms menu gives you the list of storms generated by the GetCapabilities request type. It uses a zoom factor to determine which latitude and longitude to use when requesting the maps.

The land map images have a light blue background that I wanted to replace with something more oceany. To pull this off I created a color swap filter that will replace one color with another. For the land data it replaces the background with a dark blue. For the storm data it replaces the background with the transparent color (0,0,0,0) so that the other layers will shine through.

Java2D's image APIs make this kind of a color filter quite easy to implement. First you need a custom RGBImageFilter called ColorSwapFilter:

class ColorSwapFilter extends RGBImageFilter {
    private int target;
    private int replacement;
    public ColorSwapFilter(Color target, 
                           Color replacement) {
        this.target = target.getRGB();
        this.replacement = replacement.getRGB();
    }

    public int filterRGB(int x, int y, int rgb) {
        if(rgb == target) {
            return replacement;
        }
        return rgb;
    }
}

Any RGBImageFilter must implement the filterRGB method, which will return a new color based on the input color at the current x and y coordinates. In this case it returns the replacment color when the current color matches a target, otherwise it just returns the original color. Note that I've used getRGB() to work with the colors as integers instead of color objects.

Filter in hand, you can now filter any image to swap the colors. This is a utility function that gets the source image, creates a new filter to swap the target color with a transparent color, then executes the filter with a call to createImage() on any component (a new JPanel in this case). It's that simple

public Image loadTransImage(URL url, Color target) {
        Image src = new ImageIcon(url).getImage();
        ImageFilter imgfilter = 
           new ColorSwapFilter(target,new Color(0,0,0,0));
        Image img = new JPanel().createImage(
           new FilteredImageSource(src.getSource(),imgfilter));
        Image imgx = new ImageIcon(img).getImage();
        return imgx;
    }

StormDrain loads data from a WMS service provided by GoMoos.org

Storm Drain webstart link

updated webstart link

mouth.whereIs().put(new Money())

Hmm. Perhaps it should have been mouth.getLocation() instead. That would present a more consistent BadJoke API. :)

For the last two weeks I've been talking about MiniApps: small programs that utilize rapid web deployment, do simple things well, make our lives easier, and brew Konfabulator-esqe programs is here today, we just need to get together and actually build some of 'em. C'est facile, n'est pas? Of course I'm a big important developer and way, way too busy to spend my time on these sorts of trivial small applications, right? :) I 'spose if I'm going to advocate this type of development to the Java community then I should actually build one. With that in mind I present:

MiniApp #1: RSI Buster

I have had bouts of carpal tunnel syndrome in the past, but it's been acting up a lot recently. Probably because I'm typing more emails at work instead of coding and working on more articles at home. Double your typing. Double your pain.The new office, keyboard, and keyboard tray all help; but there's no substitute for simply letting your wrists rest.

If you read Jono Bacon's excellent recent article, Alleviate RSI the Hacker Way, you may have downloaded some applications that interrupt you every few minutes to let your wrists relax. The big problem with these progrms (well, besides to the fact they aren't written in Java :) is that they ask you to wait a few seconds to let your arms cool down, but they don't give you anything to do while you wait! What can I do for 30 seconds that doesn't involve using my hands? Simple: read something.

My own open source project, Flying Saucer, the xhtml renderer, just reached a big milestone: R3. It is finally good enough, and fast enough, to render most validating xhtml content with a lot of style. Looking for a sample application I came up with the idea of providing a blurb of styled text to read while letting my wrists rest. This is also a good exploration of thick clients that combine the best of desktop apps with web programming. I created a JSP that wraps the standard unix fortune program, then adds a splash of color and fonts to make it look nicer. But enough with the synergy talk, lets get to the program.

Here is the link to RSI Buster a web startable MiniApp for helping you deal with RSI. It will stop you every 15 minutes with a small window containing some fortune output. For those of you without Java Web Start, here is a screenshot.

RSI Buster: fortune screen

Note: this app is signed and requires you to give it security permissions. This is due to a bug in the CSS support library for Flying Saucer. It doesn't really access the filesystem but it thinks it needs to. I should have a fix for this soon

When the main window is dismissed you will still see a small mini-window that you can drag around. Since I use a laptop with an external hi-res monitor I keep RSI Buster on the extra screen to my side, along with my email and iTunes. If you right click on the mini-app you'll get a menu to quit or reload the fortune.

RSI Buster: mini screen

If any of you are interested in the code to see how it works or build enhancements, just shoot me an email.

Visions of truly portable applications.

I've been thinking about the miniapps idea some more. I still think it's a good idea, but I want to extend it a bit. Miniapps are great and all, 'cause they're, well, mini.. but I want more. Java is supposed to by write once run anywhere, but in practice any given program only runs on one computer. I'm not talking about whether it can be on Mac or Windows. I mean that I typically install the software on one computer and that's it. If we've got this great portable runtime then why aren't our applications truely portable?

Okay, let me take this from another angle.

Imagine the future, 2005-AD, a child logs in to his Windows computer and recieves an email from a school friend containing an Applet. It's a cute little game, featuring sarcastic hyperbolic cartoon characters call Maroons, built right into a webpage, sent in an email.

Little Johnny plays for a few minutes, decides he likes the game and hits a button marked: Install. Now the program serializes itself, runs through a custom installer, and configures the right webstart preferences to fully install itself on the computer, all while continuing to run in a separate window. Johnny doesn't see any of this though. He just sees the program magically jump out of the email and into it's own window.

Later that day Little Johnny he's chatting with his sister, Sally, at college over IM. She's interested in the game so he drags the program into the chat window where it's instantly teleported to her iBook. Again she can run it or press the install button to save it locally.

The next day Sally prepares to go to a local cafe and study with a friend. Knowing that her friend is always late she decides to bring along the game her brother sent her. She drags the program into the iPod symbol on her computer where it is automatically synced on to her iPod-mini, adding a new menu item for Maroons.

Sally's friend finally shows up an hour late. He asks what she's playing. As she shows him the highscores list pops up. It contains the names Sally, Johnny, and Bobby (the boy who emailed it originally to Johnny), the high score list having been transferred along with the running game each time.

Finally Sally returns home, plugs her iPod in to her laptop and goes to sleep. In the background the game sends her scores to a p2p network where it syncs back to Johnny and Bobby's computers, but no where else.

What do you think? Can we get our favorite portable runtime to transport applications around in cute candy colored installable jars? I want my portable applications to really be portable: at the code, installer, and UI level.

Unleash the MiniApp

It's gonna be a busy week so I'll keep this short. I've been thinking a lot about moveable applications and the idea of rich clients. This is mainly on my mind because the Flying Saucer team has been hard at work on the next version of XHTMLRenderer. (We're shooting for an August 31st release) An embedded rendering component has pretty much one core use: applications with both GUI and html interfaces. But what do they look like? What creatures live in that shadowy borderland between the desktop and the web?

The obvious example is the iTunes Music store. Having an HTMLish component lets Apple embed visually rich content which can change without requiring a software update. But iTunes still has as a desktop interface that satisfies the core function, playing and organizing music, better than a purely webbased program ever could. But this is old news. What else is out there? And why don't I have them?

I think that we should have a Konfabulator / Dashboard equivalent in Java. They each approach the same idea, small easy to write/install/use applications, from different sides. Konfabulator starts with a desktop program and adds internet dynamic content (like rss feeds and webservices), then makes it pretty with web-era graphics and animation. Dashboard starts with pretty webpages and pulls them out of the webbrowser into separately launchable programs with more local control than HTML and Javascript typically allow. I'd like to see us do something like this in Java.

I want to be able to hit Ctrl-Alt-F2 to get my RSS headlines to popup. F3 gives me my MP3 player and F4 for an internet wide Online Help search. (With first priority for JavaDocs of course). F5 would be a MiniApp implementation of Frink, the coolest calculator I have ever seen. (It performs conversions between any unit, letting you definitively calculate the density of the alien mothership from Independence Day). These are MiniApps (TM) I want to see.

Imagine a constantly running program that manages MiniApps. It could be visualized as a dock, taskbar, or sliding Expose' sheet. Or maybe all three! Every program implements a simple common API, say a subclass of org.javadesktop.MiniApp. The MiniApps would run in a sandbox similar to WebStart apps or Applets with crossplatform APIs for user alerts, preferences, and webservice access. Since everything runs inside the same JVM (with the appropriate safety mechanisms), we could avoid the 25MB hit that each separate Swing instance and runtime.

Every MiniApp has the ability to access web resources but runs locally, even when disconnected. Think of it as the best of Gnome Panel applets combined with server based web programs.

Here's a few more ideas for MiniApps:

• Local Weather, Movie, and Traffic Listings with alerts, like an accident that's going to block my exit on 285 for the next four hours!
• SuperRef: search through the dictionary, thesaurus, and quotation index to make my articles appear smarter than they actually ar.
• MiniCal: which ties to Outlook/iCal and alerts when it's time for lunch.
• MiniSheet: for quick calculations. Is there enough in my bank account to buy that new SouthPark DVD?
• MiniDraw: annotate the current screen with a precise description of why feature X doesn't match the documentation, automatically CCed to the developer list
• InstaFlame. Lets me compose short blog entries as the ideas arrive and post immediately to my blog without starting up new software or having to reconsider my ill-conceived opinion.
• eBayLert. Tell me when I'm about to be scooped on that valuable 1961 vintage Jetson's Lunchbox.
• SafariSearch. Let me search through books and documentation in my current Safari subscription. I want to know the syntax of JComponent.repaint() and I want to know now!

And of course the best thing about MiniApps is that they would be written in 100% Java, letting the minis run on any platform without fear of malware or viruses

Quick Radial Blurring w/ Java2D

I have to say that Java2D is amazing simply for it's productivity. The other day I was watching the psychedelic display in iTunes when I thought, I wonder how hard it would be to do that? I know it's a blurred and stretched out from the center, but that was pretty much it. I found some demoz that did something similar but I didn't feel like pawing through badly documented C++ code to figure it out. Instead I went to Java2D and wrote this in about half an hour:

Java2D already has routines for blurring, image scaling, and compositing. I just had to pull them together. Here are the important lines. The rest of the code is just boiler plate for the animation thread.

First I created a kernel, which is the actual grid of numbers that make up a convolve operation. Each pixel after the operation will be based on the old one, plus the ones directly next to it. In this case, half of the new pixel's color will come from the old pixel and then 0.1 will come from each of the four adjacent ones. However, 0.5 + 0.1 * 4 = 0.9, not 1.0. This means the new pixel will be slightly darker, and over successive operations the whole screen will fade to black. If the background is already black, then the image will essentially fade away, which is exactly what we are looking for.

BufferedImage src, buf;
float angle;

public void paintComponent(Graphics g) {
    // create blur kernel
    float[] my_kernel = {
        0.00f, 0.10f, 0.00f,
        0.10f, 0.50f, 0.10f,
        0.00f, 0.10f, 0.00f };
    ConvolveOp op = new ConvolveOp(new Kernel(3,3, my_kernel));

Next I rotate the x and y coordinates of the martini around with sin and cos functions, creating a circle motion.

    
    // move the image in a circle
    double xoff = Math.sin(angle)*20;
    double yoff = Math.cos(angle)*20;
    angle+=0.05;

Now we get to the good part. First I draw the martini glass to the main buffer, buf, run it through the blur filter, and then draw it back on top of itself slightly larger. It's the slightly larger part that makes this a radial blur.

    // draw the martini
    Graphics bg = buf.getGraphics();
    bg.drawImage(src, (int)xoff, (int)yoff, null);
    // blur the buf image
    Image img = op.filter(buf,null);
    // draw the blurred image back on top of the main buffer
    // but scaled
    bg.drawImage(img,
        (int)(-0.0125*size),(int)(-0.0125*size),
        (int)(+1.025*size),(int)(+1.025*size),null);
    // draw it to the scree
    g.drawImage(buf,0,0,null);
}

Compile, package it up, and here it is in webstart form. Click to launch

If you're interested in the full code it's here and the original martini image is here

I'm simply amazed with the productivity of Java2D

Myth: There aren't any commercial apps written in Java.

The last few months have been great for client side Java. With the release of JDIC, JDNC, Java 1.5 betas, and more support than ever from Sun, I think we are seeing a revival in interest for client side Java. Still, I hear the usual refrain: "If Java is so good on the desktop, then where are all of the commercial apps?" If I point to something like LimeWire I get: "No. I mean big applications, like Word." Well, I never have an answer for that one. I didn't seven years ago and I don't know. Speed and API support isn't an issue anymore, but there still aren't any well known commercial applications written in Java. That finally led me to the question "Is any big name application written in anything other than C/C++?"

The answer is, strangely, no. Perl, TCL, PHP and Python. No big commercial app is written in anything other than the stalwarts: C and C++. But I also came to another observation. There aren't any new big commercial apps.

I want you to seriously think about this for a change. What big established software is there that's new? On my computer I have running: Mozilla, Outlook, Word, Excel, Photoshop, and jEdit. All of those, except for jEdit (a Java program), stem from a code base that is at least 7 years old. Excel is twenty! There simply aren't any new big desktop applications.

I remember ten years ago browsing through various computer magazines that would review the latest versions of word processors, layout programs, and databases. There was real competition then, and whole new categories of software came out like disk repair utilities and floppy disk compression.

Today all of that software has been either commoditized or monopolized (or both). All of the new software is small. There aren't any new large applications. The market for such things is already saturated, and no new software means no new languages for writing it.

New software is being written, of course. Constantly. It's just that the new software isn't what we would call Big Desktop Applications. The new stuff is all small. All attacking small problems with specific solutions. No need for a general multi-media package. Instead we have one for playing and managine music. One for editing music. And one for combining music with photos. Instead of one package Apple gives us four with iLife.

In addition to being smaller the new software is increasingly webbased, like Yahoo Mail, or living half on the network and half distributed desktops. This new breed of software is increasingly being written in new languages.

And most importantly, this kind of software is where the growth comes from. There aren't many new desktop spreadsheets anymore. In fact the only new software I've seen come out of the word processing category has been a result of commoditization of the file format (.DOC is now a stable target for reverse engineering) or of the category itself (it's easy to reimplement the features that we now know we need in a word processor).

There's lots of new network and multi-media apps though. Chat. Distributed PIM. P2P file sharing. MP3 players. And I don't even know what category to put Friendster in. These categories are increasingly being done in Java. And Java's faster development type and rich API really shine in these kinds of applications.

So don't worry about the lack of large applications. There's only a few of them anyway. Be more interested in the multitude of exciting, dynamic, and little applications.

My new opensource project: Flying Saucer, an all Java XHTML renderer.

I normally try to be even handed, un-biased, and bi-partisan; but today I'm going to shamelessly use my muchly vaunted position as a highly skilled blogologist in field of java.net to plug my new project: Flying Saucer, an all Java XHTML + CSS renderer.

When I was doing research for my two part series on HTML renderers for Swing (pts 1 & 2) I got to thinking Why are there so few renderers, and almost none that are opensource? Is it really that hard?. Initially I tried to fix some of the bugs in the HTMLEditorKit that comes with Swing, but found a slew of private methods that prevented me from improving it through subclassing. I also tried editing the Swing code itself during a four hour cross country flight, but to no avail. And even if I had made the changes I couldn't have released them with the current Swing license. With so little to go on I struck out on my own. I mean, really, how hard could it be? :)

Two months of hacking an hour here and there I found out how hard. It was both easier and harder than I expected.. To make life easier on me I decided to leave out everything that didn't directly have to do with rendering HTML on the screen. I dropped the idea of making a complete browser with a UI, javascript, debugging, bookmarks, history, etc. Those are all important but not the hard part. Since CSS and XML parsing are already provided by other libraries I reused them instead of reinventing the wheel. It's not that I dislike wheel inventing, it just that I have to be realistic about what one programmer can do in his spare time.

With that out of the way it was still too big. The core renderer of Mozilla took years to develop and the full time work of several top notch programmers. Gotta cut it down. Thinking about it, though, I don't need a complete webbrowser like IE or Mozilla. Since this is for embedding in my own programs most of the content will be generated by my own code. I don't need to deal with every browser bug and every malformed webpage out there. I could get by with strictly compliant pages and worry about quirks handling in a compatibility library. (to be built later, of course. :)

Now, if I'm going to write a new renderer from scratch I should go for the gold, ie: complete XHTML + CSS 2.0 (now 2.1). It's actually not as hard as I thought. The W3C makes some completely exhaustive specifications. The CSS 2 spec in particular is huge, but it does describe in great and explicit detail how each feature should behave (giving Internet Explorer no excuse for it's bugs).

So what do we have. I've written a renderer that takes a org.w3c.dom.Document object with inline styles and renders it into a scrollable JPanel. Most of plain HTML is supported, as are the full box model, tables, and images. Parts of relative, absolute, and fixed positioning work. The main issue is the bugs in float/clear, and the lack of forms support. Oh yeah, and it's really, really, really slow (Need some help with that. I used regexs for the text parsing). But it works and the supported features are pretty compliant.

I was actually surprised at how much I've done by myself. Still, I know the limits of one programmer, which is why I'm launching it as an open source project right here on Java.net. And I need your help!

This is a challenging project that needs some top-notch people. If you feel you are up to it then sign on to the project and join the dev mailing list. In particular I want to start breaking it up into modules and find owners for each:

• Rendering compliance (research the latest standards, build it, test it)
• CSS (parsing, converting, optimizing, rendering new features)
• HTML->XHTML converter (support for HTML 3/4.0 pages)
• Browser component (a standalone webbrowser based on Flying Saucer)
• Javascript support (how do we plug in rhino?)
• I18N efforts (how do we make sure the whole thing is i18n-able)
• forms (input, select, text area, etc)
• object and plugin support (SVG, xforms, flash, pdf)
• printing module (we can't print anything yet!)
• network module (ssl, redirects, image loading, etc.)
• performance and memory optimization (how do we make the whole thing as fast and light as possible)

I really think that a complete XHTML renderer is a vital component of any modern programming toolkit, and I'd like to see Flying Saucer become the best of breed implementation for Java. It's a lot of work but it's going to be rewarding. Come on in. The water's fine!

Oh, to just play with it quickly check the source out of cvs or download this zipfile. You only need Ant and the 1.4 JDK. Run ant test to launch the test program. Select different tests from the Test menu.

Update: I forgot some links. the project is here and the mailing list is here.

Swing Hack 8: An eyedropper tool

On the plane back from California I decided I've had enough with politics for a while and I'm ready to get back to coding. One thing I've always thought was missing from Swing is a good color chooser. Swing provides a color chooser model and a default color chooser, but it's always felt unfinished. Another 3rd party opportunity I suppose.

In my ideal color chooser we would have several different ways of selecting color, varying by color space model. This is pretty straightforward as you can see from the [Color Selector Tutorial]. What's not so easy in a Photoshop style eyedropper. If you aren't familiar with it, this is a tool that lets you click anywhere on the screen to select the color under the cursor.

Most paint tools give you an eyedropper, but I've never seen a Java program do it. This is because getting a screenpixel requires native access, usually locked off from Java programs. Java 1.3 introduced a new method to the Robot class, getPixelColor(), which can retrieve the color anywhere on the screen. The problem is that you don't get mouse events once the cursor leaves your JFrame. Fine if you only want to select colors from your own application, but we want to select anywhere on the screen. Java 1.5 introduces new APIs for getting complete mouse events, but that doesn't help us today. (though I'll be covering the 1.5 additions in future articles).

The answer to this tricky problem, of course, is to cheat! The program below makes a screenshot and then paints it into a JFrame which fills the entire screen. Our screenshot is indistingiushable from the real desktop except that nothing in the background updates. However, since we only need this while the user selects a color it should work fine. What I've designed is a color scheme selector with any eyedropper. Once the user selects a color by clicking somewhere on the screen the panel will show compatible colors by determining the midpoint between the selected color and the max/min values of brightness and saturation.

Here's what it will look like:

Eye Dropper

The following code is built on a simple prototype Swing framework I've been working on (a desktop equivalent to Servlet and Applet). It defines a basic lifecycle of init(), initComponents(), initLayout(), and initEventHandlers().

First we need to calculate the size of the screen and make our screenshot.

package net.java.demo.colordesigner;

import java.text.*;
import java.util.List;
import java.awt.*;
import javax.swing.*;
import net.java.swing.application.*;
import java.awt.event.*;
import javax.swing.event.*;

public class ColorDesigner extends 
                SingleFrameApplication {

    public JButton eyedropper, quit;
    public JComponent colormap;
    public JFrame rootFrame;
    public Image background_image;
    public Robot robot;
    public Dimension screen_size;
    public Container contentPane;
    public JComponent button_panel;
    public JPanel image_panel;
    public JPanel control_panel;
    public JPanel color_panel;
    public ColorLabel selected_color;
    public ColorLabel color_rich, color_pale, 
                color_bright, color_dark;
    public Font color_font;

    /* init code */
    public void init(JFrame rootFrame, 
                  Container contentPane, List args) {
        try {
        this.rootFrame = rootFrame;
        this.contentPane = contentPane;
        this.color_font = new Font("Monospaced",Font.PLAIN,14);
        
        // take a screenshot
        screen_size = Toolkit.getDefaultToolkit().getScreenSize();
        Rectangle rect = new Rectangle(0,0,
             (int)screen_size.getWidth(),
             (int)screen_size.getHeight());
        this.robot = new Robot();
        background_image = robot.createScreenCapture(rect);
        
        super.init(rootFrame,contentPane,args);
        
        } catch (Exception ex) {
            p(ex.toString());
        }
        
    }

In initComponents() we expand the frame to fill the screen and turn off the window decorations (the borders, title, and min/max buttons) Next we fill it with a JPanel that just paints the screenshot to the background and holds the sub components. The rest is your usual collection of panels and buttons.

    public void initComponents(Container contentPane) {
        rootFrame.setSize(screen_size);
        rootFrame.setUndecorated(true);
        
        image_panel = new JPanel() {
            public void paintComponent(Graphics g) {
                super.paintComponent(g);
                g.drawImage(background_image,0,0,null);
            }
        };
        image_panel.setPreferredSize(screen_size);
        
        control_panel = new JPanel();
        control_panel.setSize(200,200);

        button_panel = new Box(BoxLayout.X_AXIS);
        quit = new JButton("Quit");
        eyedropper = new JButton("Eye Dropper");
        
        color_panel = new JPanel();
        selected_color = createLabel();
        color_bright = createLabel();
        color_dark = createLabel();
        color_pale = createLabel();
        color_rich = createLabel();
    }

    public ColorLabel createLabel() {
        ColorLabel label = new ColorLabel();
        label.setFont(color_font);
        label.setOpaque(true);
        label.setBackground(Color.blue);
        return label;
    }

I'll skip showing the initLayout function since it's a very straightforward gridbag layout. In initEventHandlers() we subclass MouseInputAdapter to set the selected color on every mouse press and drag. getSMidpoint() and getBMidpoint() calculate the midpoints in HSB color space (Hue, Saturation, and Brightness) between the two specified colors.

    public void initEventHandlers() {

        MouseInputAdapter mia = new MouseInputAdapter() {
            public void mousePressed(MouseEvent evt) {
                setSelectedColor(robot.getPixelColor(evt.getX(),
                         evt.getY()));
            }
            public void mouseDragged(MouseEvent evt) {
                setSelectedColor(robot.getPixelColor(evt.getX(),
                         evt.getY()));
            }
        };
        
        image_panel.addMouseListener(mia);
        image_panel.addMouseMotionListener(mia);
    }
    
    public void setSelectedColor(Color color) {
        selected_color.setColor(color);
        color_bright.setColor(getBMidpoint(color,Color.white));
        color_dark.setColor(getBMidpoint(color,Color.black));
        color_rich.setColor(getSMidpoint(color,Color.red));
        color_pale.setColor(getSMidpoint(color,Color.white));
    }
    
    
    public Color getSMidpoint(Color start, Color end) {
        float[] hsb1 = Color.RGBtoHSB(start.getRed(),
                    start.getGreen(),start.getBlue(),null);
        float[] hsb2 = Color.RGBtoHSB(end.getRed(),
                    end.getGreen(),end.getBlue(),null);
        float[] hsb = new float[3];
        //hsb[0] = hsb1[0];
        //hsb[1] = 1;
        hsb1[1] = (hsb1[1]+hsb2[1])/2;
        //hsb[2] = hsb1[2];
        return Color.getHSBColor(hsb1[0],hsb1[1],hsb1[2]);
    }
    
    public Color getBMidpoint(Color start, Color end) {
        float[] hsb1 = Color.RGBtoHSB(start.getRed(),
                     start.getGreen(),start.getBlue(),null);
        float[] hsb2 = Color.RGBtoHSB(end.getRed(),
                     end.getGreen(),end.getBlue(),null);
        float[] hsb = new float[3];
        hsb[0] = hsb1[0];
        hsb[1] = hsb1[1];
        hsb[2] = (hsb1[2]+hsb2[2])/2;
        return Color.getHSBColor(hsb[0],hsb[1],hsb[2]);
    }

I've created a custom component called a ColorLabel which is simply a block of color with the hex value displayed in the center. It has a little bit of smarts to change the color of the text so it always contrasts with the background and you'll never get black on black.

In production this code would be integrated into a color chooser dialog which would only show the screen sized frame when the dialog is visible, but this demo code shows off the idea more simply. Enjoy the [code]!

Java's got a Bad Rep: The Rebuttal

So it's been a week and I've seen a lot of response to my last entry. One commentor in particular asked for a point by point rebuttal; which struck me as a spectacularly good idea. Here are the bulk of the arguments and my responses.

The Arguments

• Java isn't Free / Open Source / GPL / RMS-friendly
• Why use Java when there are plenty of native languages / environments to choose from.
• Java is missing templates / preprocessors / lambda functions / other advanced language feature that only backwards cave-dwelling languages lack.
• There aren't any applications written in Java. It must be a failure.
• Java / Swing is slow, looks bad, and doesn't feel native, doesn't let me do cool stuff like animation, 3D, or sound.

Here we go.

The Rebuttal

(1) Since it's such a huge (and apparently controversial) topic, I am covering the open sourcing issue separately in this other post. However, in summary, opensourcing doesn't solve our problems and buys us very little, in exchange for a lot of new problems. Follow the link for a full analysis.

(2) Why use Java when there are plenty of native toolsets to choose from? Well, first of all, it's better than a lot of them. If you want to write an application (not a script or a device driver) then Java provides you with a good toolset, great libraries, and a clean language which learned from the mistakes of the past. It's simply a good applications language that can make your programmers more productive.

Java can also be "write once, run anywhere". For people who need to support multiple platforms, especially more esoteric ones where you could never hire a native expert (say the palm pilot, or win 98), or if you simply don't want the headache of dealing with bizarre version issues, then Java provides you with a consistent platform to code against. It's compile once, run anywhere features are especially important in the age of ubiquitous networks with code flying over the wire. Java Webstart has been a godsend to companies with locked down desktops spread over the globe. (potentially running eight different versions and patch levels of Windows).

So why use Java? Because its better than a lot of the alternatives for writing applications.

(3) Java is missing language features. This is probably more a matter of taste than anything else, but Java isn't lacking features because no one thought to add them. Nothing in Java is new. Every part of the system, from language to library to VM, was carefully considered against the 20 year history of OO languages. Preprocessors were left out for a reason. So were pointers. Java is missing a lot of the more esoteric features, but most of those features aren't used in day to day programming anyway. A few of them, like generics, are slowly becoming more mainstream, and Sun is adding them as people ask for it. Remember, computer languages evolve slower than hardware or software platforms. It took 20 years for inheritance and polymorphism to become common place (and it's till not as common as you might think). The features Java is supposedly lacking we really shouldn't miss. And if there's something you just have to have, then you can use one of many addons to provide it like XDoclet and Shark, safe in the knowledge that if it compiles to Java bytecode then everyone can use it.

(4) Nobody uses Java. This simply isn't true. Probably 99% of Java applications are either serverside (where the user doesn't know or care what the application is written in) or are made for internal corporate use. As Eric Raymond pointed out: "there is empirical evidence that approximately 95% of code is still written in-house". Most Java applications, even Swing apps, are for corporate use. In these environments the robustness, productivity, and easy of deployment more than make up for Java's other flaws. There are plenty of high quality applications that people don't know are written in Java, and that's really the problem. Especially on the desktop I'd like to see more highlighting of Java success stories (and more ways to get the word out!)

(5) Java is slow, ugly, and doesn't do modern native things. I've saved this for last because I think it's the biggest problem. Java has this impression because, well, it was slow and ugly. Back when Java debuted nothing worked properly, applets were slow to load, and AWT used a horrid subset of the available widget set on each platform, all of which looked different and ugly.

Today the situation has changed. Swing has gone through several revisions to become a powerful toolkit, if complex. The speed issues have mostly gone away from improving the libraries and a decade of faster processors. Even on my now aging iBook I run jEdit quite nicely and have written tens of thousands of lines of code with it.

Swing itself has also matured (and gotten prettier). Most of the big bugs have been fixed. Quite a few attractive Look and Feels are available from Sun and 3rd parties. A lot of the missing functionality from the early days is finall in place. It is entirely possible to make great desktop applications, even consumer apps, with Java. We just need to get people to realize it.

The plan

Despite all of my argument preceding, Java still has an image problem. People still think that you can't write good desktop applications in Java because they don't see them. So what can we do? Show them! And keep building more!

First, we need to show off the good apps. Get the word out. I think we need a place to highlight great applications. Perhaps a sidebar on Java.net with a new application each day. The only requirement is that it be a desktop application with a downloadable demo. This spot should have it's own RSS feed and archive. Then we have to start the publicity. Get other sites to link. Make a download.com for Java apps.

Second, create a place to collect all of the tips and tricks it takes to make a quality desktop application. I've started a Wiki node here with a framework of what we should pull together: exe packaging, good look and feels, swing tutorials and articles, how to work with different kinds of media. Contribute whatever you know. We need to fill out the missing pieces.

Third, start a contest for quality Swing applications along the lines of O'Reilly's MacOSX app contest. We should have different categories for commercial and open source, full applications and mini programs, and maybe further sub-classification (word processing, media and graphics, personal organization). We'll probably need to get a corporate sponsor for this.

We all know that Java can make great software on the server. It's time to reclaim the desktop. (Wiki Here)

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

Does Java have a bad reputation?

I recently read on Slashdot (something I promised myself I was going to do less) about Miguel de Icaza's comments on Longhorn. It was a pretty interesting read and makes me think I should read up on XAML and Avalon, Microsoft's new technologies for making advanced rich web applications. What struck me as particularly jarring, however, was this thread where someone asked about Java as a webapplication stack to compete with Microsoft or an as yet unwritten opensource toolkit. Most of the readers jumped on this and attacked Java from all sides. What particularly worries me was not that so many of these readers are opposed to Java, but that their arguments are almost completely wrong. Take a look at some of these comments:

Stock Java is not an option because it lacks a few things: the easy-to-build functionality of a web page (XAML) and the advanced graphics and rendering of Avalon.

However, it really does not matter what is going on in the java world. Java had its chance, and failed. Java the language has outgrown the Java the (virtual) machine. Java the language is now being extended in weak syntatic ways, think of generics where it is possible to corrupt generic containers because the support is only syntax deep.

Java is faster now, and computers are faster now, but technical analyses of .NET and the CLR tend to indicate that it is better thought out than Java. No wonder, since it came substantially later than Java, but that doesn't change the fact.

If Sun brings us a Java 3 in the near future which addresses these performance and scalability issues (among others) then this post will be irrelevant (well I guess it is already, welcome to slashdot right?) but right now it makes more sense to emulate the CLR and the non-Windows portions of .NET. Since Java is not open source, and the open source world would like to have something like Java but open, and .NET and the CLR are superior to Java (arguably anyway) why not implement .NET? If Microsoft changes their implementation to a point which destroys compatibility, there is still room for Mono to provide a cross-platform runtime environment which will run on Windows.

The main problem that I, personally, see with Java-based apps, is the non-native widget set. I have to admit, I honestly detest Swing/AWT stuff. Swing even more. Not only is the default theme ugly IMO, but even if you make it *look* like WinXP or Gtk or whatever, it doesn't *feel* like it.

Java is a minor cleanup of a horrible set of object oriented extensions of a 35 year old high level assembler. Perl/Python/Eiffel/Tcl-Tk show what Java could have been and where it could have gone. Furthermore, even as a cleanup of C++ it got too many things wrong, as illustrated by the numerous minor bug patches in Java "the next generation", more commonly known as C#

I'm starting to really wonder why Java, or at least Java on the desktop, has such an image problem? If you are talking about rich web enabled applications that run on your desktop and on the web, then Java should be at the top of the list. Do we need a PR agent or something?

The future is Vectorized

I know it's been a while since I've posted. But I've been busy. With, um, you know, stuff! Writing stuff. Coding stuff. Drawing stuff.

I'm especially interested in drawing stuff. In particular I've noticed a growing interest in SVG and vector displays. I'm personally a fan of vector formats since it makes a great base for interesting drawings in Photoshop, but I've started to discover other uses too. This article covers the history of SVG on desktop Linux.

What I find most interesting about SVG is that it was created as a webcentric technology but it's finding great traction on the desktop in places like icons and window decorations. So why the new buzz about SVG in a technology world still in the doldrums? I attribute this to two things. First, processor speeds have continued their inexorable rise, making realtime vector drawing feasable for lots of non-standard (wasteful) uses. Second, Flash, SVG, and other tools have raised a generation of people who think of vector art outside the confines of Illustrator and it's print mindset.

Of course, if we rendering everything as vectors the curves and angled lines won't be as sharp as they could be with bitmaps. Even with modern anti-aliasing nothing will be as clean as an image from photoshop. Assuming you have a normal resolution screen.

We are reaching the limit of usefulness for normal desktop screen size, but what happens as pixel densities increase instead of screen inches? My ibook had a 109 dpi screen and I found it to be much more readable than the larger 92dpi laptops I tried. Years ago when I interned at Xerox PARC I saw a prototype of a 270dpi flatpanel. It was black and white, not even greyscale, but at that resolution you can start doing halftoning. The clarity was amazing. Many people also noticed the announcement of Sony's epaper initiative. This is the kind of product that requires real vector art.

So now that the tools, devices, and the platforms are coming along, what can we actually do with SVG and other vector formats. We've still go the usual suspects: clipart in Word, animation for games, and technical diagrams. But somehow I think more is coming. So where could we use vector rendering creatively?

• Scale the desktop icons. This happens to some extent in OSX and now in Gnome and KDE. That's how we get those nifty dock effects.
• Theme your app's UI with CSS. Change the selection color. Make every font bold and every line thicker. If it's all drawn with SVG then CSS for style will be a snap.
• Scale the screen widgets. Menus, icons, buttons and checkboxes, everything. Rumors are that this will happen in OS X 10.5: Jungle Cat's Revenge. Adjust the screen to match your eyesight, distance from the monitor, and lighting.
• More special effects: how about a ripple through your screen when you receive an IM?
• Vectors on gadgets: My Palm Zire71 is fast enough to do quite a bit of vector drawing. We need more screen readers and vector games. Not to mention a really good drawing application.
• How about Alice in Wonderland with the original illustrations? Or maybe mathematical texts with the real symbols. Vectorizing chunks of Project Gutenberg could go a long way towards making the etexts more accessable.

The possibilities of commonplace vector rendering are limitless. The only limiting factor I see is that we don't have a good archive of opensource vector art to start with.

2004: the year of the Net-App

A lot of people have put out lists of what they expect to see for the new year. Instead of going across the industry I'm going to focus on one topic in particular: networked applications. I really think that 2004 is the year of the netapp. Now sure, I know what you're thinking: "I thought 1994 was the birth of the most popular networked application ever: the webbrowser. You're about ten years too late". I'm not talking about the webbrowser. It's a general purpose application that isn't very good at anything, but good enough for almost everything. I really think the last few years have shown a desire for specific networked applications that, in the long run, will blow the pants off ye old browser.

We've seen the apex of business applications. Crunching numbers and wordproccesors just don't interest people anymore. The growth is dealing with small nuggets of information, and lots of them. Most consumer apps involve media manipulation or communication in some form, almost always over a network. It's not quite 'the network is the computer', but it's certainly the case that 'without the network there is nothing for the computer to do'. Dedicated networked applications, not just general purpose webbrowsers, really seem to be the way to go.

But this is still a lot to cover in a blog entry. I'm going to narrow it down even more. Being a UI guy I have ask myself: what are they going to look like? Thinking about this over my vacation here are my predictions of what we will see in the coming wave of dedicated networked applications:

• Search: Searching is important. By definition, networked apps give us access to something that our desktop can't, one of which is holding huge datasets. Thus searching those datasets will be of the utmost importance. I expect every application to have a search feature in it. Google has conditioned us think in terms of keywords ANDed together. iTunes has popularized incremental (keystroke) searching. I think eventually all GUI toolkits will have a custom search widget to support this behavior right out of the box. I also think that Lucene is one of the coolest open source libraries ever.
• HTML will be heavily used. This means both the browsing metaphor where appropriate (bookmarks, forward and back buttons, clickable links) and literally HTML rendering in the middle of the application. The iTunes Music Store, Sherlock, RSS readers, and even chat applications are all using HTML for the display of formatted text and graphics. I think this trend will continue, especially as HTML rendering engines become more embedded in our operating systems and programming languages.
• Connectedness All netapps need a sense of when they are online and when they aren't, and when to pass that information on. Since it will be a long time before we are permanently connected, and etiquette may dictate not even then, we will need connectedness built right into the UI. Chat apps have logged in / away / offline status indicators. Gnutella clients tell you when you are searching and when people are searching you. Even email tells you the state of the network with it's greyed out folders and a checked for mail alert sound. The sense of connection state will become integral to the UI.
• Drag and drop I know, it's not a new UI component, but it's becoming more and more important. Since the desktop is rapidly becoming a set of portals into other servers and datasets, we need better ways of extracting and moving data between these datasets. All netapps will need to accept and produce drag and drop events for text, files, links, and images. This also implies ubiquitous media libraries with thumbnail previews. (Can you say QuickTime for Java?) DND support has been growing steadily in all UI toolkits, but I think we are at the point when they will finally become massively useful. Of course this will cause new problems with information overload. I'm hope to have a shelf on the side of my screen that can accept drags from any application and store them for later use. Is anyone at Apple listening?
• Syncing While the technology is established it is only just now becoming ubiquitous. The link between desktop, server, and device is more common than ever and Palm has gotten everyone to accept syncing as a metaphor. (This dispite the fact that sync is not actually a word) Now phones sync addresses to Outlook, calendars sync through servers to other calendars, and iPods (my new christmas gift. thanks honey!) sync music from iTunes. Syncing is everywhere and many netapps will need some form of syncing worked into their feature list. I expect to see more syncing toolkits as we get too many devices needing custom conduits.
• Discovery You know something is out there but you don't know what or where. This is why we've seen an explosion in discovery protocols lately. Really it's a meta search, a search for things to search. I expect to see rendezvous/zeroconf, jini, jxta, gnutella, and other discovery protocols integrated into reusable libraries. Perhaps they will even hook up with RSS and Google to become truly internet savvy.
• Non-heirarchical organization Sorting is the opposite of searching and putting things into a structure is actually much harder than getting them back out. Our data is just getting too big. There's too much information to keep track of. I personally organize my email as a nested tree structure: friends, work, online, other; with many subcategories. Now I have too much to sort comfortably. What I really need is a gigantic flexible relational database to hold it all. And every netapp I have should dump it's info into the database without my assistance. And it should intelligently sync with my server and my Palm, phone(s), and iPod.

I used to think that networked applications and distributed computing would take advantage of one simple idea: use someone else's cycles. Now, with Moore's law showing us that there's no application too big to run on the desktop of the future, I'm seeing that the real use for the network isn't to get at someone's cycles but at their databases. Every thing on my list above boils down to accessing someone else's databases. Storing, searching, manipulating, and syncing databases.

In some ways this is new because we are using new technology to do it, but this is really what we have always used computers for. The UI advances I've listed all reflect a need to visualize the above tasks in ways that are meaningful to humans. And that's what good software has always done.

Swing Hack 6: Ghost Mouse

I've been playing with Swing a lot lately for my new series of articles. In my research I came across another interesting class java.awt.Robot. It's a class that can automate the UI, mainly for testing. One particularly cool feature is the mouseMove function. Once I saw this I got evil ideas. :) Imagine rogue java programs that move the mouse cursor to mystify and befuddle the user. Spelling out hideous horrible messages. Redrum! Redrum!. :)

But I'm getting ahead of myself. The code below illustrates the technique. This creates a window with a button. When you click on the button the mouse will swirl around in an ever expanding circle of zombie horror! Or maybe just in a circle. Anyway, it was a good excuse to brush up on my parametric equations. Have fun!

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.awt.Robot;

public class GhostMouse {
    public static Dimension size;
    public static void main(String[] args) throws Exception {
        Robot robot = new Robot();
        size = Toolkit.getDefaultToolkit().getScreenSize();

        JFrame frame = new JFrame("Ghost Mouse (tm)!");
        JButton button = new JButton("Gho Ghost");
        frame.getContentPane().add(button);
        button.addActionListener(new CircleListener(robot));

        frame.pack();
        frame.setLocation(
        (int)(size.getWidth()-frame.getWidth())/2,
        (int)(size.getHeight()-frame.getHeight())/2);
        frame.show();
    }
}

class CircleListener implements ActionListener {
    Robot robot;
    public CircleListener(Robot robot) {
        this.robot = robot;
    }

    public void actionPerformed(ActionEvent evt) {
        int originx = (int)GhostMouse.size.getWidth()/2;
        int originy = (int)GhostMouse.size.getHeight()/2;
        double pi = 3.1457;

        for(double theta = 0; theta < 4*pi; theta=theta+0.1) {
            double radius = theta * 20;
            double x = Math.cos(theta) * radius + originx;
            double y = Math.sin(theta) * radius + originy;
            robot.mouseMove((int)x,(int)y);
            try{Thread.sleep(25);} catch (Exception ex) { }
        }
    }

}

Swing Hack 4: The universal right click

I received an email today asking about my use of the glass pane. It seems this fellow wants to handle right clicks on any component in each screen. A logical request. In most cases your right clicks are not limited to a single component, yet to receive the events required to show popups you have to add a listener to each component! Not enjoyable.

To get around this we can use a glass pane. Remember from last time that a glass pane is an invisible component covering the entire frame. We could catch the events there and handle right clicks on any component. The problem, of course, is that now none of your components can get any of the events.

To get around this issue we can test for the right click and then redispatch the event to make sure the correct component gets it. Not trivial but not too hard either. The tricky part is rebroadcasting the event. First you have to figure out which component was supposed to be hit. To find this we must convert the click point from being relative to the glass pane to being relative to the content pane:

// get the mouse click point relative to the content pane
Point containerPoint = SwingUtilities.convertPoint(this, e.getPoint(),contentPane);

Then we can search for the child component which was hit

// find the component that under this point
Component component = SwingUtilities.getDeepestComponentAt(
            contentPane,
            containerPoint.x,
            containerPoint.y);

Once that's done we convert the point to be relative to the target component:

// convert point relative to the target component
Point componentPoint = SwingUtilities.convertPoint(
    this,
    e.getPoint(),
    component);

And now we redispatch the event:

// redispatch the event
component.dispatchEvent(new MouseEvent(component,
    e.getID(),
    e.getWhen(),
    e.getModifiers(),
    componentPoint.x,
    componentPoint.y,
    e.getClickCount(),
    e.isPopupTrigger()));

Here's the complete code. Parts of it were adapted from the Java Tutorial sections on glasspanes and popup menus. The code makes a frame with a button and a textfield. Then it creates a right click handler to grab the events, check for right clicks, and redispatch the others.

for more on glass panes and popup menus you can read here and here .

Enjoy!

- joshua

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

/**
    Written by Joshua Marinacci (joshy@joshy.org)
    Adapted from Sun tutorial code at
        http://java.sun.com/docs/books/tutorial/uiswing/components/rootpane.html

*/
public class RightClick extends JComponent implements MouseListener, MouseMotionListener {

    JPopupMenu popup;
    Container contentPane;

    public RightClick(Container contentPane) {
        addMouseListener(this);
        addMouseMotionListener(this);
        this.contentPane = contentPane;

        popup = new JPopupMenu();
        popup.add(new JMenuItem("Dogs"));
        popup.add(new JMenuItem("Cats"));
        popup.add(new JMenuItem("Mass Hysteria"));
    }

    // draw some text just so we know the glass pane
    // is installed and visible
    public void paint(Graphics g) {
        g.drawString("I'm a glass pane",50,50);
    }


    // catch all mouse events and redispatch them
    public void mouseMoved(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }
    public void mouseDragged(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }
    public void mouseClicked(MouseEvent e) {
        p("mouse clicked");
        redispatchMouseEvent(e, false);
    }
    public void mouseEntered(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }
    public void mouseExited(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }
    public void mousePressed(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }
    public void mouseReleased(MouseEvent e) {
        redispatchMouseEvent(e, false);
    }


    private void redispatchMouseEvent(MouseEvent e,
        boolean repaint) {

        // if it's a popup
        if(e.isPopupTrigger()) {
            p("it's a popup");
            // show the popup and return
            popup.show(e.getComponent(), e.getX(), e.getY());

        } else {
            // since it's not a popup we need to redispatch it.

            // get the mouse click point relative to the content pane
            Point containerPoint = SwingUtilities.convertPoint(this,
                e.getPoint(),contentPane);

            // find the component that under this point
            Component component = SwingUtilities.getDeepestComponentAt(
                        contentPane,
                        containerPoint.x,
                        containerPoint.y);

            // return if nothing was found
            if (component == null) {
                return;
            }

            // convert point relative to the target component
            Point componentPoint = SwingUtilities.convertPoint(
                this,
                e.getPoint(),
                component);

            // redispatch the event
            component.dispatchEvent(new MouseEvent(component,
                e.getID(),
                e.getWhen(),
                e.getModifiers(),
                componentPoint.x,
                componentPoint.y,
                e.getClickCount(),
                e.isPopupTrigger()));
        }
    }



    public static void main(String[] args) {
        // create a frame with some components in it
        JFrame frame = new JFrame("Right Click Test");
        JButton button = new JButton("this is a button");
        JTextField tf = new JTextField("this is a textfield");
        JPanel panel = new JPanel();
        panel.add(button);
        panel.add(tf);
        frame.getContentPane().add(panel);


        // create the right click glass pane.
        RightClick rc = new RightClick(frame.getContentPane());
        // set as glasspane and make it visible
        frame.setGlassPane(rc);
        rc.setVisible(true);

        // pack and show the frame
        frame.pack();
        frame.setSize(400,200);
        frame.show();
    }

    // utiltity function
    public static void p(String str) {
        System.out.println(str);
    }

}

Passive Tech on the Ocean

Last week I spent a much needed vacation in The Outer Banks. If you ever see a sticker with OBX in a circle on it, that's the Outer Banks. Beautiful and isolated barrier islands off of the coast of North Carolina, they provide great rest and relaxation. And also the opportunity to think about how technology fits in our lives. I've got lots of new ideas to discuss in my coming entries, but one in particular struck me: Passive technology.

Passive technology is, or at least I'm using it to mean this until I find a better word, technology that acts silently on your behalf. It doesn't require your active attention. It only makes itself known when you ask it to or when something unexpected happens. We have some of this philosophy in our technology now, but we need more.

I came to this realization when my friends and I rode on a boat out to the gulfstream for some tuna fishing. You see it's very quiet out in the ocean. Actually it's very loud. There's the lapping of waves and the roar of a disel engine. Always there and very repetitive. But that's it. Just the two constant noises with the occasional sound from a human. While there is plenty of audible noise the information density is low. I'm not bombarded with hundreds of different systems vying for my attention like I am in normal non-vacation life. It's informationally quiet and simple on the ocean. That's why it's relaxing!

The boat isn't simple though. It was a 65 foot ship with a huge engine, beds, bathroom, kitchen, and a deck specially outfitted with chairs and mount points for more fishing rods than I could count, but everything has it's place. All features of the boat are either designed to be flush with the boat itself or carefully hidden in a specific place. Rods are placed in special fittings built into the hull. All furniture is attached to the floor. All corners are rounded. They even have special cabinet knobs that recess into the smooth door, only popping out when you need to use them.

But back to technology. What we have is a system designed to be unobtrusive because the user can't have any distractions. They always need to be focused on the task at hand: sailing and fishing. Anything else is just overhead. I can only assume that this design is the result of hundreds of years of ocean fishing experience. In a world before GPS and combustion engines these considerations had to be made or people could die. Now that's some human centered design!

So why don't we see more of this in our everyday lives? Technology that just fades into the background, letting the user get on with the real task. Probably because it's expensive and takes time. Quality products always cost more. Better materials and better design simply cost more money and resources. But it also takes time for a solution to evolve. No matter how much money you throw at building the first version of a product it won't be perfect. It has to be refined as people use it in the real world. The first cars were expensive and hard to drive. It wasn't until the standardization of the steering wheel and the invention of the automatic transmission that driving became truly accessible. It takes time for a product to mature into something easy to use. Most of our gadgets are too new to be easy to use.

But what if they weren't? I'd like you all to choose an application you use today and imagine what it will be like with 10 years more development. Don't think about new features but more on how the existing features can become more passive and fade into the background. I'm going to choose email. Please post your ideas and I'll collect them in another column a week from now.

Have fun dreaming on the beach!

- Joshua

SwingHack: keyboard spinner

import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
import java.lang.Thread;

public class KeyLightTest {
    public static void main(String[] args) {
        // create the spinner
        final SpinnerThread spinner = new SpinnerThread();

        //create a frame and button
        JFrame frame = new JFrame();
        JButton button = new JButton("Quit");
        frame.getContentPane().add(button);
        frame.pack();
        // hook up an action to stop the spinner and quit
        button.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent evt) {
                spinner.quit();
                System.exit(0);
            }
        });

        // start'er up!
        spinner.start();
        frame.show();
    }
}

class SpinnerThread extends Thread {
    private boolean go;
    public void quit() {
        go = false;
    }
    public void run() {
        go = true;
        // get a toolkit
        Toolkit tk = Toolkit.getDefaultToolkit();

        // set all keys to off
        tk.setLockingKeyState(KeyEvent.VK_NUM_LOCK,false);
        tk.setLockingKeyState(KeyEvent.VK_CAPS_LOCK,false);
        tk.setLockingKeyState(KeyEvent.VK_SCROLL_LOCK,false);

        int key = -1;
        boolean state = false;
        // loop through 100 times
        int counter = 0;
        while(go) {
            // select each key every 3rd time
            if(counter%3 == 0) { key = KeyEvent.VK_NUM_LOCK; }
            if(counter%3 == 1) { key = KeyEvent.VK_CAPS_LOCK; }
            if(counter%3 == 2) { key = KeyEvent.VK_SCROLL_LOCK; }
            // flip the state
            state = tk.getLockingKeyState(key);
            tk.setLockingKeyState(key,!state);
            // sleep for 500 msec
            try { Thread.currentThread().sleep(500);
            } catch (InterruptedException ex) {}
            // increment counter
            counter++;
        }

        // set all keys to off
        tk.setLockingKeyState(KeyEvent.VK_NUM_LOCK,false);
        tk.setLockingKeyState(KeyEvent.VK_CAPS_LOCK,false);
        tk.setLockingKeyState(KeyEvent.VK_SCROLL_LOCK,false);
    }
}

Swing Hack: Window Snapping

While working on another project I came up with a silly idea. How could I force windows to remain completely on screen and to snap to the screen edges? A simple form of window snapping. Since you can receive an event every time the window is moved it's easy to create a Component Listener to do it.

import java.awt.*;
import java.awt.event.*;

public class WindowSnapper extends ComponentAdapter {

    public WindowSnapper(int snap_distance) {
        this.sd = snap_distance;
    }
	
    private boolean locked = false;
    private int sd = 50;
	
    public void componentMoved(ComponentEvent evt) {
        if(locked) return;
        Dimension size = Toolkit.getDefaultToolkit().getScreenSize();
        int nx = evt.getComponent().getX();
        int ny = evt.getComponent().getY();
        if(nx < 0) {
            nx = 0;
        }
        if(ny < 0) {
            ny = 0;
        }
        if(nx < 0+sd) {
            nx = 0;
        }
        if(nx > size.getWidth()-evt.getComponent().getWidth()-sd) {
            nx = (int)size.getWidth()-evt.getComponent().getWidth();
        }

        if(ny > size.getHeight()-evt.getComponent().getHeight()-sd) {
            ny = (int)size.getHeight()-evt.getComponent().getHeight();
        }
		// make sure we don't get into a recursive loop when the
		// set location generates more events
        locked = true;
        evt.getComponent().setLocation(nx,ny);
        locked = false;
    }
}

The code is nicely encapsulated as a listener. You can simply add it to whatever window you want to snap and the listener takes care of the rest. ex: my_window.addComponentListener(new WindowSnapper(50));

Unfortunately, since you cannot intercept the move event, only listen to it read only, you will end up with a somewhat ugly flashing effect as the window flips between where the cursor wants it to be and where the snapping wants it to be.

Strong vs Weak Typing: Can't we have the best of both worlds?

I've seen lots of arguments on the merits of weak typing. It encourages flexiblity. It lets me write code faster. I don't worry about the details until later. I can do cool runtime tricks.

I don't buy it. I use a strongly typed language because the code it produces is more robust. Typing solves a slew of common programming errors all at once. It ensures that my code will always do exactly what I mean, no more and no less.

And yet... I can see the advantages of weak typing too. Java is a better prototyping language than C++ but it's no where near the speed of Perl for whipping up something quick.

Why do we have strong typing anyway? I can only think of two things. First is performance. If you better specify what you want then the compiler can make faster code. The second is for people. The computer doesn't really care if this string really contains a number. It's all just bits in the end. The typing is for you, the programmer. To help you avoid mistakes. To express what you want the code to do to another programmer. It could be someone using your API, or someone modifying your code, or even yourself hacking on your own code in the future. Typing is a more detailed expression of what you want. But creating that expression can be time consuming and constraining.

But what if we could have the best of both worlds. A language that was both strongly and weakly typed, but at different times. What if I could declare at the top of each module (class, file, or package level?) how much syntatic sugar should be applied.

At it's loosest level you would have:

• no required variable declaration
• foreach, other loop constructs
• dynamic casting
• no required exception handling
• inline regex
• any indentation you want.

At stronger levels (less sugar) you have to declare everything:

• must declare all variables, and at the right location
• only standard looping constructs
• explicit casting
• required exception declaration
• all other syntatic sugar turned off
• Maybe bad indentation and no javadocs would be a compile error too.

Imagine if the forthcoming generics allowed anything to be stuffed in and out of a List in the weak mode and required you to declare the type of List in a stronger mode. Bingo! The ease of Perl with the robustness of Java.

I think such a system would help with three scenarios:

For managing long lived code. We have a pattern of sugar going down as the module stability goes up. Newer code is in flux and tested constantly so it's okay to have the compiler make assumptions. As the code is used more, and more components are dependent on it, we clamp down and explicitly define everything.

It's good for dealing with developers at different skill levels. Developers who's expertise lies in other areas (say graphic designers) do the prototype using sugar mode, not having to worry about the ins and outs of casting and exceptions. Then the real developers refactor it to be more solid if the prototype ends up being used.

You get the benefits of strong typing when you open up old 'hardened' code. Then if you break something you know right away because the compiler is very unforgiving.

The language would scale from prototype stage, through development, and on to deployment and maintenance. As the risk of breakage increases so does the strength of the typing to hold it all together.

This work is licensed under a Creative Commons License.