I just got an e-mail from a party with a big stake in how this plays
out, and I'm wondering how to give them a useful response, without
speculating or sending them in the wrong direction. So here are a few
thoughts currently in my head, with some questions that you guys and
girls can probably help with.
1. Likelihood that Java completely goes away in Mac OS X 10.7 ("Lion")
The wording of Apple's deprecation statement certainly seems to
prepare developers for Lion shipping without an Apple-provided Java,
and the timing (9 months out) is consistent with the idea that the
Java team is now being reassigned to other Lion development tasks.
So, if there's no Apple Java, one of the following likely happens
a. Apple contributes their code to OpenJDK
b. Oracle adds Mac to their list of supported platforms
c. A third-party effort -- commercial or open-source, sponsored or
volunteer -- successfully delivers a Mac port in time for Lion
d. Third-party efforts fail or are not attempted, and there is no
production-quality JVM/JDK available for Lion
My IMHOs:
a. I think this is highly unlikely. It's not obvious that Apple even
could contribute sources derived from the commercial version of Java,
let alone that it would want to.
b. I'm a little more optimistic on this point than a lot of people.
What makes me think Oracle could rush in to the rescue is the fact
that they didn't kill JavaFX when they could (and, IMHO, should)
have. So what's the point of JavaFX if there's not a Mac JVM to run
it on? Running on Linux is cold comfort -- PCWorld's Linux columnist
just acknowledged that Linux on the desktop is dead <http://
www.pcworld.com/businesscenter/article/207999/desktop_linux_the_dream_is_dead.html?tk=hp_new>,
and even James Gosling agrees with him <http://nighthacks.com/roller/
jag/entry/desktop_linux_the_dream_is>. With no Mac VM, JavaFX is
effectively a Windows-only product, and its value proposition becomes
"less popular than Flash and Silverlight, less cross-platform, and not
even as good." Anyone can see that's pointless. Of course, Oracle
might see that too and kill JavaFX next… but for the time being,
they're still ostensibly in the desktop game.
c. and d. are the biggies, and what everyone's talking about. It
seems like there are multiple places where this development could be
happening -- JKoala, Soy Latte, OpenJDK, and possibly others -- and it
seems like all those parties really ought to talk to each other and
see who, if anyone, has the ball. There's a frenzy of interest and a
desire to get started, but they probably need leadership, a plan, and
an accurate assessment of what they hope to get done.
2. What if this were done as an official part of OpenJDK?
Factual question: when you build OpenJDK on Windows, does the
resulting JVM have a native Windows AWT library? Meaning, is there
code in there that specifically builds against the Windows Foundation
Classes (or whatever their UI toolkit is nowadays), and is presumably
#ifdef'ed around on other platforms? If so, couldn't the same be done
for Mac, if there is sufficient development support? I guess my
question is that since the Mac JVM/JDK has always been a separate
project, we are assuming it will always be that way, but it doesn't
necessarily have to be, if OpenJDK itself decides to add Mac as a
supported platform.
3. How much work are we really looking at?
JKoala is seeking €50K, and thinks it'll take 1 to 2 years to finish
the job (not clear if that's with just Emmanuel and whatever code
contributions he can get, or if he's counting on getting other full-
time developers). As I wrote earlier, Scott Kovatch worked on the Mac
SWT while at Apple and Adobe, and said it took five full-time
employees a year to do the Cocoa version, which is why I would set my
baseline estimate as five person-years, or about US$1 million in
development costs.
A natural question is "can we do this bare-bones and leave stuff
out"? Presumably, people are thinking of the little-used AWT widgets…
nobody's going to miss java.awt.List, certainly not Swing
programmers. But I think this overestimates how much work is
skippable, and how much work is really required. Looking through the
Javadocs, what do you think is skippable:
java.awt - Even without heavy-weight components, you need the
lightweight Component, all the event stuff, layout, Toolkit, Java2D
stuff, font metrics, etc. Oh, and some Mac programmers still use AWT
menus because they're always at the top of the screen, rather than in-
wndow (the Swing default, but contrary to Mac UI conventions).
java.awt.color - Part of Java2D
java.awt.datatransfer, java.awt.dnd - Copy-and-paste, drag-and-drop.
Have to support these.
java.awt.event - Event handling. Must have.
java.awt.font - Part of Java2D
java.awt.geom - Part of Java2D
java.awt.im, java.awt.im.spi - Input methods, needed for
accessibility. Lose these and you likely can't develop for government
or education. So they really should be included.
java.awt.image - Part of Java2D
java.awt.image.renderable - Part of Java2D
java.awt.print - Printing support, part of Java2D
java.applet - Probably a practical requirement for the handful of
applets still out there, like the Facebook photo uploader. Also, do
JavaFX or Java WebStart depend on applet support?
javax.print.*- More printing-related classes
javax.sound.* - Audio support. Probably the most droppable of the Core
Java packages.
javax.swing.* - Most of this stuff is written in Java, but you might
have to write a new Mac look-and-feel (perhaps bring in Quaqua, or
fall back on Nimbus or Ocean).
I don't know if there's much in there that can be skipped or put off
to version 2, at least if the minimum metric is, say, to keep NetBeans
and InteliJ running. Maybe someone has a reason that this workload
isn't as bad as it looks. Also, there are probably other tasks that
aren't captured in APIs specifically, like more accessibility support
(tying into the Mac's screen reader, for example), file types and
double-clickable support, etc.
--Chris
--
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.
