Apple Discontinuing Java Installation Packages for Mac OS X?
Thursday October 21, 2010 11:01 AM EST
Written by Eric Slivka
A number of readers have pointed out that Apple’s developer documentation for its Java updates for Mac OS X released yesterday reveals that the company appears to be ceasing future distribution of its custom-ported Java packages.
[i]Java Deprecation
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.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.[/i]
It is not entirely clear what the move means for the future of Java on Mac OS X, as Apple has long been criticized for moving slowly on releasing updates to Java and it is possible that Oracle could roll out its own Java packages (as it does for Windows and Linux) on a more timely basis.
On a possibly-related note, Apple has noted in the guidelines for its forthcoming Mac App Store that applications using Java and other deprecated or optionally-installed technologies will not be accepted. Developers are of course free to distribute such applications through other means, but the move appears to be another sign of Apple opting to de-emphasize certain third-party technologies in its products.
Apple’s long-standing issues with Adobe Flash are of course well-documented, with the company opting not to support Flash on its iOS devices and now even shipping its new MacBook Air without Flash pre-installed.
Apple Discontinuing Java Installation Packages for Mac OS X?
Thursday October 21, 2010 11:01 AM EST
Written by Eric Slivka
A number of readers have pointed out that Apple’s developer
documentation for its Java updates for Mac OS X released yesterday
reveals that the company appears to be ceasing future distribution of
its custom-ported Java packages.
Yes, I saw this on java-dev@lists.apple.com. What this ultimately
means I have no idea—trying to divine Apple’s intentions is something
akin to kremlinology. Maybe Oracle will pick up the slack, maybe there
won’t be Java on the Mac anymore… no clue.
It does make me wonder if we should plan to stop using Java.
That actually wouldn’t solve the problem. It would appear that MacOS is leaning towards the iTunes method of software installation. I’m not sure that anyone in their right mind would want to go that path. Granted this is just a rumour, but it is consistent with depricating Java on MacOS as I can see that they would actually want to get rid of interpreted/VM software entirely.
That being said, hypothetically, how exactly could one convert VASSAL to anything? And what would it be? I’m a little surprised that you tossed that out there without convulsing violently.
That being said, hypothetically, how exactly could one convert VASSAL to
anything? And what would it be? I’m a little surprised that you
tossed that out there without convulsing violently.
In the long run, I think the important thing is the data structures and
the file format. The app itself is built on those. Given the amount of
work I suspect that all of the planned disentangling will be, I’m not
sure that it would be less work rewriting it all in a different language.
There’s basically nothing hard algorithms-wise in VASSAL.
[i]Apple and Oracle Announce OpenJDK for OS X, Java Developers Rejoice
When developers noticed Apple was deprecating Java on OS X, there was quite a mess on the internet. Today, Apple announced that is joining Oracle to bring the OpenJDK project on the Mac in order to maintain Java.
Apple will contribute most of the key components, “including a 32-bit and 64-bit HotSpot-based Java virtual machine, class libraries and a networking stack”.
With OpenJDK, Apple’s Java technology will be available open source for developers to contribute to. Press release embedded below.[/i]
I’ve thought about that. It would give us a better, more platform-consistent widget set. One of the major benefits of model-view separation is that it will be easier to try out other widget sets once that is done…