If I understood it right, this was supposed to be the "year of Java FX" at Java One. We were going to be stunned by how clever and clear Java FX is. Instead, there seems to be deafening silence in the blogosphere.
The history of Java UI is littered with disastrous decisions, starting with the AWT (Abstract Windowing Toolkit), which was created at the last second, because (no surprise) the language designers hadn't considered UI as an important paradigm for Java. Rumor has it that AWT was one month from conception to completion, which certainly fits. The results of AWT -- buggy and equally mediocre on all platforms -- destroyed everyone's faith in Java UI, for so long that Swing, which has been baking for years and years, is only just getting back some of the lost mojo. Users, who have a long memory of first impressions, still equate Java with crappy user interfaces, so to them the steaming coffee cup looks like something else that steams.
Then there's the steadfast refusal to support a component and event model in the language. No, Java Beans is not that; it's a weak attempt to fill in the gap. A true component and event model is far different from requiring the programmer or environment to spew out lots of code to emulate it. If that was the solution to everything, we'd never need abstractions; we might as well just say that a basic Turing machine will solve all problems.
And Swing programming has never been easy, but always messy and complicated. There were periodic murmurs of trying to make Java UI programming as easy as Visual Basic; at one point, Sun even had a VB porting project but abandonded it. Without the underlying infrastructure it can't ever happen. You'll always end up with lots of tedious UI code.
Basically, UI programming in Java has always been an afterthought, reluctantly accomodated but never really supported. It's no wonder that people are taking a wait-and-see attitude about Java FX.
How many well-known Java desktop applications are there? Well, there's Eclipse, a development environment, which created its own UI library because Java didn't satisfy the needs at the time. There's NetBeans, a development environment, which shows that Swing is now up to the task. And there's IntelliJ, a development environment. But I don't know of any general desktop apps in Java, especially ones that people pay for.
The reason people don't seem to create consumer and business desktop applications in Java may in fact be the UI debacle.
I've been studying Flex on and off for several years now and I continue to find it to be the best all-around solution for UIs, especially because I'm not trapped using a single language for the back-end logic. Flex was designed from the ground up as a user-interface language. The use of Flex as a UI solution for multiple languages has been expanding because people have been creating AMF (ActionScript Message Format) bridges for their favorite languages.
AMF is an ideal approach because it is asynchronous, so it fits well with the UI paradigm. In general, you never know how long something is going to take, and the asynchronous approach guarantees that your UI is always responsive no matter what is going on.
I've shown an example of PyAMF in this article. The PyAMF project appears to be quite active and well-maintained, and provides a straightforward solution for creating UIs for desktop Python applications.
RubyAMF also seems to be a very active project. It creates Flex user interfaces for Ruby on Rails apps, but there was a presentation at the last RailsConf on "Powering AIR Applications with Rails," so it would seem to support the desktop paradigm, as well.
There is an OpenAMF project for Java-Flash remoting, but it appears to be dead, with the last activity being 1.0 Release Candidate 12 in April 2006. The product doesn't work with more recent versions of Java, and no one appears to be maintaining it. Which is interesting because Java should theoretically be a much larger base and in that vastness there should be a group of people who want this -- I certainly do. Even more so because BlazeDS is open source and contains the core workings of what you need to create Java AMF (BlazeDS itself is only designed for Java web apps).
I don't know this for sure but I think at some point Adobe extended the olive branch to Sun regarding connecting Java and Flex beyond BlazeDS, but as usual, Sun couldn't see beyond their "not invented here" motto and had to create something "better." So now everyone appears to be taking a wait-and-see attitude, wondering whether Java FX is going to be another "greatest thing in the world, just you wait" that never materializes (perhaps Sun, in all of its tussles with Microsoft, has learned far too much about that company's marketing practices).
My first preference would be that Adobe would create and maintain a Java-AMF bridge for desktop applications, but perhaps Adobe considers Java a server-only technology; in any event, desktop Java support doesn't appear to be forthcoming from Adobe (I'd love to be surprised about that one). Perhaps their focus is on competing with Silverlight (I'm definitely waiting-and-seeing on Silverlight. Microsoft always promises big, but what they actually deliver is often very different -- considerVista).
So if people are really interested in desktop Java, prove it. Take the work that's already been done in the open-source BlazeDS and create a desktop Java-AMF bridge, so we can easily add AIR user interfaces on top of Java code. That way you can have easy-to-create UIs now, instead of waiting to see whether Java FX pans out.
I think many people will tell you that people do care about the Desktop Java. As the founder of JIDE Software who focuses on providing Swing components and services, we have more one thounsand company customers who are doing desktop applicatons in Java. Most of them are making enterprise desktop application. We have been doing this since 2002 and the trend is definitely going up, especially in the past 2-3 years. Since most of them are enterprise applications, many of them are used internally only, that's probably one reason people didn't feel Swing is widely used. But NetBeans and IntelliJ are excellent show cases for Swing. Not many desktop applications are more complex than these two. Swing is still weak in the consumer application area. Hopefully the Java FX and new consumer JRE release will make Swing into consumer application area as well. That's not certainly what Sun is good at and it will be a long journey.
I think Flex is very good, but I have not yet seen compelling evidence of it being highly applicable in the standard web based enterprise application in the internet space.
It seems it is a good fit for Intranet applications or even for adding complex or unique UI aspects to parts of a large enterprise application.
But if someone were to start today to develop an enterprise application (business process & form based, and data input/out with some data visualization) that will be used by hundreds of thousands of users over a browser across the Internet, would someone risk building such an application using Flex?
So as an example if I were to compare JavaServer Faces vs. Flex, I still find it hard to justify Flex in the above above application. I'd love to see some unbiased analysis of pros and cons of Flex in such a situation.
I hope Adobe will make Flex and AIR a success by continuing on reducing the barrier to entry. For example, provide good skins/themes by default. Support as many connection entry-points as possible by default (JSON). Provide for flexible UIs which use layout managers and can be re-dimensioned (800x600, 1024x768, 400x200, whatever the user has or chooses) making as much use of the available browser content area as possible. Make the development environment as close to free as possible (which of Eclipse or NetBeans or IDEA is commercial and thus has fewer users?). Soften the need for designers/designing.
At the end of the day, desktop developers are kind of hardcore, given most other developers choose standard web. That is, the market can be kind of tough.
Bruce, as David points out, desktop Java in the enterprise is quite alive, you just don't read about those apps in regular press nor blog posts. Swing has issues, no doubt about it, the JavaFX Platform will try fix some of them. Personally I don't think JavaFX Script will have the impact over its 'competitors' as Sun expects, being so close to Java but at the same time alien is going to exert a big toll on developers. Of course I'm biased against it as Groovy fills all my desktop Java needs right now.
Groovy puts at your disposal the powerful SwingBuilder. When accompanied with SwingXBuilder (Swingx), JideBuilder (Jide JCL) and GraphicsBuilder (Java2D), gives you a great abstraction over popular Swing and Java2D components, there are even other builders in the horizon that leverage Prefuse (PrefuseBuilder), JFreeChart (chartBuilder) and GNU plot (DotBuilder), what it is not to like?
You mention a Java bridge for AMF, good idea, wouldn't it be sweet to have an AMF plugin for Grails?
If you are looking for some examples of pretty serious applications written in Flex (and a couple in SL/WPF) then check out http://cynergytv.com. Disclaimer: I work there.
Bruce, I'm a little unclear on what you want to see built exactly. Is what you're looking for a Java library that can invoke services exposed via AMF? I suppose that'd be a nice convenience but I don't think backends in AMF are numerous enough for that to be valuable.
As an aside, I'm looking to write some adapters for JMeter so that I can easily do load testing against backends designed for Flex/AIR apps, be they Java, .NET or anything else.
Where i work (www.rosettabio.com), we produce several large scale scientific applications that are java clients.
Do the people using the applications care about desktop java? Absolutely not. They shouldn't know and shouldn't really care. They care about getting their work done.
Do the people developing the applications care about desktop java? Heck yeah. Sure, swing isn't the most easy to use graphical toolkit, but doing what we do in windows specific C++/etc would be insane. If we were starting from scratch we might use SWT instead of Swing, but we started some of our apps almost 10 years ago, so we have a lot of custom swing components.
> Do the people using the applications care about > desktop java? Absolutely not. They shouldn't know and > shouldn't really care. They care about getting their work > done.
That's a very good point, and there's an angle that so far no one addressed here. I developed a Swing app for public consumption once, and it still has dozens of business as users. Even putting Swing's coding difficulties aside, what I didn't like about that app was that it never quite looked snappy. It never had the "wow" factor. With Flex, I almost always get "wow" as an initial response. It doesn't mean that users later don't want to improve on the UI, just that the initial reaction is appreciating.
Before anyone jumps in to say that no "wow" factor is necessary for a great UI, of course, I agree. Having a modern look is just one aspect of a great UI - but it is an important aspect.
The other thing is that a lot of people initially prefer to access applications inside a browser window. Again, I don't think it's a particularly good model, but that's what people seem to want. Not only are applets difficult to make work inside the browser, but they also look foreign inside an HTML page. By contrast, you can style Flex components with CSS, and you don't have to be a designer to make a Flex app blend nicely in with an HTML page.
Of course, I read Chet Haase's book on "filthy rich clients," and it proves that you can make any Swing app look really, really nice, too. But with what effort?
Related to the issue of effective development is remote data access. Java has had RMI for a long time, but the secure RMI project (JERI) is still buried deep into the Jini codebase, the context in which it was developed. Although RMI may not be as efficient as AMF, I'm surprised that no one really elaborated on the need to access server-side Java objects from within a Java client over the Web.
BlazeDS is possibly one of the best things that happened to Flex. Before people would jump in to say that RPC for the Web is a bad thing, and that I should use REST instead - well, I have, and I have to say from experience that AMF and RPC is a very, very effective technique for possibly a large category of applications. You often have situations where the client and server-side object models are similar, and then you can just access server-side objects using BlazeDS, and the serialization, etc., is all taken care of for you.
I developed a small framework for RESTful access to resource from within Flex, and used that framework with a RESTful Rails app. But for a Java backend, I use BlazeDS instead.
No one in the Java world seems to think that secure RMI (i.e., RMI over the Web) is that important. Is that because other protocols, i.e., Hessian, are so much more efficient? Or is it because most people have gone down the XML/REST path so far that they don't want to have another look at RPC/RMI?
> > Do the people using the applications care about > > desktop java? Absolutely not. They shouldn't know and > > shouldn't really care. They care about getting their > work > > done. > > That's a very good point, and there's an angle that so far > no one addressed here. I developed a Swing app for public > consumption once, and it still has dozens of business as > users. Even putting Swing's coding difficulties aside, > what I didn't like about that app was that it never quite > looked snappy. It never had the "wow" factor. With Flex, I > almost always get "wow" as an initial response. It doesn't > mean that users later don't want to improve on the UI, > just that the initial reaction is appreciating.
I work on a Swing based application and I noticed recently that it looks a lot nicer running under 1.6 than on 1.5., at least in Windows XP. It's 'snappier' and even the text looks better. It looks much more like a native application. They've also apparently fixed some bugs in layout managers that used to make me question my understanding of them. I have another app that requires 1.6 in order to render the windows properly.
It's unfortunate that it's taken this long for Swing to really be a decent platform but it is getting there. 1.7 will add some more really nice features. It just may be too late, though.
The truth is that swing is a mess and it is because of backwards compatibility (and intuitive concepts). The fact that netbeans added a usable layer on top of it, does not discount the fact that they had to make EXTENSIVE refactoring and replacement of many things.
But i do in fact care about portability. I care so much i've done a application on swing. (It's still a mess right now since i'm still adding fundamental functions).
I'll chime in. I wrote a Swing app a few years ago. The level of effort required and the overall clunkiness of the result convinced me that Java UI was just pointless. I've revisited that app as recently as a couple years ago. It still looks awful (I'm using standard swing components) and feels "mushy" in terms of responsiveness.
Now I just write Mac apps. Windows is dying anyhow, Linux lacks the interesting infrastructure I need to do the kinds of apps I want.
Maybe enterprise UI's are OK to do in Java. But if that is target, I can make a better case that buying VisualWorks or even VB will yield better results with much less effort.
> I'll chime in. I wrote a Swing app a few years ago. The > level of effort required and the overall clunkiness of the > result convinced me that Java UI was just pointless. I've > revisited that app as recently as a couple years ago. It > still looks awful (I'm using standard swing components) > and feels "mushy" in terms of responsiveness.
Did you try it in 1.6? That's where the major improvements start.
Flat View: This topic has 103 replies
on 7 pages
[
123456
|
»
]
Previous Topic
