Tuesday Mar 15, 2011

preparing for migration to blogs.oracle.com

I am preparing for the migration to blogs.oracle.com.

Sunday May 13, 2007


As you probably heard at JavaOne, F3 is now called JavaFX. The initial public release is available here: http://openjfx.org. Please join me there for discussion and further development.

Tuesday Mar 20, 2007

JavaOne 2007

I'll be presenting a technical session on F3 at JavaOne this year on Wednesday, May 9.

This F3 example won't make it into my session, so I'll just post it here.






Friday Feb 23, 2007

MacOS Dashboard Widgets

I recently got a Mac and took a look at their dashboard widgets. Such widgets consist of several files:
  • An HTML file
  • A CSS file
  • A JavaScript file
  • Image files

Of course, I had to try to see how hard it would be to do the same thing in F3. Here's the F3 version of the Calculator widget:

Unfortunately, it's currently impossible to create transparent windows in Java on non-MacOS platforms, so in those cases you won't see the dropshadow and rounded corners.

It only took a few minutes to write the visual elements in F3 (I just used F3Pad). And about another hour to add the behavior (I borrowed the design of the non-visual part of the calculator from an ancient Java applet I found on the net).

F3 Source:


Original Source:


Wednesday Feb 21, 2007

3D and Faux 3D

Simple Faux 3D effects are common in 2D graphics, however the quality and performance of such effects is limited. Eventually, I want to integrate a true 3D declarative scene graph API into F3. The goal isn't to provide a massively scalable 3D engine, but rather to make it easy to program smaller scale 3D effects with high performance.

In the meantime, since you can call Java from F3 it's possible to directly use GLJPanel in F3 and call JOGL API's directly to mix 2D and 3D effects.

Here's a simple example which contains a 2D rectangle, JButton, and JTextField together with the well-known Gears 3D example in the same F3 canvas:



It's also possible to do faux 3D in F3. Here's an example that was inspired by in part by the Flex Display Shelf and partly by the ITunes Movies page. Note ITunes is true 3D, however. The scrollbar and artwork mimic ITunes but the layout is similar to the Flex example.



Wednesday Feb 07, 2007

F3 Visual Tools

So far I haven't spent time trying to develop serious visual tools to support F3 development, however once the language and API's have stabilized that's definitely something I want to do.

Useful visual tools include simple color choosers, linear and radial gradient editors, widget layout editors like Matisse, vector drawing tools like Inkscape and Illustrator, and image processing tools like Photoshop.

For each such visual tool, there are programmatic means to achieve the same effect. As a result you have to find a balance between hand crafting graphics in a visual tool and generating them programatically. In some cases the former is the more effective approach, in some cases the latter, or a mixture of both.

I don't have definitive proof yet, but I believe using F3 to develop such tools should make it far easier than what the competitors are doing (with the possible exception of Microsoft Expression), since other than Matisse all of those mentioned above are written in C.

As a partial demonstration, here's a basic F3 implementation of a "Pen Tool", which is a tool for drawing a sequence of connected cubic Bezier curves. I am not an expert or even a regular user of any of the above mentioned tools, so it took me a while to figure out how "Pen Tool" is supposed to work, but once I understood that it was straightforward to implement.

Each time you click on the canvas a new point and two new invisible control points are added to the curve. If you drag the mouse before releasing it you can adjust the tangent of the curve at that point (in effect by changing the values of the control points). If you hover near a point you'll see two small circles connected by a line and a larger circle surrounding the point. Dragging the larger circle moves the point. Dragging the smaller circles adjusts the tangent of the curve at that point (there are tooltips to that effect).

In this demo you can't delete points or insert points in the middle of the curve, however it does have infinite undo/redo with CTRL-z (undo) and CTRL-y (redo).

Here's a link to the source code.

The model of the curve is simply an array of points. The first point is a dummy control point. Following that points are added according to the following pattern: [pt, cp, cp, pt, cp, cp, ...], i.e. a point followed by two control points. For each point its preceding and following control point must be collinear (on the same line) with it. The mouse drag handlers for the control points implement this invariant when you drag one of the them by rotating the corresponding control point around the point.

From the array of points a Path is projected (with the F3 bind operator) having a MoveTo element for the first point, and CurveTo elements for each sequence of [cp, cp, pt] after that, which creates the visual curve. In addition, the circles and lines mentioned above are also projected from and bound to the same points in the array. As a result when the mouse handlers or undo/redo operations add points to the array or modify the coordinates of a point the visual elements (path, circles, lines) are automatically added, moved, or removed accordingly.

Monday Jan 22, 2007

More about F3

This was going to be a comment to a posting about F3 on Lambda the Ultimate, but got a little too big so I'm posting it here.

But I am posting this in the spirit of LtU as expressed by Ehud Lamm (the originator of LtU)

Note that from the perspective of LtU the expressiveness of the language constructs is the main thing, implementing them as efficiently as possible comes second: efficient implementation should be possible, but might still not exist in the marketplace.

The above quote is also very close to my original approach when I started F3. I knew from using Tcl/Tk in the mid-90's that high performance from F3 wouldn't be required for the vast majority of graphical user interface use cases. With Tcl/Tk all of the Tk widgets as well as my back-end code was implemented in C and Tcl was used simply to glue them together. And at that time Tcl was probably one of the slowest interpreters ever written as it actually reparsed the source code on every evaluation. So efficiency of the programmer in expressing such programs was my focus.

Although I don't think there's anything particularly innovative in F3 from a programming language point of view, my experience has been that the combination of features it provides proves more effective in expressing graphical user interface programs than other systems I've encountered (your experience may be different than mine). The language itself is only part of that. The libraries which provide useful abstractions for Widgets and 2D graphics and which, in particular, closely match the concepts used by graphic artists and content designers are also equally important.

Unfortunately, not having a background in math or formal logic, F3 doesn't have a formal basis. Prior to programming my primary interest was linguistics, so a lot my of opinions about what makes programming languages "expressive" comes from my observations and opinions about what allows us effective expression in natural languages.

Although I'm concerned that F3 may have fundamental flaws that haven't been exposed yet, I don't feel too bad about lacking a formal basis for F3, since to be honest I really never intended to write a programming language in the first place.

The F3 project was originally called GBTDS which stood for "GUI Builder That Doesn't Suck". I just wanted an easy way of creating GUI's.

I thought I could just create some visual tools where I allowed the user to define an object-oriented model, and then have them lay out widgets on the screen and somehow bind them to the model using a "stylesheet". My implementation of the model would automatically generate events whenever it changed and automatically update the widgets. Anyway, I originally wrote a working prototype of something like this (but without the visual tools). Unfortunately, it was a still a GUI builder that sucked.

There was always an impedance mismatch between the application model and the widgets and no effective way to really connect them together. I always had to add lots of extra attributes to the model as placeholders for things needed for the views or "hard-code" the styling. For example, if I had a Person class with a firstName and lastName attribute and I wanted to show a person's full name in the view, I had to add a fullName attribute to the model (and then write event handling code in Java to update it whenever firstName or lastName changed) in order to have something to bind the view to. In addition, each widget had to have special event handling plumbing to hook up to the model and special styling plumbing to hook up to the stylesheet, all written in Java (and there are quite a few widgets in Swing...).

It was obvious I needed a query language to project the model into a form that was suitable to bind to the widgets. So that's what I implemented next. Early on I recognized I needed dependency based evaluation of the query language to handle changes to the model. In the early versions this wasn't incremental, but rather reevaluated the entire query whenever any of its dependencies changed. I could reference such queries in the stylesheet and it was now much easier to express the styling of widget attributes. However, I still didn't have any reasonable way of expressing the structure and layout of widgets, and all the updates to the model had to be done through Java API's to my model (which was similar to programming through reflection, i.e. extremely tedious).

So next I added a procedural language, which used Java-like control structures and borrowed the update syntax from XQuery. This made it very easy to update the model compared to what I had before. In addition, I added support for list comprehensions to the query language (foreach, select) which allowed me to also declaratively project multi-valued attributes. Having all that I realized my "stylesheet" was really just the interface to the Widgets. So I ditched it and my Java Widget library, and wrote a set of F3 classes that wrapped the Swing widgets. Having done that I could pretty much write any Swing program declaratively all in F3. At that point I also implemented incremental dependency-based evaluation.

Although I could write any Swing program pretty easily there was obviously a large class of GUI's that I couldn't produce (including most of the demos you see on my weblog). So it was obvious I needed a declarative interface to Java2D as well.

Fortunately, a very talented young man, Jesse Grosjean, had written an excellent 2d scene graph toolkit based on Java2D called Piccolo. The conceptual model of Piccolo was very close to SVG, and I realized I could fairly easily implement F3 versions of SVG's declarative 2D graphics interfaces using Piccolo.

Once I had that, I could pretty much create any GUI or visual effect you find in Flash, Java, DHTML, or elsewhere, declaratively in F3 and started writing the demos you see today.

Anyway, as I said my original thinking was that I wanted an easy way of creating Model/View GUI's. To that end I wanted a simple, object-oriented system. The informal conceptual basis for this I borrowed from Martin and Odell.

To summarize the important points (informally):

  • Classes correspond to the concepts we use to identify the common characteristics of the things around us and how they relate to each other.
  • Thus a class declares a set of potential relationships (links) between objects.
  • Once an object has been classified we can navigate those relationships to discover its properties, i.e. the other objects related to it.
  • In F3 these properties are called attributes.
  • In F3 functions are queries that navigate links or produce new objects in terms of existing ones, but do not modify the links of existing objects.
  • In F3 all change consists of adding new objects or of adding, removing, or replacing the links between existing objects.
  • In F3 Events are simply notifications of object instantiation or of "link addition", "link removal", or "link replacement"
  • In F3 operations in addition to performing queries can sequentially perform one or more such link modifications. Such modifications may be sequenced with conditional logic and by selection and iteration over query results.
  • The values of an object's attributes may be specified either through explicit assignment or by means of a bound query. In the latter case implicit modification of the attribute occurs whenever the inputs to the query expression change and produce a new result.
  • So when a change occurs one way to specify the "effect" is to define a bound query that expresses how other objects depend on it.
  • The other way to respond to change is by making further explicit modifications using triggers. A trigger is an operation that is performed whenever an insert, delete, or replace event which applies to it occurs.

As far as the syntax of F3, it's intended to be familiar to mainstream programmers whose primary language is derived from C (C++, Java, JavaScript, PHP, etc), but also includes features from query languages (OQL, XQuery, SQL).

F3 is still a work in progress.

When F3 is open-sourced the syntax of the language and API's will be open for discussion and change.

Thursday Jan 11, 2007


My wife thought this flash application was cool, so I spent the afternoon trying to recreate it in F3.

The F3 version isn't complete and differs in some details but seems like a reasonable approximation.

This example is typical of many Flash programs where the hard work is done by the graphic artists and the progammer's job is relatively easy: in this case I just laid out the images, implemented the animations based on location, rotation, scale, and opacity, and handled the mouse events.

Here's a link to a copy of the source code.

Tuesday Jan 02, 2007

F3 Tutorial

My colleague, Ricardo Rocha, has written an in depth explanation of one of the demos I posted earlier.

Here's his tutorial.

Tuesday Dec 19, 2006

Open Source F3: Where and When?

There have been quite a few comments to my postings asking when F3 will be publicly available.

For the record, I actually inadvertently made F3 public. I was just testing out my weblog. I thought it would reside in obscurity for the time being.

Since it was noticed I've tried to provide as much information about F3 as was feasible in the context of a weblog.

I can definitely tell you where you'll find open source F3 development, namely here: https://f3.dev.java.net. This project exists, however it's still private and doesn't contain the source code yet.

I don't have an exact date when it will be publicly accessible, but if I had to make a guess I'd say February 2007 is likely.

So, there you go. Thanks for your patience.

Thursday Dec 14, 2006

F3 and HTML

Although I'm not a fan of XML, I do consider HTML+CSS the most useful tool available for composing styled text. We plan on incorporating the Flying Saucer Java XHTML renderer into F3 eventually.

One of the things I dislike about HTML is the total lack of error reporting. If you have mistakes the output just looks funny and it's a nightmare to debug.

Since Flying Saucer requires valid XHTML and CSS it's possible to provide high quality validation for both the HTML content and CSS rules. Click the button at the bottom of this page to launch two demos:

  1. The first is a (very prototypish - I spent about 1.5 days on it) demo (written in F3) of an interactive XHTML/CSS renderer which performs XHTML and CSS as-you-type validation (I extracted the W3C CSS validator from their Java web-app for the CSS validation).

    The performance is bad right now because it's synchronously loading images, but hopefully it gives you some idea of what I have in mind. For example, you can browse www.w3.org with it, edit their style sheets and xhtml documents and see what happens.

  2. Since the XHTML renderer is a Swing component it's also possible to embed arbitrary F3 widgets inside the XHTML document.

    This is done with a special form of the HTML <object> tag, for example, like this:

       var button = Button {text: "Click Me!"}
       XHTML {
           text: bind
                 Here's a button: 
                 <object type='f3' data='{#button}'/>

    The above code embeds an F3 Button (underlyingly a Swing JButton) into the HTML content. The XHTML widget is the F3 wrapper for the Flying Saucer renderer. It renders the HTML content you assign to its text attribute.

    The # operator is F3's stringify operator: it converts the object reference of its operand to a URL which can later be dereferenced with the unstringify operator ?, e.g.

       var num1 = 20;
       var s = #num1;
       assert s instanceof String; // passes
       var num2 = (Number)?s;
       assert num2 == num1; // passes

    URL's created with # aren't permanent but only refer to the object in memory.

    In addition, it's possible to create hyperlinks that call back to your application by embedding such URL's as the value of the href attribute. The second demo shows examples of this (click the File->View Source menu to see the source code).

    The second demo is an example which floats one of the processing examples I previously posted inside the XHTML document.

Tuesday Dec 12, 2006

F3 Reflection and Query operators

A friend of mine who works at MIT libraries recently showed me a neat little AJAX data visualization program they developed called Exhibit.

This seemed like a good test case for F3 reflection and for its query operators, so I decided to try to see how hard it would be to do the same kind of thing in F3.

Below is a (partial) F3 equivalent of this Exhibit example.

The above demo also displays the F3 source code.

This is actually a plain Swing program (the F3 Canvas isn't used), but demonstrates the use of HTML templating with F3.

All of the filtering and sorting is actually done in 3 lines of code (take a look at DB.f3 and AttributeValueAssertion.f3).

Some things to note:

  • Attribute is an F3 reflection class analagous to java.lang.reflect.Field
  • Reflective access to the value of an attribute uses the [] operator with an operand of type Attribute, e.g.

       var bar = foo.class.Attributes[Name == 'bar'];
       foo[bar] = 2;
       // The above is analogous to the following Java code
       // Field bar = foo.getClass().getField("bar");
       // bar.set(foo, 2);

    is the reflective equivalent of

       foo.bar = 2;
  • The F3 order by operator is a binary operator. The left-hand side is any list of objects. The right-hand side is an expression that must return a list of comparable objects. The right-hand expression is evaluated in the context of each element of the left hand side. The current element can be accessed with the . (dot) operator (as in XPath).

    For example,

       [1, 2, 3] order by -.


       [3, 2, 1]

Wednesday Nov 29, 2006

Poor man's Multi-VM

The most recent demos on my weblog are run as separate applications in the same JVM. In addition to its own F3 interpreter, each individual demo gets its own class loader, thread-group, and AWT event-dispatch thread. This is accomplished by using features also used in the applet plugin. Note that this approach isn't specific to F3, but could be used with any Swing application. You can manually kill the applications (which is implemented in the same way that applets are destroyed when you leave a web page). In addition, it installs a security manager that traps System.exit() and destroys the application context of the application rather than exiting the JVM. Some of the F3 demos may appear to start slowly, but that's due to the overhead of F3 or to the fact that many images are being loaded from the network or file system, and not due to the JVM. Self-contained Swing apps (such as SwingSet2) would start instantaneously.

I was prompted to do this by Gilad Bracha (who unfortunately left Sun recently). Gilad told me that he didn't believe in Java GUI's for two reasons:

  1. Start-up time
  2. Footprint

He mentioned a test they did comparing the SmallTalk Squeak IDE, which started up in about 3 seconds and used about 25M of memory, compared to Netbeans which in this test took a minute to start up and used over 100M. But of course you may not consider this a fair test. So next they simply took a screenshot of the Squeak IDE and then wrote a tiny Java program just to display the screenshot. This second program took 3 seconds to start up and also used about 25M of memory, but in the first case we had a fully-functioning SmallTalk IDE and in the other just a bitmap.

I personally found his arguments undeniable.

I did my own tests where I ran 10 instances of SwingSet2 in separate JVMs versus in the same JVM but with separate application contexts. In the former case total memory use was 540M, in the latter 74M.

As I mentioned this approach isn't specific to F3.

I put a zip file containing the basic code to do this for regular Swing applications here (45kb).

Note: this is just example code to illustrate how you could do this.

The zip file contains the source and compiled code and some windows batch files to build and run it (Java 1.6 required to build, Java 1.5 to run).

There's only one class called JApplication. You call its main method with a class path and class name similar to how you run the java command, e.g.

java com.sun.JApplication -classpath SwingSet2.jar SwingSet2

When you run it the first time it creates a server socket on the local host and listens for subsequent connections. At the same time it creates a new thread group, class loader, and application context and runs the application you specified (i.e in this case SwingSet2). When you run it subsequent times it simply connects to the port and writes the command line argument over the socket. The original then creates a new thread group, class loader, and application context as above and runs it in the address space of the original vm. In addition, writes to System.out and System.err from that thread group are redirected back to the socket so you see the console output of your application as expected. It would also be possible to write a C program or shell script to launch your application (rather than using another JVM).

Finally, if you're using Java 1.6 it adds an icon to the system tray which has a menu to shut down the whole thing and also can display a window listing the running applications and which allows you to kill them manually.

Note that this example code doesn't handle security issues at all.

Tuesday Nov 28, 2006

More F3 Demos

Here are a few more F3 demos.

Several are replicas of Flash programs:

  1. Bentley Continental Flying Spur
  2. Lotus Cars USA
  3. Nike 2005 Home Page

Others are replicas of Java programs written by Romain Guy:

  1. Painter
  2. Spline Editor

There's also a (partial) replica of the Winamp MP3 player, which uses the pure Java JLayer MP3 player to play MP3 files and supports Winamp classic skins (use the Next/Prev buttons to switch skins). Interestingly, I never actually installed Winamp or ran it myself. I simply programmed the F3 version according to the skin specification. Winamp skins are actually just zip files containing Windows bitmap (bmp) files with certain conventional names and specific layouts.

A Google search demo using Google's soap API, which demonstrates HTML templating with F3, and also has a fancy search control based on artwork from a Yahoo widget.

Finally, there's a standalone version of the interactive F3 editor, "F3Pad". This was inspired in part by XAMLPad. Note that other than watching the XAMLPad video, I've never actually used it.

The demo launcher also includes all the demos I've previously posted. Remember if you're using Java 1.6 you'll need to click on the F3 icon in your system tray to shut down the whole application.

Saturday Nov 25, 2006

F3 Deployment

One of the comments to my earlier posts expressed some concern that a lot of demo code seemed to be all in one file.

That's just because they were quick demos.

F3 supports packages and imports as in Java. So you can divide your application into as many separate files as you like.

The F3 interpreter actually loads F3 classes by means of the Java class loader. So to deploy F3 code you simply archive it in JAR files as in Java and then make such archives accessible to the Java class loader.

Our F3 IDE plugins are also closely integrated with the corresponding Java plugins. There is no special F3 "perspective" or F3 project type. In both Netbeans and Eclipse, you simply use normal Java projects, create packages using the existing Java facilities and then create F3 files in those packages. The normal build process will "do the right thing" and archive your F3 code into the output jar file of your project.




« April 2014