On Feb 21, 6:49 am, Steven Herod <steven.he...@gmail.com> wrote: > I'm very much in favor of JavaFX - I've been working with it > constantly since the 1.0 release, I think it has alot of potential, > and it's allowed me to do things in Java on the client site I've > never, ever been able to do previously. > > But it's not enterprise ready (yet) and a lot of the points you raise, > are in my opinion are correct, I could get into the 'its coming, it's > promised, you don't need it, JFX is 1.1' refuting, but that's probably > fairly pointless.
I thought a bit more about this, and I believe that for the foreseeable future, Sun should stop trying to get Flex or Silverlight _enterprise users_ to switch to JavaFX. Here's why: - JavaFX, Flex/Flash and Silverlight are all DSLs for UIs, which means the VMs display buttons, text, input fields, tables, images, trees, charts and such. Additionally, with enterprise applications increasingly going "multi-client" (web + desktop + mobile), the business logic will be on the server most of the time, not the client (beyond something like form validation). So while it's nice that the Java VM can do all these amazing things with tons of threads, it's reduced to render forms and tables in a single GUI thread and maybe having a background thread for network I/O, so it loses most of its theoretical advantage over the Flash Player (which has been a UI VM for more than ten years now) or the Silverlight VM. - Getting people to switch from one software product to the other is not rocket science - Joel Spolsky wrote about it nearly nine years ago: http://www.joelonsoftware.com/articles/fog0000000052.html His points: you need to remove the obvious and non-obvious barriers to entry to using your (new product), which in his case (Excel fighting the incumbent Lotus 1-2-3) meant reading and writing the Lotus 1-2-3 file format. So in our Flex app, there are a number of barriers to switch to JavaFX - Flash ubiquity, charts, AMF3, ease of development, tools, libraries etc. For Silverlight guys, the biggest barrier to entry is probably leaving the Microsoft universe - the Microsoft software stack and Visual Studio and MSDN and the books and the training courses and conferences and the components and the ecosystem. [Shameless copy from a reply of mine on a different topic] Sun tried this once before with Java Creator. I don't think Sun understood why people switch software or don't switch, otherwise they wouldn't have tasked Java Creator to lure millions of Visual Basic programmers into the Java camp (http://www.builderau.com.au/program/ java/soa/Sun-to-hand-out-Web-ready-Java-tool/ 0,339024620,320283319,00.htm). Just by looking at it you could see the problems: Java Creators made web apps where Visual Basic makes Windows apps, they needed an application server to run on, the tool wasn't Visual Studio, it couldn't use any of the Visual Basic components, it used a different language, and it probably couldn't import most Visual Basic programs flawlessly. So you had all these huge barriers to entry, and the result was predictable. At least Sun was smarter than Microsoft (which has its Expression tool line) by hooking into the Adobe tools for JavaFX export instead of doing their own design tools - though there will be a dedicated JavaFX designer tool shown at JavaOne. - Even if Sun removes these barriers to entry, what's enticing you to switch (except for the joy of learning a new language and rewriting your UI from scratch) from Flex or Silverlight? Especially in these trying economic times, you need a good reason for your boss to get sign-off for a complete UI rewrite. These are UIs, not general purpose programs, and you probably even want to make your UI similar to the ones already out there, so it'll be forms and buttons and tables and trees and charts and images, and all platforms have them (well, except for charts which I think JavaFX and Silverlight don't have out of the box). I can't think of anything in JavaFX right now that we must have but can't have in Flex. But even if there was something, with these three platforms now competing with and copying from each other, it'll probably show up in the next release of the other guys (Adobe was forced to do hardware-accelerated full-screen video in Flash Player 9 because of Silverlight - this was only planned for Flash Player 10), making switching harder. I don't know much about consumer appsl (like game), but I think here runtime penetration is the biggest barrier to entry (how many can use your product immediately without having to download anything else?). That's why Flash is king for browser games with Flash Player 9 on close to 99% of all PC worldwide. As a full-fledged VM, JavaFX should be much better for games than Flash where more code runs on the client than in "enterprise UIs". But browser games must run on low-end machines (and with the Netbook wave, a whole lot of low-end machines are being released to the market), so hardware-rendering and multi- threading and libraries and all that in JavaFX may not be such a big advantage. Heck, there are entire 3D online games done in Flash (http://play.toontown.com/webHome.php), so it works somehow. Flash Player 10 has hardware 2D acceleration, and Silverlight 3 is supposed to get that too. I think JavaFX has 3D hardware acceleration, but you need the scenegraph library for that which I believe is GPL and therefore can't be used in commercial products. Back to penetration: Shipping 100 million JavaFX runtimes is nice, but (like Adobe 100 million AIR downloads) that number is a bit misleading: JavaFX is included in the JDK sinc 6u11, so I guess I already count as two JavaFX downloads since I downloaded JDK 6u11 and 6u12. I would suggest that Sun hires the same company that measures the Flash Player penetration for Adobe (http://www.adobe.com/products/ player_census/flashplayer/version_penetration.html), have them measure Java penetration and publish that every quarter. Adobe just managed to get Flash Player 10 on 56% of all PC in 2.5 months - that's the number to beat for JavaFX. ;-) I guess that Microsoft doesn't publish these numbers because they would look bad for them (I think they recently talked about Silverlight being available "in every third household" whatever that means). I assume that unless JavaFX has 50-60% penetration, there won't be many JavaFX consumer apps out there, and Sun shouldn't go after the Flash market until then - unless Sun "buys apps" like Microsoft did with the broadcasting the Olympics through Silverlight, the president's inauguration or these various sport video deals. So instead of trying to switch Flash/Flex/Silverlight to JavaFX, I think Sun should go after users that don't have a RIA yet and see if it can get them to use JavaFX instead of Flash/Flex/Silverlight. This way, JavaFX in general just has to be "as good as the other guys" instead of _being better_. > RIA and rich media supporting tech is not a zero sum game, I think > there is room out there for JavaFX, and Flex and Javascript/HTML to co- > exist, and if the JavaFX vision is delivered on across mobiles, > desktops and TV, then I think it's going to be a worth while thing > that will benefit Sun and the developers/companies who support it. Competition benefits everybody here, I agree. But I get a chuckle every time Sun mentions the mystical "2 billion Java phones". Now mobile development is intrinsically hard - vastly different CPU / graphics power, screen resolutions, input capabilities, network connectivity. Now add to that JavaME: A friend of mine worked on a JavaME mapping client about three years ago that accessed the phone's location either through built-in GPS or through external Bluetooth GPS receivers and painted a map. It was not pretty - JavaME had some serious bugs across different devices, and GPS / Bluetooth through JavaME was even worse. So if you really want to have a JavaME application that works across of phones, I think even now you'll spent most of your time getting around JavaME issues and limitations on different platforms (again, some of that is intrinsic to mobile devices), limiting yourself to the lowest common denominator. I got some JavaME game trial versions on my N95, and they look pretty awful to me, graphic-wise (but then I have a Sony PSP :-). So let's assume you mastered all this and have your JavaME app. How do you distribute it to your customer's phones? People can't typically install apps themselves of the Internet, because carriers want to have the data revenue themselves, and uploading it locally from your PC often doesn't work either, and both of them wouldn't work for the more "casual audience" that just wants to click a button on their phone to get a new ring tone / wallpaper / game. There's no central app store, so start talking to a mobile carrier of your choice, get verified / certified there and then try to get a place in their distribution channel or get even pre-installed on new phones (both of which are typically reserved for high-volume apps, like games, and you may even have to pay for this). This typically also solves how you get paid if you want to have money for your app (typically through the phone bill, so set up billing relationship with the carrier). This all costs a lot of time and money. Then repeat this for every other carrier you want to get in - around four per country you want to sell to. I think there was an effort by carriers a while ago to have a common certification / validation, but I don't know where that stands. This means that you need a lot of money and time to write and distribute a JavaME app. Contrast that with the Apple app store for the iPhone/iPod Touch: Now that is a closed platform with a single hardware revision (it'll be interesting to see how you develop apps once the new iPhone / iPod Touch is out later this year - vastly superior graphics are rumored), but they sure got low barrier to entry, distribution and payment right. 20,000 apps (though mostly crappy ones, I guess) in eight months - when was the last time you saw a new platform taking off like that? Now Sun get money for each JavaME license shipped on a phone, and making it easier for developers to write and deploy JavaME apps is just a cost to them without additional revenue in a sense (JavaME is on most phones today no matter what), though it is vital for the long- term platform viability. But even if Sun wanted to do this - setting up a JavaME emulators for the ten most popular phones in each country, helping developers with certifying apps, setting up a global JavaME app store - the carriers or the phone manufacturers probably wouldn't let them because they want the relationship with the customer / developer themselves. So how again is JavaFX Mobile going to make that easier for developers? If I understood Josh Marinacci correctly (http:// www.riaweekly.com/2009/02/21/riaweekly044/), then JavaFX Mobile for existing phones runs on top of JavaME, won't have the hot-spot VM or hardware (video?) acceleration - these two are reserved for new phones, shipping with JavaFX built-in. So you'll get "old and new JavaFX Mobile" with new JavaFX faster by an order of magnitude (latest hardware, hot-spot, acceleration). Now add to that you have to draw your own UI controls on the phone until JavaFX 1.5, and I fail to get excited. I'm not even sure that Sun can address the fundamental problems in JavaME / JavaFX Mobile I outlined above, but it seems to me that if you really want to write something that at least resembles a good iPhone app (which seems to be the benchmark these days), you'd have to go with the new phones with JavaFX embedded (shipping in 2009, currently confirmed from Sony Ericcson and LG, though I bet Nokia will join eventually), erasing the "2 billion Java phones" advantage and leveling the play field for iPhone / Android / Windows Mobile / Blackberry and maybe Flash Player 10 (supposed to ship on phones early 2010). And if you think that JavaME / JavaFX Mobile was difficult, wait till you get to JavaFX TV or whatever JavaFX is called that will run on set- top boxes on BluRay players. There has been a Java standard for cable companies in the US (http://en.wikipedia.org/wiki/ OpenCable_Application_Platform) and a global one for TV (http:// en.wikipedia.org/wiki/Multimedia_Home_Platform#DVB-J) for years, but where they are used, they were used by the hardware manufacturers or cable companies to write apps themselves, not for outside developers to deploy their apps. So like in JavaME, you would need to test against the different set-top boxes and then talk to the cable companies to distribute your app and get paid for it. So how do you get your Java app in the set-top boxes of the thousands of cable operators in the US? You don't (although I think Comcast actually wanted to get an app store up a while ago). The same is true for BluRay - you have all these different players out there, and although the new ones have an Internet connection, they don't come with a built-in distribution channel. Like with DVD players, not all disc features work on all BluRay players, and there are specialized companies for DVD/BluRay authoring, making it not easy to break into this marked at as an outside developer. What's even worse is that unlike with a phone or a cable company, nobody has a guaranteed billing relationship with a BluRay customer, so you have to set up payment yourself if you could somehow convince the BluRay companies to ship your app (close to impossible, I think) or link to a (not-existing) BluRay app store. Shipping your app on BluRay disc is an option but cost-prohibitive for most developers. I think here you're better off writing games for the XBox Arcade or the Playstation Store, but these probably have to be native games, since they will be compared to all these high-end games on these platforms. > But for now, given your circumstances, my advice is don't switch your > company over - but play with it yourself, give it a go, watch how it > grows up over the next 12 months, and avoid, like some people, piling > on the hate when it has its inevitable stumbles. Flex needed three versions to get it right (free runtime, Flash Player 9 with compiled Actionscript), so JavaFX has at least until 1.5 or 2.0. :-) > Diversity helps everybody - if any alternative technology was halted > 'because you can already do that in x' we'd never have any innovation > and progress. Well, so far JavaFX seems to have copied Flex mostly, but I'm sure there will be innovations down the road. Heck, Adobe hired a bunch of Sun folks last year (like Chet Haase or Hans Mueller, CTO of the desktop division back then - http://www.theregister.co.uk/2008/05/15/sun_rich_client_adobe/), so they must have the same opinion. :-) > Two questions I have for you though, since I evaluated Flex early last > year and decided to go with Ext-GWT for a major project: > > 1. Have you had any issues with .swf size getting out of control? .swf files are cached in the browser like images, so this is mostly about loading them the first time. Historically, we only support IE 6 and 7, but even there caching .swf files works fine - and recognizing new versions. Now we use multiple .swf files in different frames, and that works ok. If you're concerned about the .swf files, you can either (like us) have multiple .swf files through frames or use Flex modules (although I hear this doesn't seem fully baked, yet). Finally, you can use so- called runtime-shared-libraries in Flex 3 (http://labs.adobe.com/wiki/ index.php/Flex_3:Feature_Introductions:Flex_3_RSLs). You can deploy your .swf so that the Flex framework part (typically the biggest one) is linked as a (signed) RSL and will be downloaded and cached separately by the Flash Player. So when your app (or somebody else's) uses this, you'll download the Flex framework only once per browser. I think it works with different versions of the Flex framework, and I think you can build your own (unsigned) RSL (though they are cached by the browser, not the Flash Player). Our app is typically accessed on the intranet, so bandwidth and download times aren't an issue. > 2. Does the flex runtime scale okay with a complex client? We've been very happy so fare. We have a tree where we load around 60,000 nodes on the client, and we have tables with tens of thousands of records and charts with thousands of records, and that works all fine. Frankly, data transmission times where our biggest problem (we started with XML over HTTP in some areas), but AMF3 took care of that. It's been somewhat liberating to not having to do these paging / partial loading / sorting in the database tricks from HTML. :-) I'm sure we'll hit some limits at one point in time, but they are much further out there compared to HTML+Javascript. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
