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

Perhaps there is some incompatibility, but I find it hard to imagine what.

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

Does anyone have information on these?