The original “Java desktop wishlist for 2008” was posted a little more than a year ago, and today i am reposting it in its entirety. You can see the reasons why at the end.
While the Java blogosphere is raging with debates on closures, properties and other negligible language-level features, the client-side battle is still fought between Microsoft, Adobe and Apple. And while finally Sun decided to step in with JavaFX and improved applet handling, this will change little without the tools for content handling.
As i already said, the customers don’t care about the technology. In “The Agnostic Geek“, Brandon Carson writes:
when you look at a web page, do you think, “Gee, I wonder if they coded this in BBEdit or Dreamweaver?” I don’t know about you, but I don’t give a flip what software product is used to create a web page. Use TextEdit for all I care.
And so, who cares that the applets will load instantly when there are so few good applets? Just look at the amazing breadth of Flash content created by professional designers. Content that has rich multimedia capabilities. Capabilities that come built in with the platform. Platform that is oriented towards content.
So, what are my top two wishes for Java desktop for 2008?
Number one: Cross-platform support for H.264 and FLV formats.
Showing is good, but it also must support creating the content and editing the content (just look at the Sliverlight demoes). And don’t tell me that 99.9% of the market doesn’t need editing. If you want to lead the market, you have to cover everything that the competition has and then some.
I don’t know about the licensing issues, but the reference implementation for H.264 is not that big. And Onavia already has pure-Java player. So it can’t be that hard once you decide to put as many resources on that as you do on JavaFX. And even better, accelerate it with OpenGL and Direct3D, while at the same time gracefully degrading to software loops on older cards.
Number two: Converters and viewers for competing markup formats.
You know what i’m talking about – those pesky competitors that have 99.9% percent of the consumer-facing rich desktop market. Flash / SWF, Flex / MXML and WPF / XAML. Each has its own set of designer tools for creating rich content. Each has armies of professional designers versatile in using those tools, in addition to Photoshop, Maya and others. Do you really expect them to master yet another (unproven) designer tool?
If JavaFX wants to have a fighting chance, it needs to provide a simple migration path. A path that allows taking an existing Flex / Silverlight application and importing it to JavaFX (at least the visuals). XAML has at least three – converter from Maya, converter from Photoshop and converter from SWF. The importing is not enough. You have to have exporting as well. If you’re not convinced, read what Joel Spolsky says about how Excel managed to overpower Lotus:
And this reminded me of Excel’s tipping point, which happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could write Lotus spreadsheets transparently.
Yep, you heard me. Write. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn’t want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you’re the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can’t switch until you can participate in the 123 ecology.
If you want to have professional designers to switch to JavaFX, provide a clear path back. Not that they’ll take it (of course, if the tools and the runtime are bad, they will), but it will give them a nice sense of security.
An extra step would be to allow using the same exact content at runtime without converting it to JavaFX. Soyatec does it partially for XAML, so it can be done. But if you do it, support the complete feature set (including 3D and, guess what, rich multimedia). A bonus part would be to include a bitmap to SVG converter – see VectorMagic for inspiration.
That’s it. I have only two wishes. Granted, these are two big hefty wishes. Will they come true? The first one might partially be, and the second one is highly unlikely.
So, why the repost? The reasons are quite simple – these two wishes have not been addressed in 2008.
Here are some Swing links that you might have missed during the last week:
Finally, Mikael Grev has announced release 3.6.2 of MigLayout manager for Swing and SWT. Mikael has been vigorously pushing for inclusion of this project in the core JDK distribution, amassing an impressive number of 289 votes in the bug parade. I am not quite convinced that it will be a good match. Looking at the available release notes history (since June 08), i see quite a few bugs being fixed (even this very announcement was made on version 3.6.1, with a bug creeping in requiring another minor release), as well as improving support for IDE integration. This is a perfectly normal situation for any project, even when the APIs are frozen as far as the project developers are concerned. Would you want to forego quick bug fixing cycle for a larger audience? Would you want to risk the restrictions of JDK (never breaking the APIs) even you are positively sure right now that this is the final state? These and other related questions don’t have a definitive answer (to witness quite a few API disasters in the core JDK), and tomorrow’s interview (not related to MigLayout) will provide an interesting take.
I’ve talked about LimeWire in the latest installment of Swing Links of the Week, and now it’s time to meet its lead developer, Sam Berlin.
Tell us a little bit about yourself
My name is Sam Berlin. I’ve been working with computers since I was a little kid. The first “program” I wrote was a collection of .bat scripts in DOS for my parents, to let them choose what program to open. I went to college for theater, but after one semester decided I didn’t want to be an actor and switched to computer science and music, then switched again to computer science and philosophy.
I’ve been involved with LimeWire since around 2001, originally contributing patches as an open-source developer. Nowadays I’m the lead developer for the LimeWire client and focus on all aspects of Java delopment (NIO, Swing, concurrency, etc…). LimeWire’s open-source community has fallen off a bit, due to mailing lists not being maintained & the code becoming more complex and difficult to maneuver. I’m making an effort to simplify the code and make it easier for newcomers to comprehend — fortunately that process helps LimeWire’s internal daily development too.
What is LimeWire?
LimeWire is a file-sharing program. It’s open-source (see limewire.org) and written in Java. The company is Lime Wire, LLC and also contains the LimeWire Music Store and a variety of other projects. LimeWire has been around for about a decade. Originally it was compatible with Java 1.1.8 and even ran on Mac OS 8. Today, the project has over a half million lines of code and requires Java 1.6. The most difficult aspect of managing it is that it’s a client application and runs on all sorts of desktops — we can’t target a specific VM or architecture and ignore bugs on other ones.
Why did you decide to go with Swing? If you were to start from the scratch, would you still go with Swing today?
I wasn’t around for the decision to go with Swing in LimeWire 1 (that held through till LimeWire 4), so I can’t comment on that. With LimeWire 5, we effectively did start from scratch. We threw away the entire old branch of GUI code and started fresh. The conception of LimeWire 5’s UI began by evaluating a range of toolkits (QT, SWT, Swing, AIR, and probably a few others I can’t remember). Each one presented its own problems. In the end, we ended up going with Swing after finding the mozswing browser. A browser that worked on all platforms was the last remaining hurdle to using Swing. Of course, as things turned out, it wasn’t all perfect. We decided to require Java 1.6 (for many other reasons), and Apple only decided to release Java for OS X in 64 bit architecture. Because MozSwing uses XULRunner internally, it needs native code bindings — but the native code for XULRunner doesn’t work in 64bit mode because it links to 32bit code in OS X. So we can’t use the browser on OS X.
Still, I’m happy with the choice of Swing.
What are Swing’s weak points in your opinion?
The worst thing about Swing is that it’s too easy to use wrong. This is why, in my opinion, Swing has such a bad reputation. It’s so easy to use, and so easy to use wrong, that millions of amateur hackers have written awful Swing programs and given it a bad smell. (Of course, the fact that the default look and feel felt like you were using a computer in 1990 didn’t help.) Swing is great because it’s so flexible, but the flexibility is really it’s downfall. It’s the classic tradeoff in API development — if you create something confined and limited, the internal code has the flexibility to change and grow without causing errors. On the other hand, if you create with extensions in mind, you allow for hooks and have to be concerned that additions will break the hooks. Swing chose the latter route and it handcuffed internal Swing development.
What functionality is missing from core Swing, and would you want to see third-party libraries folded into the core distribution?
The #1 thing I would like to see, and fortunately it is happening, is JWebPane — a lightweight browser. The fact that it’s not included today is almost absurd. It’s like releasing a new programming language that can’t connect to the internet. As far as third party libraries are concerned, I don’t really care either way if they’re included in core swing or as a standalone enhancement. So long as third-party development continues, it’s effectively in core Swing. The only argument I can make for wanting to have them included is that Sun would be forced to keep them up-to-date and working, but I’d rather that the components remain flexible and changeable as time goes on. Third-party libraries can break API compatibility with major releases (and doing so is often a good thing if the old API had intractable problems), but Sun can’t do that with new Java releases.
Tell us about your experiences with embedding a browser into a Swing application.
It’s been pretty easy. Finding mozswing was the hard part — it’s not advertised anywhere. We learned about it through a blog post about NetBeans. The only catch is the browser is heavyweight, so we have to do some fancy footwork to let things show on top of it. (Apparently in Update 12 Sun has enabled limited heavyweight / lightweight mixing, though I haven’t tried it.) In LimeWire 4.x we embedded the SWT browser on Windows. That worked well enough, but the SWT browser is very limited in how you can configure it. You can’t change the User-Agent, can’t run Javascript, can’t listen for downloads… you pretty much can’t do anything. What’s great about mozswing is it exposes the entirety of XULRunner. We intercept DOM events and open links in native browser when the target is _blank, listen for the progress of the page and show loading animations, etc… The ability to do anything XUL can do is limitless. We even listen for new downloads and show them within LimeWire’s UI, complete with the progress of the download.
What do you think about Sun’s new direction of client Java towards RIA space with JavaFX (called Swing 2.0 by Richard Bair)?
To be honest, I haven’t really looked too deeply into it. It came about just a little too late for LimeWire 5. I think it’s an interesting direction, but I’ll reserve my judgement until people start using it and creating more than simple applets with it. The real important change, I think, is the new Java Plugin — it’s actually good. You can run a Java applet without stalling the browser, and can drag the applet off the browser… that’s pretty cool (and useful).
Have you considered moving to JavaFX at some point in the future?
Not really, but I won’t rule it out.
Is there anything else you would like to add?
Swing isn’t dead, it just isn’t targeted to today’s designers. A designer today doesn’t want to mess with complex application logic, he (or she) just wants to paint something pretty. Swing was unfortunately written before today’s designer existed. Sun’s trying to make up for this with JavaFX (which may very well work), but that doesn’t mean Swing is left in the dust. You can still write an amazing application, but you need to be well disciplined. The approach we took with LimeWire 5 worked very well. We focused on implementing ugly wireframes that performed the functionality, and afterwards went back and painted the UI. It requires some patience to not be turned off by the ugly, and some patience to wait to ship until the pretty is finished… but it pays off. In the end, you’ll end up with a program that is very focused in what it does and how it does it, and has a consistent look & feel.
