Chui has posted 1 posts at DZone. View Full User Profile

Questions for Sun over JavaFX

08.21.2008
| 11447 views |
  • submit to reddit

Sun has released a JavaFX preview. Having played around with it, here are my questions.

  • Will using the scenegraph API conceivably consume less resources than a comparable app developed using DHTML? In Meebo is what’s wrong with web 2.0 (cached), Uncov writes that Meebo consumes 39Mb RAM over-and-above that of Firefox. Running a basic JavaFX app (JRE1.6u7) consumes about 33Mb “VM Size”, i.e. private process memory. Is JavaFX going to ditch flyweight rendering in Swing's JTable and switch over to Scenegraph-based tables instead?

  • Why is interpreted JavaFX script slow, when interpreted javascript is fast enough for client-side work? Web apps don’t necessarily have to compute prime numbers. Is it because browser's javascript interpreter (gasp) is more performant than the JVM?

  • Silverlight will consume markup generated from any web server. JavaFX requires a server-side compiler, or a precompiled script. Any client-side plugin ignores PHP at it’s own peril. Will Sun be shipping a JavaFX Script interpreter so that the browser can be used as a general canvas?

 

 

 

Published at DZone with permission of its author, Chui Tey.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Brian Sayatovic replied on Thu, 2008/08/21 - 9:20am

I honestly don't understand why Sun felt the need to build JavaFX.  I don't think ease of development is what has been holding back Java from proliferating beyond the enterprise.

To Chui's point about Silverlight being markup capable of being generated by any server, I think that is the key.  OpenLaszlo could get to this point, but they too seem too focusedon the server-side.

The only way to stop web 2.0 from becoming the next leaky abstraction is to come up with an open UI markup language that is NOT tied to any one programming platform.

David Lee replied on Thu, 2008/08/21 - 10:23am in response to: Brian Sayatovic

I agree with the why JavaFX sentiment, but the Java on the client and in the browser has been held up by JVM start up time, JVM size and the ridiculous security popups for applets and jnlp apps.  JavaFX apps load just like jnlp apps and I see this as a MAJOR problem.   Hopefully the consumer JRE will address most of the concerns,  it will have to if JavaFX is to have any chance at being successful.

Jacek Furmankiewicz replied on Thu, 2008/08/21 - 10:56am in response to: David Lee

Not to mention the proxy popup for password that still seems to be there for 6u10.

Jim Weaver replied on Thu, 2008/08/21 - 11:26am

Why is interpreted JavaFX script slow, when interpreted javascript is fast enough for client-side work? Web apps don’t necessarily have to compute prime numbers. Is it because browser's javascript interpreter (gasp) is more performant than the JVM?

The JavaFX SDK Prelease is not interpreted.  It compiles to JVM bytecode and in my experience has been very performant.  Interpreted JavaFX was just a prototype for the JavaFX SDK.

Chui Tey replied on Thu, 2008/08/21 - 2:35pm in response to: Jim Weaver

I realize that the SDK ships a compiler, but I assert that an interpreter would enjoy a wider audience.

GeekyCoder coder replied on Thu, 2008/08/21 - 4:21pm

"I realize that the SDK ships a compiler, but I assert that an interpreter would enjoy a wider audience."

 Hi Chui,

can you elaborate further why interpreter would allow JavaFX enjoy a wider audience ? Is it because the code is exposed like JavaScript so that user can run change it and refresh the content easily ?

Can you tell us what are the advantages of running interpreted versus compiled when JavaFX under the hood just compile and run the script. From technical point of view, the bytecode class file is generated but from user's point of view, I did not see that it is a concern as it is all transparent and user experience isn't affect whether it is running interpreted or compiled. At least the compilation improves on the performance.

Why make JavaFX behave like JavaScript and what is the advantages of doing so ? JavaFX is designed to develop desktop-like application running not only in browser but also in desktop and mobile platforms therefore I do not think comparing with JavaScript is appropiate as it is designed to embedded in html page.

 cheers....

 

Chui Tey replied on Thu, 2008/08/21 - 5:44pm

Thanks Geekycoder for your comments

  1. There are tens of millions of web developers who have already been trained to edit text in a file and refresh the browser to see their changes. Let us not make it any harder.
  2. There are millions of PHP developers. JavaFX can be used as a universal canvas (since IE doesn't support the canvas tag), so that you can, for instance, generate comments on this page in PHP
    content: [
     <?php foreach ($comment in $comments): ?>
       Text { content: "<?=$comment>" },
    <?php endforeach; ?>
    ]
    
  3. We should not estimate the power of "view-source" because it allows the knowledge of a few to be leveraged multiple times. All I know about javascript and DOM is from doing this.
  4. Inlining will permit existing web projects to be incrementally improved. Plugins that emit JavaFX script in Drupal, Wordpress, and other open source projects can be used to leverage adoption.
  5. Inlined JavaFX markup will be spiderable. No community-based website can adopt JavaFX if crawlers can't crawl their content.
  6. Inlined JavaFX brings the URL back into the equation. This ties in with 5, but in addition, allows links to content be embedded in emails, or other websites via hyperlinks. The browser is not perfect. For instance, look at the hacks Yahoo Maps have to implement in order to update the URL as you move around the map.
  7. I have just lost this edit once due to MSIE's popup blocker blocking the "Insert Code" tool button. Inlined JavaFX enables creation of a better text-editing widget that can be embedded within a page. To take this further, it is the cross-platform "contentEditable" that the Two-Way web has been waiting for.
  8. Inlined script can be more compact than compiled JavaFX. For mobile devices, compactness is a virtue. Here are the uncompressed sizes as a comparison.
  9. 1028 Perspective.fx
     221 Perspective$Intf.class
    4283 Perspective.class
     754 Perspective$1.class
  10. Interpreted script doesn't have to be slow. It is the effects which consume time. There are a few javascript coverflow effects on the web. Why not try them, and then as an exercise, implement them in JavaFX? You'd be disappointed to see that JavaScript achieves a better frame rate.

Incidentally, while I'm ranting, it'd have been better to create a class called transitions rather than animations. Effective transitions have different characteristics to timeline animations.

  • During transitions, event handlers are deactivated. For instance, as a window is minimized to the dock, clicking on the moving target doesn't actually talk to the actual program window.
  • Transitions are special effects. They are not "pure". Transitions is like "texture mapping", rather than "ray tracing". The scenegraph API is more like "ray tracing".
  • To implement transitions with good frame rates in JavaFX requires "faux" effects. Drop shadows, transitions, etc should be approximated. This really requires working outside the scenegraph API. For example, I'd take a bitmap snapshot, precalculate a few key frames, hide the original node , whizz the precalculated bitmaps through the canvas, and then display the node in its final position. I'd suggest the JavaFX engineering team have a look at how Flex does this declaratively.

Patrick Wright replied on Fri, 2008/08/22 - 2:46am

As far as the interpreter, I haven't seen anybody on the compiler dev mailing list (which I've been following since it opened last year) state that an interpreter isn't possible, just that their primary goal is writing a compiler for the language. I'd like to see an interpreter for JFXS again, as the JFX Pad app was a cool way to play around with the language. But the compiled code will handle large apps better, I assume. One advantage of developing the compiler is that they were forced to specify the language accurately, and to clear up a number of open issues from the original F3 prototype--at least, that's how I see it.

 

 Patrick

Chui Tey replied on Fri, 2008/08/22 - 5:01am in response to: Patrick Wright

Actually I posed this question in the Ask the Experts
3. Is the JavaFX interpreter going to be shipped with 1.6u10? Most web hosters support PHP and not java compilers, and that means if the applets can consume JavaFX script, PHP could be used to generate UI. This can help adoption. For example, silverlight supports XAML inlined with HTML.

and Joshua Marinacci has this to say

The old interpreted version of JavaFX is deprecated. The only way to build JavaFX applications now is to use the compiler. However, it shouldn't matter what your hosting company has.  You will compile the JavaFX application on your development desktop computer and only upload the binary jars and html to the website. From the webserver's point of view they are just binary files which are served to the user, the same as images or media files.

To be honest, a language specification shouldn't have to change regardless of whether it is interpreted or not. There may be some differences in compile-time vs. run-time type checks and exceptions, but that's about it. I believe that the assumption Sun made that compilation is always better than interpretation is errorneous, and will impede broader adoption of a fine technology.

Collin Fagan replied on Fri, 2008/08/22 - 10:07am in response to: Chui Tey

  1. There are plenty of programmers who work in an edit-compile-run pattern. Is that any less valid?
  2. What you seem to want is a new, more fully featured, markup language. You goal seems to be to generate content via a preprocessor like PHP. Thats cool but it's not really what JavaFX is all about. In JavaFX you can build a presentation layer and then add data. There is no good reason to mix data retrieval and UI definition. It's just how a lot of web technologies work. Google Web Toolkit builds the same kind of separation. The power of this style is that you take the server requirements out of the rich content delivery mechanism. With cheap PHP hosting I can build a Java or JavaFX applet that consumes data generated from PHP and MySQL. It's even less intensive on the server because there is no generation of markup, just data. I can also point the same front end to a Glassfish or Jetty back end, or even to a C# web service if I wanted. When you separate your data from presentation you build MORE opportunities to build a development community, not less because you components can be consumed by a larger group.
  3. There is a lot of horrendous code in the wild. I won't argue that it's not informative to have a "view-source" but it's still not the bast way to get quality information on programming techniques.
  4. There is no benefit to inlineing as you describe. There would still need to be an applet involved. It would just be more work to generate the JavaFX then to just write the applet that consumes the important data.
  5. Searching/indexing is very important. There is no reason the raw data could not be indexed though, and it would be less work to parse because of the lack or extraneous markup.
  6. The URL? Really? You want to depend on the URL? Why? I understand it's roll in indexing is important but other then that I say the less you put in the URL the better.
  7. I agree Java/JavaFX enables creation of a better text-editing widgets.
  8. Jar files are delivered compressed with Zip or pack200. Your uncompressed example is not really valid.
  9. JavaFX has/will have video acceleration and do 3d. Are you complaining about the performance of a prototype interpreter?
In the end what you want could be done, if you really wanted to, but implementing hooks in the Scripting API for JavaFX, like Javascript or Groovy. I see JavaFX as an opportunity to move away from heavily server dependent generated UIs and towards richer content delivery.

Richard Osbaldeston replied on Fri, 2008/08/22 - 11:05am in response to: Chui Tey

Erm, as the scripts are run on the cilent then wouldn't an interepter need the full Java JDK instead of the just streamlined j6u10 runtime?

Chui Tey replied on Fri, 2008/08/22 - 4:08pm in response to: Collin Fagan

My points are about having JavaFX widely adopted.

  • You are partially right about edit-compile-run. This problem can be easily overcome with an IDE. There are many people who don't mind coding swing in fully verbose Java either. I'm not challenging the validity of anything. If Sun wants to please graphic designers, then Sun should build something that works similarly to how they already work. Have you ever driven a friend's car and get annoyed because they moved the light switch or the switch for the wind screen wiper? Or made opening the door a two-step process instead of one?
  • The web browser consumes markup and displays markup. The DOM is coherent and consistent with the markup. You might see JavaFX script as script, but I happen to be able to see JavaFX script as code as well as data. I believe that viewing JavaFX script as data unleashes a lot of creative freedom. 
  • About View-Source. Maybe you don't go on the internet to look for code-examples. I do. Some of them are badly written. But people get better by doing and learning. Code-examples get people started.
  • Yes applet is still required even when code is inlined. Inlining allows incremental adoption
  • The WEB is 20 years old and Google has just announced it is able to now crawl .swf files. Commercial sites can't wait another 20 for .class files to be crawled.
  • Without the URL, even when you can crawl data, there is no guarantee a new visitor will be able to find it without navigating through menus. May be you can show me an example of how this can be achieved? For example, let's say DZONE is one .html page with one JavaFX applet, and in 2028, Google is able to index the .class file. Tell me how is Google going to send you to this discussion about javafx from the search engines?
  • Gains in compressing .class also result in even more compressed JavaFX sources. Here are my compressed file sizes
    Script: 542b
    Class files: 2472b
    
    Take a look at Java projects download on Sourceforge. Are the source files smaller or the binaries? I rest my case :)
  • See... video acceleration does not depend on JavaFX being compiled. It's done with JNI. Using an interpreter would be just as fast.

An interpreter is a very small download. The class libraries is the bigger pig that's got to be squeezed down the tube.

Riyad Kalla replied on Sun, 2008/08/24 - 1:04am in response to: Chui Tey

Chui,

Excellent writeup, you don't even need to go beyond #1 in your list, #1 is *exactly* why JavaFX will never become dominate.

Developers, especially smart ones, underestimate how powerful stupid-simple can be sometimes. Only time will tell, and I'm willing to bet my house and cats that JavaScript will stay dominate unless something else can come along that works in a edit/save/refresh cycle as quickly.

If you keep the compile/deploy cycle, you've immediately cut your viable user-base down to developers that are used to an IDE environment, post here at JavaLobby, and probably read Slashdot... the rest of the world will be using JavaScript while we sit here in 5 years and argue JavaFX or Air... or Silverlight... or Swing... or SWT... while everyone else continues to not care, and actually gets work done with something else we aren't discussing.

Gonzalez Flores replied on Tue, 2008/09/02 - 5:51pm

 

Mmmm, I agree with geekycoder but maybe You are missing one important point, JavaFX is not only for Web, with JavaFX technology you can build applications on desktop, mobile devices, and TV screens, not only on web apps.

"Chui Tey:
The WEB is 20 years old and Google has just announced it is able to now crawl .swf files. Commercial sites can't wait another 20 for .class files to be crawled." ?
The SWF files aren't 20 years old and Google has 20 years old either. The web is older than 20 years old, please go back to school and review your history books.

In 2028 maybe you were been using and developing with Javascript for the 3 pc's at your home, the world is moving and not everything is on HTML, not everything is a PC and a Browser.

 Lets do a little exercise. Look at your pocket!, you have a cell phone( or smart phone)?, now you have your mobile device on your hands, please go to develop an application with JavaScript and PHP, push right click alter on view the source code on your mobile device, then when you have finished, do the same for your desktop enviroment, then for your TV and so on...

I'm not saying that JavaFX its a killer technology, but please focus in the real target of that technology, not in your learning curve seeing like a fetish the code of other guys.

Lets work like Riyad Kalla says!!!

 

 

Chui Tey replied on Tue, 2008/09/02 - 8:27pm

Five years ago, when developing 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. Lately, with webkit taking hold, and mobile devices becoming more powerful, it seems closer to reality.

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. I read this to mean browser support is only going to improve. Against this backdrop, Sun has to work very hard to woo the web development crowd, and not count on winning by default as it has in the past.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.