Hacker News new | past | comments | ask | show | jobs | submit login
Apple deprecates Java (developer.apple.com)
386 points by tomeast on Oct 21, 2010 | hide | past | favorite | 268 comments

Note that they've only deprecated their own Java runtime.

On the other hand, is there really any other? For years, Apple has been pretty much the sole provider, and had their very own JVM with specific look & feel customization to the UI packages. The only real alternative is Soylatte[0], which is fairly purpose-specific.

[0] http://landonf.bikemonkey.org/static/soylatte/

> The only real alternative is Soylatte[0], which is fairly purpose-specific.

What do you mean exactly by "purpose-specific"?

>SoyLatte Project Goals

> - 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

The project was always intended to help ensure continuity of Java on Mac OS X; integration with OpenJDK being the means to ensure ongoing support and encourage Sun/Oracle's adoption of official support for the platform.

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)

Awesome! :)

I don't own a Mac.

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?

I believe it is Sun's JVM with OSX-specific customizations to make the UI suck less (it still sucked, generally speaking).

The Cocoa (UI) bindings were already deprecated sometime during 10.4/Tiger if I remember correctly.

However it isn't just the Cocoa bindings that are important. AFAIK SoyLatte's Swing/AWT elements run through X11. Apple's Java allows for Java GUIs without starting X11.

X11 is horrible on OSX. Applications that use it (e.g. The GIMP on OSX), are terrible and have many usability flaws, such as no clipboard between an X11 application and a normal application.

Have you tried xquartz from http://xquartz.macosforge.org/ ? I am able to copy/paste between WingIDE and GIMP and native OS X apps using xquartz. There are issues such as switching between X11 and native apps, but it works better than the X11 distributed with OS X.

True, but would you rather not have it at all?

Definitely. Unusable software is as bad as none at all. Unless someone is paying well, I'm not going to deal with the issues.

Umm... Just don't use it. No one is forcing you to. Some of us are happy to have it, even if it does have some quirks.

Well, if you have a choice, sure. But if you're working in a team where everyone uses Eclipse, it's really nice to have the ability to run Eclipse.

Eclipse should be fine since it's using their own SWT for the GUI. They're not using Swing.

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.

I'd rather not have it. I tried running OpenOffice under X11, and the fact that I couldn't copy and paste text around the place did my head in, and I couldn't use it.

Yeah, OSX's X11 is utterly dreadful.

Be it as it may, but xterm/X11 still kills Terminal.app in text rendering speed. Also, MacVim is, on my Mac at least, visibly slower in text rendering than the naked vim under xterm.

I'm assuming this isn't so slow it shows up on a screen recording (of course, if it IS, that would be interesting), but either way could you please file a bug at http://bugreport.apple.com/? It will reach someone who cares.

Text rendering speed? I type a letter Terminal, it appears. What are you doing that text rendering speed matters?

Running any kind of build process would be an easy first example. :-)

Builds. sbcl in particular is insanely verbose and is often limited by slow terminals. The readme for bootstrapping it even specifically suggests using xterm over gnome-teriminal/konsole.

I get slowdowns caused by text rendering in terminal when rsyncing large numbers of files. It's easily worked around though, just minimize the terminal window

Try scrolling large amounts of text in MacVim, where the whole screen is refreshed, and then try the same in xterm+vim. MacVim is painfull to watch doing this, feel like working over a 300 baud modem. xterm/X11+vim are VERY fast combination for pure text editing, and that matters to me greatly. Same applies to Terminal.app (and it refuses to work in 256 colors, unlike xterm)

Indeed, this will presumably affect users of Eclipse, Netbeans and similar. Not sure how many non-developer apps make use of those APIs, though, especially as they don't quite produce native look & feel. (still much better than X11, which is indeed terrible on OSX)

@nileshk: "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.""

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."


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 think Eclipse is in a better position to handle this because it uses SWT instead of Swing. SWT is not produced by Apple, and uses native widgets (for OS X, there is both a Cocoa and Carbon version). So in theory, Eclipse could run on something like Soylatte without having to use X11.

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.

Or maybe they're not interested in being on the other end of an Oracle lawsuit. I don't know.

Apple paid for Java; they're not going to get sued.

I wonder if Oracle just increased the price?

That thought occurred to me; maybe Apple decided not to renew their license.

The product ordering software for every photographer-centric company I've ever dealt with is written in Java. Given that a large portion of photographers use Macs, this could have a big impact there.

I'll have a lot of users who'll be sad if they can't run my app http://www.auctionsieve.com/

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.

Real question: is there an alternate, well-tested Java runtime that someone would advise to use afterwards ?

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.

> Real question: is there an alternate, well-tested Java runtime that someone would advise to use afterwards ?

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.

I think "may be removed from future versions of Mac OS X" sounds pretty much like it is very likely that it will be removed.

I don't think so. It makes it sound like if that's ever a bother, they'll drop it. But right now, they probably have the deployment architecture so no reason to ever remove it.

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.

"It makes it sound like if that's ever a bother, they'll drop it."

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.

Except they are actively working to make iOS jailbreaking impossible.

And it's a suggestion to people who rely on Java being there that they should keep a copy of the installer package handy, because it might not be included later.

Simple answer: No.

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.

I have not done Java development on OS X, but doesn't this mean that OS X 10.7 would not ship with a Java runtime? Wouldn't this have a negative effect on the ease of packaging and distributing Java programs on the platform?

I'm sure they'll still ship with a JRE.

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.

> doesn't this mean that OS X 10.7 would not ship with a Java runtime?

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.

Was Java that big on the Mac? Neither Windows nor most Linux distros ship with a Java runtime.

Yes, at one point Apple made a big deal about Java being a "primary" language on the OS X platform. It had proper Coca bindings, Mac like look & feel, etc. Steve hawked it in one of the early OS X keynotes as being the future of the Mac platform. An easy language for all those that were confused by Objective-C.

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!

> Steve hawked it in one of the early OS X keynotes as being the future of the Mac platform

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.

> 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.

Clang/LLVM is BSD while GCC is GPL. That means Apple can extend them all they want without ever giving you, or their competition, any sources.

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.

I would like to point out that Apple employs the guy that builds LLVM/clang and all those projects and yet they are still releasing the source code and everything out there for the public to use.

> Apple employs the guy that builds LLVM/clang

Curious. Is the copyright Apple's?

The copyright belongs to each contributor: http://llvm.org/docs/DeveloperPolicy.html#copyright

My appologies for accidental down vote instead of up vote. :(

Oh, I think I'll live :-). Apology accepted! Cheers mate!

> That means Apple can extend them all they want without ever giving you, or their competition, any sources.

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?

"A compiler is not exactly a competitive advantage for a company as big as Apple."

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.

> Having an optimized in-house compiler

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.

Somewhat of an aside, but because Apple jumped to x86 late in the game, they can make more assumptions about their CPU than Windows can (for example, all Intel processors on Macs have SSE2 or higher).

64-bit processors allow similar assumptions on Windows, too.

> It mostly means that they can use the libraries without having to open-source Xcode itself.

LGPL would be fine for that.

Yeah, but why bother? It's not like Apple has any reason to go LGPL (and actually, now that I looked it up Clang seems to use the same license as LLVM — which makes sense — and that's the University of Illinois/NCSA Open Source License not the 3-clauses BSD, which again makes sense considering LLVM got started at UIUC, so it's not even Apple who decided on the license of the LLVM suite and related tools, they got into LLVM years after the project started and just used the same license for the stuff they built on/around LLVM)


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.

On an afterthought, I wonder how much patent protection clang/llvm's license provide for downstream users.

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.

GCC has always been a centerpiece in the plan for the "viralization" of the GPL, and support for its role in this plan has always driven design decisions in GCC. This policy has caused a lot of headaches even just within the free software community (eg. http://lwn.net/Articles/343608/).

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.

...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.

It makes some sense if you view it from the perspective of users rather than developers. The FSF comes from the perspective of being interested in what rights/freedoms end users have to modify software they receive, which takes precedence over other concerns. So basically anything that would make it easier for developers to ship stuff that end users aren't allowed to hack is bad.

So basically anything that would make it easier for developers to ship stuff that end users aren't allowed to hack is bad.

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.

Weird but plausible...

> 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?

Making your software hard to interface with is making it less open. It's the same sort of move as making your word processor use an incompletely documented binary format.

> Making your software hard to interface with is making it less open

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.

These are both important. Sometimes the letter of the law is convenient. Needing to resort to the letter of the law is not "open" -- a 3rd meaning!

http://gcc.gnu.org/wiki/GCC_Plugins gives some background.

Actually, their move from GCC to their own internally developed clang has way more to do with this than some walled-garden fantasy:


"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."


"The compilers in this release are covered by GNU General Public License version 3."

The GPLv3 does not apply to code compiled by GCC 4.2.1+. It applies to code you try to fork from it.

Actually, if you developed and distributed a non-GPL compatible plug-in for GCC, the GCC license prevents you from linking to the gcc stdlib without distributing built code under the GPL.

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).

As I noted elsewhere, I wonder what kind of patent protection if offers to downstream users of derived products. Since BSD-ish licenses don't mandate the passing of redistribution rights, I must assume the patent protection (like OpenJDK users enjoy - much to Oracle's non-enjoyment) isn't there.

I am not saying Apple wants to patent-troll downstream developers, but that's a risk that's worth noting.

Apple's "proper Coca bindings" was probably an overstatement. It had a binding that didn't really work well and was incomplete due to the dynamic nature of Objective-C and the lack of it on Java.

Windows may not, but most Windows computers do, because manufacturers put it there. This used to save me a lot of pain.

It was a very long time ago (> half a decade, at one point it was almost on par with Obj-C as far as runtime-favoritism goes). These days, it's mostly fallen by the wayside

"Was Java that big on the Mac?"

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.

Windows and Linux don't ship with Java because they depend on Sun to produce the runtime. Apple produces it for OS X.

Still it is installed on pretty much every machine i know, be it server, desktop, windows or linux. Like Flash it is most of the time one of the first 3rd party tool to be installed, i guess..

Maybe it could be an optional install, like rosetta is on snow leopard.

I think this comment is spot on. Their own bespoke XWin was replaced by X.Org in 10.5 - well strictly by XQuartz. The Apple Java runtime has already been moving closer to the standard Sun one (i.e. default renderer was switched over to Sun's a couple of versions ago).

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?)

Yeah I noticed that. Does that mean that Sun can start creating the runtime again? Does that also mean I can skip the hassle of going to Apple Dev center when I want to download the JRE?

It's a smart move from Apple's point of view. Why should Apple work to support Flash or Java or any platform that is owned by someone else? Why not shift the burden of maintenance, and dealing with bugs, onto those who own the platform? And why not open the door to future Apple products that might compete in the same space?

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.

They should care because they sell hardware to people who use those platforms. They will sell less hardware to Java/Scala/Groovy/Clojure/Jython/JRuby/Beanshell programmers this way.

The Mac platform is not important enough for Oracle to care. And Java Apps won't be in the App Store.

Why isn't the Mac platform important enough for Oracle to care?

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.

Ugh, you just reminded me of the Java updater on windows machines. I hope that if Oracle does care, they at least care enough to get it right. And that Apple lets them still hook into Software Update.

Even if Oracle supported Macs. Apple made it clear they won't allow Java Apps in the Mac App Store.

So what? The Mac App Store doesn't erase the fact that I can go to http://www.eclipse.org and get eclipse.

But I suppose you won't be able to run it on iOSXI

Haters gonna Hate.

So what other JVMs can you run on the Mac today? Will Apple open-source their JVM as a starting point for whomever wants to pick up that ball and run with it?

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?

You can run Soylatte. Landon Fuller ported it when there was no Java6 on 32bit Intel Macs. Soylatte now is the Openjdk7 port for Macosx.

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.

Your point about Android development may be the reason this move occurred. The IOS vs Android war is at full steam right now and Apple is known to be the aggressor in it thus far.

Interesting (and provocative) point, but that seems like a stretch that Apple would considering such and indirect action just to put up a roadblock for Android developers, and not a very big roadblock at that.

Apple don't really have much of an interest programmers, other than those who are developing for their platforms (OSX/iOS).

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

"I doubt programmers make up a huge % of Mac sales either to be honest"

You sure? It'd be interesting to see the results of an HN poll on this.

The install base of Mac is 50 million. http://www.boygeniusreport.com/2010/10/20/apple-cfo-tim-cook... There are about 9 million programmers in the world (heard this from Joel at BoS 2 weeks ago -- not sure if it's true, or if I am remembering correctly). If 50% of devs have a mac (way overestimate), we make up less than 10% of the users. Now ... how many of us need Java?

Well...Java maybe not so much.

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

At my employer, I would guess that 60-70% of the developers use Macs, all doing Java. I've seen similar numbers at other places I've worked.

Java shops use Java -- that's definitely true. But, are there enough of them for Apple to care? Apple doesn't make their own Python, PHP or Perl, and I bet a lot of Python, PHP and Perl devs use macs. I do for Python.

Apple sells 22M Macs a year, and growing. How many people do you think compiled a Java program on Mac OS X worldwide this year? 10K? M-a-a-y-b-e 100K?

Why was this downvoted?

This worries me greatly because my startup's product is based on Java, which gave us an advantage over others in our space for being able to work across Mac and Windows while maintaining a great user experience thanks to a lot of customization on our part (see profile).

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.

To argue that having an Apple supported JVM was good, or that it doesn't matter because you'll just have a 3rd-party JVM instead, misses the fact that it's the change itself that will be cause the of problems. As crap as Apple's Java support has been, it was a known quantity: as a developer, you know what your Mac users have (currently it's "most have Java 6, but there are plenty of people still stuck with Java 5"). The same is true for Windows; even though the JVM comes from Sun, everyone gets that same JVM, and pretty much everyone has Java 6.

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.

Given that they are deprecating their own Java runtime and that the major differentiation of said runtime from others is the much better approximation of the Mac UI in Java apps, and given that this deprecation is coming ~9 months ahead of OS X 10.7 Lion, I’m going to guess they are finally freshening up the OS X look & feel and don’t want to spend time keeping their JVM in lockstep.

That seems a reasonable guess. Also, java has been showing up with a lot of vulnerabilities, so the beancounters may have wondered about the costs of doing qa on implementing those. We know that it is months before we get major new versions of java or some of the security fixes. Also java 7 is on the horizon and the dance would start over again.

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.

That is very bad news for those of us who use Java on Mac OS X. And I don't mean UI programming, but developing server Java (or any JVM-hosted language, such as Clojure) applications.

Why? http://developer.apple.com/library/mac/#releasenotes/Java/Ja...

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.

One of the major reasons why we went with Clojure for a commercial project was the maturity of the JVM platform, particularly the HotSpot VM. We really care about multiprocessing, pauseless GC (ConcMarkSweep does a good job here), low memory situations, JIT optimizing our code and overall stability. HotSpot has been great so far.

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.

I think stuff like this isn't really that bad for devs who use the platform. Devs (should) have the ability to pull down the replacement in this situation when the time comes. It's going to be harder on the end user that no longer gets why his/her Java application no longer works right.

What end-user Java applications are there for OS X? The only one which comes to mind is Crashplan but I'm sure it's lurking around in other places.

Folks have mentioned Eclipse as an IDE, but there's also Eclipse as a platform. I have three Eclipse RCP apps I use for visualization daily.

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.

Do IDEs count? A lot of Mac users use Eclipse. It's not common among all-Mac teams that just do XCode, but it's fairly common for devs in groups that mostly do PC development to own Macbooks that they run Eclipse on.

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.

As an Android developer using Eclipse on a mac, this news majorly sucks. I hope the offering from Oracle will be better than Apple's JVM though.

Encyclopedia Britannica.

Vuze aka Azureus

I won't be upset to see that go. Worst bit torrent programme I think I've ever used since the rebranding.

I don't see it having a big impact on server side JVM languages. As long as the developers are the only ones that have to be the ones to deal with the JVM installation headaches, it won't be that much worse than server side Java already is :)

Seeing Clojure deploy on LLVM would be a moment worthy of cracking open some expensive champagne, personally.

I was under the impression that iTunes (the backend server) was all written in Java using Apple's own WebObjects framework that they ported from Obj-C.

Have they ported it back, or are they planning to ship OpenJDK for server purposes?

Or are they planning to keep iTMS on Java 6 forever?

People who follow Apple's developer communication have seen this coming for years. It'll be interesting to see if Oracle steps up to fill the gap or not.

There is already a port of OpenJDK: http://landonf.bikemonkey.org/static/soylatte/

Though it's not developed by Oracle employees afaik.

SoyLatte is nothing more than a build of the OpenJDK BSD Port. You can build that yourself.

Not entirely the case. Soylatte is what became the OpenJDK BSD Mac Port. It was granted re-licensing and was merged upstream to OpenJDK.

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.

Well, I should have said "at this point". Surely building bsd-port is more interesting than building your own Java 6.

This could be good news for anyone who uses a Mac to work with Java. There could finally be a JDK for OS X that doesn't lag years behind official Java releases.

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.

Banning? I think that seems rather unlikely. To my knowledge Apple's never done anything of the sort on the desktop. On mobile platforms users are more accustomed to having restrictions in place, but if they banned Java on Mac OS the backlash would be immense.

An outright ban does indeed seem remote, but if they start to tie software installation/update/maintainance on the Mac to the Mac AppStore and ban Java apps from the AppStore, the effect on end users' ability to use Java applications is tantamount to a ban.

I hadn't thought of this in light of the App Store announcement, but apparently it's essential to do so.

From the review guidelines:

- Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected

That's interesting.

I wonder if Apple is planning a "superior platform" strategy? If they can move to an App Store being the norm for Mac users and solve lots of deeply ingrained security and compatibility problems in the process, Microsoft/Windows is going to have quite a hard time following. The record for Apple accomplishing big architectural shifts with minimal pain (OS X, PowerPC -> x86) is much better than for Microsoft. (Vista) It would be like a lightly-armed force luring heavily equipped force into boggy ground, where the latter gets stuck in the mud while the former only gets slowed down.

Of course, Debian has done this since the early nineties, and yeah, it is nice to have guidelines (DFSG, etc.) that applications must follow to be a part of the platform. Having one entity responsible for system integration makes for a well-integrated system.

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.

I'm thinking about going beyond what even Debian accomplished. As awesome as Debian is, it's based on unix-derived architecture from the 1970's. What about a successor to OS X with capabilities, orthogonal persistence, and no bootup? (App Store requirements and APIs could target easy migration to the new architecture.) Microsoft would have to follow or be left in the dust, but it would be travelling a path Apple is better suited for.

it's based on unix-derived architecture from the 1970s

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.

I think of Unix as more of a local-maxima than a fundamental item like the wheel. It's more like the internal combustion engine: there's been lots of technologies proposed that fix problems with it, but it's managed to improve faster than those technologies can gain traction.

I think of Unix as more of a local-maxima than a fundamental item

Recognizing the difference between fundamentals and local-maxima constitutes some of the most powerful entrepreneurship!

Isn't this like saying that we shouldn't use wheeled vehicles anymore, because wheels are a stone-age technology?

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.

I hope that Windows is not going to follow! I for one like to develop/use applications which require optional components

I agree. As owner of some older Macs and trying to run a Java app written in Java 6 was a serious pain to get newer version of Java on a slightly older OS (10.4) Hopefully Oracle will pick up the ball with an easy installer for the Mac so we can install newer JRE's on most versions of OS X.

Oracle does not care about Java on the Mac. I think Apple should care. They will loose customers (including me) when there is no decent Java on the Mac. Server side Java won't be a problem. But all the good Java IDEs (Eclipse, Netbeans and Intellij) are written in Java and need a decent Windowing System. X11 on the Mac is not that.

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.

Combine this news with the announcement of the App Store for OS X, and one possible conclusion is that Apple doesn't want Java-based apps in the app store. It's an easier prohibition to make if the JVM is not officially supported by Apple.

Also, this could be a guard move against Oracle, a capricious litigator.

2.24 "Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected"

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.

That's a very clever move. If you don't want your app store to distribute Flash based programs, just make it so that Flash isn't installed by default. Since it can be installed by users, most people won't notice. But they can legitimately claim that Flash is an optional component...

Clever like a fox.

Flash has had "publish to exe" capabilities since forever so I'm sure something'll emerge that publishes to w/e Macs use.

The Mac App Store also requires that you use XCode to package your apps.

One thing this enables is switching platforms. If a future MacBook Air runs on ARM instead of Intel, anyone using Xcode would only need to recompile to target the new platform. Similar to how Intel support was easy for Xcode developers (but very hard for Metrowerks developers). Getting everyone on Xcode gives Apple tremendous flexibility. They could even have apps target LLVM-IL (whatever it’s called) instead of the CPU directly.

So then what's the best way to do cross-platform development?

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?

UI & cross-platform dev are two separate issues. Cocoa/Java has been dead for some time, and nobody who cares about design or usability seems to use Swing etc. It mainly seems to be developer tools in the Java ecosystem.

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.

> I'm more worried about development of server stuff becoming more painful, particularly as Clojure, my favourite language, is (currently) JVM-based

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.

Java seems to have been dying for quite a long time, if you believe the hype. I think I saw the first "Java is Dead," headline in 2002. Frankly, I doubt the language is taking a dirt nap any time soon.

Any language that has some measure of 'good' is like a well loved comic book character. There may be reports of death, but if the character is well loved, there will be some means of bringing the thing back.

Have you considered Python? I'm a big fan of statically typed languages but that's the one I use for all my scripting on *nix and Windows. It's used by a whole slew of web developers. Nothing stopping it from becoming the new cross-platform development language of choice.

Depending on what you want to do, Adobe AIR would be a practical way of delivering applications on Mac, Win and Linux...

It's worth mentioning that AIR apps do not use native UI widgets. (and in my opinion: the Flex widgets kind of suck)

I am building one now, and they do allow you to create a native installer for all three platforms. The only thing that sucks is that you have to build the installer on said platform. Not that big a deal with vmware, but still kind of annoying.

Again, depending on what you want to do, SilverLight works pretty darn well on Windows and Mac these days.

Adobe Air, Silverlight/Moonlight Out-of-Browser, Mono, HTML5/JS.

Does anyone have any experience with Mono on macs?

MonoMac has been around for a little while, but MonoMac + the OSX App Store are firmly in Miguel De Icaza and team's sights:


Thanks for the info

How about C# in the form of Mono?

Maybe something like Mozilla's Open Web Apps? http://blog.mozilla.com/blog/2010/10/19/prototype-of-an-open...

Open Pascal with Lazarus.

Shouldn't that be Object Pascal?

No, and neither should it be Open Pascal. He meant Free Pascal, an open source implementation of Pascal that also supports Delphi syntax (Object Pascal).

GTK is trying to get there. Gimp was ported to MacOSX GTK--haven't checked in a while the state of the port. The Inkscape dev team at least has high hopes that GTK will become stable for MacOSX.


I disagree with GTK, and I recommend Qt. I use several GTK apps on Windows and they don't look native. Furthermore, GTK has some deeply ingrained usability issues - such as the close button - that they bring to all platforms.

I love Qt, and much prefer working with it to Cocoa, but Qt on OS X is ugly and doesn't feel particularly native. I can usually recognize a Qt app as soon as it starts up. It still gets the job done in the cases where elegance doesn't matter (i.e. we have a tool for optimizing query parameters that has a Qt GUI that we just use internally), but for places where it does, it's better to go with Cocoa.

This is why Steve Jobs is against ALL cross platform development. Because it's going to be a lowest common denominator. At the same time, advancements on the platform are not going to be taken advantage of. Any new features in OSX would go unused - because it's not in the lowest common denominator. As a Java dev, I have to say he has a good point there. I just wish Objective C didn't suck so much.

Which close button are you talking about and how is it inherent to GTK?

I'm guessing the close button on dockable floating windows.

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).

"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."

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.

> Is there an implementation of GTK that doesn't run via X11 on the mac?

GTK-OSX is supposed to do this, but I haven't been able to get it working.

What about Qt? It looks good for me, although I never tried on a mac.

I've been very satisfied with Qt on the mac. I've ported a couple of linux applications I use. They are not as good as truely native ports (MacVim is clearly more of a "mac" app then any Qt built application), but it gets basic things like menu bar at the top and shortcuts using command instead of ctl right.

It's meh. Not as bad as GTK+ by a long shot but still a far cry from native applications. And OSX users generally don't like non-native applications (for a number of reasons)

Nothing, Nokia has come along way with it. It the latest (Qt 4.7.0) they are slowly getting things closer and closer to native look and feel. There are carbon and cocoa versions for the mac. The Cocoa version obviously integrate better than the carbon version will. There are also Qt classes to integrate Qt based widgets into cocoa based containers etc. Is it perfect, not even close. Is it pretty darn good, yes.

Here's an example: I use WorkRave to remind myself to take breaks. If I open the preferences dialog, I can close it by pressing Close, clicking the X in the corner or pressing Esc. No matter what I do, my changes are saved.

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 am numb with anger right now. I sell java based consumer app and good 50% of my sales are from macos. To be honest java prohibition in the appstore wasn't surprising, I had to sign new dev agreement in august that explicitly prohibited java based apps, but they let my app in anyway.

What I find so utterly surprising is that they are completely killing it on the os level.

html5 here I come.

I wonder if putting the boot into the most straightforward cross-platform solution for desktop apps has anything to do with the proliferation of OSX Java apps with shoddy/un-maclike UX/UI or whether it's something to do with Oracle's recent moves.

I think it just means that Apple has no interest in bringing Java 7 to OS X. It certainly took them a long time to release Java 6.

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.

Really, that's very surprising. I'm a longtime Cyberduck user and had no idea...

I am both surprised and delighted.

is there such a proliferation? the only java app I use on the mac is cyberduck, and it is neither shoddy nor un-maclike

Had no idea Cyberduck is written in Java. If only all Java desktop applications are like this.

Oh, me neither! I really had to check this out.

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...

I use SmartSVN, wouldn't call it ugly.

But this seems to be AWT. And the GUI just doesn't feel as snappy as native Cocoa.

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?

many SWT apps, using native look and feel, still feel slowish (think azureus/vuze if not eclipse). Some AWT apps are perfectly snappy e.g. jedit opens a file faster than macvim on my box.

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)

do not pay attention to proper data structures cause you can get away with builtin collections etc

Specific examples from your experience?

code I wrote myself :)

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.

Examples where the "extra overhead" caused an actual problem?

A a few more gigabytes of memory allocated, consequent swapping and slow processing

the one I just wrote you about

What problem did that specific bit of GC pressure cause you? (I'm doing "5 whys" in reverse. Otherwise known as "The Socratic Method.")

sorry I thought I replied yesterday but apparently my comment got lost.

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.

How much slower? Just how much wall clock time did you lose?

hard to estimate I'm sorry. The first naive implementation had been running for more than 15 minutes before I thought it as too much and killed it. Rewrote version run all in about 5.

Jobs and Ellison are buddies -- I would find it surprising if Oracle went after Apple over some Java legal issue. My bet is on shoddy UI, plus the time invested vs. payoff balance.

I have found this thread blissfully flamewar free regards business motivations. That said, I think this first mention of business issues is both overdue and needing expansion.

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 would hardly be surprised to learn that Oracle will NOT sue Apple over runtimes that could trip up Google

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.

I think it's more that now Ellison owns Java/Sun, he wants control. Jobs was happy to hand over the resource-suck since he sees the future as iOS apps and appstore anyway.

I don't think Oracle is even on Apples radar, Apple is largely a consumer/creator focussed business, Oracle is purely B2B.

yet, some java developers are mac users, losing them does not seem smart

It seems like more than a coincidence to me that this announcement is made right after Oracle absorbed Sun and made some pretty shocking announcements about their plans with Sun's open source portfolio (OpenSolaris, MySQL) and Java.

The biggest loss here is the Mac specific GUI bits. Not only does Apple Java use native drawing primitives for ui (instead of requiring X11 like some ports), it also doesn't look completely horrible.

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...

Maybe the fact WebObjects was removed from Snow Leopard Server means they don't depend on it internally as much?

It seems like they've been cooling off on Java development and support over the last few years.

I believe that the current WebObjects license (while no longer having a licensing fee) stipulates that it should be run on Apple hardware. Some wags have speculated that it would be OK to run it on an Mac Pro even with Windows 7.

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.

It used to be cross platform. Back in the dotcom days, I was at a company that would sell implementations of it for Windows and Sun servers.

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.

That might have been when WebObjects was still using Objective-C.

Our coders wrote their code in Java.

Java has never been cross platform. Back in the dot.bomb days running java on anything other than Windows and Solaris was a huge pain in the ass when not outright impossible, and there was Sun's infamous internal memo about how much Java on Solaris sucked!

I found the memo from 2003: http://web.archive.org/web/20030210024427/http://www.interna... -- this blog thread discussing it is enlightening: http://www.advogato.org/article/624.html

I was talking about WebObjects.

Last I heard, and this was around the switch to Intel (2005?), the iTunes store and online web store are run off of WebObjects. Apple probably saw that outside web developers weren't using WebObjects enough to continue supporting it externally. That doesn't mean that they aren't using it (and maybe building on it) internally.

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).

The reason that this is a big deal is that they've released/leaked some of the guidelines for the Mac App Store and it states that apps developed using "deprecated or optionally-installed technologies will not be accepted."

Does this effectively mean that I will not be able to use java application on newer OS X at all (in case of java runtime support removal), or I will have to install some third party java package?

It seems like you will do what you do on Windows and some Linux distributions, you will go to Oracle's site and download the JDK / JRE from them. I am really wondering if this is totally and Apple thing or partially a suggestion from Oracle.


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.

Jobs did say at D8 that Apple chooses technologies that are in their Springs and not their Falls. Java has had far to many Falls....

Seriously, Apple does not need Java and I think the market for Java apps has become few and far....

Now deprecate your own OpenGL drivers.

Then who would maintain them? The hardware manufacturers? :\

Windows and Linux drivers are maintained by the manufacturers.

I didn't realize Apple did this (not a Mac user personally). Didn't Microsoft get sued for providing their own Java runtime years ago? What is the difference here? (just out of interest) Obviously Sun/Oracle have been fine with it, so is it different to what Microsoft did?

What Microsoft shipped was not a conforming JVM. It couldn't interoperate with servers using the native Java RPC protocol (RMI), it couldn't use the same native code (JNI) libraries that any JVM would, and it couldn't verify signed packages (JAR). It also added nonstandard methods to standard classes, and any code which called them without reflection wouldn't even load on a JVM.

This whole thing happened when Java 1.6 came out. It took Apple forever to get it into OS X and there was a big fight for it. Now it's happening again. Must be a pain for Apple to manage it.

Sounds significant, but how important is Apple/MacOS to Java?

Not really as significant as one might think. This is just Apple saying, "we're discontinuing our own, internally developed and maintained JRE/JDK." I don't know off-hand how far this diverges from Sun/Oracle Java or IBM Java though (maybe someone else can step up with that information).

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.

If they help to maintain and distribute an alternative JRE (which could only really be OpenJDK, one would think) then it's good news for Java developers. On the other hand, if they don't distribute any and don't help to maintain it then it's a disaster. If the latter turns out to be true then I'd be pretty concerned if I was a Java developer (or if I used any of the JVM based languages).

Not very significant as a target platform, I would think, but OS X is certainly a favorite development OS for many Java developers. Sun, for example, had been issuing MacBooks Pro to its engineers during its last few years.

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.

Aren’t the CEOs of Apple & Oracle bestest friends in the whole world? Will it be long before Oracle/Sun picks up the slack on this?

It's probably just wishful thinking, but here's hoping they're working on bringing some kind of newer managed environment to OS X.

Speculative, but could this be an early preventative measure to keep JRuby from challenging their up and coming MacRuby platform?

That strikes me as spectacularly unlikely. JRuby and MacRuby aren't in competition; they meet different needs and have very different usage scenarios.

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 don't believe that this is an attempt on Apple's part to hate on JRuby.

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.

We'll have to see how this plays out. It's been very nice that Java's already available on all new Macs, but then there's been the dreadfully slow progress of incorporating updates, security fixes, and so on. On the other hand, OpenJDK has been building well on OS X for some time in both 32 and 64-bit forms. The only real missing pieces are easy ways to get OpenJDK builds installed (helped by Apple's restructuring of how they configure and locate Java installs) and the Cocoa-based backend for Swing (if you're using or building GUIs).

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.

That wouldn't make very much sense to me, given that Ruby 1.8.7 is a much more formidable "challenger" than JRuby will ever be.


"Their" up and coming MacRuby platform? Is that a joke?

In what respect? MacRuby is a project hosted by Apple. It's lead developer is an Apple employee, and there are several other Apple employees working on the project. In what significant way is it not Apple's platform?

Might I say, "the up and coming MacRuby platform Apple has designs for"? At least a couple of the committers are Apple employees. But I misattributed the project as being "theirs", which apparently isn't true.

Eh, it's Apple's in any meaningful way. The project is led by Apple's Laurent Sansonetti, hosted by Apple's Mac OS Forge, and Sansonetti has said that MacRuby is intended to replace RubyCocoa, which is currently bundled with Mac OS X. MacRuby also recently started making improvements to Apple's BridgeSupport framework. I don't know how much more an open-source project like MacRuby could do to deserve to be called "Apple's."

From the contact page:

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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact