back to article Oracle should cannibalize JavaFX Frankenstein

One of the survivors of Oracle's mammoth takeover of Sun Microsystems is JavaFX, the Flex wannabe and illegitimate son of Swing. The biggest coup for JavaFX three years after its unveiling at JavaOne is its integration into, in a spinning-wheel app that shows countries' medal counts dating back to 1924. It's …


This topic is closed for new posts.
  1. TeeCee Gold badge

    Oh dear.

    I went to that linked FX app.

    You failed to mention that the length of time the "wait while I'm loading" bit sits there doing its stuff makes Flash look screamingly quick by comparison.

    What's the term for something slower than "unacceptably crap"?

    1. Anonymous Coward
      Anonymous Coward

      Look on the bright side...

      At least the example froze - it didn't crash your browser unlike certain Flash apps (I'm thinking of certain games from adultswim...)

  2. DrXym Silver badge

    I like JavaFX but...

    JavaFX stomps all over Silverlight & Flex in terms of what an app is capable of because it has the entire power of Java at its disposal - any jar can be used with JavaFX e.g. to act as an EJB client, to hit a database or whatnot. The scripting language sits over the JVM so it can import and use any class it likes. The Java security model also means an app doesn't have to be bound by a sandbox either unlike its rivals.

    The biggest problem for me are the tools are really horrible. Compare the ease of producing a Silverlight or Flex app to a JavaFX app. In Silverlight land you have an XML based UI language (XAML) and tools built into DevStudio for quickly knocking together an app. In Flex you get a very nice visual editor running over Eclipse. In JavaFX you get a text editor, a hideously nesty declarative structure and little or no assistance from Netbeans aside from a lame code snippets toolbar. It doesn't even have a decent code formatter to deal with the nesting.

    Mostly these issues aren't inherent to JavaFX, they're issues of a broken development environment. I think if JavaFX is to be salvaged, they have to get the tools in a usable state. There is no excuse for the pain they inflict on developers. Secondly, the declarative UI style is frankly bollocks and leads to code so nested or so decomposed (to flatten the nesting) that its impossible to read. JavaFX docs talk about the possibility of UIs being defined in some other way such as XML - so implement it! I think the general concept of a scene being composed of a tree nodes onto which scaling / transforms etc are applied is completely sound and has a lot of potential but the realisation is just rotten.

  3. Anonymous Coward


    Aren't most places getting rid of this outdated 1980's fat client forms builder in favour of web based apps?

    Compared to develoing a UI in HTML swing is inflexible, complex and slow - then during deployment you've got the nightmare of resolving JVM version incompatabilities on the client.

    The Insurance company I just worked at formerly a big Oracle user have almost entirely discontinued Forms / Java app development in favour of lightweight, rapid to develop web applications.

    As for JavaFX - looks set to join the Java Applet in the dustbin of web technologies that never quite made it in the real world.

    1. Daniel B.

      Depends on what you call 'fat'.

      If you follow the true three-tier development model, having the client-side component as a Swing UI *doesn't* mean you have a fat client. The whole Business Logic should be processed by the AppServer instead, and the UI is just that: a UI for the user. I for one would rather see actual thin-clients on the, erm, client-side than the diarrhea of web2.0 apps relying on crappy JavaScript or those ugly Flash-based "sites".

  4. Andy 73 Silver badge

    To an outside observer...

    ..Sun seem to have never quite had the courage of their convictions. They've produced a series of extensions to Java pushing in various directions, but then beyond the initial release of a functional demonstrator, have appeared to sit on their hands waiting for someone else to make it all look good.

    You can't fault them for well thought out components, but it has usually been the application in the real world that falls a little.. flat. Ubiquity of the platform has been a problem that they've never quite banished, and whilst the language and libraries are smart, they've never quite addressed the development environment. You could blame a lot of that on the decade or so that saw the XML mantra of 'must be human readable' accepted without thought. Certainly while MS and others made drag and drop programming ever more easy, Sun's stubborn reliance on hand written code has repelled casual programmers and set the bar relatively low for tool chain suppliers. Even now the various competing J2EE frameworks fight to make their configuration files easier to type and read rather than providing better tools for visualising and implementing a sophisticated application.

    All this is a great pity. The J2EE platform is mature, efficient and very effective in use. Swing is more than capable of producing excellent client applications. The Java runtime and associated Libraries are broad and robust. Yet .NET continues to gain ground and Java as a whole benefits most from developers wanting to avoid the MS tax rather than from the strength of the platform.

    Oracle would benefit immensely from understanding that access to the outstanding features that Java can supply will remain an issue without a fresh approach. PHP, Ruby and other platforms show that the huge technical effort that has gone into Java is not unassailable. Beyond that, showcasing the technology is a constant requirement, not a postscript to a new project. That task should fall to people who can lead the charge, rather than playing catch up with other platforms.

  5. Dave Murray
    Thumb Down

    Dr Frankenstein is dead?

    The marketing team would have more success sending shockwaves of electricity into the corpse of Frankenstein's monster surely.

  6. DrStrangeLug

    Swing 2.0

    About a year ago a lot of people starting shouting for Swing 2.0 as well as JavaFX. Some of this is already happening with the swing generics project but frankly its not enough.

    Layout managers

    Layout managers

    Layout managers

    Worth mentioning 3 times because the thing everybody mentions against swing is the layout control.

  7. Osvaldo
    Thumb Up

    Works for me...

    (Disclaimer: JavaFX enthusiast writing here.) The GeoView works pretty well here. I don't notice scrolling or any other issues with this or other Java/JavaFX applets. Notice that you really need JRE 6u18, and also JavaFX 1.2.3 - this point-release was readied especially to fix a few bugs for the GeoView app, days before the games started. (Unfortunately the JNLP doesn't enforce these runtime versions, it just requires JRE 5+ and JavaFX 1.2+, so the GeoView may run on older crap if you've already got it installed.) And you really need Windows - the JavaFX ports for Mac and Linux are still lagging a bit. On the Mac, the problem is Apple's JDK lag behind Sun's; on Linux the problem is much more severe as Linux's core media stack is a pile of monkey dung, from graphics drivers to the multiple crappy/nonintegrated sound subsystems etc.

    The very first time you load the GeoView (or any FX app that's your first FX apps), there is a bigger download time because the JavaFX runtime weighs in ~10Mb, and that's assuming you've already got the latest JRE. But the warm-start is pretty good in my tests (JRE 6u18 is important for that, contains some significant improvs in the Java PlugIn cache where applets are stored).

    Notice that GeoView will query its server for specific info, like each country's flag and medals, on demand as you navigate stuff. This data is stored in the Java PlugIn cache (check the JPG and JSON resources) so the next uses will be fast. Perhaps they could pre-load things in the background when the applet is idle, e.g. prefetching data from nodes that are "neighbor" to the node in focus, that would provide an even better perf. Don't blame the platform for everything; app design plays a big role in PERCEIVED performance.

    Now, Flash is certainly ahead in deployment, but... I've just seen the Tour De Flex demo... pretty UN-impressive. The deployment is still good, but not brilliant: I already have the latest Flash so the initial UI loads reasonably quick (>5s) and without fuss. But it's certainly not in the "instantaneous" standard of most Flash applets; and I'm just talking the initial screen! Every single menu item I open for specific demos has a VERY noticeable, extra loading time - always several seconds, like the COLD-start of an entire small Java applet. The performance sucks horribly - drawing of the chrome, simple effects like fade when a modal dialog is shown, etc. Try dragging a window with transparency, e.g. in the TileWindow demo, the shitty performance JUMPS in your face. And don't tell me that Flash 10.1 will fix this with GPU acceleration and other enhancements - I AM already using 10.1beta2. (Doing this test on a Q6600 + NVidia Quadro FX1700, it's not a bleeding-edge gamer system but it's pretty decent. God helps Flex on a laptop with some Intel IGP.) The look&feel is nothing to be proud of, nor is the memory usage (a bit HIGHER than JavaFX's GeoView, in my tests).

    All in all, for tiny applets there's still no competition to Flash which can cold-start a small SWF in a couple hundreds of milliseconds. But it's a different ball game for Flex/AIR, that demand very large frameworks that are downloaded on demand (and apparently without any decent caching). Flex/AIR is just as much slow-booting and RAM-eating as Java/JavaFX, so the playing field is much more level here (of course Adobe is still ahead in items like tooling, developer midshare, and runtime distribution - but then, they've been 10+ years in this game, so there's still a lot of ground for JavaFX and also Silverlight to catch up).

  8. Anonymous Coward
    Thumb Up

    Has anyone actually used JavaFX?

    @Anonymous Coward: You might want to sit down, because what I'm about to tell you could come as a bit of a shock -- not every application is a simple form based CRUD sat atop a database. I know, shocking isn't it? Apparently some newfangled apps deal with strange things called "video" and "images", some even claim to feature a thing called "animation" (whatever craziness that is!) It seems the Facebook generation, for some reason, don't want their software to look like it was designed for use in a call centre!! (I blame the parents!)

    Okay, sarcasm aside, has anyone posting negative comments here ACTUALLY DEVELOPED WITH JAVAFX...?

    I think JavaFX has two problems, Firstly there's an image problem -- for any developer who doesn't have serious experience of animation or pixel-pushing code (and I'm assuming this includes Matt Stephens) the power of JavaFX Script goes way over their head. It's a DSL (in the same way SQL is a DSL) designed specially for UI and animation, so don't expect it to look like PHP or Ruby. Unfortunately ignorant web developers are looking at it and blogging "this doesn't look like JavaScript!!!" (well duuuurh!) and that has generated some negative feedback, which ultimately ends up on sites like this.

    Secondly, JavaFX is still a work in progress. It hasn't reached maturity yet. It only works on some phone platforms, and still has gaps in its APIs. Fortunately the race to decide which technology will become the dominant RIA of the future (AIR, Silverlight, JavaFX, GWT...) is far from over -- it's a marathon, not a sprint -- but even so, JFX needs to fill in its gaps ASAP.

    For all it's failings, if developers would actually try learning JavaFX before they slag it off I suspect the majority of the criticism would evaporate.

  9. webster phreaky ate my iphone


    Can't get or the linked page to work on FF3.6 on Mac without getting the spinning beach ball of death. Not exactly a ringing endorsement of JavaFX.

  10. Matthew Barker

    Suffers from same problem all Sun projects suffered from

    Serious understaffing, overanalysis, too many meetings, too many metrics, too many conflicting priorities, too much multitasking.

    It's a wonder they were ever able to release anything. But what they released has potential beyond a Swing replacement.

    Look at timelines as a way to craft a simulator, for instance.

    Look at other potential applications of variable binding.

    When it stabilizes, I intend to use it.

    Swing is too painfully complicated.

    When Maya Angelou was going to read Clinton's inaugural poem, she apologized for the length, saying she didn't have time to write a shorter one.

    Maybe Sun employees will have a chance to focus more on fewer priorities so they can deliver simpler, more well thought out products now.

  11. peter_pilgrim
    Thumb Up

    Wake Up and Smell The Coffee

    Please understand what a scene graph is first? A scene graph is a data structure of descriptive object nodes that in themselves represent abstract graphics declaratively that are rendered through runtime (software and/or hardware pipeline) to produce graphic primitives on the target display device.

    JavaFX is designed to support a scene graph

    JavaFX is a Domain Specific Language

    Swing was not designed to support a scenegraph runtime. It uses ``immediate mode graphics'' with GraphicsContext (AWT and Java 2D) as it underlying technology. Immediate mode graphics programming has been around since the 1980's with Windows Handles, X Windows Contexts, Borland Graphic Unit Contexts and of course Java AWT Graphics2D context.

    Swing was designed to be an emulation of windows user interface technology of the period, the classic WIMP model (Windows Input Mouse and Pointer).

    Smell the real coffee with the new kinds of UI/UX that you already know about to hit the streets. The Apple iPad is foregoing the traditional UI/UX of WIMP. It is a new style of consumer device with a touchscreen. Surely you do not think that Swing 2.0 will be able to execute on these devices or other slates (that you might be using in the five years). If you do then you are a dumb .....

    With devices like Apple iPhone / Google Nexus you all know about the graphics objects that seemlessly rotate, scale, translate and shear; and can perspectively rotate. How on earth do they do that? You might have wondered in your mind. I hope you probably know that there is a programming model and graphics pipeline that makes what you see on iPhoneOS a doddle to program. It would be very hard and difficult to take a Swing UI 2.0 and develop it now to the iPad (or another other forthcoming competiting i-slate). This is why JavaFX was invented, or rather Christopher Oliver of See Beyond, created an experiment called Form-Follows-Function (F3) that in prototypical terms set the stall out for JavaFX. His research endeavours to build a language to manipulate a scene graph , see his blog on the older, pre-date the announcement of the first generation Apple iPhone in January 2007 WWDC. Plus we all know that Chris Oliver and Apple were separated by concerns and could not be influenced by each other, in anyway.

    Simply put, the new UI/UX mode is to have a runtime that supports a combined 2D/3D scenegraph runtime, which is performant and takes advantage of 3D graphics GPUs. If Tony Blair mentioned once: education, education, education and Bill Clinton mentioned once, the economy, economy, economy then please believe me, with JavaFX, and this including another graphics RIA solution, it is all about now the performance, performance, performance. Why? Because Apple are setting the agenda in this game. They just did in 2010 with the new Fangled Apple iPad. The demos were stunning when I had a change to watch them as podcast on iTunes. Flex, Silverlight and even JavaFX had better catch up.

    I realise there are wide spread confusions here are that people think that JavaFX can only run inside a browser, or it is based on extension of Swing, or about a fluffy stackitecture and the runtime. The real prize to be able write RIA that can ported/target to a multiple of devices (screen) in one DSL and one runtime. This is the rocket science that everyone has to understand.

    We are waiting for Oracle to finish the work that Chris Oliver started. Produce a Java/JavaFX runtime that supports scenegraphs and replaces the old fashion Abstract Windowing Toolkit (pipeline circa 1995) and then it will contain combined 2D and 3D graphics. This runtime is called tentatively by Oracle, "The PRISM Runtime" and it will solve not only JavaFX but also Java Runtime Environment (JRE). That's right even those m****f***rs of b**k*rs will be able to download the JRE with the Prism ``Stackitecture''. If they want they still run little bitty Java Plug-in based financial trading applications, while the rest of us can work with a scenegraph enabled FX. Once Oracle release this code and the platform, I bet that Java on the desktop will be blooming fast! Then all they need to do is port it to devices. Ok Apple won't allow byte code interpreters or virtual machines to run in their walled garden with Java or even Flash. However If Oracle ever makes a deal with Google, and then with Android, to port the JavaFX runtime over there to those mobile devices. I think we will be laughing really hard. Finally JavaFX is still based on ideal of WORA, your JavaFX desktop can be with of course modifications be running on JavaFX mobile device if you architected that way.


    1. DrXym Silver badge

      The problem is...

      ... if you look at Silverlight, Flex or even Android, they all use the equivalent of a scene graph. Silverlight has a WPF-lite XAML, Flex has MXML and Android has layout XML. They may differ in some respects but they allow such things as transformation, rotation, animation, blending etc. More importantly, they offer some level interactive UI design for visualizing and modifying the look and feel on the fly. Largely or completley separating the UI definition from the logic also allows a designer to hand off a largely functional UI to a developer.

      Also, none of these languages prevent you from writing a UI programatically and probably most apps have to do some of that too for hiding, resizing and other tasks.

      I'm sure a domain specific declarative language in JavaFX is well intentioned but god does it make the code hard to read. The amount of nested curly and square braces is unreal and the netbeans and eclipse plugin editors are useless at telling you where errors are or offering to format the indentation to find them.

      JavaFX has to start by winning over developers and the easiest way to do that is make things easy to get going. The tools need to improve and IMO, Sun/Oracle have got one shot before the tech is doomed to the dustbin. Android is going to eat their lunch in the phone sector and Flash (& Silverlight) have it going on the desktop.

  12. Anonymous Coward

    Jumpin' Jack Flash

    I enjoyed the remark about "the cosy safety-in-numbers (and stability) of their Flash players," especially in light of a few other recent El Reg articles: "Adobe pushes out Flash security fix" (12 Feb), "Adobe apologizes for festering Flash crash bug" (9 Feb), "Dear Adobe: It's time for security rehab" (5 Feb), and "Researchers penetrate last bastion of Windows security" (by hacking in through Flash, 3 Feb). If that's "stability," I hope you're working above a net.

  13. Anonymous Coward


    It (JavaFX plugin) does not even install on my VISTA laptop. Probably the moon is currently in a bad position relative to Pluto or something.

    Reminds me of JavaME, which would contain a new strain of bugs on each different type of handset. Also, last time I checked Applets they loaded sllloowwwlllly and also looked very ugly. I can recognize an application made with the funny Swing widgets in two seconds.

    Can't they give AWT, Swing and JavaFX a decent burial ?

    For all their deficiencies, Flash and JavaScript do their job very well from a user's point of view. Java and GUI never did that and probably never will. FAIL.

  14. Chris Lowe


    What version of Java do you have installed? Try updating to 1.6.0_18 from There has been quite a lot done to improve start up speed of applets etc. JavaFX requires at least 1.6.0_10 to run, so your JavaFX installation process may have failed because of that?

    There is still more to be done with the start up performance and the installation process, IMHO, still leaves much to be desired. I find the Flash installation process very user friendly and actually quite slick.

    Also - I have also seen AV software such as Kaspersky *absolutely murder* JavaFX startup time. Unfortunately that is out of JavaFX's domain.

    As for ugly applets, that's just FUD - it's not the fault of the technology, that's just sloppy programming. Anyone can pump out ugly ass apps in Java, Flash or whatever.

    And if your wish comes true for the burial of AWT, Swing and JavaFX, what exactly are you proposing takes their place?

    1. Osvaldo
      Thumb Up

      Most Antivirus kill Java's performance

      This is true for all Java apps, FX or not. The biggest problem seems to be that the JVM creates native code on-the-fly, on heap pages that are later remarked as executable. There are also other creepy low-level tricks, like page faults that JVMs use as a method to capture some uncommon events like nullpointer exceptions; complex memory management performed by garbage collectors; tricks employed by JNI in the stacks; on-stack replacement and deoptimization/re-compilation (even more complex churn of JIT-generated native code), etc. To make it worse, all this action is performed by userspace code. Stupid antiviruses expect all programs to exhibit the much simpler (and mostly kernel-space) low-level behaviors of native-compiled programs, so they stomp over Java processes to investigate possible virus attacks all the time. But of course, there's never a virus because the platform is trusted. (Even if there IS a virus due to an exploit of some JVM security bug, I don't think antivirus would have much success to detect a real thread - the exploit would, by necessity of the JVM's dynamics, have a very complex behavior.)

      I am not affected because I don't run antiviruses at all, haven't run them for ~10 years without any problem - generally, antiviruses are good only for non-tech users (or for idiots - that get programs from warez/torrent sites without discipline to run a manual scan, etc.). Now I'm running MS Security Essentials because its overhead is minimal - even for Java programs; it's apparently not broken like other AVs, and I can understand that because MS's .NET platform has similar dynamic behavior and MSE should not bring .NET apps to a halt, so perhaps we Java users are just lucky that MS created an AV that's smart enough for the CLR but this also benefits JVMs. My advise, good at least form Vista and Win7, is simple: 1) uninstall all third-party AVs and other security crap; 2) install latest stuff from MS (firewall, MSE); 3) profit.

  15. Anonymous Coward

    Java, JavaFX on VISTA

    As I wanted to be objective regarding my latest anti-Java rants, I spent some more time with it and figured that the online-installer of Java does not work on my 2GB RAM, VISTA laptop from Fujistsu, which is automatically updated by the MS update service. I did *not* have Java on this installation before.

    The "offline" Java installer worked, though. Not good.

    I then tried the examples of and they are really, really pathetic. The very simple stuff (such as simpleton address managers) actually works. But the first realistic thing, a video player, first displayed a flying bird logo for two minutes until it decided to tell me it can't work. Not good either.

    The bottom line is that either JavaFX is a toy or the Soracle people did not find the time for at least a single compelling demo. Adobe's Flash loads like a lightning and all works on their demo site. Youtube happily displays movies with Flash, even though they sometimes have to be restarted.

    And this is not my first bad experience with Java on the client side. I have experienced numerous Java client bugs as a developer, which cannot be worked around. Three years ago I tried to run a Java messaging client using UDP Sockets and AWT in a browser. This would first work and then crash both IE and Firefox. That was at a time Java was available on the client for more than ten years.... JavaME exposes this sort of behaviour in different flavors for each handset model. It is also slow and very difficult to debug on real handsets.

    Quality assurance on Java GUI systems simply is totally inadequate, and this also applies to JavaFX. So Larry, if you are serious about the Java GUI, fire the current QA team and assign your best people from the "old" Oracle to that task. Or just focus on the server, where Java makes some sense and is actually widely used.

  16. Anonymous Coward

    Realitätsverlust ?

    "The real prize to be able write RIA that can ported/target to a multiple of devices (screen) in one DSL and one runtime. This is the rocket science that everyone has to understand."

    "Write once, run nowhere", eh ? Sorry, was it "write once, debug everywhere ?", No, it was "write once, wait everywhere".

    "We are waiting for Oracle to finish the work that Chris Oliver started. Produce a Java/JavaFX runtime that supports scenegraphs and replaces the old fashion Abstract Windowing Toolkit (pipeline circa 1995) and then it will contain combined 2D and 3D graphics. This runtime is called tentatively by Oracle, "The PRISM Runtime" and it will solve not only JavaFX but also Java Runtime Environment (JRE). That's right even those m****f***rs of b**k*rs will be able to download the JRE with the Prism ``Stackitecture''......... Once Oracle release this code and the platform, I bet that Java on the desktop will be blooming fast! Then all they need to do is port it to devices. Ok Apple won't allow byte code interpreters or virtual machines to run in their walled garden with Java or even Flash. "

    Now back here on planet earth, hundreds of millions happily use Flash and JavaScripts while nobody bothers to install the JRE on their new private PC. Will we experience the Second Coming of The Saviour Of Mankind By Virtue of JavaFX ? Probably.


    @Osvaldo: I don't have VirusScanner "protectionware" on this PC, as I don't run it as an Admin, but the class loading delay issue exists also here. Microsoft does a much better job on loading their CLR bytecode than SUN. Maybe they cache the compiled bytecode or they actually assign proper programmers to their VM R&D team.

    The drones of SUN never managed to get decent class loading performance and they never seriously thought about caching or precompiling. That would probably be not academic enough for Mr Gosling. Or, god beware, reference counted pointers, destructors, values/arrays on the stack and other similar performance-enhancing heresies.

    1. Osvaldo
      Thumb Up

      Java classloading

      @joeuro The classloading is indeed a major problem. It's getting better; the CDS facility in Java5 speeds&shares the loading of most core APIs (though not JITted code), and 6u10-6u18 have important improvements like much better JavaPlugIn cache (e.g., downloaded jars will only be verified once, then future classloads of the same cached jars will not pay the cost of bytecode verification). JDK 7's Jigsaw promises a decent installed module format, even allowing ahead-of-time compilation / JIT caching (although I don't know if they will actually deliver this by FCS, perhaps just in some future minor updates - but at least the underpinning will be there, i.e. a good module system much like .NET's assemblies).

      Wrt your other suggestions: most of them are bogus (esp. refcount and other manual memory mgmt tricks). On-stack allocation of objects will be delivered by JDK 7 as a fully automatic optimization - Escape Analysis-based scalar replacement - already implemented in latest JDK7 weeklies so you can test it; this is a bit limited compared to programmer-controlled stack allocation but in the flipside it's completely transparent without any tradeoff in language/typesystem complexity or in requiring more effort from the programmer. "Value types" in general are the major missing perf feature, I've been advocating this myself, and there are some MLVM projects pursuing this (e.g., inlining of array field-in-last-position; tuples).

  17. Kebabbert


    is easy to develop applications for. Combined with Java (which exists on every Windows computer, Linux, Mac OS X, Mainframes, Unix servers, billions of mobiles, BluRay, etc) the market potential will be enormous. Windows Forms can not compare, nor Silverlight.

  18. tchite

    BioTech Developer

    Hi all,

    I'm getting a LOT of work done in JavaFX. Much more quickly than in SWING.

    Its like the press thinks the only thing I need JavaFX for is to add bling

    to webpages.

    As if.

    I need a lot more than that.

    The constant comparison of JavaFX to FLASH is all obsession

    and little substance. It seems to be a rut that tech reporters

    just fall into when talking about JavaFX. Flash does a very good

    job at adding bling to webpages. It is quick and easy. But the

    depth isn't there. Nor is it cheap.

    I added up all the costs that Adobe charges if

    you want to be a full fledged Flash developer. I was up

    to $THOUSANDs OF US$ when I added up all the charges

    for Adobe stuff.

    Adobe Acrobat 9 PRO $ 699.00

    Adobe Flex Builder $ 699.00

    Adobe Flash Pro $ 699.00

    Adobe Illustrator $ 599.00

    Adobe AfterEffects $ 999.00

    Adobe DreamWeaver $ 399.00

    Adobe Audition $ 399.00

    Adobe Cold Fusion $1,299.00 or $7,424.00 for the Enterprise

    Adobe Captivate4 $ 799.00

    Adobe Authorware 7 $2,969.00


    and there is more $$$ for all sorts of extra specialized tools...

    AIR and FLEX are new technologies trying to be a JVM. Adobe is adding

    capabilities, then rethinking and starting over with new versions

    I understand. They've got a ways to go with those.

    If you look at the FLASH posts in that community you'll see that they

    have a LOT of technical problems to overcome. Just as there are

    with JavaFX. For example Flash 'tricks' need to be employed to do simple

    things like play mp3 loops without gaps in the sound.

    I really do think that you CANNOT develop an app that will run well on

    a phone and on a device with a bigger screen. It just isn't possible

    without completely rethinking the app. There is just too much of a

    difference between a 3" screen and a 10+" screen. The best that can be

    done is that you use the same language and tools to develop two differnet


    The programs that I want to write cannot be done with Flash. I least I don't

    know how to do them. And they are difficult to do with Swing. But are easy

    and fun to do with JavaFX.

    I do have high hopes that soon JavaFX will have a quick start up time from

    browsers time and a solid and reliable web deployment using any browser.

    I'm expecting this will be possible by the end of the year.

    Kicking JavaFX is like kicking a really promising puppy.

  19. Romain Guy

    Scene graphs

    FWIW, neither Android nor the iPhone use scene graphs for rendering. The Android UI model is actually very close to Swing's.

    1. Osvaldo
      Thumb Up

      Re: Scene Graphs

      Some people "see" a scene graph whenever they see a declarative (XML/DSL) representation of the GUI. This, and also stating that the JavaFX Script's syntax makes code "harder to read", tells me that @DrXym is talking about stuff he[she/it] has spent less than 5 minutes learning. OTOH, the dreaded, perceived issue with deeply-nested structures is mostly a fault of sample code that's not written in good style - we don't _have_ to write an entire GUI as a single object tree with 35 levels of indentation, just because the language allows it. Refactoring and modularity best-practices are available to split the scene graph in smaller, more manageable pieces. Even tool-generated code - from good tools, like JavaFX Composer - will do that. The "single monolithic tree" style is OK mostly for graphics resources produced and manipulated only by drawing tools.

      1. DrXym Silver badge

        Thanks for your patronising remarks

        I've spent enough time with JavaFX and other languages to know exactly what I'm talking about.

        JavaFX is an extremely bad "domain specific language" for declaring UIs and the tools are horrible. It might be elegant and JSON-like for normal programming but it's not great for declaring a UI. If you bothered to read what I said you would know I am aware it can be flattened - "the declarative UI style is frankly bollocks and leads to code so nested or so decomposed (to flatten the nesting) that its impossible to read."

        Flattening the UI to make it less nested also removes the readability. It's like presenting someone with flat pack furniture and expecting them to visualize what it will look like when assembled.

        JavaFX composer is a huge step in the right direction but it doesn't forgive or excuse the language it has to deal with.

        Silverlight, MXML and Android all manage a declarative language which succinctly describes the UI with far less nesting. All of them also follow similar principles to a scene even if they call them UIElements, DisplayObjects or Drawables instead of Nodes. All of them far more easily separate concerns allowing designers to construct the UIs and throw them over the wall to developers to complete the business logic. As it happens they use XML for their UIs but I am not arguing for XML as much as a succinct UI language with tools to match.

        Despite all of this I have been mildly positive about JavaFX since it was launched but that does not mean I have to look at it through rose tinted glasses. Its deficiencies especially in the tools were obvious last year and virtually nothing has changed. In fact, here is a post I made almost exactly a year ago making the same point

        I think the boat has sailed on the desktop and on the mobile phone but I'd gladly like to be proven wrong.

        1. JKing
          Thumb Up

          You're ignoring the real power of JavaFX Script

          Having a two-language approach (eg: MXML and ActionScript) works fine so long as your UI is largely static. But as soon as any variable content is introduced things start to get ugly. All the designer can do is place empty container nodes into the declarative code, so the programmer can later inject the dynamic content using procedural code. The power of JavaFX Script is it's an expression language, enabling the seamless mix of business logic and scene graph via a unified language that works well for both.

          Quick example: say I need to display a list of up to five daily events in my UI -- on any given day there might be data enough for all five, or there might be none at all, we don't know until the code runs. A language like MXML, which lacks programmability and therefore variability, cannot handle this with grace. The only solution is to either allocate a rigid space for all five events regardless of whether they're needed, or use an empty container and have a programmer later inject the dynamic parts at runtime and rearrange the UI as necessary to accommodate them. Messy -- now your UI design is split across two separate programming languages and two different documents.

          Compare that to JavaFX Script, an 'expression language' that's equally at home with declarative structure and business logic, and can switch effortlessly between the two as the UI is coded. In JFX I can blend programming constructs like FOREACH and IF blocks into the UI declaration, all in one document, using one language. (A simple FOR loop, placed at the relevant point in the UI structure, would be enough to elegantly solve the problem above.)

          If you look at a lot of Flex applications the one thing you'll notice is they tend to be very rigid in their layout. You don't see many UI's that are customisable, allowing the user to organise their own toolbars, menus, views, whatever -- hardly surprising given the more flexibility you demand of a Flex UI the more fragmentation you get between the two schizophrenic methods being used to manufacture it.

          One of the nice things about a unified language approach is not only can you declare a UI, but you can engineer its dynamic elements at the same time (and in the same place -- not a totally separate source file!)

        2. Osvaldo
          Thumb Up

          To each its own

          You can structure the UI in any extend and style you like, from a single tree to an individual field or method for each node, to the usage of some algorithmic code (e.g. loops) embedded in the declarative structure (JKing has beaten me in this part of the reply). In the end, maybe judgments like "is an extremely bad DSL for declaring UIs" are just in the eye of the beholder - I would use the exact same words to describe things like MXML (and once again, goto JKing's words). I agree though that JavaFX is still catching up in the tooling.

  20. Anonymous Coward
    Thumb Down


    "Wrt your other suggestions: most of them are bogus (esp. refcount and other manual memory mgmt tricks)"

    I can tell you that I developed for the number one CAD/CAE system (do some reasearch and find out what it is, it's from france) and it is completely based on C++ with automatic pointers that perform reference counting internally. Boeing, Mercedes, VW are only some users.

    This system comprises 2000 Modules of about 10000 lines each and it is actually very responsive on a 1500 Euro PC. Doing the same in Java would simply be not possible.

    It is true that refcounting does require manual breaking of cycles, but the JVM could automatically inspect the type information and use refcounted pointers if cycles are impossible. That would have the nice effect of freeing lots of memory when it is no longer needed. And not aeons later.

    Alternatively, the Java standard could be enhanced for something like a "refptr<Type>" type. The compiler would detect cycles and warn or reject. This would also allow for destructors, which are highly useful.Imagine this code:

    void AClass::performTransaction()


    DatabaseConnection db("");

    db.query("select from bla bla");




    db.execute("insert into...");





    DatabaseConnection::~DatabaseConnection() will be called irrespective of where you leave the method AClass::performTransaction() and will close the very expensive database connection automatically and return all resources. Java cannot do that. You always need the try{}finally{db.closeConnection();} cruft.

    1. Osvaldo
      Thumb Down


      Anecdotes of large-scale, successful applications built with refcounting don't mean that this technique is adequate to be used 100% of the time, by the VM's automatic memory manager itself. I was myself a fscking good C++ hacker before moving to Java; I've once written a LR(1) parser optimizer that used every trick in the book to make complex transformations in a very complex object graph. Refcounting is one of the good tools you can use in languages like C++ where manual memory management is the rule, and various kinds of alternative / semi-automatic schemes can be added by libraries and conventions.

      But a completely different problem is mixing manual and automatic memory management, or implementing fully-automatic memory management with refcounting. There is a TON of literature around automatic memory management, and refcounting has been basically dead for ages. There's are always somebody trying to resuscitate refcounting because it has the obvious advantage of early detection of dead objects, which in theory could allow early freeing and reduced heap usage. Sometimes a refcounting-based research turns out some limited success, e.g. age-based collection of old-gen heaps (google this within JikesRVM research papers), but so far these ideas appear to have important restrictions or for some reason they nevere reach production VMs (hint: non-refcounted GCs may just keep delivering superior performance in the real world). At best, you can find some resemblance of refcounting in the remembered sets of partitioned heaps like Sun's G1; the remset of a particular sice of the heap can be considered a refcount because when it goes down to empty, that slice is known to be completely empty, so it can be either deallocated or recycled without further overhead. But the general idea of refcounting sucks for other reasons than just cycles. Consider free space management; heap defragmentation; concurrent allocation -- think from GC's perspective, not from C++'s perspective and you will see why refcounting is just a bad idea.

  21. Anonymous Coward

    Stanford University Network

    Academics like to prove something in theory, but they are way too lazy to do the nitty-gritty, ugly routine work that actualy makes an economically great machine.

    S.U.N. proved that Unix worked, they proved that RISC worked and they proved they have new ideas about programming languages.

    But those ugly, efficient machines were built at *real*, greedy capitalist companies like Microsoft, Intel and Hewlett-Packard. Lately the academics of S.U.N. were beaten to bits by Power7 of IBM Corporation. Microsoft employed a real engineer (Heijlsberg) to reimplement Java and named it C#/.Net.

    Some more free suggestions to Larry Ellison:

    1.) Make a Compilation Proxy (CP) available that will serve up the compiled version of a class or jar file for all possible CPU architectures like ARM, x86, Itanium, Power, SPARC, MIPS etc. Compile the whole bytecode into a plain, old, readily linked executable/dll. CPs would be operated by SUN in the internet and by individual users in their intranet. It would save tons of classloading and JITing time and make end users happy.

    2.) Lay off that academic Gosling and hire a real engineer like Anders Heijlsberg to expand the JVM specfication for refcounting pointers, values on the stack, arrays on the stack, destructors, a proper generics language (could be Java itself) and reference types. A good engineer can do this in two weeks. Gosling probably will take infite time do this, as it would mess up the elegance of his nice little research project called "Java".

    3.) Hire some actual engineers to hunt down and eliminate the many bugs that still lurk in the Java libraries, including the native libs. Hint: try using UDP Sockets in an Applet that runs in Firefox. I bet the whole browser comes down.

    4.) Start charging something for the good work done in 1.) to 3.). Richard Stalinman will go ballistic, but isn't he also an academic sucking money out of the MIT ? Freetard Java destroyed an actually innovative language/IDE (Delphi) by this "culture of sharing". It also killed the Stanford University Network itself.

    1. Osvaldo
      Thumb Up

      Stanford University Network

      1) Not necessary, we can just do ahead-of-time native compilation at module installation time (some JVMs already do that - IBM JDK and JRockit already do it, perhaps JDK 7 with Jigsaw will allow a better implementation (modularized, like .NET's GAC) .

      2) James Gosling has not been involved in Java's design for a long time, >10 years; he's moved off to other projects like real-time Java, embedded Java and other stuff. He only poses as the "father of Java" in tech conferences but that's just marketing. I am in a few mailing lists from OpenJDK / JDK 7 and JG is nowhere to be seen, doesn't participate (at east publicly) in discussions like the lambdas proposals etc. So, your wish has already been satisfied. (There's already many "real engineers" wearing the hat that was once Gosling's, you just don't have a good knowledge of the Java evolution process. And JG _is_ a "real engineer", we should thank him for many pragmatic decisions that resulted in Java 1.0 which was a hugely successful platform.)

      3) I have my own set of pet bugs, everybody has. Many thousands of these bugs, including some very old ones, are fixed in each major release, and a few more continuously in update releases. Time is short, resources limited, users always want a ton of new features for next release, and it often happens that some bugs cannot be fixes without breaking backwards compatibility (even if that's only for broken apps - sometimes there are many such apps, and Sun has support contracts to honor). Yeah life sucks, we'll never get a perfect platform - if you prefer .NET, or the native Windows or Linux or Mac SDKs, they have thousands of bugs too (the proprietary ones only look better because they don't have a public bugtracking system - at least Sun has got the balls to expose its bugs (much before OpenJDK), so we can at least know the perils and work around them while not fixed.)

      4) Sun does monetize on the Java platform in many ways - support contracts (they will do anything from fixing bugs that are important for paying customers, to releasing special JDK builds for SAP), licensing for large JavaME/SE/EE vendors who build their own big platforms around Java, etc. Java was actually a lucrative operation of Sun, it was just not big enough to balance the hemorrhaging of money from other operations. (That was probably a failure - Sun's control of Java should have resulted in MUCH more lucrative services; but Sun was never good in marketing and selling anything, from services to servers.)

This topic is closed for new posts.