Skip to main content

Java(FX) Enterprise Development

Posted by rbair on November 7, 2008 at 1:16 PM PST

The past couple months have been incredibly busy for the Java client group. After JavaOne we started essentially from scratch writing and rewriting the JavaFX APIs and implementations to get them ready for general use. When we do release the bits, bear in mind it won't be perfect, but our commitment to JavaFX is strong and as you would expect, future versions will always be better than the last. There is a talented team of developers working on the JavaFX SDK, including Kevin Rushforth, Chris Campbell, Jasper Potts, Jim Graham, Dmitri Trembovetski, Igor Kushnirskiy, Amy Fowler, Tony Wyant, and on and on, and it is a pleasure to work with these folks on a day to day basis.

As many of you know, I've been the SwingLabs lead for 4 years now (has it been that long?). When Hans left, I took on a lot of responsibility in the JavaFX SDK and haven't had time (along with the rest of the team) to properly interface with the community. I personally very much appreciate the work and interest in SwingLabs even while I've not been able to participate in the day to day operations as I had before.

Our team of Swing & AWT engineers in Russia have also been very busy on some pretty important skunkworks projects. Alex Potochkin has taken ownership some months back of JSR 296: Swing Application Framework. He's also going to be the main day-to-day Sun contact at SwingLabs. He's the author of the JXLayer component which is quite cool. We have a number of additional announcements in this area which will be made at Devoxx.

Alex has also been heads down for the past couple months absorbing the design of the App framework and looking at directions he'd like to take it. JSR 296 is definitely staffed and supported and you will see forward progress.

Sun is committed to enterprise Java development, both with Java and with JavaFX. Sun is also committed to rich internet applications and mobile applications and consumer applications. These are not mutually exclusive.

When I say we're committed to enterprise Java development, I mean everything that that implies. We're committed to powerful and extensible GUI toolkits. We're committed to frameworks and tools for validation, authentication, web services, etc.

We're also committed to ease of use and good documentation. You haven't always gotten that from us in the past. We understand the issues and are addressing them. We're committed to making our UI toolkits easy to use, without giving up enterprise class power.

There has been a bit of discussion about JavaFX, specifically that putting time and resources into JavaFX is "wasted" or for "toy demos", or that by investing in JavaFX we're abandoning enterprise developers. Nothing could be further from the truth! We will have more announcements going forward as things are released. But I want to make this point very clear:

    Sun is committed to enterprise application development.

If you have questions, please leave a note or contact me directly, I'll try to keep up! Also, please come to Devoxx and bring all your burning questions. We'll be making a series of announcements at Devoxx that relate directly to the question of the future of enterprise Java development and all the continuing work in both SwingLabs and Swing.

Related Topics >>

Comments

@Patrick Right, but improving ease-of-use in the context of developing desktop apps is one of the main practical benefits of tail calls. I think it is really important to stress that.

@jdh: I _do_ think Richard is a great person to discuss ease-of-use in the context of JVM-based desktop technologies. I don't see him as the best person to influence a decision about whether the JVM should implement tail call optimization. There are better forums for pushing that particular issue. Regards Patrick

@Patrick I apologise if Richard is not the right person to discuss ease-of-use in the context of desktop apps. To the best of my knowledge, nobody at Sun is interested in the features they're missing that drove us to .NET. I know this isn't the right time though: Microsoft have had this in .NET for 7 years now...

Richard, assuming all technological aspects for JavaFX 1.0 are finished by Dec 2 2008, there is still an itsy bitsy legal issue: the current licensing scheme. Last time I checked project SceneGraph is GPL v2, the open jfx compiler is too, this means that the javafx runtime is also GPL v2, meaning that no serious commercial nor enterprise development can be made with these APIs/tools. Will the licensing model be revisited to become more friendly, perhaps using the same licensing model as the JDK (GPL v2 + classpath extension) or even LGPL?

@jdh: This seems like neither the time nor the place to bring up tail calls. Richard works on desktop/client/UI technologies for Sun. He's written a blog entry about Sun's work on and position on desktop technologies. I'm pretty sure you'll have little influence on the priorities regarding tail-call by writing here. I wish you the best in your quest, just suggest you find a better outlet for your suggestions. Cheers Patrick

@Xnilo I agree completely and that's exactly why I'd like to see the JVM catch up in this respect. If the JVM had tail calls, third parties would build modern languages on the JVM (OCamlJava, Scala, Clojure etc.) and we could leverage that to tap a market twice the size of our current Windows-only market. The only reason we've gone to Windows is that it is technically superior (for now).

Wow... talk about some vitriolic rants in the comments! M$ may have tail calls, but they don't have much to offer when it comes to platform independence. I know there are some options, but they are a generation or two behind, and M$ doesn't really have an impetus to change that. I'm looking forward to the JavaFX. If it lives up to its potential, we could potentially see the rebirth of the rich Internet application.

maybe i'm being overly critical here, but i just can't see a declarative markup for java2D/swing and maybe a video codec as the second coming of applets (even w/update 10). it seems like sun knows it's behind the game so the only thing they *can* deliver is promises. why announce javaFX so early and incomplete unless you have no compelling alternatives? it was years before swing could really hold it's own and was hardly a raging success, JSF is a train wreck. i'm just not that optimistic about javaFX.

@Jean-Francois Scala does not support tail calls but it does transform some (non-mutual) tail recursive functions into imperative loops. That is better than nothing but because most functional design patterns (e.g. combinators, continuation passing style, monadic style) use functions that do not happen to tail call themselves directly cannot be written robustly in Scala because it is prone to stack overflows. There is no stronger evidence for the seriousness of this problem that the Scala compiler itself. The authors are, of course, expert Scala programmers. Yet there have been 32 bug tickets taken out for stack overflows against the Scala compiler itself! For me, Scala is one of the most interesting language on the JVM but you cannot expect enterprise applications to use it when it has such fundamental problems undermining its reliability. @jb I'm not a "zealot". I am the CEO of a hi-tech company that is migrating to .NET because it is technically superior. If Sun implement tail calls for the JVM, we will surely migrate back. We're not alone: Morgan Stanley are migrating 100,000 machines off the JVM and onto .NET for the same reason (F#)! I'm well aware of Clojure: it does not and cannot support tail calls adequately because the JVM lacks them. That means you cannot implement most functional design patterns in Clojure robustly. Hence Clojure either cannot be used as a functional language or it cannot be used for enterprise applications because they require reliability. Scala has the same problem. So does the OCamlJava project and all other FPL implementations running on the JVM: they need Sun to implement this functionality in the JVM or they will never go anywhere.

@Jon "Until that is done, the JVM cannot possibly hope to compete with Microsoft's alternatives." LOL ! You must be kidding or be the last on earth (appart from MS employees or zealots) beliving that .net is about to "kill java". Ever heard of clojure ? Seriously, the only area where a JVM have strong competition with MS.net is not on the business logic (mostly server side those days) but at the client side. F# or whaever "MS touted" revolution language based on a "common ground" (aka .net) will not be any different from from other language on its technical perimeter, hence its inherent capability. Need a complete list of innovative languages for the Java platform ? google to "vmlanguages" (an good ole link) and enjoy. Need good-old languages for the JVM, go to the same link, python, php, even C ! @Richard Clearly, JavaFX is not going in the right direction. Enterprise software need clear separation between visual rendering and business logic/content. JavaFX is not proposing this (same problem with xul, xaml, silverbloat or any of the adobe technology created so far). But JavaFX is not having the same level of tools that adobe got at home ! Thus, JavaFX will never compete with the Flash family.... unless ... sun start to thin with two minds "one for design" and "one for business logic". Rgs, JB

I sure would like to see information on JSR 295. Anything forthcoming?

Don't forget JSR 295 - Beans Binding... Combined with the Application framework, that is what us old-time Swing developers are counting on.

Thank Richard and JavaFX team for the great works. Hope to see a group photo of the JavaFX team , "There is a talented team of developers working on the JavaFX SDK, including Kevin Rushforth, Chris Campbell, Jasper Potts, Jim Graham, Dmitri Trembovetski, Igor Kushnirskiy, Amy Fowler, Tony Wyant, and on and on," Is JWebPane released together with JavaFX Desktop ?

@Richard: - what about JSR-295 (beans binding)? Are there still efforts in that direction? - I am one of those who claimed that I consider JavaFX as a toy (from the first day I've seen it -it was called "F3" then- quite some time ago now), maybe I am too reluctant to change (like 99% of the world)? But Sun will have to convince me that JavaFX is ("will be" would be more correct in this context) a better choice than other (JVM-based) solutions (eg scala-gui, groovy-griffon, there are probably others too) which are natively based on Swing (which provides a faster learning curve for Swing developers and allows a lot of reuse of the many good open source -and commercial also- libraries that exist in the Swing ecosystem) @Jon: scala is JVM-based and supports tail-calls (don't ask me how). So it seems this change is not absolutely mandatory (although it might make it easier to implement new functional languages atop the JVM). @Patrick: Right on target! We need more blog posts from Sun staff (and not only about JavaFX but also about Swing please and also other improvements to the language that would benefit Swing GUI development!) Cheers Jean-Francois

In other words, Sun is no longer committed to mere-mortal desktop application development. If it isn't enterprisey you don't want to have it.

@Richard: Thanks very much for posting this. I think the biggest mistake Sun has made in the last year is not clearly communicating what the schedule and plans for Java 7 are, including changes and improvements to existing libraries such as Swing. It's been pretty quiet and one gets the impression all you all are working on is JavaFX. A lot of the anger in the last couple of days stems from lack of good, regular communication. Update 10 was important, sure, but we're also wondering what's happening with APIs. As FX is still an unseen and unproven technology, we need to keep hearing about the improvements to the good old stuff we have out in the field. IMO, the "transitions" around the two JSRs were not handled very well either. We (outside Sun) need to know if those are real, or not, and if they'll be finished, supported, etc. Tip: you guys need to start blogging again. One blog entry a week. No need for demos (although tell Chris C. we miss the cool applets he used to post :), just start talking, please! Regards Patrick

Functional programming greatly simplifies several core problems in enterprise application development. Microsoft's F# programming language is destroying all JVM-based alternatives in this context because the JVM itself is missing a single critical feature: tail calls. If Sun are serious about enterprise application development then they will need to implement tail calls on the JVM, allowing the language implementors to create competitors to F# that are built on the JVM instead of .NET. Until that is done, the JVM cannot possibly hope to compete with Microsoft's alternatives. Regards, Jon Harrop.

look to this demo http://jfxstudio.wordpress.com/2009/05/25/the-graphic-database-front-end... - it implements JSR 296, it has nice design, it works with sql server. It show all you need for enterprise applications.