Why This MacWorld Means More To Java Developers Than Anyone Else
Although many people have been anxious to speculate on what the Intel transformation means for Apple going forward, and what Intel machines will be released tomorrow, one issue that has not been spoken about as much is what the Intel transformation means for Java developers. It’s no secret that at any JavaOne or geek conference you attend, what would have been a sea of standard Dell laptops around 2001 are now, just five years later, a sea of glowing apple logos from Powerbooks.
The reason for this transition is simple: Apple provides developers with the best of both worlds. You can develop and set up your XML files, CLASSPATH entries and config files on Mac OS X and create a perfect build environment that can be moved over to whatever Linux or AIX/Solaris platform you are deploying on with absolutely no extra steps. Developing in Mac OSX for UNIX deployment really is WYSIWYG development on all levels. This can’t be said for Windows, which because of it’s 1980s Win32ness (which shows no signs of changing in Vista) requires a build environment totally different from where most apps will be deployed. This requires large migration efforts and usually results in the local development environment and the QA / Production environment always being out of sync.
In the other world, Apple also allows developers to plug easily in to the business side of their work life, with Microsoft Office, Adobe Photoshop and other large business applications (not to mention you can always fire up World of Warcraft in your hotel room for some down time with your favorite night elf friends). These benefits for the developer even drawf the other large strengths of Mac OSX, such as it’s state of the art Quartz rendering, open source friendliness, and gorgeous UI.
The deal seems too good to be true. For the last few years, it has been.
The dirty little secret is that Apple has been using the JDK to force upgrades to it’s latest operating system, and Java developers have had to give in to the very Microsoft tactics of Apple in order to continue to be relevant when developing applications. Further, as Dmitry from Creo (recently purchased by Kodak) recently commented to me, those companies that make Java applications that run cross-platform (including the Mac) can’t be certain if their users are using the latest JDK. Also, since they can’t legally install the new Apple JDK on their client’s computers that may not have the latest OS (think about that for a minute, this is Java we’re talking about), they can’t use JDK 5 features even if they wanted to. The write once / run anywhere benefit of Java couldn’t be stopped by Microsoft, but seems to slam in to a Sun approved brick wall with Apple and holds all Java client apps that want to be truly cross-platform without uprgrade to the JDK 1.3 level (Jaguar).
If you install the JDK 5 distribution available from Apple’s Developer Connection website, the installer will check your OS level and politely tell you that the JDK 5 update is only for Tiger users. There is no technical reason why this is the case, as many developers who choose not to upgrade their operating system simply use the excellent Pacifist application to install the JDK without going through Apple’s OS test. Apple’s JDK update simply installs the latest Java JDK in /System/Library/Frameworks/JavaVM.framework/Versions/, updates the symbolic links and goes away. The fact that there is no difference in how Java was distributed between Tiger (10.4) Panther (10.3) and even Jaguar (10.2) shows how transparent and deplorable this restriction is.
Needless to say, Java developers who moved to the Mac platform have been taken aback by the fact they don’t have a redistributable platform, the very definition of Java since it’s inception.
Luckily, Apple is slated to lose control of their PowerPC built, invitation-only JDK distribution with the release of Intel based Macs. Since OS X will run on the x86 instruction set, the JDK work that is often hardest to port (threading, “Little Endian” vs. “Big Endian”, ect.) will become mostly transparent between linux and os x compilations going forward. Either Sun will make an x86 Mac JDK with Apple’s consent, or Apache will make one without their consent. The differences at the architecture level should be minimal, although file system integration and other important things will still require at least some work.
Apple seems to know this, as they have done to Java what they do to most third party environments when they know they can’t control them anymore, they drop their own internal work on it and leave it for the vendors to do. They have abandoned the Java-Cocoa bridge, they have given the amazing WebObjects framework over to the public for free, and are minimizing Java over Objective-C in their Xcode feature development (I will be shocked if Xcode 3 even has Java in it). Once a large bullet point on the advantages of using Mac OSX, now Java is seen as something that Sun and IBM can do much better on Mac OSX than Apple can.
All of this is great for the Java developer, who will finally get the platform that OS X seemed at first to be.
January 11th, 2006 at 1:54 am
I think you’re mistaken about engineering effort requirements for porting the JDK. I guess that 90% of the work goes into platform-specific things like AWT, Swing L&F, process communication (like JMX). Sun didn’t add much to the VM in recent years except SSE, some other optimizations, and some classfile updates. I think Apple developers put some work into concurrency primitives on PPC for Tiger’s java.util.concurrent, but I doubt it was much of the overall effort in porting the new features.
January 11th, 2006 at 8:23 am
This does sound great for Java. I may just get a 20″ iMac with Intel Inside. Provided of course Java performance is up to par. And provided Eclipse is going to work on it of course.
Does anyone have information on these?
January 21st, 2006 at 5:34 pm
The tone of your blog entry seems a bit too ‘conspiracy theory’ for me, and I believe this is based on a false assumption about the people writing the JDK. I have met a number of them, and they are not interested in pushing people to use the latest OS. They are interested in doing that which gets a JDK out as fast as possible, with as high a quality as possible.
They have no secret tools - they use the same XCode, Eclipse, IDEA, Shark, etc., toolsl open to every other Mac developer. Further, they do not get a lot of help with secret hidden APIs. In point of fact, one developer told me that they try to avoid hidden APIs, as those often come back to bite you later.
A bit of ancient history: the first JDK on the Mac was deliivered by Sun, and it was utter crud. Apple would have really rather let Sun do the JDK, according to people who were around at the time, but it was clear that Sun was not interested in making the GUI work well on the Mac. Apple took the job on because they felt it would be a good competitive advantage, and so I can see them doing that which gets the JDK to market fastest.
Simply put, the OS restriction is a matter of resources. They can either test and qualify on several OS platforms, or they can write code that depends on the current OS release only, and cut down on the test/qualify resource costs. In the 1.4 time frame, they made the call to stick with the most current release of the OS, in an effort to cut time to market and costs.
Since any Java licensee can write a JDK for the Mac platform, I can understand Apple deciding to pay for development on the latest platform only. That is what pays their bills, and from the perspective of the Java team, it lets them get to market faster. I fail to see this as Microsoftian move, as anyone else can certainly write a JDK if they want to. IBM has had the option to write such a JDK for MacOS X for a long time. So has Sun. Neither has stepped up to the plate, and I really do not think it is Apple pressure stopping them.
I really hope the Apache project works well. Competition is a good thing, IMO. That said, I just doubt that they are going to do a substantially better job, just because I have not heard any reason why they would. Open source has its beneifts, but I do not see it as magic.
On another note, I do not see the changes in WO and Cocoa/Java as a sign that Apple is responding to losing control. Instead, I see them as responding to market realities.
The Web Objects group is not a part of the Java group at all. Talk to the recruiters for jobs for both groups - they do different things for different parts of the company. WO was not getting any traction because of competition from Spring/Hibernate and other free tools. Even $500 was a big price tag in comparison with $0. I know - I have clients in this space, and WO faced a lot of competition.
The 1.3 era Java-Cocoa bridge was dropped for performance reasons - every call went over the JNI bridge, and that was not cheap.
Cocoa/Java was dropped by the Cocoa group, because there was an fairly large impedence mismatch. The Java team cannot support the APIs of the rest of the company - it is up to the other groups to decide to provide functionality. QTJ, for example, is a product of the quicktime group.
I do agree that the Intel switch is going to be good for Java on the Mac - Sun’s JIT compilers will now work well without needing a port, and that is a good thing. In fact, that is why we are getting the Server compiler on the Intel boxes. Other parts of the pipeline will likely benefit as well, because Sun’s tests will be on the same CPU as the Mac OS X users will be using.
So, from where I sit, the switch to Intel machines is a good thing all around. We get better speed, source from Sun that is more likely to work out of the box, and eventually, the ability to compare directly with Vista on identical hardware.
This just does not feel like a clever Microsoftian plot coming to light. Instead, it feels like the Java team at Apple is trying to provide the best product they can, with the limited resources they have. Changing those resource levels requires letting your regional Apple sales rep know that they are losing sales because of their current policies.
Scott
January 21st, 2006 at 7:19 pm
I would agree with all of these points except that people who have upgraded OS X 10.3 to JDK 5 using less than honest means (Pacifist listed above) have had success running it.
Perhaps there is some incompatibility, but I find it hard to imagine what.
January 23rd, 2006 at 6:27 pm
From what I understand, the Java team made a conscious decision to allow 10.4-specific code for their Java 1.5 build. I do not know whether they _did_ do so, but I know they decided to have the option. (In point of fact, I have never asked them whether they needed to.)
One big reason for that was to take advantage of graphics speed enhancements that were on the to-do list for Tiger, I suspect. 1.3 had hardware acceleration, but it always had glitches as it was not integrated with Quartz, so they hoped the main graphics group would take that on. Googling for ‘Quartz 2D Extreme’ shows they did, and that same search describes why it did not ship with 10.4, in the opinion of outsiders.
Similarly, by only targeting 10.4, they did not have to put in workarounds for OS bugs in previous OS releases. Some of those fixes might have been back-ported to 10.3.9, so the lack of workarounds might not be as harmful now than they once were.
Again, I am not quoting anyone from Apple, so take it with a grain of salt. That said, it matches what they have said about forcing installs of DP and release JDKs.
In other words, while I do not _know_ of anything that breaks, breakage on an unsupported configuration would not surprise me. Incompatibility might range from a few pixels not redrawn correctly to severe failures. We don’t know, and so we make a risk assessment blind.
Installing using pacifist is inherently unsafe, but so is running a beta release of a new OS, and developers do that all the time.
Scott