Note that they've only deprecated their own Java runtime.
What do you mean exactly by "purpose-specific"?
> - Support for Java 6 Development on Mac OS X 10.4 and 10.5
> - OpenJDK support for Java 7 on Mac OS X
> - On-time release of Java 7 for Mac OS X
I've updated the project goals on the home page accordingly:
- Support for Java 6 Development on Mac OS X 10.5 and later (including Mac OS X 10.7 Lion)
Apple has been pretty much the sole provider, and had their very own JVM with specific look & feel customization to the UI packages.
So was it their own separately developed JVM or just a bunch of additions to make the UI not suck on OS X?
Iv'e developed Swing for 10 years and I think it's basically botched. Sun had no clue about UI development, and Sing is the expression of that. Compared with the UI frameworks on OS X it's like night and day. But I digress - I think SWT is a much better approach in any case.
From Apple's Mac App Store review guidelines: "Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected."
http://www.appleinsider.com/articles/10/10/20/apple_issues_r...
Java in XCode was already deprecated, but it sounds like there won't even be a (standard) install of the Java runtime in Mac OS X Lion.
It's the Swing apps (such as Netbeans, etc) that are potentially in trouble. Apple has been maintaining their own code for Swing. If they are going to stop maintaining this, I hope they contribute their changes back to OpenJDK so that someone attempting to maintain a Mac version does not have to reimplement this.
I wonder if Apple is really going to stop maintaining their port of Java, or if this move is to be able to say "you can't use Java for App Store for Mac apps because we could possibly stop including it." Or maybe they are planning to hand over development to Oracle.
I don't use any Mac specific APIs except for checking/setting some properties to do things like put the menus in the right place. The rest is straight Swing. So no great loss as long as Oracle provides a good implementation.
Sidenote: I can only imagine the guy who wrote "Java Deprecation" in h2 font-size 187%, jiggling inside at the moment he did.
EDIT: I understand it's only a "possibility of removal", yet if I started working on a JVM-based app/product right now, I would be concerned.
Please carefully note the wording:
> 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.
Java 1.6 will probably still be there in OSX 10.7.
> Sidenote: I can only imagine the guy who wrote "Java Deprecation" in h2 font-size 187%, jiggling inside at the moment he did.
It's a standard Apple style, so he probably didn't put the h2 187% size himself. Though he probably did giggle.
On the other hand, don't hold your breath for an OpenJDK release from Apple. In fact, that's very likely the purpose of the move: they're warning developers they will not port Java 7.
Right, it's the same ambiguous phrasing that Apple uses to let iOS jailbreakers know that Apple isn't going to go out of its way to support them. If a future update breaks a jailbroken installation: too bad. Which isn't to say that Apple will actively work on making jailbreaking impossible.
Long answer: Who knows? Apple has always developed the Mac port of Java, with a lot of customization in the GUI (custom Swing properties, events, etc). This was historically because at the time, the Mac user base was too small for Sun to support themselves. So, Apple took over the project and has run with it ever since. They've added some good things to their JVM too, such as shared memory for libraries (I believe).
However, I think that now, Apple has decided that it isn't worth it for them to support it. So the answer to your question will largely be up to Oracle. If they decide to port Swing over to the Mac, then I think there is a shot of having a good JVM for 10.7+. If not, I think that you can say goodbye to the JRE in the Mac.
It isn't like the client has ever been a big focus for Oracle. To them, Java is all about the backend. They may want to work on a JVM for the Mac just to allow developers to still code on their Macs, but I'm not sure.
The issue has always been that Apple has maintained their own JRE code base, while Sun had maintained all of the other JRE's for the other OS's.
I've been doing Java dev on OS X since OS X came to be, and it's always had problems. Apple was constantly late in implementing features that were in all of the other JRE's, and it was a real pain to deal with across the different OS's.
Not, but it does mean 10.7 may ship without a Java runtime:
> 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.
Several years ago Apple reversed their position on Java and have been ignoring it ever since. This is merely the last act in the Java play at Apple. Goodnight sweet prince!
That's standard practice. You make it easy to port apps to your platform until you gain traction and until your exclusive technologies do, then make it hard to port away from your platform by phasing out technologies that would enable that.
A Java app that runs fine on OSX but that's easy to port to (or directly run on) Windows or Linux does Apple no good while an application written in Objective-C depending on the latest *Kit stuff locks both developer and user into Apple's walled garden.
Their move from GCC to clang is no coincidence.
Erm... what? Clang has already been ported to Windows (and other platforms). Their move from GCC to clang comes from GCC sucking goat's balls at error reporting and being integrated into an IDE. You might want to note Apple produces an IDE so that's kind-of a big deal for them, and a big reason for the existence of LLVM and related technologies (Clang, LLDB, ...) is very much that they can be used as libraries and easily integrated into tools.
Seriously, you should be careful, your anti-apple-tag shows a bit too heavily in that comment.
If they ever perceive a threat from their competition, Clang/LLVM provides a lot more maneuvering space than GCC ever would.
And yes, GCC is a very hard thing to integrate into tools and it's that way by design.
Curious. Is the copyright Apple's?
It mostly means that they can use the libraries without having to open-source Xcode itself. A compiler is not exactly a competitive advantage for a company as big as Apple.
> And yes, GCC is a very hard thing to integrate into tools and it's that way by design.
Uh yes and?
Apple might not make money directly with its compiler, but for its 3rd party developers to be stuck with a mediocre compiler is definitely a disadvantage for Apple.
Hypothetical: The hardware under the hood is identical to that of a Dell. Compare an application written for both, but the one running on the Dell uses Intel's highly optimized compiler while Apple uses one that's not tuned for any particular platform, and therefore performs somewhat poorly on x86.
Result: Apple has a 20% performance deficit.
Now say that application is Photorealistic RenderMan or Cinema4D or Modo.
That 20% performance deficit, that has nothing to do with the hardware, just created a significant cost disadvantage for a mac user -- to implement a renderfarm, the mac adds either 20% in rendering time, or 20% in extra hardware costs to offset the rendering time (which ends up costing more still in logistics).
Result? Apple would lose a potentially non-trivial sale.
Having an optimized in-house compiler would probably also help to improve OpenGL performance on the mac -- because odds are the entire OS is compiled with the same compiler...
Though it may not be a significant direct revenue generator, having a good compiler would probably still be very beneficial for Apple AND its customers, not to mention developers.
Not only that, but making tweaks and optimizations (remember that Apple's compiler has to target a very narrow subset of what general Clang, or GCC, target) to an internal version even while releasing the sources for the "base" version would also give Apple a competitive advantage.
Since they own the product, the licence would not bother them much - they could just relicense it - but I assume that by using GPL they would be educating their customers in subjects they would rather keep them ignorant.
edit: Apple doesn't own Clang or LLVM. Copyright belongs to individual contributors. However, since it's BSD, Apple's ability to tune a "secret-sauce" version to its hardware is unhindered.
64-bit processors allow similar assumptions on Windows, too.
LGPL would be fine for that.
Looks a lot like a 3-clause BSD, but it's a cross between MIT and BSD. The point on LGPL is that if GCC were LGPL, Apple would be able to link it to Xcode.
Any reference for that claim? This would seem to be an absurd design decision. It's more work to design this way but the benefits are enormous.
I can't find a citation for this at the moment, but RMS has said on several occasions that GCC has to be difficult to integrate into other tools just for the sake of pushing the GPL. For example, this was his explanation for why improvements to GCC's intermediate representation formats (GIMPLE and friends) were refused for a long time.
Weird. Though not as bad as the worst of Microsoft's shenanigans, this strikes me as in the same class of uncivil moves that the FSF complains about proprietary software vendors pulling.
But if end users are hacking stuff, then they are also developers. Replace "end users" with "developers" and it gets interesting:
"So basically anything that would make it easier for developers to ship stuff that developers aren't allowed to hack is bad."
So making it hard to hack X for people trying to make Y hard to hack is okay. Seems a bit weird.
Why? Did you buy a copy of GCC?
We are using two different definitions of "open". Back in the 80's Unix was considered "open" because you could compile a program for various flavors and the various flavors could share data on the same network (contrary to other platforms of the time). GCC is open not because it runs on many platforms, but because you can freely inspect, change it and redistribute it. Those are two completely different meanings.
http://archives.free.net.ph/message/20070721.195500.f37fa735...
"GCC 4.2.1 will be the last release of GCC covered by version 2 of the GNU General Public License. All future releases will be released under GPL version 3."
http://archives.free.net.ph/message/20071009.202219.6b725019...
"The compilers in this release are covered by GNU General Public License version 3."
It's a peculiar exception - and Apple is almost certainly never going to be in violation of it. Still, the point is that Apple's lawyers are terrified that it could somehow taint iOS/OS X/iTunes if someone comes to believe that Apple might be in violation of it. Why take the chance? Clang is a compliant and fast c/c++ compiler at this point, and is mostly clean code (which is more than can be said of gcc).
I am not saying Apple wants to patent-troll downstream developers, but that's a risk that's worth noting.
The precursor to Mac OS X, Rhapsody, had three environments, treated as equals: classic MacOS, Java, and OPENSTEP.
Schematics here: http://macguild.org/rhapsody.html
Obviously, OPENSTEP/Yellow Box/Cocoa won out.
My guess is that we'll either see Oracle take back support for shipping a version, or Apple contributing to OpenJDK (like they do with X.Org) - having A version of Java available on OS X is necessary - but for the most part it is as a web server for developers, not for native GUI development - and it is the latter point where the differences are.
(Also doesn't SWT use a different approach to the same native look-and-feel end?)