Skip navigation
ANNOUNCEMENT: community.oracle.com is currently Read only due to planned upgrade until 28-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

CNet's news.com is reporting today that IBM is urging Sun to make Java open-source. The article sources an open letter from Rod Smith, IBM's vice president of emerging technology, to Rob Gingell, a Vice President and Sun Fellow at Sun — the letter has been publicly posted here.

In it, Smith replies to comments from Sun's Simon Phipps, who earlier in the month asked why IBM hadn't open-sourced its own Java implementation. Smith takes that to be an offer for the two companies to work together to open-source Java. The deal offered is this: IBM puts up its JVM implementation, Sun provides Java specs, tests, and code.

Read the article, read the letter, and tell us what you think in the talkback below.

kfarnham

The Kids Are Alright Blog

Posted by kfarnham Feb 24, 2004

Kathy Sierra, an author with a java.net weblog of her own, has just posted a tremendously interesting message to Studio B's "Computer Book Publishers" list. Click the above link — hereit is again if you're seeing this via RSS or equivalent funkiness — before continuing here, because she's got a lot more to say than I do.

You read it right? OK, we can continue.

First, there are an extraordinary number of interesting observations in this message, and while Kathy writes it for the purpose of wondering how book authors address a technical audience (indeed, what even counts as a tech book when the Final Cut Pro book is on Border's "Movies" shelf?), the technical immersion of the next generation touches all sorts of efforts.

Take java.net for example. Is this site just for developers? Should it be? Right now, developing java applications involves a steep learning curve, but what if Rave changes that? Or what if we started writing and sharing small, useful applications / applets / servlets that users could configure and deploy without coding? I can imagine a "java audience" that wouldn't be programmers, but people stopping by to pick up code for blogs, wikis, DIY P2P networks, game applets ("Whack-A-____", where you could use a config file to point to whack-able pictures of ex-significant-others, politicians, your boss), and who knows what else. We might someday be speaking to a very different audience than the one we enjoy today, one that would effortlessly work with code the way that Kathy's kids work with digital media.

(talkback hint: this is where you tell me that "people already do this with your favorite language / framework / OS")

Technical immersion surprises every generation, and I suppose it's only going to get more profound. My 21-month old can pick out his favorite movie on DVD or game and load it, label-side up, into the side-mounted PlayStation 2 and get it started. And he will express a very distinct preference for Toy Story vs. Toy Story 2, or SSX over SSX Tricky (yes, he's tasteful for a toddler... Tricky sucked). I can hardly imagine how easily and effortlessly he'll pick stuff up as he grows up... if it provides value to him and isn't too much of a hassle.

Are tech savvy kids our potential audience, or our potentialsuccessors?

kfarnham

As Your Users Like It Blog

Posted by kfarnham Feb 12, 2004

'Tis true; for those that she makes fair she scarce makes honest, and those that she makes honest she makes very ill-favouredly
-As You Like It, Act I, Scene ii

As much as I hear people talking about "a renewed interest in Java on the desktop", I hear just as many differences in basic assumptions about what we want or expect from these applications. Conversations with other authors and webloggers, and some articles I've edited recently, have me thinking more about a basic question of how an app should present itself to the user.

The problem is a paradox. We want Java to succeed. We want to deliver great apps to users with Java. But here's where there's a split. We have one camp that believes it's best to completely obscure the fact that an application is written in Java, and make it as close to a native experience as possible. The positive reaction to Joshua Marinacci's series "Make Your Swing App Go Native", parts 1, 2, and 3indicate there is a great interest in this approach.

But is that bad for Java? If users don't know that an app is written in Java, does the platform fail to get some end-user respect, support, and admiration that it would otherwise get? This is where a second mind-set comes in: the idea that an application should be very clear about the fact that it's a Java app. Successful applications that implant the coffee-cup and Duke icons into the public's consciousness are good for the platform under this theory, since it will prompt users to choose Java-enabled technologies whenever possible (you may be able to argue that this is happening in the phone space right now... they're certainly trying). In the ideal world, users would take their application from device to device (see my alternate reality vision of this), and in such a case we'd want to give them a consistent experience on all these platforms, hence we would do our apps in Swing's "metal" look and feel and adhere to Sun's look-and-feel guidelines, even if they clash with those of the underlying native platform.

This is the paradox: if we do a great job of concealing the Java-ness of an application, then we don't really advance the platform (if that's even an important goal... should it be?). But it's a blunt reality that in the here and now, there are users who absolutely will not use a cross-platform look-and-feel application. Heck, I haven't worked anywhere where the management thought the Windows L&F was Windows-y enough (and I'm like, "what, our app is ugly and confusing... how much more like Windows do you want?"). Don't get me started on the Mac zealots. And as much as the multi-device argument makes sense in theory, in practice there are only three J2SE environments that matter (Windows, Linux, and Mac OS X), and it's a rare user that uses more than one.

There's an analogy to the web app experience. Working through a web page isn't particularly Mac-like, or Windows-like, or Linux-like. It's a specific user experience, in large part dictated by the limitations of working in a browser. J2SE is so much richer, it may not be able to define a user-experience in this way because the sense of how it's different from native apps isn't so different as to make users adopt a different mind-set. Worse, being just slightly different from the underlying platform's native apps may make users focus on the 10% of the experience that's different or less pleasing, and not on the 90% that's the same. On the other hand, it may be that web apps have delivered so much functionality that users tolerate the less-rich experience, whereas few useful Java desktop programs have made their way to end-users. Maybe users would embrace metal-themed apps if only there were any that did anything essential.

Mac OS X is now officially up-to-date with Java, as Apple has just released a substantial J2SE 1.4.2 implementation that catches up with the latest release version from Sun. Panther (ie, Mac OS X 10.3.x) users can find it in their Software Update. For those wanting a stand-alone installer (hello, sysadmins!), one is available here. The download is about 28 MB.

The big news in this update is the support for JavaScript-to-Java communication, aka LiveConnect, when used with the also-updated Safari web browser. This hitherto-absent feature has been the subject of more feature requests / complaints / angry screeds than I'd care to remember.

Commentson the MacBytes/MacRumors site indicate that users have seen some performance improvements and greater compatibility in some cases, though there have also been reports of breakage (particularly of the file-sharing application Acquisition Lite, which looks for Java 1.4.1 and can't find it, since the 1.4.2 installer removes it).

The developer talk on the java-dev list is more focused on Eclipse compatibility and certain scenarios that can cause problems when upgrading to the final version from various combinations of betas and other limited-access pre-releases.

Developers are also noting the disappearance of javadocs and thesrc.jar file, but those are provided by the "Java 1.4.2. Developer Package" (50.6 MB) that has been posted to the Apple Developer Connectionsite. After installing the developer package, src.jaris in /System/ Library/ Frameworks/ JavaVM.framework/ Versions/ 1.4.2/ Home. The javadocs are now in two places: docs for core Java are at /System/ Library/ Frameworks/ JavaVM.framework/ Versions/ 1.4.2/ Resources/ Documentation/ Reference/ doc/ api, while docs for Mac-specific com.appleclasses are in /System/ Library/ Frameworks/ JavaVM.framework/ Versions/ 1.4.2/ Resources/ Documentation/ Reference/ appledoc/ api . (note: spaces included in these giant paths only to keep your browser from horizontally scrolling)

Filter Blog

By date: