You have some good points JamesJ - On Feb 9, 5:21 am, JamesJ <[email protected]> wrote: > However. If you are trying to write an interface to existing code, the lack > of generics is painful. The lack of arrays or easy access to Java arrays is > also painful in some situations. Sequences are interesting, but they just > don't do it all. It just doesn't feel like a "heavy lifting" language yet. > It feels hard to write robust solutions to more complex problems. (I > understand that it is still evolving, but I feel it still has a ways to go.)
IMO, the biggest problem in this are is that JavaFX Script doesn't yet have a native Map-like data type - something similar to the sequences in spirit and features (powerful syntax, immutability, interaction with other language features like generator (for), binding/triggers, etc.). Many so-called dynamic/scripting languages can get away with just list and map as fundamental constructed types (some langs, e.g. JavaScript and perl, don't even have real classes - everything is maps/ dictionaries); so it's a good model, at least for the bulk / higher- level work. When things get tough, it's lovely to just be able to use any of the hundreds of available collections from JavaSE and third- party Java libs - but there's some cost in convenience and portability to mobile. Augmenting sequences with a map would arguably be an excellent balance; the map would also help in better interop with Java methods that have map parameters/returns, which are very common. The support for native (Java-style) arrays should also be improved with the ability to instantiate the array, then I'd be happy enough. Yep, this whole paragraph was another plug for http://javafx-jira.kenai.com/browse/JFXC-642, please go there and vote ;-) That bug is very old for JavaFX standards (June 2008 - before 1.0FCS...), I have blogged about it in June 2009 (link in the bug), and it's unfortunately scheduled for "After SoMa", I would love to see this confirmed to the next major release. I understand that the javafxc team has been spending massive effort in the compiled-bind feature (that turned out to be ~100X more elaborate than I initially thought), but once this settles down, perhaps we should aim once again to ideas like JFXC-642. JavaFX Script must indeed become a more "heavy lifting" language. > Also, I'm not a fan of the distribution model. It seems that the > tools/licence won't let you make an executable jar and just send it out. The JavaFX runtime contains native code. LOTS of it. And it resorts to other tricks, part of the runtime is (or will soon in a future release) be put in the bootclasspath instead of the classpath. So, you won't be able to just stuff that runtime in a single jar, any time soon. Unless you use some packaging tool that supports native code. Then, at the very least you wouldn't get a portable package (but that's usually ok for internal apps). The license OTOH sucks indeed; Sun has officially promised that JavaFX would eventually be full open source - Rich Green from Sun was clear about this years ago in the first JavaOnes that hyped JavaFX, so I will continue to quote this to remember everybody that Sun either lied or broke a promise to developers, until they (now Oracle) open source at least the desktop runtime. (javafxc is already open source, but that's clearly insufficient. There are some encumbered pieces like codecs but missing these would be ok, the FOSS community could replace them.) BTW, if JavaFX starts building real momentum and market share, then its proprietary runtime will lose 80% of all the goodwill and mindshare that OpenJDK gained among developers in general and FOSS enthusiasts in particular. I fully understand the benefits of keeping the runtime project private and even the Apple-esque secrecy in the initial build-up of the platform; but this stage is close to the end now, I think Prism will be the last release that Sun|Oracle will have any excuse of strategy. After that, each year without the open source release will be a major mistake, the history of the JDK repeating itself (potentially with a "too little too late" release far in the future). > I would love to see how long it would take a some without any JavaFX or JNLP > experience to download the tools, build hello world and publish it. For a > product that is supposedly targeted at a larger audience than core > developers, I was surprised at the steepness of the learning curve. The tooling sucks too, the NetBeans plugin has a long way to go, for one thing it should support project dependencies (JavaFX libraries / subprojects) and have a superb JNLP editor and package generation / deployment / publishing features. A+ Osvaldo -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
