I’m still marveling about the Treasure Island party. Terri Nunn of Berlin said that “Oracle gives the best f*****g corporate parties!” and she’s probably right. I have never been to a corporate party on this scale, well, except for last year’s Oracle party. In fact, I’ve never been to a party of any kind that big, ever.

There were almost too many bands. I would have liked to have seen the English Beat but they played early and by the time we got onto the island the set was almost over. We heard some of Berlin but we were trying to get food at the time. I caught most of Don Henley’s set, which was great. Like all of us, he’s getting older, but he seems to be taking care of his voice. He sounded pretty good. I popped over to see the Black Eyed Peas for a little bit, but I just don’t get them. I’m really out of touch. When people started talking about Fergie I thought “What does the Duchess of York have to do with this?”

* * *

Looks like highlights videos from the keynotes are up on the web now. Check out http://medianetwork.oracle.com and click on News and Events and then choose JavaOne or Oracle OpenWorld.

* * *

We had another fabulous lunch at Henry’s Hunan!

* * *

Today’s sessions included Hardcore CSS with Rich Bair and Jasper Potts. I knew most of this stuff since I did my share of work on it in JavaFX, and I wrote a bunch of the manual, but I wanted to be there and show support for the team. The power of using CSS to control region backgrounds and borders and shapes is really amazing and I give Rich and Jasper a lot of credit for thinking it up and implementing most of it.

I also attended Rich GUI Testing Made Easy given by my colleague Alex Ruiz and Yvonne Price. The talk was basically about using the FEST to test Swing GUIs. The code was a bit small to read but I picked up on a few key concepts.

The last session I attended was Concurrency Grab Bag by Sanjin Lee of eBay. This was a discussion of various concurrency issues and “gotchas” they’ve run into at eBay. I was familiar with most of the material already but it was good to see a treatment of the material rooted in practice, as compared to the somewhat more academic approach from people like Goetz and Lea. I’d have thought that the conference was winding down at that point, but the session was packed and there were lots of questions. In fact, I think this was a repeat performance of the talk. The earlier one was probably so popular that they had to schedule a repeat session. [Update: slides here.]

This session was in fact in the last session slot of the conference. The audio tech put on Scott McKenzie’s San Francisco (Be Sure to Wear Flowers in Your Hair) as people were leaving the room, which I thought was a nice touch.

* * *

I usually find the end of a conference a bit melancholy, as people drift away, take off early to catch their planes, leaving the final sessions sparsely attended and the conference center lonely and empty. This was a bit different. The conference hotels were as crowded as ever, buzzing with new batches of tourists, business travelers, airline staffs, etc. checking in.

Workers were scurrying about tearing down all the JavaOne and OpenWorld paraphernalia. A few JavaOne attendees were hanging around. It was pretty easy to spot them: developers’ sense of fashion contrasted sharply with the snappy Japanese airline crew uniforms and with the trendy European tourists. Oh, the laptops helped give it away too. I wandered around a bit longer but it was clear that there was nothing left for me to do but go home.

On that note it’s time for me to recap of my impressions of the conference.

This JavaOne was unique in many ways, not only because it was the first run by Oracle, but because it was the first not in Moscone. Sure, there were activities and events and keynotes at Moscone, but those were primarily OpenWorld events. JavaOne itself took place in two conference hotels, the Hilton Union Square and the Parc 55. (The third conference hotel, the Nikko, seemed dedicated to Oracle Develop sessions.)

I have to say that I didn’t like having the conference in the hotels. Even within the same hotel, the rooms were fairly spread out. Then there was the matter of getting between the hotels. It seemed like you were forever going through the back door to get in. At the Hilton, you either walked in through the garage or you used the employee entrance! (But the latter made it easy to punch your Hilton employee time card on the way to the next session.) The hallways were narrow and between sessions they were quite crowded with people trying to get from one area to another.

The rooms were all too small and so they filled up quickly — too quickly. As an Oracle employee I couldn’t reserve places in the session rooms. This was irritating but understandable — paid conference attendees should indeed have priority. But I also heard that even paid attendees had trouble getting in. Some popular sessions were filled even before the conference started.

Since the conference was spread out, there were no obvious gathering places like there were in Moscone, like the movie/game area upstairs in Moscone South or the beanbag area downstairs in Moscone North. If you hung out in one of those places for a few minutes, you’d be guaranteed to see someone you knew and hadn’t seen since last year’s conference. This kind of networking is what conferences are all about! In the hotel setup, the foot traffic all led through various rabbit warrens of corridors, so there was no central gathering place or main artery of traffic. Things just seemed all scattered and disorganized and it was really hard to find people. There were people I knew were at the conference, but I just never ran into them. That didn’t seem to happen before.

It’s not at all clear to me that there is any benefit of combining OpenWorld and Oracle Develop with JavaOne. (With the possible exception of JavaOne attendees getting to attend the Treasure Island event.) I don’t know if there was any cross-pollination. The only JavaOne things at Moscone were a couple keynotes; everything else there was OpenWorld stuff the suits attended. Also, as I mentioned, Oracle Develop seemed segregated in the Nikko. The only effect that combining the conferences had was to make things more crowded and expensive and to push JavaOne out of Moscone.

The technical program seemed a little flat as well this year. Maybe this was because there were some talks I wasn’t able to attend because they were full. It also might have been because of Google’s last-minute pullout. I heard they had 13 sesssions and 6 BOFs. But I also think it’s because of a development slowdown caused by the waning days of Sun and the transition to Oracle. It took a lot of energy to get through that, and a lot of people left before and during the transition, so that took away from developing stuff that could have been presented at the conference. A lot of plans and roadmaps were announced, and there seems to be renewed momentum around Java development at Oracle, so let’s hope this will lead to more material for next year’s program.

* * *

I attended a Java Desktop lunch at Anzu. There were about 30 people there, including lots of FX folks, but also lots of others, including a special surprise appearance from James Gosling! James isn’t officially at the conference but is hanging around and meeting with lots of people. After his departure from Oracle he’s turned into a bit of a rabble rouser. See his eWeek interview for example.

* * *

Stephen Chin and Dean Iverson had a BOF on JFXtras. Historically the role of the JFXtras project has been to fill in the gaps and to add “extra” features that aren’t in the core JavaFX platform. With the transition of JavaFX from JavaFX Script to Java as the main API and implementation language, the role of the JFXtras project will change. Specifically, Steve announced an initiative to continue the development and evolution of the JavaFX Script language in open source, and eventually to rehost it on top of the new Java-based JavaFX APIs when they are delivered. Steve already has a grab bag of features he wants to add to the language, such as a map type and the ability to bind over a key in a map (even if it’s not yet present in the map). Steve’s provisional name for the project is “Visage.” He doesn’t have a site up yet for this effort, but keep an eye on his blog. I’ll update this post with links when they become available.

* * *

Kevin Rushforth and Jim Graham gave a talk on JavaFX Graphics. They gave an overview of the scene graph along with some information about JavaFX 3D capabilities that will be in the next release. They had some cool demos too, including a few snippets and behind-the-scenes information about the FX demo that was shown during Thomas Kurian’s JavaOne keynote. Kevin and Jim also showed some other, more pedestrian demos, some of which were based on my Flood Game sample program. Thanks for the shout-out, Kevin!

* * *

Of course, no JavaOne day 3 update would be complete without a description of the Oracle Appreciation party (“Rockopolis”) on Treasure Island. This is really part of Oracle OpenWorld, and one of the advantages of JavaOne being combined with OpenWorld is that JavaOne attendees get to partake of the Big Event. This year the top acts included Don Henley, the Black-Eyed Peas, the English Beat, and Steve Miller.

Now, officially this event is for Oracle customers and partners, not employees. The employee speaker badges don’t include tickets for the event, but it turned out that there were some extra tickets available so most of my team was able to go. In addition, a lot of regular (non-employee) conference attendees didn’t actually want to go, so that made more tickets available. Finally, through some … connections … several of us were able to score VIP tickets, which promised better food, shorter lines, and special reserved areas near the stages. Fortunately, I remembered to bring earplugs!

There was even a black market for the tickets. I heard that they were going on Craigslist for $100. Not too surprising really, since the ticket included free food and drinks, carnival games and rides, and six A-list musical groups. (No, I didn’t participate in the black market!)

Really the Treasure Island event was quite a spectacle. As I described last year, it was pretty much like an entire county fair that had been set up for one day. Truly amazing.

Actually, the real big news so far is the demise of JavaFX Script. The reviews from the blogosphere/twittersphere are mixed. Some people are loving it. Indeed, one of the comments I received on my JavaFX Script talk from last year’s JavaOne was “It’s beyond me why anyone would create such a language.” People such as this commenter are perhaps glad to see JavaFX Script go away.

On the other hand, there is also some disappointment, some criticism, some mourning, and even some denial. But this is the price — or perhaps the cost — of progress. (But see also below.)

There’s been some misinformation floating around the twittersphere about “JavaFX is dead” and some such. This is decidedly not the case. JavaFX Script is indeed on its way out (though existing programs will still run for a while, and you can still develop new ones, should you decide to do such a thing) but JavaFX itself is most definitely alive and will continue develop. Here’s a clarifying statement from the JavaFX Architect, Richard Bair (what Mr. Bair meant to say was…) about the changes coming in JavaFX 2.0:

http://fxexperience.com/2010/09/javafx-2-0/

Also, the official JavaFX roadmap statement is here:

http://javafx.com/roadmap

* * *

The talk I gave this morning (along with my colleague, Paru Somashekar) was on JavaFX UI Controls. Originally we were going to present a lot more code examples, but with the move away from JavaFX Script we had to retool the talk. In the end we showed a survey of the controls and some demos of the controls in action but relatively little code. We did do a small comparison of JavaFX Script to a new, provisional Java-based API for JavaFX. Overall the talk was well attended (better than I expected for an 8am tech session!) and I thought it was a success.

One questioner at the session criticized the dropping of support for JavaFX Script and in particular its declarative syntax. He was very polite, apologizing for making a statement instead of a question and also for shooting the messenger. I didn’t get a chance to talk to the gentleman, but I wanted to say that I wasn’t offended by his comment. On the JavaFX team we knew that dropping JavaFX Script would be painful for some. Anyone who’s affected needs to speak out about it. I don’t think the decision will be reversed but it might be possible for those impact to get some help with migration.

* * *

We had a great lunch at Henry’s Hunan. I’m still full. Oh, well there was also that big cookie I had during the afternoon break.

* * *

It’s a bit odd not being in Moscone. Unlike I think all prior JavaOnes, this year JavaOne is in a trio of hotels: the SF Hilton, Hotel Nikko, and the Parc 55. The hotel meeting rooms are smaller, so they fill up sooner, and in general Oracle employees (such as myself) can only get in if there’s space available — which there often is not. As a result I’ve been unable to get into a few sessions that I wanted to attend. Oh well, I’ll have to pick up the presentation slides later on. But, who am I to complain?

* * *

This evening I’m attending a few BOFs: on Jigsaw, OpenJDK, and on Visual Design with CSS. After that I’ll head home, attempting not to fall asleep during the drive, and fall into bed at the end of a very long day.

The first, easy answer is that you can often avoid the need for listeners by binding to the state of the control. Let’s consider a simple CheckBox example. Suppose you wanted to change the visibility of something based on whether the checkbox is selected. In Swing, you’d do something like adding an item listener to the checkbox, and when it got called, you’d look in the event to see which checkbox got changed and whether it was selected or deselected, and then modify the visibility of your component (or whatever) accordingly.

In JavaFX, you’d do something kind of the opposite. Instead of having a listener get called that “pushes” the side effect of the checkbox state change into some target object, you’d instead bind the “visible” state of the target object to the selected state of the checkbox. Here’s how:

var cb:CheckBox;

Stage {
    scene: Scene {
        content: [
            HBox {
                spacing: 10
                padding: Insets { top: 10 right: 10 bottom: 10 left: 10 }
                content: [
                    cb = CheckBox {
                        text: "Check Me!"
                        selected: true
                    }
                    Label {
                        text: "sample label text"
                        visible: bind cb.selected
                    }
                ]
            }
        ]
    }
}

The bind-expression makes sure that the Label’s “visible” variable will always track the state of the CheckBox, and so the Label will appear and disappear as you check and uncheck the CheckBox. Simple.

This is all well and good if your situation calls for some state to be updated when the CheckBox changes state, and the update computation is something simple enough to be written using a bind-expression. But what if you have some kind of process that you need to perform, say, one that requires having some function called. Wouldn’t you need a listener? Yes, but it’s fairly simple to construct your own.

Like many languages, JavaFX Script has block structure, where any code block “{ … }” can declare local variables that are scoped to that block (i.e., they are not visible outside that block). It’s also legal to declare local variables within the “{ … }” of an object literal, even though it’s a syntactically different construct from a code block. What’s not very well known is that it’s also possible to override variables of the class you’re instantiating. By itself, overriding a variable doesn’t let you do much except to override the initial value of a variable. Since this is already within an object literal, you’re providing initial values already, so what’s the point? Overriding useful because it provides a point of (re)declaration of the variable where you can supply an “on replace” trigger. This is code that gets called whenever the value is changed … just like a listener!

Let’s try this out. Instead of just toggling the visibility of the label, let’s toggle a timeline that rotates it:

Stage {
    scene: Scene {
        content: [
            HBox {
                spacing: 10
                padding: Insets { top: 10 right: 10 bottom: 10 left: 10 }
                content: [
                    CheckBox {
                        text: "Check Me!"
                        override var selected on replace {
                            if (selected) tl.play() else tl.pause();
                        }
                    }
                    label = Label {
                        text: "sample label text"
                    }
                ]
            }
        ]
    }
}

var tl = Timeline {
    repeatCount: Timeline.INDEFINITE
    keyFrames: [
        at (2s) {
            label.rotate => 360
        }
    ]
}

(See Footnote 1.)

This is a little non-obvious but it works quite well.

Now, there’s a problem with this technique. In order to override a variable, that variable must be public. Let’s say that we wanted to create a ListView and create the equivalent of a listener that gets called whenever the selection changes. We’ll just do this, right?

ListView {
    items: [ "One", "Two", "Three" ]
    override var selectedItem on replace {
        println("selection is now {selectedItem}"); // ERROR
    }
}

Oh no, this doesn’t work! The “selectedItem” variable isn’t public, it’s public-read. (Why? See Footnote 2.) This is a bit of a pain to work around. We cannot override public-read variables, but we can still bind to them. This means we can use the foreign trigger idiom to create a new variable that tracks the value of the variable we’re interested in, and then add a trigger to our new variable. Here’s how:

var list = ListView {
    items: [ "One", "Two", "Three" ]
    var sel = bind list.selectedItem on replace {
        println("selection is now {sel}");
    }
}

This is fairly cumbersome, since we have to create and name a new local variable and hang our “listener” code there, and we have to make sure the ListView is accessible to it via a named variable. This is probably about as much boilerplate as adding a listener using an anonymous class in Java. Still, we’re used to much more concise syntax in JavaFX Script. It’d probably be nicer to have a function variable such as “onSelectionChanged” whose value is a function that gets called when the ListView’s selection changes. Adding callback APIs like this hasn’t been a very high priority up until now, though, since it’s possible (if inconvenient) to use the controls without them using the bind or override-and-bind-with-trigger techniques. We’re definitely considering adding them, though, since it makes the API much more approachable.

Footnote 1. This is a bit sloppy. Those of you who compile this code will note that the “label.rotate => 360″ line gets a compiler warning to the effect that “label is not a constant but will be treated as such”. This means that, at the time the KeyFrame object of the Timeline is created, a snapshot of the current value of “label” is taken and stored within the KeyFrame. This means that “label” needs to have been initialized to the right value before the Timeline and KeyFrame are created. In fact, I first created the Timeline above the Stage/Scene/HBox hierarchy, and the animation didn’t work! Moving it below makes it work, but the compiler still issues the warning. ↩

Footnote 2. Why are selectedItem and selectedIndex public-read instead of public? If they were both public, the implementation would have to have triggers to handle the cases where the application wrote to them. Each trigger would have to write to the other variable, which in turn would invoke its trigger. This doesn’t cause infinite recursion, though, since the trigger won’t fire if the variable is set to a value equal to its current value. But it’s still a pain. Oh, another problem is, what if the application set selectedItem to an object that’s not a member of the ListView? The trigger would have to set the variable back to a legal value, and add a flag to avoid recursive trigger invocation as noted here. (Also note that Toggle.selected and ToggleGroup.selectedToggle are both public and have this problem. Trust me, dealing with this kind of situation is a real pain.) ↩

http://java.sun.com/javafx/1.3/docs/api/

Probably the most significant change is the addition of a new CSS Reference Guide. This document is linked from the javafx.scene package docs and from the Scene and Node class docs, but it’s actually a bit hard to find. For your convenience, the direct link is here:

http://java.sun.com/javafx/1.3/docs/api/javafx.scene/doc-files/cssref.html

You’ll probably want to bookmark it. A lot of the information is out there already, having been derived from the examples in the caspian.css file (which is included in one of the jar files in the SDK). The styles in caspian.css show a lot of what you can do with CSS in JavaFX. However, even caspian.css doesn’t show everything that you can do with CSS. The CSS Reference Guide is comprehensive. For instance, check out all of what you can do with a Region using CSS. Or, take a look at all the properties of charts you can customize. There’s really a lot in there.

I’ll post some examples later. Meanwhile, dive in and enjoy!

.scene {
    -fx-background: cornflowerblue;
    /* ... */
}

There have been a bunch of questions about this, for example in the forum threads here and here, and in comments at the bottom of the Applying CSS to UI Controls tutorial. People are tinkering with this rule and it’s not working the way they expect. The pieces of this part of the system fit together in funny ways, so I certainly can see why there’s lots of confusion. Let’s dive in.

First, let’s create a simple scene:

Stage {
    scene: Scene {
        width: 150
        height: 150
        stylesheets: "{__DIR__}styles.css"
        content: [
            Rectangle { x: 50 y: 50 width: 50 height: 50 }
        ]
    }
}

Now let’s try to style the scene. The various examples use the -fx-background and -fx-fill properties. Which one is correct? Let’s try both, using different colors so that we can tell which one took effect. Place the following into the styles.css file:

.scene {
    -fx-background: cornflowerblue;
    -fx-fill: orchid;
}

What happens? Basically, nothing. We get a black rectangle on a white background, just as if we hadn’t specified any CSS at all.

Well, that sucks.

The main problem is that Scene objects don’t have any CSS-settable attributes. There are a couple things on Scene that seem like they ought to be settable from CSS, such as the fill and cursor variables. But they don’t work, and that’s a bug. See JIRA issue RT-8653. If you want to set the background color of a Scene, you have to use a rectangle or ScrollView and style that instead. See Dean Iverson’s article Into the Background which covers this pretty well.

If a style rule for “.scene” doesn’t apply any properties to the Scene, what does it do? Let’s first examine an assumption here, which is that a style rule with “.scene” actually applies to Scene objects. This is a reasonable assumption because we’ve set things up for the controls so that “.button” styles apply to Button, “.slider” styles apply to Slider, and so forth. This convention that applies to the controls, but it doesn’t apply everywhere. You can’t, for instance, declare a style rule for “.rectangle” and expect it to apply to all Rectangle objects. Try it! It doesn’t work. To style a Rectangle, you have to give it a styleClass value and then use that in your CSS. For example:

// Main.fx
Rectangle { styleClass: "myrect" ... }

// styles.css
.myrect { -fx-fill: dodgerblue; }

gives the following result:

Now back to Scene. If the “.scene” styles don’t apply to Scene objects, what do they apply to?

Let’s examine a little puzzle in the scene graph API. The scene graph is a tree of nodes, and all trees have a root. Every Node has a parent variable, which is of type Parent (a subclass of Node). If you walk up the scene graph following the parent variable, you’ll eventually get to the root. That’s the Scene, right? But it can’t be, because a Scene isn’t a Node. What is the root Node then? Let’s find out.

var rect:Rectangle;
...
Stage {
    scene: Scene {
        ...
        content: [
            rect = Rectangle {
                styleClass: "myrect"
                x: 50 y: 50 width: 50 height: 50
            }
        ]
    }
}

println("parent={rect.parent}");
// and while we're at it
println("styleClass={rect.parent.styleClass}");

The output will be something like this:

parent=Scene$Root@27d314cc
styleClass=scene

Whoa, what’s that? Inside of every Scene, there’s a hidden node called Scene$Root that’s the parent of every Node in the Scene’s content sequence. It’s a subclass of Parent. It’s the actual root node of the scene graph. And, most importantly for this discussion, it handles CSS on behalf of the Scene. Indeed, its styleClass is “scene”. So, style rules that use “.scene” as their selector are really applying styles to this hidden Scene$Root object.

We’re a little closer, since we now know that “.scene” styles apply to the Scene$Root object and not the Scene object itself. But Scene$Root doesn’t actually have any properties that are affected by CSS. What good does it do to set properties on Scene$Root if they don’t actually affect it?

To understand what’s going on, we have to talk about two features of CSS. First, a feature of JavaFX CSS is that colors can be specified not only using standard color names such as “dodgerblue” or by using RGB syntax like “#0093ff”, but they also can also be looked up by name using properties defined by styles above them in the hierarchy.  Second, as in standard CSS, some properties are inherited. Let’s examine these features in more detail.

Color Lookup

Continuing with the simple rectangle example from above, let’s define style rule for .scene that defines some new color names:

.scene {
    -smarks-special-fill-color: #40d080;
    -smarks-special-border-color: #d02040;
}

I just made up the property names -smarks-special-fill-color and -smarks-special-border color. They don’t exist anywhere else, and merely setting these properties won’t have any effect on anything. However, the property names and values are applied to Scene$Root, so we can put them to use. Define

.myrect {
    -fx-fill: -smarks-special-fill-color;
    -fx-stroke: -smarks-special-border-color;
    -fx-stroke-width: 5;
}

(I also made the stroke width thicker so that it’s easier to see the border.) The result is as follows:

This works because in JavaFX CSS, you can use an arbitrary property name as the value for a color property. This property name is looked up on all ancestor nodes, and if a value is found, that color is used in its place.

Now, I could have specified those colors directly in the .myrect rule and it would have worked just fine. However, if I had several different style rules (say, for different shapes) that wanted to use the same colors, I’d have those color values spread around in a bunch of different rules in my style sheet. If I wanted to change a color, I’d have to change it in several places. Since the Scene$Root node is the ancestor of every node that appears in any Scene, and since its styleClass is “scene”, I can place some color definitions in the “.scene” style rule and they’ll be visible to be looked up from any node in the scene graph. The “.scene” style is thus about as close as we can get to a global repository of color properties. Indeed, if you look at the “.scene” rule from the caspian.css file, just about all if its declarations are for color properties.

Inheritance

Let’s change the scene’s content to have some Text nodes in order to show inheritance of font properties:

content: [
    Text { x: 30 y:  60 content: "Hello, JavaFX!" }
    Text { x: 30 y: 100 content: "CSS is fun!" }
]

This will use the default font, which will give a result like this:

Now let’s modify the .scene style rule as follows:

.scene {
    -fx-font: 18pt "Times-Italic";
}

The result will change to the following:

Why did this have an effect? The reason is that, as in standard CSS, font properties are inherited down the hierarchy. More precisely, if a font value isn’t provided for a particular node, the font property is looked up in ancestor nodes until a value is found. Since Scene$Root is at the root of the hierarchy, and the “.scene” properties have been applied to it, the font defined there ends up being used by the Text nodes. Of course, I could override the font by specifying a font value directly in the code, or by creating a style with a font property and arranging for it to apply to the Text nodes or to an ancestor. Since I didn’t do that, the font property from the “.scene” rule applies. It’s effectively a specification of the default font to be used everywhere in the scene graph.

In summary, the “.scene” style rule doesn’t apply properties to the Scene itself (though maybe it should). Instead, it stores properties on the Scene$Root node. These properties aren’t used directly, but can be inherited (for fonts) and can be looked up (for colors) by nodes anywhere in the scene graph. Thus, the “.scene” style rule is where global color and font properties can be defined, which makes it easier to develop and maintain consistent style sheets.

Time and location information is available at the SVJUGFX website. If you’re not in the SF Bay Area, a webcast will also be available. Information is at that link.

I’ve posted the presentation materials on my website here. They’ll be helpful if you miss the talk and want to review it, or if you’re watching remotely and want to follow along (or read ahead).

See you there!

JavaFX Script is a strongly-typed language. You don’t have to declare types everywhere; usually the compiler can infer the right type based on usage. For example, in the following:

var msg = "Hello";

The msg variable is of type String. Occasionally the compiler won’t be able to infer a type, in which case it will issue an error message, and you’ll have to declare the type explicitly.

Now, what’s the return type of a function? If you don’t declare the return type in the function declaration, the function’s return type will be the type of the last expression in the function body. (Also, the return value will be the value of that expression.) This is often just fine. For example,

function getMessage(count:Integer) {
    def verb = if (count == 1) "is" else "are";
    def suffix = if (count == 1) "" else "s";
    "There {verb} {count} item{suffix}."
}

The return type is clearly String. You can use the return statement to return a value from a function, but you don’t have to.

Unfortunately this isn’t documented very well at all in the JavaFX Script Language Reference. The section on function return type inference is extremely short, and I’ve quoted it below in its entirety.

Type inferencing can generally determine the return type of a function. In most cases the parameter types can be determined by type inference as well.

However, functions which, by virtue of their access modifiers, are visible outside the script should be explicitly typed.

[To do: detail on type inference]

The advice about explicitly declaring the return type is a good one, but it doesn’t explain why. I’d prefer a stronger rule and say, always declare the return types of functions.

Functions are used for different purposes. Sometimes they’re used to compute a value and return it to the caller. Other times they contain sequences of statements that mutate state, but that do not return any value. Some languages, such as Pascal, distinguish between these cases by calling them different things: a function must return a value, whereas a procedure cannot return a value. In Java, all methods are declared the same way, but the return type must always be declared. A Java “procedure” returns no value and has a return type of void.

If you want to write a “procedure” in JavaFX Script, you can just declare its return type to be void. But why bother, since the compiler will infer the type for you? The last expression in the procedure might have some value. The compiler will return that value, and use its type, even if you didn’t want to return a value. Consider a banking application. You might want to allow someone to have deposit-only access to an account, but not allow them to make withdrawals or to check the balance. You might code up the interface like this:

function makeDeposit(amount:Number) {
    balance += amount;
}

Whoops! The compiler inferred a return type of Number, and you just leaked the account balance. The obvious fix is:

function makeDeposit(amount:Number):Void { ... }

Function return type inference can have some surprising effects, especially in the presence of subclassing and overriding. Consider the following example:

class A {
    var count:Integer;
    var status:String;

    function update() {
        count++;
        status = "update() was called {count} times";
        println(status);
    }

    function doSomething() {
        // other stuff
        update()
    }
}

class B extends A {
    var subCount:Integer;

    override function doSomething() {
        // more stuff
        super.doSomething();
        subCount++;
    }
}

This works fine. Oh, you left a debugging println in A.update()… just take it out. The compiler now gives you an error, complaining about incompatible types at the end of B.doSomething(). Whut??

The return type of B.doSomething() should be Integer, since the last expression in the body is an Integer. Since it’s an override, it has to match the return type of A.doSomething(). What’s that? Well, it’s inferred from the return type of A.update(). Now, in the original code, the last expression in A.update() is a println(), which is one of the few things in JavaFX Script that has a return type of void. So that’s the return type of A.update(). When you removed the println, the last expression became a String and thus the return type of A.update(). That also affected the inferred return type of A.doSomething(), which also became String, which caused the mismatch with B.doSomething().

The fix here is to declare the return types for A.update() and A.doSomething() explicitly to be Void. It might also be reasonable to declare the return type for B.doSomething(). In this case it’s less important, though. The return type of an overriding function is determined by the type of the function being overridden, so the type won’t be inferred from the last expression in the body. Even though the last expression in B.doSomething() is an Integer, its return type must always match that of A.doSomething(). It’s good documentation to put in the return type, so you don’t have to go hunting through other source files to find out what it is. The compiler will flag an error if there’s a mismatch.

Like I said above, always declare the return types of functions.

We’ve decided that when a node is added to a group, that node is automatically removed from the group that previously owned it, if any. (Let’s call this the “auto-remove” feature.) We’ve also decided to turn off the warning message by default, but to have it be enabled optionally, possibly via a system property, for debugging purposes. Finally, we’ve relaxed the enforcement of some scene graph invariants in cases where the group’s content sequence is bound.

What’s the big deal? Well, there were a bunch of things pulling us in different directions. During the development of 1.2, we added code to prevent nodes from appearing more than once in the scene graph or creating cycles in the scene graph. One case in particular caused us a lot of trouble: adding a node to a group while the node was already a member of another group. We fully intended to disallow this case, and require that code remove a node from its old group before adding it to the new one. Unfortunately this caused a lot of our internal code to break. In versions 1.1 and prior, auto-remove was the specified behavior, and a surprising amount of code relied on this. Given the number of cases we ran across internally, we were sure that this would break a lot of external code. For this reason we decided to relax the restriction for this particular case, continue the auto-remove behavior temporarily, and issue a warning message instead. In a subsequent release, we were going to change the warning to an error and to remove auto-remove behavior.

During the development of our current release, we kept running into this issue. A couple of us wrote code that we thought was reasonable, yet it surprised us when the warning message came out! We had a few hallway conversations from time to time, but a clear-cut answer never emerged. Finally, we realized that we had to get the interested parties in a room and have a knock-down, drag-out meeting to resolve the issue. And so on October 7, 2009, Amy Fowler, Kevin Rushforth, Richard Bair, and I got into a conference room to decide the issue. Three hours later — with no breaks! — we had decided. Actually, it was a great meeting, without a lot of conflict. There were just a lot of issues to cover. Each of us came into the meeting with our initial opinions, but the issues were so close that I think each one of us switched sides at least once during the meeting.

Obviously I can’t reproduce the entire discussion here, but the gist of the arguments went something like this:

1. It’s simpler, more efficient, and more consistent to disallow auto-remove.
2. On the other hand, 1.1 allowed auto-remove, so this is incompatible.
3. On the third hand, we expect people to set up scene graphs at initialization time and modify nodes in-place, instead of doing scene graph surgery.
4. On the gripping hand, some applications really do need to move nodes around in the scene graph.
5. Well, that’s not too difficult, just remove the node from the old group first.
6. Sometimes (especially with bind) it’s difficult or even impossible to remove the node from the old group first.
7. But most of the cases we’ve seen with bind are actually poor coding practices that we want to have emit a warning message.

And so on, back and forth, and around in circles.

Let’s start off with the topic of moving nodes around within the scene graph. What’s the problem? Suppose you have a node n that you wanted to insert into group g. If you do this:

insert n into g.content;

This might generate the warning message if n were already a member of another Group. To avoid this, you’d have to do:

if (n.parent instanceof Group) {
    delete n from (n.parent as Group).content;
}

This is a bit subtle but overall pretty straightforward. First we have to test that n.parent is a Group. (It might be a CustomNode instead.) Note also that if n has no parent, n.parent will be null and the instanceof test will fail. If the test succeeds, we can cast n.parent to a Group and then remove n from the content variable. This is a bit inconvenient but not too bad. We could wrap this up in a nice function and use it in a bunch of places. We even considered adding a utility function to the scene graph to handle this.

Things start to get hairy, though, when when you add bind into the mix. What are people doing with bind that makes it difficult or impossible to remove the node from the old group first? Which uses of bind are “poor coding practices” and which are legitimate?

In order to answer these questions, we’ll need to review the semantics of bind. Consider the following:

var p = bind q + r;

If either q or r changes, the expression is recomputed and assigned to p. The rule is that only the subtree of the expression affected by the variable change is re-evaluated. So if q changes, r isn’t recomputed, and instead its saved value is added to q to get the result that’s then assigned to p. This is hard to see if q and r are simple variables, so let’s make the expression a bit more complicated:

var p = bind f(q) + g(r);

where f() and g() are functions. In this expression, if q changes, f() is called with the new value of q, as one would expect. However, the function g() is not called again. Instead, the saved value of the previous call to g(r) is used, added to the new value of f(q), giving the result assigned to p. You can see this by putting println() statements into f() and g() to see when they’re called. Try it!

Now let’s throw an object literal into the expression:

var xval:Number = ...;
var yval:Number = ...;
var p = bind Point2D { x: f(xval) y: g(yval) };

What does this do? Initially it calls f(xval) and g(yval), then creates a new Point2D instance and initializes its x and y variables to the values obtained by calling the functions. Now suppose xval changes.  Naturally f(xval) has to be called again; as before, the saved value of g(yval) is used and function g() isn’t called again. These values are then used to construct a new instance of a Point2D, which is then assigned to p. What happens to the old instance? Well, it still exists (probably) but if it’s no longer referenced, it’ll eventually get garbage collected.

The important point here is that an object literal is an expression that creates a new instance of an object, not unlike calling a constructor. It’s kind of similar to something like this:

var p = new Point2D(f(xval), g(yval));

except that Point2D, being a JavaFX class, doesn’t actually have a (Number, Number) constructor.

Usually we don’t want to create new instances of objects when the bind-expression is re-evaluated. In some sense we might prefer to do something like this:

var p = Point2D { x: bind f(xval) y: bind g(yval) };

Instead of creating a new Point2D object each time xval or yval changes, it would create one object and mutate its variables in-place. This doesn’t work though, since the x and y variables of Point2D are public-init. To bind to a variable initializer in an object literal, that variable must be declared public so that code outside the class can modify it. So if you want to bind something that has type Point2D, you always end up creating new instances.

Most scene graph objects have public variables that can be bound. Consider this:

var rect = Rectangle {
    x: bind xval
    y: bind yval
    width: bind wval
    height: bind hval
};

This works quite nicely. One Rectangle instance is created and assigned to rect. If any of xval, yval, wval, or hval change, the variables in that single Rectangle instance are mutated, and the effect is that the Rectangle moves or changes size in-place in the scene graph. In turn, if you hook these values up to a Timeline or to one of the Transition classes, that’s how you get animations.

Now instead of writing all those binds, couldn’t we just do this?

var rect = bind Rectangle {
    x: xval
    y: yval
    width: wval
    height: hval
};

We could write this, and it would work, in that we’d get a Rectangle animating in the proper way. But it’s enormously wasteful. Each time any of xval, yval, wval, or hval changes, a new Rectangle instance is created and the old one is thrown away.

It gets worse.

var g = Group {
    content: bind [
        Rectangle {
            x: xval
            y: yval
            width: wval
            height: hval
        }
    ]
];

Now, when any of xval, yval, wval, or hval changes, a new Rectangle is created. Then, because the content sequence of the Group is bound, the old Rectangle is removed from the scene graph and the new Rectangle is inserted in its place. It’s quite common for an operation to change both the width and height of the Rectangle, by changing wval and hval. Let’s say wval changes first. This creates a new Rectangle and replaces the old Rectangle. Then, hval changes, and another new Rectangle is created and replaces the one that had just been created. Furthermore, replacing things in the scene graph is more expensive than moving pointers around. Additional calculations occur, such as recomputing bounds, invalidating and caching transformations, etc. Some of this can be done lazily (indeed, in the next release, more of it will be). But it’s undeniable that creating new objects, generating lots of garbage, and doing scene graph surgery because of where a bind is placed, is very expensive. It would be a lot more efficient to rewrite the above code like so:

var g = Group {
    content: [
        Rectangle {
            x: bind xval
            y: bind yval
            width: bind wval
            height: bind hval
        }
    ]
};

This mutates the Rectangle in-place, doesn’t generate any garbage, and doesn’t do any scene graph surgery. We’ve improved the efficiency of some of our code quite significantly just by moving bind around.

Now, what does this have to do with the auto-remove behavior that we’ve been debating? Let’s take a look at this variation:

var g = bind Group {
    rotate: angle
    content: [
        Rectangle {
            x: xval
            y: yval
            width: wval
            height: hval
        }
    ]
};

Note that the bind is outside the group. This might look convenient, since the scene graph will automatically be updated if any of angle, xval, yval, wval, or hval is modified. But look carefully: suppose that the value of angle changes. Since it’s inside the Group object literal, a new Group object is created and its rotate variable is set to the new the new value of angle. There’s no need to create another Rectangle object, though, since none of its values have changed. Instead, the same Rectangle object is placed into the content variable of the new Group, which is then assigned to g. The old Group is unreferenced and will eventually be garbage collected. Now, who removes the Rectangle from the old Group? Aha!

This is where the auto-remove issue comes up. In the above code fragment, changing the value of angle causes the same Rectangle instance to be placed into the new Group, but it’s not removed from the old Group. As I mentioned previously, in release 1.1 auto-remove was the specified behavior, so placing the Rectangle into the new Group would automatically and silently remove it from the old Group. Furthermore, there’s really no way for application code to get in there and remove the Rectangle from the old Group first; the bind processing pretty much happens all at once. This would seem to be an argument in favor of auto-remove.

But wait, this code is pretty wasteful. It turns out that the auto-remove warning message was actually pretty useful, since it pointed out a bunch of places in our code where we were doing stuff like this: generating useless garbage and performing wasteful scene graph surgery. We ended up rewriting the code along these lines:

var g = Group {
    rotate: bind angle
    content: [
        Rectangle {
            x: bind xval
            y: bind yval
            width: bind wval
            height: bind hval
        }
    ]
};

True, we had to write bind five times. But this made things much more efficient, since it didn’t create any excess objects and it avoided doing any scene graph surgery. It also got rid of the warning message! So that convinced us to leave the warning message in, to get people to fix their bad code, and eventually to turn the warning into an error and effectively disallow auto-remove.

Or did it?

Customer Appreciation Event (evening Wed Oct 14)

As a speaker I received a full conference pass, including a pass for the big party on Treasure Island. This was quite a privilege, as apparently Oracle employees (not even speakers) don’t get to go to this party.

[7:30pm] Hundreds of people are lined up to take chartered buses to Treasure Island. There’s apparently no parking there so buses and cabs and taxis are the only way for party guests on and off the island. We arrive and the place is big. Staggeringly big. Mind-bogglingly big. It’s like they’ve set up a county fair here for just one evening. There are two big tents each with several  buffets, rows of booths with more food, more booths with an open bar, carnival midway games (ball tossing, whack a mole, darts etc.) with stuffed animals as giveaways, and carnival rides like a ferris wheel, a drop tower, swing carousel, etc. Oh, and then there was the music.

[9:15pm] Aerosmith arrives onstage at the outdoor theater. There are probably a couple thousand people standing in an open area in front of the stage, and there are a couple thousand more in bleacher seats around them. The bleachers are pretty tall, maybe 40 rows high. They even have luxury boxes at the top, for the conference sponsors of course.

There was more music than talk, but here are some choice quotes from banter with the audience:

We almost didn’t make it tonight, not because of the [B.S.] you heard about in the press, but because of some Mac event. But when we had to choose between Apples and Oracles we knew we made the right choice. — Steven Tyler

What’s the difference between Windows and viruses? Viruses keep getting better! — Steven Tyler [I think that joke would have worked better at the Apple party.]

This is the biggest frat party we’ve ever played. — Joe Perry

Not being a huge Aerosmith fan, I didn’t recognize several of the songs they played. But they did play their big hits. Here’s a partial setlist:

• Dream On
• Walkin’ the Dog
• Love In An Elevator
• Livin’ On The Edge
• Walk This Way
• Sweet Emotion (it looked like Perry played one note on a theremin)

– encore –

• Joe Perry live duel against his Guitar Hero avatar
• Train Kept A-Rollin’

[10:50pm] Aerosmith’s set ended, so I wandered over to where Roger Daltrey was playing. His stage was set up in a large indoor tent area. It wasn’t quite as large as the Aerosmith stage but there was probably space for a couple thousand people. Unfortunately the sets overlapped, so he was already in the middle of his set when I arrived. I did hear a couple songs: Ring Of Fire (Johnny Cash style) and Won’t Get Fooled Again.

Other bands up were the Wailers and Three Dog Night. It was getting pretty late at this point though so I decided to skip them head home.

Keynote (afternoon Wed Oct 14)

[2:30pm] The Moscone North foyer (bottom of the escalators) is incredibly crowded. The Oracle logo, is everywhere. Banners, carpets, every surface you can think of. It’s hard to believe this is the same place where JavaOne happens. It looks so different.

The shoe-shine stand is open. Hm, they didn’t have the shoe-shine stand at JavaOne. I wonder why?

[2:50pm] Charles Phillips, Oracle President. Roger Daltrey stepped on stage and said a few words; promo for tonight’s “customer appreciation” concert.

[3:00pm] Kris Gopalakrishnan (founder InfoSys, a platinum sponsor) spoke on IT innovation in industry. Gap between intent and action in IT innovation: 78% of banks think innovation is important, but only 37% have an innovation plan. IT is about interconnection. We no longer should think about a value chain, but a value web. “No man is an island” — similarly, no enterprise is an island.

[3:35pm] Larry Ellison takes the stage.

• Status update: Oracle Enterprise Linux and Virtual Machine. Very pleased with uptake. 65% of Linux installations running Oracle RDBMS run Oracle Enterprise Linux. Smaller percentages for Red Hat, SUSE, and others.
• Exadata 2: Sun/Oracle Announcement. This is a Linux/Intel box. Different from the Sunday announcement, which set the TPC-C records, which is a SPARC Enterprise T5440 machine running Oracle Database 11g on Solaris. (IBM is challenging Oracle’s claims of 16x their performance; they say it’s really only 6x the IBM machine’s performance. “They might be right. IBM also forgot to point out that their machine consumes 6x the energy of ours.”) Exadata 2 shows really impressive numbers. For example, a single rack Exadata 2 will do 1 million random I/O operations per second. Two racks do 2m, etc. Exadata 2 is fault tolerant, while IBM is not; Exadata 2 costs about a quarter of the competing IBM product; Exadata 2 is modularly expandable, whereas IBM’s need to be replaced entirely to be upgraded. “The fastest business computer that has ever been built.”

[4:00pm] Special surprise guest: Arnold Schwarzenegger! “This conference is about pumping you up.” California is the world’s technology leader. Technology can help reduce errors in medical care; can help fight global warming; biotech and stem cell research can help Alzheimer’s sufferers; can grow algae for ship fuel; electric cars (Tesla); improved efficiency in the power grid (Smart Grid). Acknowledges two great California technology companies, two great success stories: Oracle and Sun, Larry Ellison and Scott McNealy [applause]. Employers of 16,000 people in CA and 150,000 people worldwide. Wishes the combined companies great success. California’s state IT infrastructure also improving. GIS being used to help firefighters’ helicopters drop fire retardant more accurately even if the area is obscured by smoke. People’s lives and homes at stake. Confident in the future: we face enormous challenges that can be overcome with technological innovation. Global warming negotiation going on in Copenhagen. We hope this goes well but it’s a political negotiation. The real work is done here, in technology. “When this conference is over, don’t go home. Stay in California and spend money! We need the revenue!”

[4:30pm] Larry Ellison returns to the stage.

• New Product Support System. Proactive problem prevention. Keeps track of configurations; can alert potential problems experienced by other customers with similar configurations. Unification of Enterprise Manager and MyOracle service. A couple demos of service management by Richard Sarwal who has returned to Oracle from VMware.
• Fusion Applications. Customers have made a huge investment in Siebel, JD Edwards, Peoplesoft,etc. Committed to support these product lines for a decade. [Mild applause.] Oracle has $3bn R&D budget. Can maintain software you’re running today, but also develop new software you can migrate to tomorrow, next year, or in ten years. Fusion is brand new. SOA. Easily connected to existing suites. Fusion coexists with existing applications, can replace individual apps as needed or augment with new ones. Not developed in isolation; developed in close collaboration with customers. Has a “modern UI.” Enormous project: 6000 tables, 20,000 views. Fusion v1 code complete, in test with customers, will be delivered next year. Only suite built on standards-based middleware. All standards-based, all Java-based Fusion middleware. No custom components. UI is business-intelligence driven; “exception-based”. Steve Miranda, Chris Mayo: demo of Fusion. The demo included fixing a problem with an Exadata V2 order from Stark Industries. “We really need to fix this problem, because you know what happens when Tony Stark gets mad.” I don’t think anybody got the joke though.

[5:15pm] Session ends. I now have some dead time until the evening event. This is totally not a geek conference. There are bean-bag chairs at the foot of the escalators in Moscone North (kind of like JavaOne) but they’re only half occupied. Power and network are easy to come by. There are still guys getting their shoes shined.

Oracle Bloggers Meetup (evening Tue Oct 13)

Pythian sponsored a bloggers meetup at a bar in the Metreon this evening. Thanks to Alex Gorbachev for arranging it. Richard and I both went. This was pretty cool. We met a few Oracle folks there. There were also some Sun folks there (including blogger extraordinaire Tim Bray).

It’s not like this was a substantial session or anything but some of the conversations got me thinking about Oracle’s strategy in buying Sun. One perspective is that Oracle is an Enterprise Software company. After all, that’s what they do today, and they have a $23bn business doing it. From this standpoint Oracle would mine out Sun’s software assets (primarily Java) and jettison the rest. But that rests on the assumption that Oracle is simply going to continue to be an Enterprise Software company. That’s not necessarily the case. So, where will Oracle go next?

Some clues are emerging at OpenWorld. Sun hardware has played quite a strong role here. First there were the Sunday announcements of the TPC-C record on Sun’s T5440. Then there’s the Exadata 2 announcement, which is based on Sun hardware. (I’m writing this in retrospect, but Ellison’s Wednesday keynote segment on the Exadata 2 was all about hitting IBM repeatedly and very, very hard.) So maybe Oracle is no longer going to be an enterprise software company, but instead an enterprise systems company.

What does this mean for JavaFX? Of course, nobody knows for sure. But any enterprise systems company is going to have to figure out what to do about the client side. Will Oracle settle for open technologies such as Ajax, or will they rely on other companies’ proprietary technologies like Flash and Silverlight? When Ellison spoke at JavaOne he talked about how important Java and JavaFX are. So maybe that’s a hint at the answer.

Our JavaFX Talk at Oracle Develop (afternoon Tue Oct 13)

Richard Bair and I gave our introduction to JavaFX talk in the “Develop” stream of Oracle OpenWorld. The talk went pretty well. We deviated from the slides a lot though… Rich spent a lot of time typing live code into NetBeans and demonstrating immediate results. This actually went quite well. I think the audience (which consisted entirely of Java developers) appreciated the live coding exercise much more than slideware.

I did my part with a live demo of the JavaFX Production Suite, exporting artwork from Adobe Illustrator using the Suite, and bringing it into a simple JavaFX app in NetBeans and displaying and rotating it.

We were in a fairly small room (capacity 100) and there were about 25 attendees. This seemed small to us compared to JavaOne, where a small room fits 500. But I think this was typical for the Develop talks. While OpenWorld is a huge conference — I think I heard 37,000 attendees — it’s a business conference, not a developer conference. Oracle Develop was relegated to the “ghetto” of the Hilton San Francisco. It was crowded, but the space was much smaller than Moscone. I think Oracle Develop might have had only on the order of a thousand attendees. Compared to JavaOne, a developer conference that usually attracts over 10,000 and has had up t0 25,000, Oracle Develop is quite small.

Having a small audience had its advantages. There’s a lot less pressure, it’s more interactive, and while not quite intimate, it was easier to create personal connections with people in the audience. There were some good questions and a couple attendees hung around with us afterward and had in-depth conversations. I think they learned a lot from our talk, and in turn we learned a lot from talking to them. In that respect the talk was a success.