I was very happy to see that Sun released a final version of Java 6 yesterday. But what I find very disappointing was that Apple has not updated a Java 6 version for Mac OS X still remains only a developer preview which is based on JDK 1.6.0_b88. If you’ve been following Java 6, you know this a very old release.

I’m starting to believe these rumors that Apple will introduce a refreshed UI in Mac OS X (10.5) Leopard. Because of this, Apple has not put out another developer release of Java 6 that will run on Tiger (10.4). With a new UI, Apple may have had to make some major changes to its Swing implementation and may not be backwards compatible with 10.4.

This would be similar to what Apple did with Tiger; you could only get Java 5 if you upgraded to Tiger (even though there were reports that early releases of Java 5 could run just fine on 10.3). I’m betting that in order to get Java 6 on your Mac, you’re going to need to upgrade to Leopard. Now I don’t know for certain, but it would be a compelling reason for any Java developer using a Mac to upgrade to 10.5. For me, Java 5 support was enough to get me to upgrade to Tiger (10.4). Guess we’ll all know more in a month.

The folks over at MacShrine are reporting that Apple has seeded a new build of Leopard (Mac OS 10.5) internally. What really caught my eye was the last statement:

“TextEdit also features support to export and open new Word 2007 documents”

What’s interesting here is that there is no mention of the OpenDocument format supported by the OpenOffice suite. Oh well. (UPDATE: it would appear that OpenDocument is supported as well according to this post at Uneasy Silence). However, if TextEdit can read and write OpenXML documents and Leopard ships within the first half of 2007, Apple will be supporting the new Office format before Microsoft. I still fully expect that the next version of iWork will support the Office OpenXML (now ECMA-376) and OpenDocument file formats in its next release, which probably will be announced at MacWorld 2007.

But what I find even more interesting are the recent claims put out by Microsoft’s Mac BU who say they will have Office 2007 converters ready by Spring and that Office:mac 2007 will ship 6 to 8 months after the Windows version. What I find difficult to understand is why it’ll take so long? For starters, they all work at the same company that also happens to make the Windows version of Office 2007. Second, this is the same company that drafted the Office OpenXML format, so you’d think there’d be few folks with expert knowledge on the subject. And finally, this new format is now an EMCA standard, of which anyone who can read a spec could implement the format. And even though the spec only became a standard on 12/7/2006, the spec had been published well in advance.

It blows my mind that a group of folks who work at the same company, can’t get it together with other internal teams to make compatibility with the new file format a top priority. After reading some of the Mac Mojo post, it sounds like they even wrote their own XML parser to read the format. Why? I guess this gives some insight was to why Vista was a few years late.

It’ll be interesting to see what Apple has in store for iWork in 2007. My gut is starting to say that this is the beginning of the end for Office:mac. This could be Microsoft giving Apple a head start into the office market on the Mac. Eventually, Office:mac will be cede to iWork much in the same was as Internet Explorer did to Safari, even while Safari was a beta. The good thing is that with the Office OpenXML format, we now have an established standard so file incompatibilities should not be as problematic as they have been in the past.

Update #2: It appears I’m not the only who thinks that Office:mac is on its way out; Rob Griffiths of MacOSXHints.com has a piece over at MacWorld.com which points out that Office:mac will not have VB support for things like macros and other goodies. Of interest, the folks over at OpenOffice.org are working on VBA support. It’ll be interesting to see if Apple is able to leverage any of that code base.

I have had a Motorola E815 for sometime now, but my older PowerBook didn’t have Bluetooth so I never got to enjoy its capabilities. Just recently, I acquired a brand spankin’ new 17″ MacBook Pro as part of my new job. I knew I could use the phone as a modem, but exactly how to do it was a bit of a mystery. I ran across this post which describes how to set up the Motorola V710 with Mac OS X 10.3. Unfortunately, these instructions don’t cover the subtle differences with the E815 and Mac OS X 10.4.

For the most part, the Mac OS X configuration is basically the same, but the E815 is slightly different. For some reason or another, Verizon Wireless disables dial up networking on this phone. You can enable it by dialing: ##DIALUP. It sounds odd, yes, but when you enter the number, the phone will present a message stating that dial up networking is enabled. If you don’t do this, your Mac won’t be able to use your phone as a Modem.

One the Mac side of things, you can still follow the same instructions on Steven Fettig’s site. While some of the UI is a bit different under Panther, you should have no issues figuring it out. So far, this works rather well. I get a decent connection that allow me to browse the web, check email, and use IM while riding the train into work now. Now those two hours commuting just became much more productive.

I ran across a post over at An Outlet which questions why Apple does not support OpenOffice. For me, the more important question is: Why doesn’t Apple support the OpenOffice document formats? I have written about this in a prior post about how the Mac platform currently has little or no support for the OpenDocument format. This format, which is the default format for OpenOffice, is also becoming the format of choice for many Government agencies. Effective January 1st, 2007, The State of Massachusetts will be switching over to open formats, such as OpenDocument, and will phase out proprietary formats such as the current MS Word format. Once this goes into effect, Mac users will be at a disadvantage.

Personally, I think OpenOffice has an awful long way to go before it becomes a viable alternative to MS Office:mac or iWork for that matter. And yes, I know about NeoOffice, but that too still has a long way to go as well. What I’d like to see is Apple support the OpenDocument format in their applications. To date, Apple has had a decent track record supporting open formats. For example:

I could go on, but I think you get the point. Many of Apple’s applications are simply really nice GUIs to an open standard. Support for the OpenDocument format in the next release of iWork would a logical step in following Apple’s pattern of supporting open standards. Whether or not Apple adds OpenDocument support to iWork remains a mystery, at least until MacWorld 2007.

Considering that Apple is a member of the ECMA Technical committee to standarize Microsoft’s Office Open XML format, I fully expect iWork ’07 to support the new MS Office formats come MacWorld 2007. Windows users will have access to an ODF converter available for Office 2007 users, but it will not be available for Mac OS X. What is interesting about the converter is that at its core, this is an XSLT transformation. So it might be trivial for Apple to add support for both OpenDocument and Microsoft’s Office Open XML formats.

While having OpenOffice getting polished up and properly integrated into Mac OS X would be nice, it’s just not going to happen any time soon. Apple’s iWork is here now and is actually pretty good. If iWork supported both OpenDocument and Microsoft’s Office Open XML formats (and adds a spread sheet application), iWork could become a much more viable application suite. And we’d have a single application suite which could author the two major office file formats.

We have had a Mac mini for over a year now and while it served us well, it is rather underpowered. Nah, underpowered is being too nice, the 1.4Ghz G4 model is slow as shit. The main culprit, in my opinion, is the 32MB ATI card that is in the PPC-based Mac mini. The slow performance is especially noticeable when hooked up to a 23-inch Cinema Display. I’d love to upgrade to a new Intel-based Mac mini, but it too is lacking in the video performance category, so I fear that I’d see similar issues. The Mac Pro’s are a bit too out of my price range and due to space issues, I don’t want to have another hulking tower in my home (my PC already fulfills that role). Since I already have a nice display (which is also being shared with my PC via the excellent Gefen 2×1 DVI KVM Switcher), the 24-inch iMac probably won’t be a good solution either.

In fantasy-land, what I’d love to see is something like a Mac mini Pro. A Mac mini Pro would have close to the same tech specs as the iMac (but with at least one FireWire 800 port) and sell for around $999 to $1,400. If the extra video and CPU power can’t be crammed into the current enclosure, the maybe it’s a double-height Mac mini, at which point you could then call it a Mac Cube Pro. With decent video & CPU performance and a minimum of 1GB RAM (expandable to at least 2GB, preferably 3GB+), I’d snatch one up in a second.This would be a great developer/photo-editing workstation for those of us who prefer the more space conscious design while being half the price of a Mac Pro and more flexible than the iMac. That’s what I want for Christmas, or at least for MacWorld 2007.

You could describe F3 as being kind of like Flash meets Java. I ran across a link to Chris Oliver’s Blog, from a post on OS News, where he talks about an upcoming project from Sun called F3. The latest demos Chris has up are quite impressive. There is also mention to a server component too, which makes me think that F3 could be in the same vein as Adobe FLEX or OpenLaszlo. The big difference with F3 is that this is all pure Java, and you’ll still have access to the entire JDK on the client machine.

Chris also has new demo up which demonstrates F3′s SVG support. While still not as robust as Apache’s Batik, F3 is a bit slower rendering the initial SVG. However, pan and zoom is significantly faster with F3 than with Batik. Apparently, F3 will be open sourced soon on Java.net, but no time frame has been given. Right now, I am EXTREMELY curious to see what else comes out of F3. Finally, a compelling reason for an end-user to download the JRE!

Yesterday I was reminded just how much work the OpenDocument group has to get before it becomes a usable standard. I say “usable” because as of now, I cannot use it. At least on my PowerBook anyway. Normally, I write my posts in a either OpenOffice or MS Word. I don’t have office on my PC so I use OpenOffice. Since Mac OS X is my primary platform, I own an MS Office 2004 license. I started yesterdays post while on my PC and I later attempted to finish it on my PowerBook. I saved it as an OTD, and then I was quickly reminded that it cannot be opened on a Mac OS X system.

It’s interesting that my home state is pushing for a standard that really on supported by one major Office Suite. There is this page which lists the appications that work with OpenDocument. But with the exception of AbiWord (which still leaves A LOT to be desired) nothing in that list runs on a Mac. Ignoring Windows for a moment, Mac OS X represents the next largest installed base for desktop systems. Mac OS X is still much bigger than Linux on the desktop. And please don’t tell me that OpenOffice will run fine under X11 or that NeoOffice is “will work.” Yes, they do work, but they are both unfished or do not integrate with the OS. Take a quick glance over at opendocumentfellowship.org, and it doesn’t look like much progress is being made on making applications that support OpenDocument. And lastly, the ODF Add-In for MS Word will only work on the Windows version of Word.

The other major word processor on Mac OS X is Apple’s own Pages which supports the current MS Word format. Seeing how Apple is on the ECMA Technical Committee for the standardization of the Office Open XML Format and not on the OpenDocument comittee, I can only imagine that the next release of Pages will support the Office Open XML format. Additionally, Office 2007 for Mac OS X will support the Office Open XML Formats as well. But still, not a peep from the OpenDocument community on how they intend for Mac uses to be able to work with this new “standard” format.

So come 2007, Mac users won’t be able open documents from the great state of Massachusetts, even though it is an ISO standard. It’s ironic that a standard is shutting out an entire platform! Wasn’t Microsoft accused of this 6 or 7 years ago? I’m all for standards, but when only a very small group supports a defined standard, is it really standard? Remember that Mac users are a whiney, pissy bunch who make themselves heard when we’re being neglected. With the current state of OpenDocument on the Mac, I’m hedging my bets that Microsoft will be successful at making Office Open XML the defacto document standard. That is of course if Adobe, which is an OpenDocument member, doesn’t swoop in the next few moths with a cross-platform Office Suite which intgrates with Acrobat and their graphics tools. Such a product on Mac OS X might be far more compelling than what Office 2007 might provide.

This weekend, I read a pretty ridiculous article. You may have heard about it, it’s titled: “How to save JEE, and it’s not EJB3.0″. JDJ must have nothing new to write about these days considering that the original post had been published 9 months ago and they’re just getting to it now. But whatever, that’s not my issue. First it’s the idea that Java EE is in trouble, which is just plain silly. To take it a step further and state that it can be “saved” by looking at the examples that AJAX set fourth, is lunacy.

AJAX has its place and there are some compelling reasons to use it, but it is still an experimental and inconsistent technology. As Brandon reminds us, with AJAX, “there is not even a ‘reference implementation’ of it”, as if that is a good thing. To further that point, nor is there a concrete definition of what AJAX is or how a browser should implement AJAX technologies. In fact, AJAX is nothing more than DHTML plus remoting. The W3C DOM specs covers much the interactive portion of AJAX, but there is nothing to cover the remoting aspects of AJAX. Most of us are also aware of how inconsistently the DOM is implemented accross browsers. With that said, you will be hard pressed to find consistency across applications which implement AJAX.

Any Backend you Want

I’ll agree that coding strictly to the JEE spec probably doesn’t suite everyone’s needs, but the JEE stack does provide a lot of flexibility. My current J2EE architecture of choice is a combination of Session Beans plus Hibernate. Not a strict J2EE design as per the standard, but I feel the choice of Hibernate is better than using Entity Beans. I did get to choose my own back end and chose my own persistence API. Additionally, Hibernate complies with J2EE standards as it can participate in a container managed transaction and be managed through JMX. As of 3.2, Hibernate can be used as a full-on JEE 5 standard, or still used as plain old Hibernate. The choice is mine.

I never felt inclined to implement my own servlet container, transaction manager, JMS implementation, persistence API, or whatever. I’m very pleased that the JEE spec defines what components of the JEE stack need to be implemented in order to be called JEE Compliant. I have choices from several vendors which follow the JEE spec or integrate nicely with the platform, as is the case with Spring. I have a certain expectation that vendors will offer specific JEE features but look for the value adds that the vendor may provide. I still can choose “any backend I want”, but still can count on a level of consistency between products. I have great confidence that I can publish a message from an application running in WebLogic to a queue that resides on a WebSphere MQ instance using JMS, and it will work as expected. If JEE were to take a page from AJAX, we’d have to write multiple “if/else” blocks to handle the different ways each messaging system implements its messaging interface. Even better, I have a great deal of confidence that I can reliably execute an RMI call from a client running a Sun JVM on Windows to a JBoss instance running on Apple’s VM on Mac OS X by doing nothing more than calling the remote method. If JEE followed AJAX, this would be a 100 steps backwards.

Any backend you want, as long as you use my front end

AJAX frameworks like DWR (which is an awesome AJAX project BTW) muddle Brandon’s point about using any back end you want. For starters, I can sit DWR on top of a pure JEE application, JEE/Hibernate hybrid, or Spring based app just fine. But each AJAX framework out there uses some form of proprietary message format to transmit to the browser. Additionally, not all AJAX frameworks use XML as the messaging format ( which begs the question why is there an “X” in AJAX?). Now suppose the stability of the AJAX framework you’re using starts to deteriorate either under heavy load, or the project has just fallen apart. Now you need to think about switching to something more stable. In the case of DWR, you will have a lot of reworking that needs to be done on the front end as well as the backend. So I sure can use any backend I want with AJAX. But when you change it, be prepared to change the frontend too.
The Need for AJAX Standards

Most of folks have “good idea” of what AJAX is but there are no specific guidelines or official AJAX patterns that have been published. To make matters worse, browsers such as Mozilla, Safari, and Opera all have subtle differences to how they implement the XmlHttpRequest object. Remember, that Mozilla’s implementation is derrived from Microsofts XmlHttpRequest ActiveX control, which is a propritary technology. The Mozilla implementation is method compatible with Microsofts, but the means to instantiate the object differes between the two browsers. To date, there is no formal agreed up spec as to how this object should work. Safari for example, still cannot execute certain HTTP methods.

So with all of this “exciting” inconsistency between browser implementations, what example should JEE learn from? In fact, I think the opposite could be true: AJAX could learn a thing or two from JEE. Publishing a spec of what the XmlHttpRequest object should and should not support would be an excellent first step. Second, a common message format would also help a lot. The folks at Adobe get this and that is why the Flash player has direct support for consuming Web Services as well as the ability to interact with RESTful web services. Having stanard means to consume WebServices directly via JavaScript in a WebBrowser would be outstanding. The ability to plug into an SOA architecture using existing WS standards would be great. Hell, even XML-RPC would be a great start.

Yes freedom is good, but anarchy is worse. AJAX, in its current form, is anarchy and chaos in the same bag. Standards are not a bad thing. But enough with this crappy article.