Apple deprecates Java
developer.apple.com
developer.apple.com
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.
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.
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.
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.
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?
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.
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.
Curious. Is the copyright Apple's?
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.
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.
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?
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.
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.
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.
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.
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)
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.
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?)
Besides all that, this moves suggests a confidence that was unimaginable 10 or more years ago. Apple is no longer desperate for market share, the way it was in 1997.
All the same, it makes me sad. I like the JVM. I do not like Java itself, but I like Groovy and I have started to like Clojure.
The Mac platform is not important enough for Oracle to care. And Java Apps won't be in the App Store.
How do you develop for Android on a Mac when their JVM finally disappears? I understand Android uses Dalvik, but will you be able to run Eclipse to get to that point?
Which is all good except for desktop Apps. It was impossible to run Netbeans, Eclipse or IntelliJ IDEA on top of Soylatte which only supports X11. Server side development was great with Soylatte and most likely still is. Thanks to Landon Fuller who earned an eternal place in my personal hall of fame with this :-)
Without him I would have had to work on Linux or Windows at that time.
Seems to me that maybe it's big enough that Mac should be supported by Oracle. That would be a bit more ideal, get updates when all the platforms get updates.
I doubt programmers make up a huge % of Mac sales either to be honest, with the success of the iPhone breaking Apple into the mainstream, I don't think it's that difficult to find casual users making the switch to a Mac
You sure? It'd be interesting to see the results of an HN poll on this.
But we all know the only reason to buy a Mac is that we look great when using it to write our Rails apps! :P
While I concede that Java has lost relevance on Mac, there are outliers like ourselves who've written native looking Java software and don't have a viable route should the worst case scenario arise.
My only inside knowledge is that the Java "team" within Apple was very small, which explains why it constantly lagged behind on updates.
It will take some time before a new one true JVM for Mac emerges. Furthermore, Apple's wishiwashiness on the support ("may not be included") will probably inhibit development on a true replacement.
There's an opportunity here that Apple should encourage. I write in-house apps in java on the Mac for deployment for my Windows colleagues. They are not going to stop using Windows. Java has real good libraries for rdbms access.
I guess the options are java develop in a vm hosting Linux or hello -ugh- mono. But I hope someone gives us a good java that runs natively.
The situation for Java will now be the same as that for developing in any programming language that Apple doesn't ship with OS X or that ships with a version lower than the one you are targeting.
My suspicion is that Apple is likely to drop Java in 10.8 which gives ~3 years for the JVM community on OS X to get their act together making OpenJDK work well with OS X.
That said, being a Clojure user this does increase my interest in seeing a Clojure-in-Clojure sooner than later. I'd like to see Clojure target LLVM the way MacRuby does.
Probably not a big concern for Apple, but it's common in universities, too, since Eclipse is (until now, at least) cross-platform enough that you can assume Windows/Mac/Linux-using students can all install it on their laptops.
I also manage a lot of equipment that requires java webstart to load a configuration GUI to accomplish tasks that would be darn near impossible at a CLI or any other way.
I logged into Cisco TAC the other day. Requires Java for ticket management tasks.
I use some rf propagation tools for a hobby that are java apps.
I make frequent use of Deskzilla. Java app.
I could go for days. I won't.
I do not want to spend time on debugging VM or dealing with its issues. I've had that with Common Lisp and I don't want to go back there.
Have they ported it back, or are they planning to ship OpenJDK for server purposes?
Though it's not developed by Oracle employees afaik.
What this means:
- The Java 6 Java Research License (JRL) binaries are based on Sun's Java 6 JRL releases, which mean they closely mirror the shipping official Java 6. They are also out-of-date and no longer supported. You can only build them using the JRL sources available from Soylatte, and redistribution of code and binaries is limited by the JRL.
- The OpenJDK 6/7 binaries are built from the OpenJDK repository, which is where all the Soylatte and BSD patchset changes were merged. All current development occurs as part of the OpenJDK BSD-Port project, and the code and binaries are fully redistributable.
On the other hand, the margin between Apple not supporting something and Apple banning something is incredibly narrow. Steve Jobs doesn't seem to understand the difference between choice and fragmentation very well.
From the review guidelines:
- Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
That's interesting.
I doubt what Apple comes up with will be as good as Debian, but at least it gives "the masses" the chance to use a well-integrated platform.
Isn't this like saying that we shouldn't use wheeled vehicles anymore, because wheels are a stone-age technology?
It's fun to reinvent the wheel, but the wheel has been around for a long time for a reason.
Recognizing the difference between fundamentals and local-maxima constitutes some of the most powerful entrepreneurship!
No, it's more like saying we should consider pneumatic tires, spring suspensions and ball bearings, despite greased wooden axles and wheels having done such a commendable job over the centuries.
Wheel = OS. I'm not proposing reinventing the notion of OS. I'm proposing using some more of the stuff we've learned and developed in the past 40 years to design and implement it.
The App Store announcement makes it clear that its only a question of time when Apple will close the MacOS-platform the same way they did with iOS.
This makes me really sad. I suspect I will have to switch to Linux then.
Also, this could be a guard move against Oracle, a capricious litigator.
It doesn't explicitly e.g. it, but Flash isn't installed by default either on the new MacBook Airs, so I'm guessing you can't do a wrapper around a SWF either.
Clever like a fox.
For all its faults, Java does deliver something that resembles the "write once, run anywhere" dream.
Any idea for a high-performance, cross-platform, native UI development stack? Is C++/Objective-C still the best option?
Is there an implementation of GTK that doesn't run via X11 on the mac? Gimp/Inkscape are lovely software on Linux, but using them on the Mac drives me insane. They're "meh" on Windows.
I concluded a while back that the only decent way to do GUI programming properly was to develop multiple native frontends for the platforms you want to support. Everything else seems to produce crap.
I haven't found the ideal runtime/language for this yet, though. The C family is an obvious candidate but is a little more low level than necessary for desktop apps. .NET/Mono seems promising, though I do worry about having to distribute the Mono runtime with apps. Plus, people seem to have an irrational fear of it (though probably not end-users).
This +100. Qt is OK-ish if dev resources are a bigger concern than platform integration, Gtk is not even remotely integrated with the platforma (well except in a Gnome desktop where it basically is the platform), and all the other attempts like wxWidgets, Tcl/Tk and the hundreds of smaller projects/products don't even come close.
Anyone developing desktop software who want to make his application feel 'native' to each platform has to make various frontends, with each platform's native UI toolkit. It takes some careful design but it's not all that painful, really.
GTK-OSX is supposed to do this, but I haven't been able to get it working.
In Windows the guideline is to use Ok & Cancel buttons while most of the GTK apps I've seen use just a Close button. GIMP is a mixed experience: most dialogs have both buttons while others just the close button.
I'm more worried about development of server stuff becoming more painful, particularly as Clojure, my favourite language, is (currently) JVM-based. There's obviously plenty of other JVM-based server development going on, and it'll be a pain if that stops working properly.
As for Cocoa bindings in higher-level languages on Mac, there are MacRuby, Nu and Mono. I haven't tried any of them, but this will be relevant for me in the near future so I'd be interested in any war stories from anyone deviating from the Objective-C path.
I generally wouldn't recommend cross-platform GUI development, it just ends up producing mediocre software; obviously, try and pick a common language/runtime if you're going to have different frontends.
That is what the clojure guys get for investing in a dead platform. Java as a language was dying. The sun-oracle deal means that the Java platform is also dead for open source.
What I find so utterly surprising is that they are completely killing it on the os level.
html5 here I come.
The main point seems to be: They don't use any of the Java GUI frameworks. They instead use some Cocoa bindings.
See here: http://trac.cyberduck.ch/browser/trunk/source/ch/cyberduck/u...
Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT.
I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?
My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding.
In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)
Specific examples from your experience?
First one I think of (cause I redid it today, in ruby :) is:
you need to keep a list of lines you already processed in a large log analysis. I'd just use a Set (which is a hash underneath) and get done, although I'd have saved a bunch of overhead (memory allocations, gc pressure) using a bloom filter.
Using a (hash)set instead of a bloom filter caused memory usage to explode, which in turn led to memory thrashing/swapping which in turn led to slow processing times.
The rest of the code runs in constant time (well, linear in the size of the item, with num(items) >> size(items[n]) ) and it did work fine for smaller inputs.
Funny thing is, one of my favorite Mac apps was/is written in Java: Cyberduck FTP client.
Cyberduck is an open source app originally written using the Java/Cocoa bridge, then using some hybrid of Cocoa and Java. But the thing is, the end user has absolutely no idea that it's a Java application. The only reason I know it's written in Java is because I looked at their source code to see how they implemented Quick Look (before it was a public API), and boom, the damn thing's in Java! As a longtime hater of Java desktop apps, I was flabbergasted.
As far as I'm concerned, OS X was the only desktop platform where Java had any sort of chance for user acceptance, but it never caught on with developers. As such, Java has been effectively dead as an option for desktop development since OS X Leopard.
How can one look at the deprecation of a particular runtime in isolation from (a) Apple's simultaneous announcement of increasing commonality of iOS and OSX, and (b) Oracle's aggressive enforcement of comm-related java libraries?
Since Apple sells and approves all app-store products, they bear plausible liability for an iOS app, if Oracle was lawsuit-minded. I would hardly be surprised to learn that Oracle will NOT sue Apple over runtimes that could trip up Google, thanks to Apple's agreement to remove possibly-offending code.
Or, alternatively, if you have an iOS app that wants to do comm in java, how could Apple field an alternative library to one that Oracle claims is theirs?
This makes Apple-supplied java runtimes a dead end. We'll see how interested Oracle is in licensing alternatives.
I think the difference is that Apple licenses/d Java and bundles a standard VM and framework, while Google did not do so - they just used the language with their own VM and framework distinctly different from, say, J2ME.
Unlikely as it is, I wish Apple would upstream that code to Oracle.
I guess there's potentially still SWT on top of a ported, open source Java7 from Unix/Linux if you need to do non-X11 UI on Mac.
Well, some Googling suggests that might work anyway...
It seems like they've been cooling off on Java development and support over the last few years.
I don't believe this is an immediate issue, but one that people doing long term planning should consider. If you want to write/run Java code, have at it. If you want to write something that will be widely distributed, you may want to think carefully.
That was when the software price started at 50k (iirc) though. When you're charging that kind of coin, I guess the motivation to support Windows is higher.
I don't think it's that you can't use WebObjects anymore outside of Apple, it's that most people don't (not even in the Java community).
Here's what Steve Jobs said in an email to a Java developer: "Sun (now Oracle) supplies Java for all other platforms. They have their own release schedules, which are almost always different than ours, so the Java we ship is always a version behind. This may not be the best way to do it."
To me, the sheer number of people using Java on the Mac in one way or another guarantee that it's not going anywhere. Apple isn't going to develop it anymore, but that may be a good thing. We'll see.
If Java apps can't be in the app store it would be a bummer. I don't see where it says that though - the app store rules say that you can't depend on deprecated tech. But it doesn't prevent you from shipping your Java based app complete with a Java VM - like you'd do on Windows.
Seriously, Apple does not need Java and I think the market for Java apps has become few and far....
I didn't see anything saying that they would never distribute any JRE on Mac OS X though. They may just find someone else's JRE to distribute.
It's unclear whether this is positive or a negative announcement. If another party steps up to maintain a JDK/JRE port on OS X, this will probably end up being a good thing, as Java updates from Apple had been infrequent.
MacRuby is a free software project by Apple Inc. Many folks inside and outside of Apple contribute to this great project and we have a MacRuby Project Team page to list them. Please feel free to contact us if you have any questions, ideas or bugs to report.
There's no challenge or threat. Ruby interpreters are not a There-Can-Be-Only-One Highlander scenario. You more or less have to be trying to imagine the most wildly cartoonish and improbably malicious motives to think otherwise.
I am however very curious about what impact this will have on the development of JRuby and other JVM-based languages, such as Clojure and Scala. It's no secret that a lot of folks in the (J)Ruby community work on Macs, but I think that bleeds over into the other languages' communities as well. For example, I'm pretty sure Rich Hickey uses a Mac, and a tweet from Michael Fogus earlier today suggests that he does as well. Not sure about the Scala folks, but I wouldn't be shocked to find out that they're Macheads too.
In any case, there's lots of vectors to getting JDK/JRE on OS X, and this might actually make it easier to choose which vendor and version you want for your OS X Java install.
It doesn't prevent someone else from bringing Java 7 to OS X, nor does it mean that the existing support for Java 6 is going anywhere.
OS X and iOS, full steam ahead !
I can't speak for that today, but my source for this info was the Java Swing team themselves since they talked all the time with the Java "team" at Apple.
Head spinning.
Like they give a shit about the Java brand.
Back when Jobs was only "interim" CEO and Apple was at least nominally looking for a permanent CEO, he and Ellison played a prank on some guy who seemed overeager to apply for the job: http://www.cnn.com/TECH/9801/01/apple.oracle.reut/index.html and Jobs was the photographer at Ellison's wedding.
AFAIK Oracle still charges license fees for Oracle per core, while Microsoft charges per socket. The result is a HUGE price disparity... and the less expensive product is also the one that's far easier to deploy and maintain, and has vastly superior tools for developing and optimizing code.
Honestly, I don't see how Apple would be on Oracle's radar at all, since they serve such vastly different markets.