Joshua Marinacci's Blog

Joshua Marinacci first tried Java in 1995 at the request of his favorite TA and never looked back. He has spent the last ten years writing Java user interfaces for wireless, web, and desktop platforms. After tiring of web programming at a certain home improvement retail center, a wireless carrier, and a document management company he joined the Swing team at Sun to finally get back to into high quality user interfaces. Joshua recently co-authored O'Reilly's Swing Hacks with Chris Adamson. He also leads the Flying Saucer open source project and helps out with JDIC and SwingLabs. Joshua holds a BS in Computer Science from Georgia Tech and recently moved to San Jose, California.

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.

Java Doodle: fading translucent windows, on PC & Mac

This is the next in my series of Java Doodles. There is a link to my previous one in the references below. This time I'm going to show you how to make a translucent window by setting the opacity value using new apis in JavaSE 6 update 10. However, I'm also going to show you how to make it fade in when you mouse over it, similar to some popular chat applications, as well as work properly on the Mac and degrade gracefully when running versions of Java.

The basic idea

Here is a screenshot of the basic app. It's a simple translucent window. I've you've read the recent SDN article then you probably already know the basic APIs. This app will add Mac support, a rollover effect, and show you how to degrade gracefully.

Translucent Window

Degrading gracefully

Turning on translucency with Java SE 6 is as simple as calling a new private API: com.sun.awt.AWTUtilities.setWindowOpacity(float). To make it degrade gracefully on older VMs we could test if the feature is supported using the isTranslucencySupported() method. However, this API will probably change in Java 7 (since it's currently in a non-public package) and of course it doesn't exist on older versions of Java. If I want to compile this on an older VM (such as on my MacBook) then I simply can't call the API directly. Instead I'll use reflection and wrap it in a try catch block. I've created my own method called setAlpha(float) which will safely call the setWindowOpacity() method.

    private static void setAlpha(float alpha) {
        try {
            Window win = frame;
            //invoke AWTUtilities.setWindowOpacity(win, 0.0f);
            Class awtutil = Class.forName("com.sun.awt.AWTUtilities");
            Method setWindowOpaque = awtutil.getMethod("setWindowOpacity", Window.class, float.class);
            setWindowOpaque.invoke(null, win, (float)alpha);
        } catch (Exception ex) {
            //ex.printStackTrace();
        }
    }

Now, if the method doesn't exist at runtime because the user has an older version of Java then the exception will be caught and nothing will happen. It degrades gracefully.

Mac support

So what about the Mac? Well, Mac OS X doesn't have a version of Java SE 6 update 10 yet, however in Leopard they did introduce a new API for doing translucency. Using this new support we can add translucency on Mac with a single extra line. In the catch block above we can add this:

        } catch (Exception ex) {
            //ex.printStackTrace();
            frame.getRootPane().putClientProperty("Window.alpha", new Float(alpha));
        }

This sets a magic property on the rootpane of the frame called Window.alpha. Because this is a client property it will have no effect on other platforms that don't know about it. Again, degrading gracefully.

The fade effect

Now that we can make a window translucent lets do something interesting with it. I want the window to be mostly transparent, but whenever the mouse moves into the window I want to return to mostly opaque. So let's say the opacity will go from 0.5 to 0.9. I could set a mouse listener on the background of th window, but that wouldn't work on subcomponents. I could also put in a glasspane to check for mouse events, but then I would have to redispatch all events back down to the real components as I did in my book Swing Hacks. Very messy. Fortunately, as of Java 5, we have an easier method: just poll the global mouse position using the MouseInfo class. Here's a Runnable which does that:

    private static Runnable mouseWatcher = new Runnable() {

        public void run() {
            boolean previouslyInside = false;
            while (true) {
                try {
                    Thread.sleep(100);
                    Point pt = MouseInfo.getPointerInfo().getLocation();
                    boolean currentlyInside = frame.getBounds().contains(pt);
                    if (previouslyInside != currentlyInside) {
                        if (currentlyInside) {
                            setAlpha(0.9f);
                        } else {
                            setAlpha(0.5f);
                        }
                    }
                    previouslyInside = currentlyInside;

                } catch (InterruptedException ex) {
                    Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
                }
            }
        }
    };

The code above will check the mouse position ten times a second. If the mouse has moved in or out of the window then it changes the opacity. It's that simple.

Run the app

You can try the live application here. It will work on MacOSX 10.5 or Windows/Solaris/Linux if you have a recent beta of JavaSE 6 update 10. On older versions of Java 6 you won't get the translucency effect, but the app will still run.

That's all there is to it. This is just one of the many cool new features in JavaSE 6 update 10. Go check'em out then come back to my blog for more Java Doodles in the future.

References

• source to the app
• SDN article: How to Create Translucent and Shaped Windows
• JDK 6 update 10 b25
• new ui properties in Java for MacOSX Leopard
• Swing Hacks
• previous doodle: Java Doodle: crossdomain.xml Support

Java Doodle: crossdomain.xml Support

While we wait for the full JavaFX SDK to be released later this summer I'd like to show you some cool desktop Java things that you can do right now. This is the first in a series I'm going to call Java Doodles, highlighting the new features in JavaSE 6 update 10, now in beta. Join me over the coming weeks when we will explore more cool things you can do with desktop Java.

A photo applet

Above is a simple applet which loads the most recent photos from my Flickr stream. It's a very simple pure Java applet that's only 8k in size. This applet isn't interesting for what it does, but rather what for what it doesn't do. If you have JavaSE 6 update 10 then you won't see a security warning dialog, even though it's hosted on my personal server (not java.net) and it's connecting to Flickr.com. How this this possible?

The applet security model, known as the sandbox, only lets applets connect to the webserver they were loaded from. They cannot connect to anywhere else unless they are signed. Signing is great when you need access to more than what is allowed inside the sandbox, but it has two problems: the user will receive an ugly warning dialog about the applet, and the applet will have full access to the user's computer. Full access is overkill when all you want to do is talk to a webservice on another server. Surely there is some middle ground between the sandbox and full access? Well now there is.

crossdomain.xml support

If the server hosting a webservice has special xml file on it then the applet plugin will allow connections to that server. This special file is called a crossdomain.xml file and it must be present on the exact subdomain hosting the webservice. Here is the crossdomain.xml file for the Flickr server hosting the images:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Because Flickr wants people to build apps which connect to their webservices they have put a crossdomain.xml file on all of their domains which host webservices. The crossdomain.xml mechanism was originally designed for Flash applications, but with JavaSE 6 update 10 now Java apps can take advantage of these services too!

Degrading gracefully

So what happens if you don't have update 10? In a plain applet the connection to static.flickr.com would throw a security access exception. The applet has to be signed for that to work, but we don't want the applet to be signed in the update 10 case. The key to degrading gracefully is to have two sets of jars, one signed and the other unsigned, and use the new JNLP support to specify the update 10 version, falling back to the classic applet classpath for older JVMs. Here's how it works. In my webpage I put this applet tag:

<div id="applet">
    <applet code="photostrip.Applet"
            archive="http://projects.joshy.org/demos/PhotoStrip/webstart/PhotoStrip.jar"
            width="400" height="200"
            >
        <param name="jnlp_href" value="http://projects.joshy.org/demos/PhotoStrip/photostrip.jnlp">
        <param name="flickruser" value="31706743@N00"/>
        <param name="size" value="100"/>
        <param name="cols" value="4"/>
        <param name="rows" value="2"/>
    </applet>
</div>

then in the photostrip.jnlp file I put this

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="" href="">
    <information>
        <title>PhotoStrip</title>
        <vendor>Joshua Marinacci</vendor>
        <offline-allowed />
    </information>
    <resources>
        <j2se version="1.5+" href="http://java.sun.com/products/autodl/j2se" />
        <jar href="unsigned/PhotoStrip.jar" main="true" />
        <!-- Application Resources -->
    </resources>
  <applet-desc 
      name="PhotoStrip"
      main-class="photostrip.Applet"
      width="400"
      height="200">
  </applet-desc>
</jnlp>

The applet tag version uses the signed jar in the webstart directory. The JNLP version uses the unsigned jar in the unsigned directory. New JREs will use JNLP version without a warning dialog. Older JREs will use the applet tag version with the warning dialog. Using this simple method you can degrade gracefully in older JREs and browsers. In fact, you don't have to use this technique just for signing issues. The two jars could point to different versions of the app that turn on and off any of the other new JavaSE 6 update 10 features.

Going forward

With crossdomain.xml support in Java now all sorts of mashups become possible in applets without any jar signing at all. Here are a few other sites with crossdomain.xml supported webservices that you could connect to and do interesting things with.

• Twitter.com
• Yahoo
• Youtube
• Amazon
• MusicBrainz

For more information on crossdomain.xml support in JavaSE 6 update 10 see these references:

• JavaSE 6 update 10 plugin release notes
• crossdomain.xml on static.flickr.com
• Adobe's technote on crossdomain.xml files
• The Java bug report for adding crossdomain.xml support.

Source

Here is the source to the PhotoStrip application. You also need this bin directory which includes some extra Ant tasks for packaging.

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.

JavaOne video blogs with Rachel Hill

My first two video blogs with Rachel Hill are up. The first is a sneak peek of what's coming during my demo prep. The second is some excerpts from this mornings keynote, including the t-shirt hurling and Neil Young's Blu-Ray disk.

Stay tuned for more JavaOne excitement.

JavaFX.com

We launched JavaFX.com today. I'm very excited about this site since I was personally involved in putting it together. We have videos of the JavaFX demos from each keynote as well as explanations of what JavaFX is, where you can get more info, and a signup page to get the SDK when it's ready.

Okay, back into the fray. I'll see you tomorrow

My keynote demo

Well, the initial showing didn't go so well. The main parts worked but it crashed twice on stage when my boss demoed it. When we showed it again this afternoon and added Jabber support live, everything worked beautifully. I guess the demo gods were happy the second time around.

Hear me on RIA Weekly

I almost forgot in the rush up to JavaOne that I recently appeared (is that possible in an audio only podcast?) in lucky episode 13 of the RIA weekly. RIA Weekly is a podcast by Michael Cote of RedMonk and Ryan Stewart of Adobe. I talked about JavaOne, our general goals for JavaFX, how the pieces of JavaFX came together, and what it's like working on designer tools.

You can read the episode synopsis here or download the mp3 here. If you like the episode be sure to subscribe to the full RIA Weekly feed in iTunes.

JavaOne is like Christmas

You may be wondering why I haven't blogged recently, or why some of the JavaFX lists have died down, or more generally just what the heck we are all doing these days. Well, there's something you need to understand:

JavaOne is like Christmas

I do not mean 'like Christmas' in the kid sense of 'waking up and going downstairs to open presents'. Well, it is, but that's for you guys who watch or attend JavaOne. I mean JavaOne is 'like Christmas' in the sense of rushing around for two months before the big day. We plan, shop, wrap, prepare, cook, and travel in our mad but exciting efforts to put together a great event for you (even if you won't be there in person).

We have some really cool stuff in store. I just spent a few days down in LA with Chris Oliver and Ant working on some really great demos. Then there's articles, tutorials, samples, and much much more. Oh, and I have to finish my slides in there somewhere. The days before JavaOne are truly a colossal effort, but it's worth it when the big week arrives.

So when someone asks where we all are I'll just say: getting ready for Christmas.

At the speed of JavaFX

As we all rush headlong into JavaOne prep someone (okay it was James Gosling) sent me an email about performance of JavaFX. Speed is a crucial issue for anything dealing with user interfaces, so we care deeply about performance in our work with JavaFX. On the other hand we are focusing on bug fixes and correctness right now, not optimization, so it's not as fast as it could be.

So how do we fare?

Well, as a rough measurement, since there aren't any real benchmarks yet for rich internet applications, we have been using a website called BubbleMark, which has a simple graphics application written in many different languages/runtimes. It's the closest thing we have to a cross platform bench mark.

So, how do we fare?

James had this to say: "I just tried it on a MacPro running JDK6(developer preview 10) and the swing version runs at 198 fps with 32 balls, and the JavaFX version runs at 186 fps. Flex (cached) ran at 58...".

So JavaFX's graphics layer, built on the currently un-optimized SceneGraph library, is only a few percentage points behind the plain Java2D/Swing version, and they are both 3 to 4 times faster than the Flex version. Not bad!

July 2008

Search this blog:

Categories

Archives

July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
November 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003

Recent Entries

JavaFX Innovations: Inline Examples and Screenshots

Java Doodle: fading translucent windows, on PC & Mac

Java Doodle: crossdomain.xml Support

Articles

Mapping Mashups with the JXMapViewer
Having introduced SwingLabs' JXMapViewer and JXMapKit in a previous article, Joshua Marinacci puts these components to work by showing how you can bring in geographic data from external sources and use Painters to create custom geodata GUIs. Nov. 13, 2007

Building Maps into Your Swing Application with the JXMapViewer
Mapping is a common feature of many applications, and a new component from SwingLabs makes it easy to add maps to your Java GUI application. Joshua Marinacci shows you how to adding maps to your Swing app can be as simple as dropping a JXMapViewer component into a NetBeans layout. Oct. 30, 2007

Generating PDFs for Fun and Profit with Flying Saucer and iText
Generating PDFs used to require proprietary and/or difficult-to-use tools, but the combination of the Flying Saucer XHTML renderer and the iText PDF library makes it easy to generate PDFs from a variety of markup formats. Flying Saucer founder Joshua Marinacci shows how it's done. Jun. 26, 2007

All articles by Joshua Marinacci »

This work is licensed under a Creative Commons License.