Live data from Hacker News

Apple deprecates Java

developer.apple.com

181–190 of 277 posts

Re: Apple deprecates Java

#181

Earlier quoted context omitted.

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) I…

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.

Re: Apple deprecates Java

#183

Earlier quoted context omitted.

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

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

Re: Apple deprecates Java

#184
post #72

Earlier quoted context omitted.

> 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) Window…

Actually, their move from GCC to their own internally developed clang has way more to do with this than some walled-garden fantasy: 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... "T…

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

Re: Apple deprecates Java

#185

Earlier quoted context omitted.

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…

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.

Re: Apple deprecates Java

#186
post #140

Earlier quoted context omitted.

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

Re: Apple deprecates Java

#187
post #158

Earlier quoted context omitted.

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

Re: Apple deprecates Java

#188

Earlier quoted context omitted.

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) I…

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.

Re: Apple deprecates Java

#189

Earlier quoted context omitted.

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.

Re: Apple deprecates Java

#190
post #84

Earlier quoted context omitted.

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

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

Post reply on HN