Tom Ball's Blog

Community: JavaDesktop Archives

Divide and Conquer

As anyone following the JavaFX Script compiler project knows, we have a schedule gun to our heads to finish a useful tool quickly, so the interpreter-based prototype shown at last year's JavaOne can be retired. It's a big job since the language doesn't have a specification yet, but our team of four engineers plus some really good volunteers are set to deliver what looks to be a great product. Of course I'm biased in this appraisal since I'm one of its contributors, but feel free to browse the project's source or subscribe to its dev and/or commits email aliases and make your own assessment.

Unfortunately, it has become more obvious as the project progresses that when our clients say "compiler" they really mean a full SDK, similar to what is delivered by the JDK. In particular, our management just assumed that a version of the javadoc tool which understands JavaFX Script would magically appear without any stated requirements or staffing. So we had a sub-project with a short deadline, no engineer available, and frustrated customers.

To make matters worse, javadoc engineers are hard to find since the job requires two unique skill sets: compiler engineering and web designing. Why does the JDK's javadoc output look dated? Because compiler engineers have owned it for the past few years. Why was it lagging behind the language a few years ago? You guessed it, our doc-writers were supporting it. Now, our team understands compilers, obviously, but none of us have any design skills worth noting. However, we have some engineers with great design skills on other teams. The "correct" solution would be to pull one engineer from each team and have them work together, but there wasn't time nor anyone available. Sound familiar?

What we did was follow the Unix rules for tool development: break the task apart, define a tool for each part, and use ASCII text to communicate between them. I wrote a simple doclet that dumped all information available from the Doclet API to an XML file (other people have done this over the years), then copied the JDK's javadoc source and enhanced it to provide JavaFX Script-specific information for that doclet (the doclet also works with Java sources when used with the JDK's javadoc). Joshua Marinacci then wrote an XSLT translator to generate XHTML pages similar to what javadoc's standard doclet creates. We use this tool to generate the project's UI Runtime documentation, and soon, all JavaFX Script-based API. The full tool source is here.

This divide-and-conquer strategy really pays off. Neither Josh nor I put much time into this project (as shown by how short both the doclet and XSLT script are), so our main jobs weren't impacted much. This approach also makes it much easier for our community to contribute: don't like the (currently primitive) output? An XSLT file is much less intimidating than javadoc's source, so jump in and make it better. But why limit ourselves to one output format? Just use the tool's -xsltfile option to use your own translator. And why limit ourselves to documentation generation? That XML file defines a model of any JavaFX Script and/or Java-based program, which can be used by other tools. As the Unix tool masters learned early on, breaking a big tool up into smaller, specialized tools opens the door to all kinds of unanticipated uses.

Elephants and the JavaFX Script Compiler

I don't know what it is about elephants, but they sure work well in analogies. Whether we are ignoring them, seeing pink ones or trying to sell white ones, elephant analogies seem to communicate ideas well. An elephant analogy came to me when I was recently grilled about exactly when the JavaFX Script compiler team will deliver our first milestone release. "I can't give you an accurate date," I said. "It's like pushing an elephant through a door*; until a critical mass makes it past the threshold you just don't know when you'll be finished. Once you pass that threshold, though, the rest happens quickly and in a manner that can be more accurately predicted." And then the tension in the room broke, as I think everyone has been in that situation sometime in their respective pasts.

In a way, this compiler project has turned out to be very similar to some of the GUI toolkit ports I've worked on in the past. We're making lots of measurable progress, which anyone can monitor in our test/features directory; for example, we recently implemented support for our "big three" language hurdles: sequences, multiple inheritance, and functional attributes (aka closures). Since the primary focus of JavaFX Script is as a domain-specific language for Rich Internet Applications, however, few people want an early access release of what we have so far -- like GUI toolkits, it doesn't get interesting until you can start working visually. So even though the JavaFX Script UI runtime needs an overhaul, we're porting it as is for the first release so those necessary GUI features are there.

Another similarity this project has to a GUI port is that most graphical toolkits have a few core components that depend upon most of the rest of the toolkit; call those classes Widget, Component, JComponent, Window, (graphic) Node, it doesn't matter -- there are so many benefits to sharing code between GUI components that these elephant-sized classes are just part of the GUI toolkit territory. So porting a GUI toolkit means that often there will an excruciating period where there is little visible progress as you work through all the dependencies, and then your first window appears, and then most of the remaining toolkit seems to just fall into place quickly. That's what happened many years ago when I was part of a team porting Presentation Manager from OS/2 to CTOS (which was about as unlike OS/2 as could be possible in those days). For several weeks, we slogged along without any visible progress (as voiced daily by our frustrated management), then we finally got the login panel showing and, in less than a week, all of the core applications were up-and-running. That login application was the critical part of our elephant, since the closure of its toolkit requirements encompassed most of the system. It wasn't really the login panel itself, of course, because whatever application is chosen first will be the hardest.

This is all a long-winded way of saying that we are really close toward delivering our first milestone release, but when the exact date will be remains unknown. If anyone is interested in monitoring our progress, check out our JIRA issue tracking system (courtesy of Atlassian), and/or subscribe to our developers alias (comments from experienced elephant pushers are welcome). Once we hit this first milestone, we'll be able to provide a much better road map for the remainder of this release.

*No elephants were hurt during the writing of this blog entry.

The Birth of the JavaFX Script Compiler

Today a new JavaFX Script compiler incubator project, openjfx-compiler went live. Yes, it has source code, issues, mailing lists and a wiki, but the compiler itself actually does very little right now (although Chris Oliver did offer a nice tease). So why open it now? The answer is that our team wants to open not just its source, but the design and development of the compiler itself. We are also asking for feedback on the JavaFX Script language to make it fully specified and compilable.

If you have an interest in watching or participating in a compiler for JavaFX Script, please join our project and help shape its future. If the past couple of months is any indication, it's going to be fast, furious, and fun!

Are Closures Just Delegates?

Finally, a Good Use for Finalizers

Finalizers bit me hard back in the JDK pre-1.0 days, because they were originally used to free the Windows resources from AWT graphic objects. This technique gave Tumbling Duke the power to cause the Blue Screen of Death, but such power is cannot be entrusted to a mere applet, or for any class for that matter. Any class that allocates a critical resource needs an explicit "close", "release" or similarly named method in its API. Its clients must then always use that method.

The problem is that a library provider cannot always regulate its use, or misuse, by developers who use that library. The java.io documentation, for example, can warn, argue, even plead that developers close file streams after using them, but it cannot enforce that requirement. So what a lot of library engineers do is add a fallback routine in a finalize method to check whether a resource has been released, and if not, release it during finalization. It's an ugly hack, but often necessary to avoid granting Tumbling Duke-like powers to their client programs.

But cleaning up after one's messy clients doesn't encourage good behavior on their part. I found this to be true while on vacation this summer with our children, who didn't understand why food wrappers cannot just be thrown on our hotel floor since a maid will pick them up later. "Because you have to" may work for making children clean up after themselves (it didn't for me, but maybe for other parents), but such an approach is guaranteed not to work for developers. As long as the maid (or library) silently cleans up, messes will be left to clean.

But what if the maid left a nasty note whenever such a mess was left? Something like (using java.util.Logger):

protected void finalize() throws Throwable {
   if (handle != null) {
       Logger.global.log(Level.WARNING, "my handle not released"); // new
       release();
   }
}

private Throwable trace;
...
   // during handle allocation
   callerTrace = new Throwable("handle allocation");
...
protected void finalize() throws Throwable {
   if (handle != null) {
       Logger.global.log(Level.WARNING, "my handle not released", trace); // new       
       release();
   }
}

Easy Version Support with ClassLoading

• NetBeans supports many different JDKs, each of which have their own version of javac; and
• The Mac OS X includes the javac classes in its bootclasspath (and supportable products shouldn't whack the bootclasspath if possible).

    private static class GJASTClassLoader extends URLClassLoader {
        private final PermissionCollection permissions = new Permissions();

        public GJASTClassLoader(URL gjastJar) {
            super(new URL[] {gjastJar}, Factory.class.getClassLoader());
            permissions.add(new AllPermission());
        }

        protected Class loadClass(String n, boolean r) throws ClassNotFoundException {
            if (n.startsWith("com.sun.tools.javac") || n.startsWith("org.netbeans.lib.gjast")) {
                // Do not proxy to parent!
                Class c = findLoadedClass(n);
                if (c != null) return c;
                c = findClass(n);
                if (r) resolveClass(c);
                return c;
            } else {
                return super.loadClass(n, r);
            }
        }

        protected PermissionCollection getPermissions(CodeSource codesource) {
            return permissions;
        }
    }

public interface ErrorChecker {
    int parse() throws CompilerException;
}

public final class Factory {
    private static Factory instance = null;
    private static Constructor newErrorChecker;
    
    public static synchronized Factory getDefault() {
        if (instance == null) {
            instance = new Factory();
            Class[] newCheckerTypes = new Class[] {
                ECRequestDesc.class
            };

            File gjastJar = InstalledFileLocator.getDefault().locate("modules/ext/gjast.jar", "org.netbeans.modules.javacore", false);
            try {
                ClassLoader loader = new GJASTClassLoader(gjastJar.toURI().toURL());
                Class c = Class.forName("org.netbeans.lib.gjast.ASErrorChecker", true, loader);
                newErrorChecker = c.getConstructor(newCheckerTypes);
            } catch (Exception e) {
            }
        }
        return instance;
    }

    public ErrorChecker getErrorChecker(ECRequestDesc desc) {
        try {
            return (ErrorChecker) newErrorChecker.newInstance(new Object[] { desc });
	} catch (Exception e) {
	    Throwable t = e.getCause();
	    throw new RuntimeException("Cannot create errorChecker: " +
                                       t != null ? t : e);
	}
    }
}

No Regrets with Undo

    public void setLocation(int x, int y) {
        currentX = x;
        currentY = y;
    }

    public void setLocation(final int x, final int y) {
        undo.add(new Undo.Entry() {
            public void undo() {
            }
            public void redo() {
                currentX = x;
                currentY = y;
            }
        });
    }

    public void setLocation(final int x, final int y) {
        private final int oldX = currentX;
        private final int oldY = currentY;
        undo.add(new Undo.Entry() {
            public void undo() {
            }
            public void redo() {
                currentX = x;
                currentY = y;
            }
        });
    }

    public void setLocation(final int x, final int y) {
        private final int oldX = currentX;
        private final int oldY = currentY;
        undo.add(new Undo.Entry() {
            public void undo() {
                currentX = oldX;
                currentY = oldY;
            }
            public void redo() {
                currentX = x;
                currentY = y;
            }
        });
    }

'Tis a Gift to be Simple

'Tis a gift to be simple, 'tis a gift to be free,
'Tis a gift to come down where we ought to be,
...
To turn, turn will be our delight
'Till by turning, turning we come round right.
-- Old Shaker hymn

This work is licensed under a Creative Commons License.