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, which is fairly purpose-specific.
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)
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.
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'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.
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)
"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."
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.
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 ?
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.
"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.
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?
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.
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.
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.
"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.
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.
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)
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.
> 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.
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.
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?)
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.
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.
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
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?
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.
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.
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.
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.
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 :)
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.
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 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.
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 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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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!
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."
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.
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.
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.
For all the competition, Apple and Google have loads more in common with each other (they both make immensely useful products for end-users) than either has in common with Oracle (who sells very expensive employment-insurance policies for people who'd die laughing three times over before touching the software they purchase with a ten foot pole).
Oracle's friends are Fortune 500 executives with small minds and deep pockets. That is to say, people who are willing to shell out for Oracle products and services when there are considerably better and less expensive alternatives available.
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.
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.
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."
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.
Does anyone else use Oxygen on the mac. I've never found anything that comes close when working with XML. But judging from the clunky UI, I have to conclude it's written in Java. I wonder what they will ship in future, maybe the app with a JVM installer?