Category Archives: javafx

Java’s answer to Silverlight and Flex

JavaFX Experiments – Order of Declaration Matters

Given the following piece of JavaFX Script

import javafx.scene.CustomNode;
import javafx.scene.Group;
import javafx.scene.Node;
import javafx.scene.shape.Rectangle;
import javafx.scene.paint.Color;
import java.lang.Math.sqrt;

class C extends CustomNode
{
    // Test #1: Commented out
    //var node: Group = Group {};

    protected override function create():Node
    {
        return node;
    }

    public var data:Number[] on replace olddata
    {
        for (item in data)
        {
            var side:Number = sqrt(item);
            insert Rectangle{
                width:side height:side
                stroke:Color.RED strokeWidth:2 fill:Color.TEAL
            }
            into node.content;
        }
    }

    // Test 2: Comment out
    var node: Group = Group {};
}

C { data: [21000, 10000]; }

One of these declares node at the end of the class, and the other declares it at the beginning of the class. Take a look at it for a while and see if you can guess the difference in behaviour?

Continue reading

JavaFX Fidelity

JavaFX gets to start on a clean slate, without burdens of compatibility with browsers. However, how well does it paint itself?

How are – say – Rectangles defined?

Is the startX based on center lines? or is it from the origin?

What about borders? Are borders painted to the bottom right of the origin?

How is the boundsInLocal defined?

Here is a piece of test code.

Rectangle
{
    strokeWidth:50 fill:null stroke:Color.BLACK
    x:0 y:0 width:200 height:200
}

and I didn’t like what I saw:

Rectangle with 50-pixel thick border

Overlaying a grid, we could see that the X and Y origins are indeed based on center lines.
rect2

The big disappointment comes from the boundsInLocal measurements:

Rectangle2D [
minX = -35.85533905029297, 
minY=-35.85533905029297, 
maxX=235.85535430908203, 
maxY=235.85535430908203, 
width=271.710693359375, 
height=271.710693359375]

This doesn’t make any sense at all, and is going to make laying out components properly that much harder.

JavaFX 1.0 considered

JavaFX 1.0 is finally out of the gate. There are probably many Java engineers and architects who are trying to figure out this technology and see how it could apply to their existing projects. Here is my assessment. Note this applies to JavaFX 1.0.

JavaFX 1.0 is not ready as a Flash replacement in public-facing projects

While slow start-up time has been largely addressed by JRE 1.6 update 10,  it is not widely deployed (3.7%). For some strange reason, my machines would not install JRE 1.6u10 until JRE1.6u7 has been installed. Perhaps Sun engineers could explain why?

The runtime is still heavyweight. When the applet starts up initially, my development machine – which had Netbeans loaded – started thrashing the HDD, and the browser’s message loop was tied up for about 10 seconds. On lesser equipment, running JavaFX applets will be a distinct negative experience.

Furthermore, the new (applet) browser plug-in only works on FireFox 3 and Internet Explorer. There has been reports of browser instability, especially on the Mac.

JavaFX 1.0 will have mobile runtime – but not yet (as of Dec 2008)

Sun is positioning JavaFX at the mobile devices market, but no runtime have been released yet. Note that although JavaFX builds on the JVM and applet technology, it uses native DLLs to take advantage of underlying graphics chip. Conservative engineering means one has to be judicious in applying special animations and effects, especially on the mobile platform. I noticed that the JavaFX SDK ships with a JavaFX emulator (in the javafx/javafx-sdk1.0/emulator directory), I tried it, but didn’t have much luck with the pathanimation demo.

However, there is no doubt behinds Sun’s determination to see JavaFX succeed. Sun has pulled engineers from Swing and other projects to ship JavaFX 1.0.

JavaFX 1.0 is not ready for line of business applications on the desktop

Don’t get me wrong, JavaFX can be very productive environment to develop in, compared to Swing. Furthermore, JavaFX is (apparently) embeddable in a regular Swing application. However, the javafx.ext.swing package does not contain a DataGrid implementation, nor provides any guidance on how to handle virtual tablemodels. POJO classes will have to be rewritten to support property change notifications. For companies willing to experiment, there are several projects which implement custom classloaders to retrofit java classes with this ability. Sun should annoint one for use in their internal projects in order to improve code-quality.

JavaFX 1.0 is suitable for internal test deployments of media applets, games and simple proof-of-concept applications

We can’t get to JavaFX 2.0 without getting to JavaFX 1.0 first. While the platform is relatively immature, it is still useful for simple scenarios. In a corporate environment, where there is plenty of bandwidth and where standard operating environments is relatively easy to specify, JavaFX 1.0 can be useful for proof-of-concept applications.

Technical assessment of JavaFX Script

Java as a language is hobbled without a macro system, and as a consequence, JavaFX script has to be invented to

  • remove the tedium when writing plain objects with propertyChange support,
  • improved support for background animation threads and
  • scenegraph layout code that reads more like layout than code.

It is somewhat surprising that Sun has not gone down the route of retrofitting Java with syntactic sugar, as Microsoft did with C# did using object initializers, but is introducing a brand new language instead.

Pragmatically, Sun has chosen not to standardize JavaFX script. This leaves the door open for more language tweaking. However, JavaFX script still lacks the dynamism of Javascript. Perhaps Douglas Crockford can show us how to flex JavaFX around as he did with Javascript.

JavaFX runtime vs HTML

I hold some strong opinions regarding this. Out of the three RIA platforms from Microsoft, Adobe and Sun, only Microsoft’s Silverlight retains the advantages found in web applications. These are

  • Text selection
  • Bookmarkability
  • Text search

The JavaFX 1.0 runtime to date will not render rich text. JavaFX content is not indexable by web crawlers.

As such, JavaFX is not a substitute for text-heavy applications, like a bug tracker, or a blog – a web application’s equivalent of a “Hello World”.

There is no CSS support in JavaFX 1.0 [thanks El Cy], which is like programming without variables. One will have to touch sources at multiple points to effect a style-change.

The development experience is poor when compared to HTML. JavaFX is compiled rather than interpreted. As such, think of JavaFX as first Java, second Web, and has a lot of ground to catch up before it gains the same kind of ease-of-use compared to HTML.

From an adoption standpoint, Sun may gain mindshare of applet developers (from a very low or non-existent base), but will struggle to convince the millions of web-developers out there that Edit-Compile-Debug is more desirable than what they already have.

Conclusions

JavaFX 1.0 is not ready for prime time deployment. However, given Sun’s posturing, it is safe to conclude that Sun will continue to throw resources at the client-side. In order to ship JavaFX, a host of long neglected client-side bugs and issues have already been addressed. Watch Sun, and I can’t wait for JavaFX 1.1.

I’d appreciate any comments, corrections or questions.

Has the JVM design been holding back Java?

[Note: I've reposted this (with minor edits) as my original post got accidentally deleted. Thanks to Google cache]

Why is it? Why is it that Java applets -despite having the first mover advantage – achieved little traction. While Flash – a tool which targets graphic designers originally – continue to gain mindshare, and is now a serious player in the application space with Flex?

Perhaps it is because applets suffer from slow start up times. Maybe it is because applets crashes browsers when they become non-responsive. Perhaps it is due to heavy resource usage.

None of these are Java’s fault.

The latest client-side offering from Sun – JavaFX – improves the language, but does nothing about the underlying JVM itself (more about JRE 1.6u10 later). JavaFX is a fine language, once you get past the YAML syntax. Unfortunately, the JVM itself is the issue. JavaFX or not, Sun will not see JavaFX overtake Flash on most web pages.

When Flash 1.0 came out, it supported streaming bytecodes, and movies played immediately. JVM’s design requires all libraries to be downloaded, and then verified before playing in the sandbox. [Edit 18-Sep-2008: lispnik pointed out that this has been addressed in Java 6 Update 10]

The JVM implements share-nothing class libraries1, every new JVM process requires run-time libraries to be loaded up separately. This adds another block of run-up time before any screen is visible.

This makes me wonder if the JVM has a fundamentally flawed approach when the use-case is to run in a browsed environment, i.e. where people are moving from web page to web page quickly, and only having a taste of your application, and sometimes, involuntarily, as in the case of a banner ad1.

For browsing environments, I contend that Sun should have bundled some sort of interpreter in the VM, that can process a streamable language, in the manner of Flash. Sure, it is not Java, but it would have guided the evolution of the JVM.

Looking after little details matter. If Sun had cared about applets, and tuned it for lower resource usage, we would have arrived at MultiVMs and OSGI years ago.

The Java camp has a reputation for dogma, e.g. rejecting delegates in favour of anonymous inner classes, static methods instead of standalone functions. There are promising signs of change. Invokedynamic is nearly here – thanks to realization that the JVM needs to support dynamic languages.

Java 6 Update 10 saw a flurry of updates to the JVM precisely to support JavaFX better. This goes to show how little work has been put in to over the past ten years. It is not until Sun – with back against the wall – and a big competitor eating it’s lunch for breakfast, that Sun finally pays attention.

It is late. But not too late. Sun engineers ought to ask themselves this question. “JVM is everywhere. What is Flash doing right but we aren’t?”

 Reposted Comments

:

  1. No. 2 — September 4th, 2008 at 11:55 pm
  2. Sun engineers ought to ask themselves this question. “JVM is everywhere. What is Flash doing right but we aren’t?”
  3. Engineers? Strategists rather.
  4. Matt Grommes writes:
    No. 3 — September 5th, 2008 at 12:44 am I believe the newest update of the JVM (included with the JavaFX package) includes a rework where it will only download what that app needs to start up, then it downloads other libraries as needed later. So this at least seems taken care of.

 

1Update 5 Sept, I was wrong. See this
2Incidentally, addressing this use-case on the server-side could be a boon for Java on shared hosters. I would like to see the JVM be a viable competitor to PHP. See Matthieu Riou.

Has the JVM design been holding back Java?

Update:Looks like the post has been linked from DZone. Tell me what you think? What kind of projects would you choose Java applets over Flash or AJAX?


After all these years, Java’s applet has not seen much adoption, while Flash continue to gain mindshare. Applets suffer from slow start up times, crashing browsers, heavy resource usage. The latest ‘solution’ from Sun is to keep the java libraries in the disk cache.

The latest client-side offering from Sun – JavaFX – improves the language, but does nothing about the underlying JVM itself (more about JRE 1.6u10 later). JavaFX is a fine language, once you get past the YAML syntax. Unfortunately, the JVM itself it the issue. JavaFX or not, Sun will not see JavaFX overtake Flash on most web pages.

When Flash 1.0 came out, it supported streaming bytecodes, and movies played immediately. JVM’s design requires all libraries to be downloaded, and then verified before playing in the sandbox.

The JVM implements share-nothing class libraries1, every new JVM process requires run-time libraries to be loaded up separately. This adds another block of run-up time before any screen is visible.

The JVM has a fundamentally flawed approach when the use-case is to run in a browsed environment, i.e. where people are moving from web page to web page quickly, and only having a taste of your application, and sometimes, involuntarily, as in the case of a banner ad1.

For browsing environments, I contend that Sun should have bundled some sort of interpreter in the VM, that can process a streamable language, in the manner of Flash. Sure, it is not Java, but it would have guided the evolution of the JVM. For example, we would have arrived at MultiVMs and OSGI much faster.

The Java camp has a reputation for dogma, e.g. rejecting delegates in favour of anonymous inner classes, static methods instead of standalone functions. There are promising signs of change. Invokedynamic and Annotations are nearly here, thanks to realization that the JVM needs to support dynamic languages, and thanks to competition from the .Net camp.

Sun engineers ought to ask themselves this question. “JVM is everywhere. What is Flash doing right but we aren’t?”

1Update 5 Sept, I was wrong. See this
2Incidentally, addressing this use-case will also address resource usage on shared hosters, making Java a viable competitor to PHP. See Matthieu Riou.

Browsers will Rule Mobile Devices

Five years ago, when prototyping some apps for PDAs, I’d never consider HTML + javascript. This is because there are enough form factor issues as well as browser incompatibilities to keep one awake all night.

Things have changed.

  • WebKit seems to have gained ground in the mobile space, giving compatibility a much needed shot in the arm

  • mobile devices have become more powerful

Self-interest drives mobile device manufacturers to improve their support of Web Applications.

Mobile device manufacturers do not particularly care whether you build applications in Java or HTML+javascript. All they really care about is selling more devices. Any device that can make use of existing applications (i.e. the web) is going to be important.

Just as Microsoft was careful not to break backwards compatibility from DOS to Win 3.1 to Win NT, mobile device manufacturers have a business reason to support HTML.

Read this to mean browser support is only going to improve.

Against this backdrop, JavaFX, Adobe Flex and Silverlight will have to work very hard to woo the web development crowd, and not count on winning by default as they have had in the past.

Postscript On the other hand, there is no reason why mobile devices can’t support everything. Nokia is now supporting Silverlight.

A concrete proposal for inlining JavaFX

Jan Erik calls me the “high IQ” type. Unfortunately, I think he means “impractical” and “living in an invory tower”.

The idea of a inlining JavaFX script is actually a smaller and incremental goal. It is practical and is achievable. It will allow people who don’t have the JavaFX SDK to experiment with the technology, within the browser, just as they have been doing with HTML.

The inlining proposal goes somewhat like this…

    <l
    JavaFX script lives in a <script /> section on a Web Page. A little bit of javascript can be used to extract javafx script from HTML DOM and then pass it to an JavaFX interpreter running in the applet.

    Currently, Silverlight is inlineable. There are also some XForms plugins which work in the same manner. So we are not talking about a new fangled technology here. Someone else has done the work to show it can be done. SIFR is another example of inlining, where a Flash applet is used to render beautiful fonts in headings.

    Java applet plugins are pervasive, so there is little issue of waiting for 10 years for cross browser support.

    Jan belongs to a rare class of people who can both code and do beautiful graphic design. My hope is that by making JavaFX accessible and easy to tinker with, it might attract a bigger crowd of people outside the programming community who are not so design-challenged.

JavaFX and Disembodied Reality

Jan Erik opined insightfully about JavaFX’s prospect:

Java.net is disconnected with reality. For every guy who knows Swing/Java there are a 1000 guys who know HTML/DOM/CSS/Javascript. Silverlight is only marginally important because Microsoft controls 90 percent of the desktop marked and is the company behind C#.

JavaFX will ride the JRE in the same way AIR is riding Flash and PDF. So it’s not irrelevant. The problem is that most Java developers don’t know jack shit about developing user interfaces.

Simon Brown has also voiced similar concerns

Why are Sun doing this? : I don’t know, I don’t understand the impetus for doing this, aside from throwing the Java brand and an inferior Flex/Silverlight competitor into the RIA mix.

You know, Jan’s opinion hits pretty close to home truths. I have been mulling over what constituent can JavaFX actually serve well, despite claims from Sun that it is WORA desktops and mobiles.

  • Most developers know very little about design (or care about design), with the top 10 percentile remotely capable of mimicking existing designs.
  • Existing tools to lay out swing components is adequate. Not much bling, but it is functional.

On the other hand, any one who had played with JavaFX would dread to go back to a world without the “bind” keyword.

Secondly, design is like any other skill. It is possible to think about design algorithmically. “mac is not a typewriter” is one such book.

Thirdly, organisations who would like to migrate their user interfaces from Swing might consider JavaFX ahead of Flex, simplly because it markets itself as 6/8th Java, 2/8th FX. Of course, in reality this is not true, but – hey – word associations worked for JavaScript, and that’s not even Sun’s product. JavaScript was a Netscape invention.

JavaFX Coverflow Part 2

Continuing with our previous example, we now create a CustomNode Coverflows, which contain 11 covers.

A new function called positiveOrZero is introduced so that the tilt angle can be negative.
A fill attribute is introduced to the Cover class and it is bound to the Rectangle.

/**
 * Coverflow.fx 
 **/
package coverflow;

import javafx.application.*;
import javafx.animation.*;
import javafx.input.*;
import javafx.scene.geometry.*;
import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.effect.*;
import java.util.Random;

var rnd : Random = new Random();

class Cover extends CustomNode
{
  attribute height:Number = 100;
  attribute width:Number  = 100;
  attribute angle:Number  =  10; /* 0 to 10 */
  attribute fill:Color    = Color.WHITE;

  function positiveOrZero(v:Number):Number
  {
    if (v &gt; 0) { return v; } else { return 0; }
  }

  function create():Node 
  {
    this.opacity = 0.1;
    return 
      Group 
      { 
        content: 
        [
          Rectangle
          {
            width: 100 height: height x: 0 y: 0
            fill: this.fill;
            effect: Reflection { topOffset:0.0 topOpacity:0.30},
          },
        ]
        effect: 
          PerspectiveTransform
          {
            llx: bind translateX+0.0    lly: bind translateY+height*2 - positiveOrZero(-angle)
            lrx: bind translateX+width  lry: bind translateY+height*2 - positiveOrZero(angle)
            ulx: bind translateX+0.0    uly: bind translateY          + positiveOrZero(-angle)
            urx: bind translateX+width  ury: bind translateY          + positiveOrZero(angle)
          }
      }
  }
}

class Covers extends CustomNode
{
  attribute covers:Cover[] = 
    for (i in [0..10]) 
      Cover { 
        translateX: if (i==5) {125+i*25} else if (i&gt;5) {150+i*25} else {100+i*25}
        translateY: bind this.translateY
        angle: if (i5) {-10} else 0 
        fill: Color.rgb(rnd.nextInt(255), rnd.nextInt(255), rnd.nextInt(255))
      }; 

  function create():Node
  {
    this.covers[5].opacity = 1.0;
    return
      Group
      {
          content: covers;
      }
  }
}

Frame
{
    visible: true
    title: "Coverflow Part 2"
    closeAction: function() { java.lang.System.exit(0); }
    width: 800 height: 300
    stage: Stage
    {
        fill: Color.BLACK
        content:
        [
            Covers { translateY: 20 },
        ]
    }
}

JavaFX and Unicode source files

The JavaFX compiler supports unicode source files, just as Java compiler does. To use them you need to

  • make sure the source does not include the three-byte byte-order-mark
  • call javafxc with the -encoding parameter
JavaFX and Unicode Text
JavaFX and Unicode Text
javafxc -encoding UTF-8 Chinese.fx
javafx Chinese

And now for the example

import javafx.application.*;
import javafx.scene.Font;
import javafx.scene.text.Text;
import javafx.scene.paint.Color;

Frame {
  title: "JavaFX Unicode Example"
  width: 400 height: 300
  stage: Stage
  {
    content: Text {
      x: 20 y: 150  
      fill: Color.ORANGE  
      content: "我也会说华文"
      font: Font { size: 50 }
    };
    fill: Color.BLACK;
  }
  visible: true
}

This is a prerecorded message