Chris Adamson's Blog

Community: Mac Java Community Archives

Apple's JavaOne BoF

Apple offered two surprise BoF's at JavaOne - a "surprise" because they hadn't previously been announced or expected and just appeared in the addendum and corrections to the JavaOne show schedule. Still, about a hundred developers managed to find their way over to the Marriott to see the show.

I got there too late to see the formal introductions on the first presentation, which was well into describing the affects of the Intel transition when I arrived. Also, if there was an NDA warning, I missed it, though the second BoF wasn't NDA and it would be impossible to enforce an NDA at these offsite BoFs anyways, so I don't seriously think Apple would say anything they didn't want to share.

The message about the Intel transition is, by and large, it just works. Of course, as a Java programmer, you'd expect this -- your code only sees the JVM, not the architecture underneath. The gotcha, of course, is that JNI native code needs to be recompiled, and you could have Java-side endianness hassles, depending on how you interact with JNI.

A little more interesting was the discussion of the various virtual machines for Mac OS X. Buried in this was the implicit announcement that 1.3.1 on OS X is end-of-life'd, as it won't be available on Intel-based Macs. If you depend on this Carbon-based JVM, it's time to work out any issues you have with 1.4.2 (or the nascent 5.0). The speakers also presented some performance comparisons of two Hotspot compilers: the "C1" that's currently available, and "C2" which apparently will only be available on MacIntel, not PowerPC. C2 is more aggressive in compiling Java bytecode into native code so it can run faster than C1, but depending on the choices it makes about what to compile and when, it may be slower than C1.

Personally, I'm still adjusting to the thought that the register-challenged x86 can so soundly trounce PowerPC to make the transition necessary, but I guess PowerPC really does have feet of clay.

They noted that the current game-plan gives them six VM's to support (and they didn't seem happy about that prospect):

At the end of this BoF, they also showed how to set up XCode to work with the recently-released J2SE 5.0 instead of the default 1.4.2

In the Q&A, several attendees questioned... berated, actually... Apple's decision not to back-port J2SE 5.0 to Panther or earlier versions of Mac OS X. The Apple guys replied that they're always "forward looking" and that using the newest version of the OS lets them use the latest native SDK's to deliver a better JVM. Not mentioned was the fact that this has long been Apple's Java policy: Java 1.2 was never made available on the "classic" Mac OS, 1.4.2 was Panther-or-better, etc. So IMHO, you may not like it, but at least don't be surprised.

Part 2 was a show and tell. The demo I remember best was the CocoaComponent demo, which allows you to put native graphics into your Mac Java application in a reasonably straightforward manner. The demo showed various Quartz Composer compositions running in a Swing GUI. Surely the most amusing of these was the "Aha Video", which grabbed video from an iSight, dropped the frame rate, and used an effect to convert the video to white with black outlines, effectively aping the classic "Take On Me" music video with a live source (playing the song as an MP3 helped the effect too). The demo is available on ADC, as is another CocoaComponent demo which grabs from your capture device into an AWT window... something that the QuickTime for Java community has been begging to have back after it was removed from QTJ in the 2003 deprecatastrophe.

Surely I've forgotten stuff. Hopefully someone else who attended can point out other items of interest in the talkbacks below...

Why Mac Developers are Concerned About the J2SE 5.0 Wait

With Tiger released for the systems that Sun cares about - Windows, Linux and Solaris - it was only a few hours before the where's the OS X version posts started appearing. Some immediately called this "whining", but history shows there's good reason for Mac developers to be concerned.

The following table summarizes the lag times between releases of JDK's (later called J2SE SDK's and JRE's) and their Mac equivalents.

So, over time, the lag time between a JDK release and its corresponding Mac version has gotten much, much worse. If you were to extrapolate a trend from this, you might think Tiger wouldn't reach Mac OS X for 2-3 years. Of course that's ridiculous, since 10.4 is already known to have some amount of Java support, but still, the track record here is not a timely one.

"And why's it such a big deal," you might ask, "nobody expects an insta-port of something as big as Java." Good point - after all, where are the bloggers demanding that IBM immediately deliver Java 1.5 for AIX, or for their Linux and Windows JVM's for that matter?

I think there's some fear that being able to do your Java development on a Mac is a tenuous situation. In my last blog, I mentioned that there seemed to be more of an audience for Java development on the Mac than Java deployment, and wondered if that was really enough of a market to justify Apple's investment in Java. I got some pretty angry talkbacks - the threading has been lost in the move to Movable Type - but one thing to notice: the last four talkbacks are all "I wouldn't have a Mac if it weren't for being able to develop Java on it", which was exactly my point.

Because now, if a project in your company moves to J2SE 5.0, being on a Mac is suddenly very difficult. Some IDE's may support compiling 5.0 code from a non-5.0 environment (someone enlighten me with a talkback, s'il vous plait), but you still won't be able to unit test without running on another box of the Win/Lin variety.

And from practical experience, there are probably a lot of co-workers who would love to see the Macs go away. The Windows Bigot Java Programmer seems like it should be a contradiction in terms - if you like Windows so much, why not program in Active X or .NET or whatever Redmond's flavor of the month is - but in reality, I think this actually accounts for a massive percentage of Java programmers. Certainly half the developers I've ever worked with. Grep some source code sometime and see if you don't find java.io.Files constructed with C: at the beginning of the path, or with a complete path that uses \ for the separators, or ties to native code that are only implemented with Win32 versions, or other Latent Subtle Windowsisms

It's a pathology, one that I don't claim to understand beyond the annoying habits of confirmism, thuggish tech evangelism, or perhaps what Ayn Rand called "the hatred of the good for being good." At any rate, these people don't like the Mac, and would be perfectly happy to advance a project to J2SE 5.0 not just because of its intrinsic benefits, but because hosing the Mac developers is a happy side-effect.

So that's why I think so many Mac developers are so concerned, and won't feel safe until Mac OS X 10.4 ships. Of course, at some point, there will be a new version of Java and the cycle will repeat.

Apple @ JavaOne

Apple's JavaOne session this morning, Tech Manager Francois Jouaux and several other Apple representatives laid out the case for Java on the Mac, and why Java developers should develop on and for the Mac.

Saying that basic support of J2SE wasn't good enough, Jouaux went into Mac technologies that help Java applications work better. These include the Quartz Extreme graphics technology, which provides a speed boost to Java applications on Java 1.3.1 on Mac OS X 10.3, and for both Java 1.4 and 1.5 on the upcoming "Tiger" release of Mac OS X. He also pointed out how the 64-bit G5 processor improves performance for longs and doubles, since a G5 register can store a 64-bit value with a single machine-code instruction. He also pointed out the enterprise support of the XServe, which bundles JBoss, tomcat, WebObjects, and Apache Axis web services.

Today's announcements included improved support for Java in XCode, which now provides:

• ability to merge or copy jars
• ant and JUnit integration
• Java class modeling
• Java CodeSense
• improved deployment options
• J2EE XDoclet tasks from XCode

Matt Drance demo'ed the new XCode features, showing a Java 2D demo deliberately hobbled by unnecessary object creation in its animation loop. Using Apple's Shark tool, called with a simple -XrunShark command-line argument from XCode, he showed how to time-sample a running application, narrow down the slow parts, and bring them up in the XCode editor. This feature boost for XCode is available for Panther, the current Mac OS X release, and is available from the Apple Developer Connection site.

Next up, Stuart Cheshire spoke about the Rendezvous self-networking technology, which allows TCP/IP devices to assign their own addresses (if necessary, for example in a household network without DHCP), assign their own names, and use multicast discovery to browse the network for Rendezvous services. A huge hit in the printer world, Cheshire explained how an Apple VP was able to print transparencies to a network printer at a recent conference, completely without configuration and before the conference's surly tech guy could even finish his "we don't work with Apple's, they're so hard to work with" speech.

Of greater relevance to JavaOne attendees, Cheshire and fellow presenter Roger Pantos announced a Java library to use Rendezvous. Of particular interest was Apple's decision to re-make the API to make it more palatable to Java developers, by employing Factory and Listener metaphors and fashioning objects from the straight-C API (Apple's done this before, of course, in the form of QuickTime for Java). The Java bindings are currently available as part of the Rendezvous project in the Darwin open-source cvs repository. Cheshire and Pantos showed off the technology with a peer-to-peer chat application, written in Swing and Rendezvous and running on Windows and Mac laptops.

In a final bit of news, it was announced that the Java labs across the street at WWDC have filled up, so new sessions have been set up for Thursday. Registration for these sessions is at http://seminars.apple.com/private/wwdcjavalab

Java Studio Creator for Mac OS X

After a fair amount of hue and cry when the first previews of the all-Java Java Studio Creator — um, hello, run anywhere — Sun has announced that an early-access Mac version is now available. Better yet, MacCentral reports that buying a 15" or 17" Powerbook now gets you a Sun Developer Network Standard subscription, a $99 value which includes the Studio.

Maybe next time we'll get run anywhere without needing a public outcry, but for now, this is good news.

The new Mac Community on java.net

With the major Mac and Java conferences, WWDC and JavaOne, sharing San Francisco's Moscone Center for a week it's either a great time or an awful time to be a Mac Java developer: great because you only have to make one trip, awful because you can enjoy only part of each conference.

But wait, who are these Mac Java developers? They've been seen in the wild for a few years now, with PowerBooks and iBooks appearing in large numbers at Java conferences. Is it just the pretty laptops and the oh-so-lickable user interface? I don't think so... the motivation is deeper than that. Maybe it's the whole "I can run Office and bash" value equation of OSX. But really, who's that passionate about Office, fercryinoutloud?

No, speaking from experience in the dark pre-OSX days (more on that in a future blog), the Mac Java developers have always been there, supporting the idea of a cross-platform future in the most direct and fruitful way possible: by developing Java code for and on an alternate platform.

That dichotomy is something I've long talked about with respect to Mac Java - that there is one set of issues faced by Java developers working on Macs with an eye to deploying on other platforms, and another set of issues encountered when you're bringing a Java application to the Mac. And on top of that, there are now new kinds of possibilities, like Cocoa Java, which is the use of Java instead of the typical Objective-C for developing rich OS X applications.

There's probably a lot more going on in the intersection of the Mac and Java worlds than we've fully accounted for, which is one reason starting a java.net community makes sense. By giving developers a place to meet, share projects, collaborate and communicate, we hope to help foster more and better applications for both.

Our front page will have updated news, features, project-spotlights, etc., of interest to the Mac Java developer. We also have a wiki, Mac Java webloggers and handy front-page links to essential FAQs and API's. But most importantly, mac.dev.java.net hosts the community projects, which include deployment technologies, Mac-specific toolkits and adapters, ports and other support for Java apps that need help running on the Mac. And more... whatever you like. If you have an idea for a project, click that request a project link to get started.

We hope you enjoy the new site. If you have any suggestions, please feel free to add them as talkbacks, or send mail to the community contacts.

Special Note: Please join us at WWDC, Wednesday June 30, from 7:30 to 9:00, for the java.net Mac Community Birds of a Feather (BoF) discussion. Here, you'll have a chance to meet the community organizers and see what the Mac Java community has to offer. Even if you're only attending JavaOne and not WWDC, we're told you'll be admitted to the Apple side of Moscone for this BoF.

This work is licensed under a Creative Commons License.