John O'Conner's Blog

John O'Conner is a software architect, consultant, author, and speaker. After many years developing the internationalization features of the Java platform at Sun Microsystems, he is now actually trying to use those features in real world projects.

Learning Curve: Declarative UI in JavaFX Script

Continuing the effort to ramp up with JavaFX Script, I decided to port a recent demo's UI from the Java language to JavaFX Script. I think the result is successful. I outlined my experience in the Learning Curve Journals, Part 2: Declarative UI.

I'm not finished with this series, so you can expect me to start adding actual behavior to this UI very soon.

You don't know Sun? How about Java?

Now with Java on desktops, cellphones, and devices everywhere, there's a good chance people know about the Java brand but not the company behind it. Oh, you don't know the company? That's Sun Microsystems, Inc., SUNW to investors and Wall Street.

This little piece of info -- that people know Java not Sun -- has sparked change. Starting next week, Sun will no longer be SUNW on the tickers. Instead, you can look forward to seeing JAVA in your portfolio. That's right. Sun Microsystems will change its stock ticker symbol from SUNW to JAVA in an effort to capitalize on the Java brand awareness.

Well, that was certainly unexpected.

You can read Jonathan Schwartz's announcement to find out more. Jonathan Schwartz? You know him, right? He leads that company that makes Java.

Learning Curve Series for JavaFX Script

Learning a new technology has its own set of challenges. Sure the technology itself may have quirks -- is that a code word for bugs? -- but sometimes just getting enough information to get started can be tough.

If you're interested in JavaFX Script, you want to make sure you get the right information and resources. Maybe you want to bounce questions around with others. Where do you go? Who do you ask? How do you proceed?

I'm in the same situation. I'm an early adopter of JavaFX Script, and I'm experimenting with the language. Since I've never been too afraid to let you sit next to me as I explore new things, I've decided to share my experience learning JavaFX Script too.

You can read along as I bumble my way along. Maybe you'll learn something. Maybe I'll learn something. Or maybe you'll have a question. Maybe you'll see solutions that I don't. I'll share my experiences though, and you can read them on the Learning Curve, a new article series available on the JavaFX hub of the Sun Developer Network.

I've posted the first part of the series there now. My editors called it "Exploring JavaFX Script." I think of it as my description of how I set up my initial environment and learning resources. So, it's sort of a "Setup" article too. There's more coming. So go check out the first titled Learning Curve Journals, Part 1: Exploring JavaFX Script. Leave a comment, ask a question, and maybe I'll be able to explore your question as part of my own Learning Curve experience. Hey, we're in this together.

Learning the JavaFX way of doing things

I set a challenge for myself: to port the UI of a simple application to JavaFX Script and keep all the existing application logic, models, event handlers, etc. The goal was to port just the UI and to reuse all the rest of the code. I thought it would be relatively easy to port the UI of an application without moving other code. It turns out that this isn't as easy as I once thought.

I discovered that although using JavaFX Script's declarative syntax to define the visual UI is easy, I was being simple-minded to think I'd be able to just return that whole UI structure to Java. I haven't been able to successfully pass JavaFX objects back over the Java - JavaFX Script environment boundaries.

My first problem arose when I discovered that the declarative syntax doesn't readily support naming of individual UI components. For example, look at the following JavaFX frame with a single button:

Frame {   
    content: Button {
        text: "Press me!"
    }
}

I thought I'd be able to create this UI and return the entire thing back to my Java code, then add event listeners, etc to the button on the Java side. But notice that there's no way to name the Frame's individual UI elements. In this case, that's just the single Button. Yes, the button exists; yes, it displays. However, I can't just return this whole frame and dereference the Button easily.

Then I thought that I could create a helper class to wrap the frame and to provide names for its UI elements like this:

class MyFrame extends Frame {
    attribute button: Button;
}
var myFrame = MyFrame {
    var: self
    title: "JavaFX Demo"
    button: Button {
        text: "Press me!"
    }
    content: self.button
    visible: true
};
return myFrame;

But it turns out that this return value isn't really a JFrame. Casting it over on the Java side -- where I use ScriptEngine's eval method -- just throws an exception:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: 
net.java.javafx.typeImpl.TypeFactoryImpl$ModuleImpl$ValueImpl cannot be cast to javax.swing.JFrame

So, there has to be a better way. I'm convinced of it. My initial experiments with the language suggest that although it's easy to access Java objects from JavaFX Script, using user-defined JavaFX objects from Java might not even be possible. I'm still learning, so I could be mistaken. Regardless, I'm obviously not doing this in the JavaFX way...I just have to discover exactly what that is.

Every language has its way of doing things, its own idioms, its own natural path to accomplish a goal. I think my initial goal may be constrained too much. I'm discovering that although I can call into Java to execute libraries and other business logic, it's probably best to implement all of the view and models in JavaFX. Leaving the models back in Java doesn't seem to be an effective way to use JavaFX Script.

Using JavaFX Script for UI Declarations

This is an exciting time for the Java platform for a lot of reasons, and certainly JavaFX Script is part of the buzz right now. If you read much about this new script language, you'll see lots of comments about how Sun is targeting this language for rich content development, a language to help us make our UIs sparkle. I think that opportunity is real, and I think JavaFX Script can help.

At least one argument for using JavaFX Script is its simpler syntax for content developers and UI designers. Personally, I don't think the procedural, algorithmic parts of the language are that much simpler than the Java language, but I do think the declarative UI syntax is easier, or can be easier, than Java. Reading the marketing literature for the language, I think the message includes an appeal to "non-programmers" and content creators. I don't know a lot of content developers or UI designers, but I'm going to go out on a limb and say that they probably aren't that interested in packages, class definitions, for-loops, operations, and maybe not even triggers. The UI declarations and UI definitions are going to be the most interesting to to a UI designer. Seems reasonable to me anyway.

My skills and interests aren't in UI design. However, I do want to know how a Java programmer and a UI designer would work together -- one using Java for the business logic, event handlers, and models, and the other using JavaFX Script to design only the UI and maybe a little animation here and there. Maybe that's not how the language designers intended it to be used; I don't know. But that's interesting to me. And if you can't use something for an unintended purpose, what good is it? OK, maybe that's not really true for programming languages, but my kids do seem to have a lot more fun jumping on the bed than sleeping on it. I'm digressing...

Unfortunately, I haven't yet found any demos or examples that show this sort of interaction with JavaFX Script. Instead, I see great demos -- absolutely fantastic, eye-popping demos -- that launch complete applications that have been written in the new language. That's great, but I want to pull back a few notches. I don't want to create my whole application in JavaFX Script just yet; I've spent too many years as a Java programmer. I have lots and lots and lots of Java code, complete with event handlers, listeners, models, etc. Although my application UI itself might benefit from a little scrubbing and a port to JavaFX Script, I don't want to port my whole application, at least not yet. I want to introduce JavaFX Script slowly, use it for the UI view only. I want to keep all my business logic, event handlers, and models in my Java code. Now that's what I'm interested in...for now at least. And, you know what, I think that's how many Java programmers would like to use JavaFX Script right now too. Hey, that's my opinion, completely unsubstantiated of course. Let's just say it's a feeling that I have -- an unendorsed feeling completely independent from Sun Microsystems*.

So for the next few blogs, that's where I'll turn my attention. I'm not going to write a complete application in JavaFX Script, but I am going to figure out how to access a declarative UI written in the scripting language. And I'll keep all my existing business logic and models and event handlers back where I'm comfortable...in the Java code. I hope my exploration helps someone else too. If I'm successful, you'll know; if I'm not, you'll know that too. If you have tips and more information, share them with me as I explore this language along with you.

*[Goofy disclaimer...just in case someone thinks I actually represent Sun in my personal blogs, I do not. Nothing in this post represents official statements of Sun Microsystems, although Jonathan Schwartz does call me from time to time asking for my opinion. Wait...he doesn't sell timeshares in Vegas or refinance home loans. Hmm...maybe that wasn't him on the phone. Never mind. As it turns out, all this is still just my independent opinion. ]

Unicode support in JavaFX Script

I was pleasantly surprised with my first real interaction with JavaFX Script. Of course, I had to test at least one of its i18n features, so I picked something simple, Unicode text in the script.

My goal was simple. Find out whether I could successfully create a simple "Hello, world" using non-ASCII characters. I picked Japanese since I'm familiar with that language. The translation accuracy doesn't matter much as long as it generated hiragana and kanji text, so I typed my first script into NetBeans after creating a JavaFX Project:

import javafx.ui.*;
Frame {
    title: "Hello World JavaFX"
    width: 200
    height: 50
    content: Label {
        text: "こんにちは、世界！"
    }
    visible: true
}

Then I saved this script as HelloWorld.fx. I suspected that this wouldn't quite work, knowing in advance that NetBeans would save the file using my host system's native charset. In my case, that's 8859-1 or the Mac OS X approximation called MacRoman or somesuch -- The silly deviations of 8859-1 across different OSes is another topic entirely. In the editor it looks ok so far -- I haven't reloaded the file from the drive -- but I quietly anticipated that the on-screen version and the file-system copy were slightly out of sync at this point. Poor NetBeans...it just blindly tried to save those Japanese chars in an inferior charset, and it's just not going to work.

Running the script confirmed my thoughts:

Fortunately, I know exactly what's wrong. It's the charset conversion when I save the file. Converting the Japanese text to 8859-1 loses data; see all those '?' marks in the above image. That's the giveaway. I have to escape the non-ASCII Japanese characters in my script. It's a pain, a big pain, but I'm used to this sort of problem in both property files and code source files. So I just escape the chars as shown here:

...
    content: Label {
        text: "\u3053\u3093\u306b\u3061\u306f\u3001\u4e16\u754c\uff01"
    }
...

Now I try again. Save, recompile, run, and...nice.

This wasn't a complete test of JavaFX Script's ability to display Unicode characters, but it does clarify a few things for me. A script's character encoding has the same limitations as a Java resource file. For now at least, the easiest way to get non-ASCII characters into a JFX script is to escape them.

It's not easy to remember the Unicode codepoint value for all characters. That's simply not the way people type characters into any editor. So you'll probably have to use the JDK tool native2ascii to convert your source file to an escape-encoded file. You need to use an editor that can save a file in a charset that supports the characters you're trying to enter. Sounds reasonable, right? You'd be surprised how many tools don't pay attention to charsets, and they rarely warn you when you save a file using a charset that doesn't support what you've tried to type. I suspect NetBeans saves to my host charset, not UTF-8 or SJIS which can represent these Japanese characters. I'll check more on this to find out if there's a way to tell NetBeans that a particular file should be in a specific charset...or better yet, maybe there's a way to have NetBeans save the file using \uXXXX encoding for all non-ASCII characters. Hmmm...maybe that's a plugin opportunity for someone. But it's definitely a problem for now, and if it's just a limitation of my NetBeans knowledge, I'll followup on this in a subsequent blog.

For now I'm just happy to report that you can embed Unicode chars into your JavaFX Script files. Just remember to encode them with the native2ascii tool first.

---
I hate to add this to my blog, but I feel compelled. I want everyone to know that I use NetBeans every single workday. I like it, and I'm not picking on it. This problem with encodings isn't specific to NetBeans, and I'm not blaming NetBeans. I hate explaining that...but I'm trying to avoid the inevitable backlash against me if I don't explain that I'm not being negative.

Could you cut your development time in half?

Application frameworks are supposed to save you time and effort. That's probably true for most frameworks after you slog through the complex APIs, tutorials, docs, forums, a few just-in-time courses, and maybe even a couple nightmarish starts and stops to your project due to nothing other than the framework itself. I remember working with a big, overwhelming framework back in 1998...a long time ago, and I'm just now recovering. In 1999, the project was abandoned, and the entire team was disbanded. I like to blame it on the framework...and management. You have to take a shot at management whenever you can. It was a bad experience whatever the cause, but that huge, monolithic framework factored in heavily I think. We didn't save time or effort, and almost two years of development time were just wasted. What a fiasco that was!

So, with just a little trepidation, I started to research the Swing Application Framework (JSR 296). I've already declared it an "unframework", trying to be a little silly but also trying to give a compliment too. So far, and let's hope the trend continues, the Swing Application Framework is small and easy to grasp. It provides some basic, skeletal best practices for organizing your application code. And it stops there, long before it gets overwhelming.

I think Hans Muller said someone could understand it in an hour. He's pushing the limits a little, but he's a genius too, so we can forgive him for being optimistic. Realistically, give yourself a couple hours, maybe three if you like to do a little experimenting with code too. I do. I'm basically saying that you can understand everything about this framework after a couple long lunch breaks.

To help you cut those three hours back down to just 2, I've summarized everything I've learned about the framework. I've provided a couple blog entries on the subject, but I've gone off and created a complete article about the framework too. After working so hard on the article itself, my brain just stopped working. So, I skimped a little on the article title. Lacking imagination at the last moment, I've called this article Using the Swing Application Framework. Geez, you'd think I could have come up with something a little snappier!

Could you really cut your development time in half if you adopt the Swing Application Framework? Uh...maybe. Hmm...ok, I give. I don't really know. However, I'm absolutely sure you'll save some time. The investment will be worth it, especially if you have new developers on the project. Why? Well, because new Swing developers don't always know how to set up an application, how to interact with Swing components on the event dispatch thread, how to use Actions and event handlers, or how to properly set up resources for localization, etc. This framework packages up some of these basics quite nicely, making it relatively easy to start a project correctly. Finish in half the time? Maybe not. Your mileage may vary, etc. I'm being a little dramatic with the blog title -- perhaps to make up for the boring article title, but I do know that the Swing Application Framework will help you structure your app correctly and help you adopt some best practices for handling some very common Swing application tasks. That's worth quite a lot in itself.

It shouldn't take you long to decide if the framework can help you or your team. Check out the framework reference implementation, read the article, and leave a comment about your experience.

Cookie Handling

This month's version of the Core Java Tech Tips describes Java SE 6 Cookie handling along with Drag and Drop tips for JTree components. These tips have been part of Sun's newsletter program for a long time. Now you have another option for their delivery, and this one might be the most convenient.

The Core Java Tech Tips are now available via blog. You can use your browser or favorite blog reader to subscribe to their Atom news feed. Take a look, subscribe if you'd like, see what you've been missing.

Managing resources in the Swing Application Framework (JSR 296)

Instead of loading and working with ResourceBundle files directly, you will use the ResourceManager and ResourceMap framework classes to manage resources. A ResourceMap contains the resources defined in a specific ResourceBundle implementation. A map also contains links to its parent chain of ResoureMap objects. The parent chain for any class includes the ResourceMap for that specific class, the application subclass to which the class belongs, and all superclasses of your application up to the base Application class.

The ResourceManager is responsible for creating ResourceMaps and their parent chains when you request resources. You will use the ApplicationContext to retrieve ResourceManager and ResourceMap objects.

You have three options for working with resources:

1. manually load and use ResourceMap objects and their resources
2. use the framework to automatically inject resources into the UI components that need them
3. use the framework to automatically inject resources into the object fields that need need them

Covering all three options is a bit much for one blog post, but I can let you know about manual resource management. Maybe the remaining methods are the seeds of another blog entry...maybe an article?

Manual Resource Management

The ApplicationContext class provides access to the ResourceManager and its ResourceMap instances. Retrieve the ApplicationContext using the static getInstance method. Then you can use the context to retrieve a ResourceManager and a ResourceMap. Use the ResourceMap object to retrieve resources for your application or specific class. The following example shows how to retrieve resources and apply them to UI components.

public class HelloWorld extends SingleFrameApplication {
    JLabel label;
    ResourceMap resource;
    
    @Override
    protected void initialize(String[] args) {
        ApplicationContext ctxt = ApplicationContext.getInstance();  
        ResourceManager mgr = ctxt.getResourceManager();
        resource = mgr.getResourceMap(HelloWorld.class);
    }
    
    @Override
    protected void startup() {
        label = new JLabel();
        String helloText = (String) resource.getObject("helloLabel", String.class);
        // You can optionally use the convenience methods that cast resources for you
        Color backgroundColor = resource.getColor("color");
        String title = resource.getString("title");
        label.setBackground(backgroundColor);
        label.setOpaque(true);
        getMainFrame().setTitle(title);
        label.setText(helloText);
        show(label);
    }
    ...    
}

You can also retrieve retrieve ResourceMap objects using the convenience method in the ApplicationContext instance:

resource = ctxt.getResourceMap(HelloWorld.class);

The HelloWorld class uses three resources: a label's text, a color for the label background, and text for the frame's window title. It gets those resources from a ResourceBundle for the HelloWorld class. You know that because the application gets a ResourceMap instance for a specific class, the HelloWorld.class, as shown in this code line:

resource = mgr.getResourceMap(HelloWorld.class);

You provide the Class instance that represents either your Application subclass or a specific class in your application. The ResourceManager will search and load a ResourceMap that holds the resources defined in a resources subpackage below the HelloWorld class. In this case the ResourceBundle implementation is a file at resources/HelloWorld.properties. The following code shows part of the HelloWorld.properties file.

helloLabel = Hello, world!
color = #AABBCC
title = HelloWorld with Resources

The next figure shows the HelloWorld application. Each of the resources -- the window title, the label text, and the label background color -- were manually retrieved and applied to each specific component. When you use manual resource management, you are responsible for providing code to perform all steps of retrieving and using the resources in the appropriate component.

That's it. Now you can create ResourceMap objects that map onto ResourceBundle implementations for your entire application or for a specific class. You can load those maps, and you can retrieve resources from them. You know there's a better way right? Yep, there is. But that information will have to wait until next time. Or you could find out right now if you check out the JSR 296 reference implementation.

Core Java Technologies Tech Tips

The Sun Developer Network has a few newsletters that you can subscribe to. One of the newsletters is Core Java Technologies Tech Tips. I still can't see that title without smiling. I'm always amused that Sun's proper use of the word "Java" must always have an approved noun after it: Java language, Java platform, Java technologies. It doesn't matter that Java Technologies Tech Tips sounds redundant; that's just the way it must be. But hey, I'm getting way off track, and the naming oddity is not what I want you to remember about this blog.

I want you to remember this: the Core Java Technologies Tech Tips are now available in blog format. Nearly 300,000 subscribers receive the email version of the tips each month, but now you can get them via blog and their Atom feed. This is a really popular product, providing tips and hints for using the Java platform's core APIs. You're going to like it, really like it.

If you've been getting the email tips, don't worry. Those aren't going away immediately. If you've never heard of the tips, you've been missing a treat. Have a look, make a comment...just make sure you check it out.

Swing Application Framework: Lifecycle Events

All applications have a lifecycle of events that are called in a specific order. Your primary Application or SingleFrameApplication subclass should start in its static main method and should launch the application from that point. The supported lifecycle includes the following methods, called in the same order:

1. launch -- you must call this framework method
2. initialize -- the framework will invoke this optional overridden method
3. startup -- the framework will invoke this overridden method
4. ready -- the framework will invoke this optional overridden method
5. exit -- you must call this framework method
6. shutdown -- the framework will invoke this optional overridden method

Your application's minimum requirement is to call the Application.launch method and to override the startup method. By calling the launch method, your application begins the lifecycle. The launch method will then call the initialize, startup, and ready methods. You should also handle your application frame's closing by calling the exit method, which will eventually call the shutdown method.

The following code example shows how to subclass the SwingleFrameApplication class and override the startup method.

public class BasicSingleFrameApp extends SingleFrameApplication {
    JLabel label;
    
    @Override
    protected void startup() {
        getMainFrame().setTitle("BasicSingleFrameApp");
        label = new JLabel("Hello, world!");
        label.setFont(new Font("SansSerif", Font.PLAIN, 22));
        show(label);
    }
    
    public static void main(String[] args) {
        Application.launch(BasicSingleFrameApp.class, args);
    }
}

Optionally, override the initialize method to check db connections, process command line arguments, etc. The default method in the superclass does nothing.

If you need to do something after your UI is visible, override the ready method.

Finally, the SingleFrameApplication class implements a WindowsAdapter that processes the window-closing event by saving session state, contacting ExitListener objects, and finally calling System.exit(0). You probably don't need to override that behavior, but you might want to register your own ExitListener to give your application an opportunity to veto the exit request or query the user for exit confirmation. The following example shows how you might implement an ExitListener:

public class ConfirmExit extends SingleFrameApplication {
    private JButton exitButton;
    
    @Override
    protected void startup() {
        getMainFrame().setTitle("ConfirmExit");
        exitButton = new JButton("Exit Application");
        exitButton.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                exit(e);
            }
            
        });
        addExitListener(new ExitListener() {
            public boolean canExit(EventObject e) {
                boolean bOkToExit = false;
                Component source = (Component) e.getSource();
                bOkToExit = JOptionPane.showConfirmDialog(source, 
                                "Do you really want to exit?") ==
                                JOptionPane.YES_OPTION;
                return bOkToExit;
            }
            public void willExit(EventObject event) {
                
            }
        });
        show(exitButton);
    }
    @Override
    protected void shutdown() {
        // the default shutdown saves session window state
        super.shutdown();
        // now perform any other shutdown tasks you need
        // ...
    }
    
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Application.launch(ConfirmExit.class, args);
    }
}

There's a lot more to lifecycle event methods. Check out the reference implementation of the Swing Application Framework and its demos to learn more.

September 2007

Search this blog:

Categories

Archives

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

Recent Entries

Learning Curve: Declarative UI in JavaFX Script

You don't know Sun? How about Java?

Learning Curve Series for JavaFX Script

This work is licensed under a Creative Commons License.