While teaching a Java course this past semester, I enjoyed Java's platform independence, which let me easily work at home on my Macintosh using Sun's JDK and Metrowerks' CodeWarrior 11 while teaching in a Windows 95 environment using Sun's JDK and Microsoft's Visual J++. My students at John Carroll University (University Heights, OH) and I happily e-mailed code back and forth, compiled it, and ran it. There were very few problems.
With the Windows release of JDK 1.1, however, this multiplatform scenario would no longer be possible. Some students wanted to move to JDK 1.1, which was available in beta for Windows in December, 1996. But the semester came and went without a beta (nevermind a final release) of JDK 1.1 for the Mac (although JavaSoft did manage during this time to release a Japanese language version of 1.1 for Windows and Solaris). What convinced our students not to move to 1.1 was the lack of browser support for 1.1.
The question arose (and I posted it to several newsgroups): Can a Java developer work on a Macintosh and be competitive? This article explores the answers to this question as well as the issue of the considerable delay in release of tools for the MacOS. The wild card that is not considered: the implication of Microsoft's RNI technology, which maximizes run-time speed in a Windows environment.
The lag in release of JDK 1.1 for MacOS
Sun's Eric Chu, product manager for the Java Developer Kit, explains that "JavaSoft's goal is to provide implementation for Windows, Mac, and Solaris," but "each implementation of the Java Platform and JDK is tied to the targeted operating systems." Since "JavaSoft is still a relatively small organization," engineers "had to do one implementation at a time."
How big is this lag? The Windows beta of JDK 1.1 was released on December 3, 1996. Less than two weeks later, a second beta was released to fix bugs, among other places, in security (see JavaWorld's January issue). The final release of JDK 1.1 for Windows shipped in February, 1997. As for the Macintosh version, Chu says "the Beta release of the JDK for the Mac ... will be announced over the next few weeks" and "the final release of the JDK 1.1 for the Mac will [ship] early this fall." Because Chu says the Apple betas are very high quality, he views this as less than a four-month lag.
Actually, the difference between beta releases is 7 months, and Chu's own prediction for general maintenance (GM) releases has a difference of 7-9 months. Will Iverson, Java & components product manager at Apple, adds that "previously, JavaSoft released revisions to Apple in the following [sequence]: JDK alpha, JDK beta, JDK GM, Apple alpha, Apple beta, Apple GM." As you can see, even the alpha version for the Mac wasn't released until after the JDK GM release. The good news is that many of the Java-specific problems had been fixed before the Mac version was released.
"Mac Java developers are not at a disadvantage," says Gordy Davies of Metrowerks' media relations department. "[We] will include 1.1 capability (compiler and VM) for the Mac in the pre-release folder of [the latest] CodeWarrior Professional. [Also], Apple stated publicly at the recent World Wide Developers Conference that it intends to ship JDK version 1.2 and to release new versions in the same time frame as their Solaris/Windows counterparts."
Why would you use a Mac
Steve Rose is one of six Java developers at his company and the only one to use a Mac. Rose prefers to use Metrowerks CodeWarrior, saying that while his Windows-based "co-workers do their compiles from the command line in DOS ... [and] can't reliably set break-points and step through code when debugging ... I can even examine variables including the contents of Vectors while debugging. I can set my output to Apple, Application, Class Files, or a zip file. I can even run a zip file while in debug mode if I like."
Last month's cover story in JavaWorld, "Which Java visual development environment is best for you?," compared five top tools. Even though JavaWorld has covered Mac-based integrated development environments in a previous review and promises a follow-up review of Mac IDEs, the recent review considered only tools running on Windows 95 or NT. The article mentioned that many of the environments plan Mac ports, but Microsoft's Java evangelist, Brad Merrill, says that there are no plans for a Macintosh version of Visual J++.
Many of the programmers who offered input for this article use both Windows and Macintosh machines and prefer Java development on the Mac. Most respondents to my Usenet newsgroup query told similar stories about being happy using CodeWarrior or Symantec's Cafe for Java development on a Mac. "The tools I get with CodeWarrior are first rate," remarked Glenn Howes, a Macintosh programmer. After reading complaints on Usenet newsgroups about Java on Windows "not having proper source level debuggers, having to launch applets from the command shell, and [how Visual J++] is the fastest way to turn a 17-inch monitor into a 14-inch [monitor]," Howes wondered: "Shouldn't this drive people from Windows 95 to MacOS?"
The second-most-cited reason for preferring the Mac is the superiority of text editors available on the Mac. (Favorites include BBEdit, MPW, CodeWarrior, and Alpha.) One developer complained that although the Mac has the best text editors, it is hard to stay with the Mac given the lack of JDK 1.1 support. Programmer Wally Wedel answered this objection by suggesting Mac developers seeking 1.1 support "use BBEdit on the Mac, zip things over to Windows 95, and compile and go."
Isn't everyone rushing to 1.1?
Many of us have been programming in Java since it was a beta or even an alpha release. It is difficult for us not to want to play with the newest and coolest features -- but is that the best way to produce stable software for customers?
Apple's Will Iverson distinguishes between the needs of developers and those of users: "We must have both early access to bleeding-edge technology for developers, and a solid, stable, high-performance technology for end-users, and these demand radically different release and quality schedules."
Many respondents say that even if JDK 1.1 for the MacOS was available, they would not necessarily make the make the change from JDK 1.0.2. "The lack of 1.1 support on the Mac doesn't keep us from moving to it," Steve Rose says. "It is [the combination of] the lack of any other support for it, the time to modify our code for 1.1, and the newness of it all... Do any browsers support 1.1? [JDK] 1.1 is still new and [people] are finding bugs in it."
Consultant and author Bruce Eckel echoes the split in the needs of developers and users described above by Iverson. Bruce is the author of Thinking in Java, (freely available at http:www.eckelobjects.com/eckel. In his seminars he highlights JDK 1.1-specific features for developers who want to know what's new, but says that "where applets are concerned, I think there will be a problem between 1.02 and 1.1 for quite a while, because it will be a while before all the browsers will be updated to support 1.1 and even then many users are balky about uploading and installing new software. So everyone will need to write their applets to 1.02 for some time to come."
Another obstacle for Mac developers
Even when the JDK 1.1 is available, Mac developers may feel that they live in a Windows world. Bruce Eckel explains that he uses "a Win95 box because, due to the widespread use of the platform, the competition in the development tool arena is much greater and so language features tend to get earlier support." It is very difficult to find affordable object-oriented analysis and object-oriented design (OOA/OOD) tools for the Macintosh.
What tools can a Mac programmer use for analysis and design? Mikael Arctaedius has written a shareware OOA/OOD tool called Object Plant, which you can download at http://www.softsys.se/ObjectPlant/download.html. Arctaedius agrees with Mark Mayfield's assessment of the potential market and suggests that perhaps "the presence of lots of large and good frameworks like MacApp, PowerPlant, TCL" explains why there are so few OOA/OOD tools for the Mac.
Write once, run anywhere: Why write on a Mac
Apple has joined Sun, Netscape, and IBM in building the Java Foundation Classes, and also has committed to making Java an integral part of the MacOS. The MacOS runtime for Java, MRJ 1.5, should (according to the March edition of
, an online publication hosted on Apple's own Web site) include a just-in-time Java compiler and Marimba's Castanet technology. MRJ 2.0 will include support for JDK 1.1 which will include all of the features you've been reading about in
: JDBC, the Java API for accessing SQL databases, and support for JavaBeans.
Within the next few months, JIT and Castanet automatically will be on all Java-enabled, MacOS-based computers. Mark Mayfield sees opportunities here: "Development for pure Mac applications in Java would be wonderful," he says. "I think Java would make an excellent Mac application development language if Apple would create some Mac-specific APIs for Mac development." He adds that if, as Apple announced, "Apple's next operating system is for both PowerPC and Intel platforms, that will mean an even bigger market for Mac developers."
Will Iverson goes further. "Build your app, compile it to bytecode, but do a runtime check to see if you are running on a Mac and then modify the program's behavior," he suggests. "The code should still run on other platforms, but it also allows developers to provide MacOS-specific functionality without rewriting their apps from scratch... Developers should get used to writing code that does some basic environment-checking now."
The news isn't all positive for Mac users. Microsoft is working on its own RNI (Raw Native Interface). As PC Week reported recently, "The RNI technology maximizes run-time speed on Windows, [but requires] a hefty amount of [code]. Microsoft has the staff to do this, but implementors for other platforms might not... RNI moves Java one step closer to Microsoft's admitted strategy for Java: 'Write once, run anywhere -- but run best on Windows.'"
So there may be a split in flavors of Java, and Microsoft has no plans for a Mac version of its development environment. Microsoft's Brad Merrill says, however, that Microsoft is working with Metrowerks. Gordy Davies says Metrowerks "will support JFC (Java Foundation Classes, a collaboration of Sun, Netscape, and others), AFC (Microsoft's entry), and JavaBeans. [This support] extends to our Java implementation as well."
Less lag with future MacOS JDK releases?
The lags between releases of the JDK for Windows and Mac have been significant. JavaSoft and Apple claim this delay will disappear in the near future. Yet questions remain.
Even though "JavaSoft is still ... relatively small" and the JDK "is tied to the targeted" OS, Eric Chu of Sun predicts the JDK development team will be able "to shorten the lag between the different implementations." He says that JavaSoft is "working closely with Apple, and we anticipate the lag to disappear over the several months."
Apple's Will Iverson explains that, contrasted with the order of releases in the past, "a closer working relationship with JavaSoft looks more like ... JDK alpha, Apple alpha, JDK beta, Apple beta, JDK GM, Apple GM." Iverson says Apple expects "to release JDK 1.2 for the MacOS simultaneous with JavaSoft by the end of this year."
Gordy Davies says that Metrowerks developed a VM (Virtual Machine) for the Mac because, at the time, none was available. "The Java Virtual Machine is really OS software, and [Metrowerks] will support Apple's Java VM for the Mac," Davies says. As for Apple, the MRJ (Macintosh Runtime for Java) 1.0.2 is publicly available now, and the VM will be included in operating systems for Macs shipping this summer. The beta of MRJ 1.5 is available and includes the JIT and AWT graphics improvements. The JIT reportedly helps applications run twice as fast as on any other Mac VM. The final version of MRJ 2.0, including the final version of JDK 1.1 for the Mac, will be available in early fall, Apple says. MRJ 1.5 and MRJ 2.0 will be incorporated into system software updates scheduled for later this year.