Monthly Archives: July 2009

Quick note about JavaFX Sequences

If you’re learning about JavaFX, you probably already know about some of the basic data types: String, Number, and others. But what do you know about sequences?

A JavaFX sequence looks and behaves much like a Java array. A sequence is an ordered list of objects. Unlike JavaScript, JavaFX Script requires that each item in the list share the same type. The following code shows a sequence of Strings:

var names = ["John", "Gary", "Ruby", "Nick"];

JavaFX infers the correct type, but you can be explicit:

var names: String[] = ["John", "Gary", "Ruby", "Nick"];

Above, the names variable has the “Sequence of Strings” type.

Like arrays, sequences can be accessed by content index. A sequence’s position (index) is a number from 0 through n-1, where n is the number of items in the sequence. You can use the sizeof operator to tell you how many items are in a sequence.

var size = sizeof names;
println("size of names: {size}");

The easiest way to iterate through a sequence is with the for-in loop like this:

var friends: String[] = ["Jack", "Nick", "Matthew"];
for (friend in friends) {
    println("My friend: {friend}");
}

Note that the friend variable inside the for loop does not have a var declaration.

Speculations on Google Chrome OS

Today’s announcement of Google’s Chrome OS is exciting in a few ways. I think it has implications for Java developers. With hindsight, I now think that Larry Ellison was hinting about Google’s Chrome OS when he expressed some of his desires for JavaFX on small netbook-like devices.

So, without any real knowledge and armed with nothing more than a vivid imagination, I provide some of my predictions/speculations for the upcoming Google Chrome OS and the devices it will power:

  1. Google Chrome OS will be a slightly more beefy Android OS. More beefy because it will have additional hardware driver support you might find in a netbook. However, its essence will be Android OS.
  2. The Chrome browser (or a slimmed down cousin) will be the primary application on that OS. It’s already integrated into Android via Webkit
  3. The developer API will be very similar to what Android G1 developers already use. Android G1 apps are essentially Java apps written to a Java-like API. Same Java language on top of the most important, core packages of the Java SE platform. And, of course, Google won’t be able to call it a “Java” platform because it will be stripped down to what Google engineers consider only the core, “good” parts of Java SE APIs + Google’s own Android APIs of course.
  4. Google Chrome OS will be attractive to Java engineers because it looks and feels so much like the the JVM…except it’s really the Dalvik VM. Many simple applications that run on Java SE will be able to run on the Dalvik VM after a recompile. Or maybe you’ll just have to run your class files through a simple converter to target the Dalvik VM. At any rate, Java developers will feel right at home.
  5. Google Chrome OS devices will need to get onto the network easily, seamlessly, regardless of Wi-Fi availability. Google really does believe that “the network is the computer”. Without the internet, these devices will be severely hampered. Expect these devices to have multiple network access technologies built in. Wifi hardware will obviously be on board. But you can imagine it also having a cellular transmitter/receiver built-in too.
  6. Remember all that cellular radio spectrum that Google was interested in only one or two years back? Wouldn’t it be just an awesome thing if Google purchased a huge portion of that and used it to make their Google Chrome OS devices be able to instantly jump onto that for network access? You buy the device, punch in a pre-purchased code for access, and your notebook is on the net in 5 minutes! It will be incredibly, insanely easy to get on the network with your Google Chrome OS-powered device.
  7. Hey, what’s that Google Voice project anyway. Only one of the coolest telephony projects around! Maybe Google will leverage this service? Here’s a scenario for you: you buy a Google Chrome OS device, open it up, agree to the terms of a Google voice membership, get a Google voice number and Google account (if you don’t already have one), and the device then connects to the network using the built-in cellular hardware to connect to some of that cellular spectrum that Google will or has already purchased.
  8. After all of this, or perhaps even before this, we all start to feel a little uneasy about just how pervasive Google really is. And despite Google’s mistrust and derision of Microsoft, they begin to look a little bit like Microsoft too…really, really big and really, really powerful and located at every digital turn. But this time, instead of controlling your PC, they control your network. Ooh, there’s a suspenseful novel in there somewhere.

Ok, some of that’s just silly, crazy talk…or is it? We’ll see over the next few months.

Oh, one last thing. I just cannot resist the urge to compare Google Chrome OS to Sun’s Java OS. Do you remember that? I could hardly find any references to it, although I did find an old article called Inside the IBM JavaOS Project. At some point, Sun apparently enslisted IBM to help. At any rate, the Java OS project started (and ended) a long, long time ago. It’s been a decade at least. Remember the Hot Java browser? I actually ran it and used it. I remember that one of our tests at Sun was to run the SwingSet demo on it. But now I’m just distracted. What was I saying? Oh yes, there are even more similarities. Java OS is to Google Chrome OS as the Hot Java browser is to the Chrome browser. Maybe Google Chrome OS will finally be the successful reincarnation of JavaOS?

It’s all fun to think about, and as I suggested, pure speculation at this point.

An Internationalization and Unicode Web Service?

Chances are that your favorite development platform already has internationalization support built into it. And probably Unicode charset support is there too. For example, Java and .NET platforms contain lots of APIs for formatting dates, numbers, etc in locale-sensitive ways. And you can get Unicode character data easily too. Unfortunately, the Unicode standard changes periodically, typically much more frequently than your development platform. You applications probably do NOT have full awareness of the latest Unicode database properties. Maybe that’s not important to you? But maybe it is? What do you do in that case? What can you do? You wait…and wait a little more. You wait until your platform’s authors update their Unicode support. That can be a very long time.

Do you think there’s a need for a web service to provide up-to-date Uncode character property information? If there were such a thing, would you use it?

Maybe Unicode character data isn’t exciting enough for you. So how about this? What if a web service existed that could provide human readable dates, times, and numbers in locale-sensitive formats? Sure those APIs exist in Java and .NET…but again, those platforms aren’t always up to date with the latest locale data and formats. What if your application could use use a web service to retrieve those formats?

Oh, and we haven’t mentioned calendar support yet. With Java, you get Gregorian, a Japanese Imperial calendar, a Thai one….and maybe that’s it. Those are important of course. But what if you need something more exotic? A Hebrew or Islamic or … any number of other calendars in use today and the past. What if a web service existed that could provide that information to your application. Would you use it?

No. I don’t have this web service today. But I wonder if others see a need for it. If so, drop me a note, let me know your ideas. If you don’t think it’s needed, let me know that too. I’m interested in arguments for and against such a service.

My valiant attempt to install JavaFX 1.2 into NetBeans 6.7

If you follow NetBeans development, you know that NetBeans 6.7 has been released this week. By far the friendliest IDE for JavaFX development has been NetBeans. However, in a very surprising twist, the latest NetBeans 6.7 release does not include the JavaFX SDK 1.2. Instead, the download’s information page clearly indicates that you’ll need NetBeans 6.5.1 if you also want JavaFX.

I’m sure there’s a good reason for not including JavaFX with NB 6.7. No one has said a thing to me, but I suspect he reason for not including JavaFX 1.2 is the JDK requirement. JavaFX requires Java SE 1.6 Update 13, and Update 14 is recommended. NetBeans requires only JDK 5 Update 18. Perhaps the NetBeans team doesn’t want to require Java SE 6 Update 13, even though the JavaFX team apparently must.

The NetBeans team didn’t include JavaFX 1.2 “in the box”. Maybe they want you to be able to continue using NetBeans on the older JDK? The JavaFX team, on the other hand, does not have the same large user base. They can require an upgrade to Java SE 6 U13 because, well….they simply don’t leave too many existing users behind by doing so. That’s reasonable I think, but it leaves you wondering whether JavaFX SDK 1.2 will even work on NetBeans 6.7. I mean…the NetBeans site doesn’t actually tell us whether it works.

Of course, I had to try to install the JavaFX SDK 1.2 anyway.

First, the JavaFX SDK plugin simply doesn’t appear in the list of available plugins for NB 6.7. That’s ok, you can add the NB 6.5.1 update site to the list of plugin repositories.

Once you do this, the JavaFX plugins show up in the plugin catalog:

Now that’s exciting to see. You’re just a single “Install” button click away!

Or so I thought…no. As soon as I pressed the “Install” button on the plugins page, a warning/error dialog tells me that an unmet dependency stands in the way. Something called the “Editor Hint” plugin is necessary:

Suppose we just forget the referenced “JavaFX Kit”? Would that work? I unchecked the JavaFX Kit plugin. Nope. The next complaint is against the weather example plugin. OK, let’s get rid of that. Now the only thing selected is the JavaFX SDK itself. After pressing the “Install” button again, I watch NetBeans 6.7 download and install the “JavaFX SDK for Windows”. OK so far, but I’m not sure what I’m going to miss without the JavaFX Kit plugin.

Other than a short message about the unsigned nature of the plugin, this JavaFX SDK plugin appears to install without a problem. But what does it give me? I quickly realized that all the JavaFX Project and JavaFX file type references that usually show up in the New Project and New File dialogs just aren’t available yet. Hmmm….that “JavaFX Kit” plugin is necessary after all. I bet it contains exactly what’s needed to add JavaFX file types to NetBeans. But that requires something called the “Editor Hints” plugin….sigh.

I’ve checked around the NetBeans plugin site. I can’t seem to find the “Editor Hints” plugin. If you know anything about it, let me know. Until then, we’ll have no JavaFX 1.2 in NetBeans 6.7. I feel like I’m close, very close. So come on Joshua M, Jasper P., one of you guys…if you’re listening….give me a hint. I know you know how to make this work…even though it’s not “officially” supported by NB 6.7 yet. :)