Slashdot Mirror
Apple Deprecates Their JVM
Mortimer.CA writes "In some recent release notes Apple has deprecated their JVM: 'As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.' In the past Sun (now Oracle) has always let Apple do this: 'Apple Computer supplies their own version of Java. Use the Software Update feature (available on the Apple menu) to check that you have the most up-to-date version of Java for your Mac.' I wonder how much heads-up Oracle was given for this change, and if the Java team has any code ready to go, or whether they'll have to ramp up porting for Mac OS 10.7 (aka 'Lion')."
MacOS is actually based on the mach kernel, and not UNIX. /pedantic
Mac OS X is actually based on the mach kernel, which, along with OS X's userland is a certified implementation of UNIX. /pedantic
From the Mac App Store guidelines:
2.24
Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
This space for rent.
Other media players will probably support HTTP Live Streaming in a couple months. It's not like it's a proprietary format or anything- it's just a continuously updating MPEG-2 file sitting on a server. Quicktime continuously checks that file for updates and downloads just the new parts when they get uploaded. I'd rather they use that than Adobe's proprietary streaming format or Real's proprietary streaming format.
Java on the Mac have always been maintained by Apple, they licensed it about fifteen years ago from Sun. There has never been a Sun Java for Macs. I don't know how much code is going back to Sun/Oracle but in worst case that may be nothing at all. The main problem is that Java by itself has no support for things like the Mac Aqua UI, that's all additions made by Apple. In the late 90's when the Mac wasn't going well Apple decided to license Java and fix those things since Sun wasn't likely to put much time and effort on it. It's actually really good and well done.
Right, but Apple does ship versions of Python and Ruby that can access their Cocoa libraries. Apple would rather all developers use Objective-C, but that's just a way of ensuring that developers use Cocoa. Using Cocoa is what they're really after, technically speaking, because their real goal is for all Mac applications to use the same toolkit, look nice and behave like other Mac applications.
I promise you Apple doesn't care if Swing applications look similar to Mac applications since they won't behave like Mac apps due to not running through Cocoa. I bet Apple would be happy if those apps just never ran on OS X. But they have in the past provided a way of using Cocoa through Java. Apparently the Mac Java developer community had enough of a clue to realize that using Cocoa is a great way to restrict your app to one platform and miss the whole point of using Java in the first place.
Apple's special JVM was really just a way of trying to sneak Java developers into Cocoa, but it never really worked, so at this point, it's probably in Apple's best interest to just provide a stock JVM so people who really want to use Java can and let Oracle worry about whether or not Swing apps look like Mac apps. In general, Swing app usability is damning enough that Apple can just leave well enough alone and their customers will want Cocoa apps or Swing apps that have been engineered to look and behave a lot like Cocoa apps anyway.
NeXT jumped on the Java bandwagon early on, porting their flagship WebObjects framework from Objective-C to Java. When Steve returned to Apple, he planned to make Java a first-class citizen of OS X. The Apple JRE had a number of enhancements over the stock one. For example, it shared classes between JVM instances, a feature that didn't appear in the Sun JRE for a few years. It also included a lot of stuff for native integration - you could make the menu bar sit at the top of the screen from Swing apps, just like a proper Mac App and use the standard Mac keyboard shortcuts, for example.
They also shipped an Objective-C to Java bridge. You could call the Cocoa APIs directly from Java programs with some low-level automatic translation letting you use Java strings and arrays instead of NSString and NSArray, for example. This was deprecated some time around 10.2 or 10.3 (I can't remember - Wikipedia probably can), largely because no one was using it. New Cocoa APIs were not added to the bridge.
The idea that Java would be one of the dominant languages for OS X development died five years ago. Apple has only continued to invest money in their JRE to help sell XServes running OS X Server and running WebObjects. I'd imagine this market is now so small that it's no longer worth bothering with.
I am TheRaven on Soylent News
Why wouldn't a peripheral require a driver?
The driver is already present on the machine and available to native code, yet the Java virtual machine is not aware of it.