Java desktop wishlist for 2008
October 26th, 2007 | 9 Comments »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.
Related posts:
- Java desktop wishlist for 2009 The original “Java desktop wishlist for 2008” was posted a little more than a year...
- Is one of my Java desktop 2008 wishes coming true? I had only two things on my Java desktop wishlist for 2008 – cross-platform support...
- Java on the Desktop, the past, the present and the future – interview with Richard Bair In this interview Richard Bair answers my questions on Swing, SwingX, JavaFX and Java on...
- Java desktop spotlight – interview with Elie El Khoury of Woopra Woopra desktop client is my favorite Swing application of the year, and it’s time to...
Thanks for stopping by. My name is Kirill Grouchnikov and I am a user interface engineer. I have been doing client side development professionally over the last decade or so, in a variety of UI toolkits and libraries that spanned Motif, MFC, VB, Ada, Delphi, Swing and SWT. Recently I joined the
I think properties are rather important to the client ;-)
However, I agree on both but I think the problems are far greater since I actually spent time with the lawyers on these issues… Flash/SWF converter seems like the biggest problem, the Adobe file format license explicitly forbids you from writing a player without written consent from Adobe. You can try to argue that a player is not a converter but I wouldn’t bet on how this will end up in court.
I was in a position in a project that had the financing to do something like that and such a requirement and it fell simply because of the licensing problems. There is hope though, I’m not to crazy about the license but there is https://jflash.dev.java.net/ which is trying to build a pure Java solution. Maybe now with Java being open source the community will spring in, after all there have been quite a few open source attempts to clone Flash (clone/convert is very similar…).
About the media, I’ve been saying for years that Sun should just fix the damn thing… The main problem is again with the lawyers (you get a feeling Sun has too many), the patents and licenses involving media formats and tools are just a huge mess. Sun doesn’t have patent agreements in the field since it has no media experience, so its stuck negotiating every little format with small and large companies that keep blackmailing it. Sun can’t pay licensing since it gives the JVM for free (that was a huge problem with GIF at the time).
I doubt 264 will be supported by Sun, I don’t think its a realistic request. However, integrating with platform native players has no licensing complexities since Sun doesn’t ship any codec with their implementation.
The main problem there is Linux which has unstable media standards and whose players are usually in violation (putting Sun in a potentially risky position). Generally I like the approach taken in Java 7 and I think its a smart move, I wish it would be here sooner…
Capture seems like blue sky right now… its been 12 years, give me decent playback in the JDK first I’ll settle even for that :-(
Personally I think things like Java 3D/JOGL should be part of the core JRE, its ridiculous that JNDI naming, JDBC and CORBA are part of the JRE and 3D/Media/file associations are not…
Shai,
Thanks for the information on licensing issues. You would notice that i don’t ask for pure-Java solutions (except mentioning that Onavia is one, so it’s feasible). This is on purpose – i don’t care if it’s a native library wrapped in a lightweight component or a pure-Java Swing component. As long as i don’t have to install anything else and it’s truly platform-independent – who cares?
These two are the biggest obstacles that JavaFX faces against AIR, Silverlight, Apollo etc. All the rest (file associations, access to bluetooth / firewire / usb, nio 2) is nothing compared to these.
And i think that Sun has enough money to enter into a licensing agreement with Adobe and Apple on FLV and H.264. Unless, of course, these companies actively refuse to do so, and if this is the case, it should be made public.
Hello Kirill,
Great post!
I think we also need to think about what is needed in the lower levels. I’m thinking about components. Not until people start writing good, easy to use components will JavaFX have something to work with. Sun needs to make the JavaBeans overhaul happen and add properties. Both are needed to firm up the IDE/Authoring tool – Component interaction. Now it is simply too hard to write cool components that works everywhere.
Cheers,
Mikael
Money is a big issue with Sun, especially with something that needs technology licensing for distribution in the JDK. Most of these companies demand royalties (Sun would have to pay for every JDK download!) and its hard enough to get Sun to pay for something it gives away for free.
Furthermore, this would hurt the open source aspect of Java since copyrighted/patented technology would knowingly exist in the JDK…
With Apple I can see a license agreement happening (although it might be problematic), ideally I would love to have Java bundled with QT and just have QT bee the Java media layer (the only major problem here being Linux).
Adobe Flash licensing is a whole different ballgame, I would love to see this happen but I think both companies are too arrogant at this point to actually do this.
> I doubt 264 will be supported by Sun
> Sun should just fix the damn thing
> Sun has enough money to enter into a licensing
> Sun would have to pay for every JDK download
Sun, Sun, Sun, Sun, Sun…..
Your guys seem to believe that Java is Sun and Sun is Java. As long as big enterprises like IBM, Oracle, SAP, Sun don’t cooperate on Java’s progress there will no progress. JavaFX will be another giant failure on the desktop. Sun Microsystems considers Java to be a Sun-only thingy. Sun even tries to “kill” the Apache Harmony-effort. Why not cooperate with Intel’s and IBM’s excellent software-engineers?
That’s the whole problem of the so-called “Java-community”. There’s no true Java-community. I hope that IBM will kill Java as fast as possible. The successor of Java is ready. Look at IBM Developerworks.
You talk about problems with patent-encumbered media formats. That is a big problem, I admit. File formats should be open. But why the hell is not Ogg Vorbis in the JDK, Ogg Theora in the JDK, SVG in the JDK, …. ? Sun just really don’t care about media, even open media formats, which is really bad.
Kamil, I agree with your conclusion about Sun’s treatment of media sucking… SVG, HTML4, 3D etc… should have been in the JRE long ago with some sort of media support and there is no excuse for these omissions.
I have no idea about the specifics of OGG and how practical it is for the JRE.
I agree with Shai Almog that Properties are rather important! I think that first we get properties right, then binding to work with them, then we can concentrate in content in a way that is most agnostic of the GUI.
Of course I don’t disagree with the Kirill for the other features, but goot properties would untie my hands :-)
[...] was almost hoping that the video support would address the number one wish i had for desktop Java in 2008 – cross-platform support for H.264 and FLV. We’re still not [...]