Slashdot Mirror
Apple Freezes Java Support for Cocoa
Nice2Cats writes "A little message on Apple's Developer Connection tells us that Cocoa for Java will get no new features after 10.4. The full text is:
'Features added to Cocoa in Mac OS X versions later than 10.4 will not be added to the Cocoa-Java programming interface. Therefore, you should develop Cocoa applications using Objective-C to take advantage of existing and upcoming Cocoa features.' Is this bad for Java, or bad for Apple, or bad for both, or doesn't anybody give a damn anyway?"
Recently, Microsoft announced "Digital Ink," a handwriting-recognition technology that many compare to Apple's InkWell, both respectively set to debut in the next major revisions of Windows and Mac OS X. As whenever similar technologies pop up at Microsoft, Apple Mac zealots ask a few questions: Was it developed in-house at Microsoft? Was it bought from a third-party? Grabbed from a sub-licensor?
The answer is that Digital Ink came directly from Apple, but the story behind how Microsoft was able to so simply buy InkWell and rename it for use in Windows is a tale of moral depravity and sordid carnal desperation that few are privy to until today! Read on to discover how Microsoft came to own yet another key Apple technology in the most sordid of political maneuverings.
It all began in the late Seventies. Steve Jobs, after a night of smoking marijuana and tripping on lysergic acid diethylamide, conceived of a way to interact with computers using only the mind. Well-known at Stanford for his telekinetic abilities, such as making entire fields of grass sway with but a thought, Steve wanted to move the "mouse" and "menu" (bizarre, alien concepts to anyone outside of his clique of 2600 hackers and EE alcoholics) with nothing but the power of his mind. Of course his compatriots the peaceful, bearded Steve Wozniak and the illegally immigrated Avie Tevanian dismissed the idea as yet another episode of harmless drug-induced rambling.
Twenty-six years after his messianic user interface vision, Steve Jobs was hard at work in the deepest part of Apple's labs, personally overseeing secret user interface experimentation. It turns out that Steve had never forgotten about his psychedelic user-interface dream and was tirelessly attempting to realize it thirty miles beneath Cupertino, Califnornia. Down here, in his "dungeon," the attempts to connect silicon to carbon were in full force and without regard to their subjects.
Some men had industrial-grade alligator clamps attached to their nipples and testicles which were randomly jolted with millions of volts of electricity in order to stimulate their brains. Other men had deadly mixtures of cocaine and heroin ("eight-balls") injected into their penises while being forced to watch gay porn. Another group endured horrible procedures in which their arms, legs, and scrotums were replaced with chimpanzee equivalents. One smaller group were forced to smoke opium eight hours a day while being whipped and beaten until they managed to move the cursor a pixel or two. The most successes, however, had come from Steve's own bizarre device dubbed "handJobs."
handJobs was a series of wires and electro-sensitive pads placed on the fingertips that allowed one to manipulate elements of the Mac OS GUI with simple motions. Steve Jobs, being telekinetic from years of tripping acid, wielded it more powerfully than anyone else in his RD dungeon. In fact, so powerful was his mind that he like to hook the wires and pads up to his own penis and controlled his Power Mac by means of pelvic thrusts and lewd gyrations of his hairy penis and scrotum.
Bill Gates, on a visit to the Apple Campus, accidentally stumbled onto handJobs in a moment that would change UI in computing forever. Feeling that he simply owned the Apple Campus as he did the rest of the world, Mr. Gates walked into Steve Jobs's private office without knocking. Steve was in the middle of "making love" to thin air, pants in a puddle at his ankles, hands on hips, thrusting his engorged member at the monitor! He had decided to take his latest revision of the device to his office to test out when Mr. Gates had walked in on him! Gates knew what he liked and liked what he saw, and began immediately bargaining with Jobs.
By the end of the day, Jobs had created a new technology agreement with Gates. Apple would begin partnering with Microsoft on alternative input technologies, and by late June MS would announce "Digital Ink" for Windows. In reality Digital Ink was a front, and b
While it may not seem like such a big deal it complicates crossplatform toolkits, and the like. Of course the whole idea of having a "blessed" programming language seems rather old fashioned, and academic.
I'd do something interesting, but my server can't handle a slashdotting.
WebObjects 4.5 had support for both Objective-C and Java, if my memory's right. In WebObjects 5.0, support for Objective-C was dropped, because this was during the time when Apple Wanted You To Use Java.
Now, of course, it seems as though Apple Doesn't Want You To Use Java Anymore. Does this mean that WO6 will drop Java support, or at least bring back Objective-C?
Cyberduck. It's the only cocoa-java app that I use, or even know about (not saying there aren't more, just that I don't know about them). Following the cocoa mailing lists, questions about the java bindings are few and far between, which probably lead them to this point. Why dump so much time and effort into a language that your developers aren't using? Either redirect the manpower somewhere else entirely, or into a language like python, which gives your users a meaningful choice - between objc (lowlevel) and python (scripting). And applescript, I guess :-)
All this seams to say is that any new wizzbang features of Cocoa won't be directly accessable with Java... There are already features of the Windows and Linux UI's that Java doesn't use...
Fact is, Java apps will still work. Still look like MacOSX apps (at least as much as they do today). I don't see how this is much news really.
If they did have an interface to use these features, it would break cross platform compatibility anyway as they are bound to be Mac specific UI elements.
Good idea? As far as large software makers go, it probably doesn't matter. Adobe's Mac developers have all learned Objective C already. This does significantly raise the barrier of entry for hobbyist coders, though. Seems like a typical Apple decision, certainly.
What I'm listening to now on Pandora...
It's Java. Does anyone really care? *ducks*
Deja Vu
n. 1. The sensation that you've read this very article before.
(as I sit here typing this on my iMac 20")
Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant. If the promise of Java did take off - people would be free to choose their platform without having to worry about buying all new apps or learning new look-alike apps.
By forcing programmers to use Objective-C - Apple can ensure that those apps are hard to port to any other platform.
That said, the 10.4 API is pretty feature complete, so by not too much harm is done by freezing the Java to OS X API right now.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
It has been considered best practice by Apple for some time to not use cocoa with java. Typically when someone has done this it has been for the GUI so that native widgets are accessible but with the Aqua widgets being accessible through Swing there is really no need for it now. If the argument is for cross platform writing of Java apps then pure java is always going to be more portable than Java + native elements.
Bad Panda! No Bamboo for you! In matters of importance ACs will not be responded to. Want to say something critical,OK
I wonder how this effects swt or if swt can provide similar functionality to java-cocoa?
Reality is nothing but a collective hunch.
Mmmmmmmmm...frozen Cocoa Java
Please remember, Java is still supported, it is simply the Cocoa-Java bridge that will no longer be improved. If you are not clear on what the Cocoa-Java bridge is (or event Cocoa), then here is a quick primer: Cocoa is the preferred API for Mac OS X, specifically for applications written in Objective-C. The Cocoa-Java bridge was a similar API that exposed essentially the same object model to Java based applications. As the API was specific to Mac OS X, any application written on top of the Java Cocoa APIs was specific to Mac OS X and thus not portable.
I would expect the impact to Java developers on OS X to be quite low. Most probably use Swing or SWT for cross-platform support, so the impact of this decision should be negligible.
Apple is just telling people to stop using the Java-Cocoa bridge which was actually not useful for building cross platform applications and not used much by the development community anyways.
People wanting this functionality in the future will still be able to do so by just writing a little JNI to handle it - though I'm really not sure its worth the effort.
It might be that Apple on Intel is a little to close to the Sun on Opteron workstation market for Sun's liking.
As long as they would now commit those resources to swt support on Mac OS X, this would actually be a Very Good Thing ...
Apple is managing it's change. They are moving a huge code base, and will have to leave some things by the wayside as they do. This is not to say that there will never new support after the change, but I personally doubt it. My personal opinion? People are going to bitch. No matter what. If they win the lottery they will complain about taxes. It is just there nature, they are resisting change for its own sake.
Ross Winn "not just another ugly face..."
NeoOffice/J is the port of OpenOffice.org to MacOSX. It does make full use of the Java Cocoa interface.
If someone writes a widget that places icons in the task tray, that only works on SCHOOMOO operating system, and then writes the Java class and JNI calls for this, but then goes and releases a new version of the widget, but doesn't update the Java classes.
+1 mod points to everyone who spotted this is neither anti-java or anti-Cocoa, in fact, it is pro Java because no Java developer wants to be bogged down with much non-portable code or mac only code.
I would wager than Apple was even nudged by some Java developers who said, yes, this was nice, but look, not much interest in it, we can use our own libraries and keep it cross platform.
This is GOOD for Apple, as this 'embrace the non-proprietary cross platform Java' rather than using Java Cocoa fixated programming, will mean more Java developers will target the Mac. Oooops! But they already do because Java is cross platform. Oh Hahah I am funny.
Now, sometimes you do want to access proprietary extensions, and in yesteryear, the extremely small quirky devices would give some benefits for being able to access their split bars, or their dialogue classes, so each platform had their own set of 'device API's', nothing too wrong with that, but with great power come great erm, device abstraction. Go spidey.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
I don't understand why anyone cares about the end of Cocoa-Java support in the first place. Why was anyone using it in the first place?
Java is a good language but restricting it to Cocoa destroys the cross-platform compatibility, which is pretty much why you'd use Java in the first place. I would understand if Cocoa were garbage and the Java class library was needed as an alternative, or if Objective-C were a complicated language to learn. But Cocoa is a great API and Objective-C is just a small and elegant bag on the side of C.
It really isn't a big deal. Few people use Cocoa-Java to build apps, and it hasn't ever been very well supported or documented.
It doesn't effect cross-platform Java, won't effect WebObjects (which is 100% Java).
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
Who writes programs like that ? Very few people, it turns out. I'm sure there are excellent examples of Cocoa-Java programs out there. In fact, I know there are. But really, they are neither highly portable, nor are they fully native code. It's entirely like having a Java program with an ActiveX interface. It's neither native nor cross-platform, it's a mix of technologies, and has the advantages and drawbacks of both, oddly enough.
Apple has, for some time, been moving away from full Cocoa-Java support. If you're shocked by it going away, you haven't been paying attention. If you want a multi-platform Java application, use multi-platform libraries, i.e. Swing. If you want a native application code program, write one- if you don't want use Objective-C because you'd like to port it more easily ( GNUStep aside ) , use C++. But if you want to use Java, well... use Swing. Seriously. It's not as bad as you've been told.
Then again, having native binary projects designed for their respective platforms has it's advantages, too.
Don't get me wrong. I've always thought Cocoa-Java was neat. But mostly in a 'cool trick' sort of way, not in a "I'm going to use this all the time" sort of way. If I want a chunk of code that just runs on any JVM-supported system, I'm not going to use Cocoa-Java, I'm going to use Swing and avoid having more than one build. If I want a native Mac OS X program, Objective-C is easy. Cocoa-Java fit some in-between requirements space that I guess I never really fully understood.
With all due respect, have you tried Objective-C? It's far easier to learn than C++, and in some ways far more powerful. Objective-C is a dynamic (late-binding) language. The Cocoa framework could not have been written in C++ -- many, many decisions are made at run-time.
Don't get me wrong, I'm not one for "language wars"; I'm just saying that C++ is not a replacement. I'm not sure what is, given that Objective-C is fully compatible with C code -- all pointer and bit-twidling nonsense -- and dynamic.
Objective-C coders don't use the language grudgingly.
quiquid id est, timeo puellas et oscula dantes.
Ouch. I wonder what that means for an OOo 2.0 (and beyond) version of NeoOffice/J?
http://www.neooffice.org/
oh how i wish i could elaborate, but i fear the power of apple/sun+lawsuits=slashdot giving my IP.
Move to x86 = anger
Lack of Java support = more anger
Are Apple just trying to piss off their loyal developer base? Maybe they are
arrogant enough to think they can replace them with thousands of mindless
VisualBasic migrants and AppleScript/Automator?
Neko
Move to x86 = anger
Lack of Java support = more anger
Are Apple just trying to piss off their loyal developer base?
Most developers are happy to see the move to x86 as it will simplify the performance-optimization stage of software development or software porting. But that's another arguement for another time.
This announcement has nothing to do with Java support in general. Apple and Sun are going to continue supporting Java on Mac OS X just as they always have. If you want your Java app to look like a native Mac app, then use SWT, just like you would do to make your java app look like a native Windows app. This hasn't changed one bit.
The announcement refers to using Cocoa (native Mac OS X GUI and API) with Java, rather than Objective-C. Very few people use Java in this way as this JavaCocoa code only runs on the Mac and is not portable. There are many 10 freeware applications written like this, it's more of a technology demonstration than anything else. Because of this, Apple is not going to develop JavaCocoa past 10.4 Tiger. They are not removing anything from 10.4 Tiger, and chances are it will live on in 10.5, albeit a straight copy from 10.4 Tiger.
Could this direction be to deal with the performance issues of Java on little endian systems like x86? Seems I recall reading that Java performance is generally better (or much better) on big endian systems such as Sparc (and, PPC970/G5). Given the migration to Intel, could it be the little endian performance issue (penalty?) is prompting them to make a preemptive move away from some of the Java support, so the Intel based Macs don't look like they perform badly for Java apps that are integrated tightly with Cocoa?
If memory serves, the performance penalty was related to numeric processing, including GUI interfaces.
I'm just speculating out loud, but that's the first thing I thought when I ready about this yesterday.
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
If you don't know what Cocoa-Java is, it's a way of gluing a Cocoa native interface onto a Java bytecode program.
no, no, no. Cocoa-Java is a way to write native Mac OS X applications using the Java programming language. The Java platform (i.e. java.lang.*), never enters into it.
Instead of using javax.swing.JFrame, you use com.apple.cocoa.NSWindow (the exact package name escapes me, but you get the idea), and you compile it into native code using Xcode, not bytecode using javac.
Reading articles such as this one should explain further. Excerpt:
"Because Cocoa is an Objective-C framework without automatic garbage collection, however, Java applications sometimes need to take steps to handle peculiarities in this mixed-language environment."
see what I mean? You're using the Java language, which has no free() method, so you have to use weak references or other such idioms to mimic memory management.
Mod the parent down. It's not "Informative", it's "Misleading"
I say we take off and nuke the entire site from orbit. It's the only way to be sure.
I haven't had much to to with NeXTSTEP/OS X since then, but your comments make me reconstruct the Java/Cocoa story as follows: after adopting NextSTEP as the basis for OS X, Apple management decides Objective C as a fringe language, and that Java, which was then being hyped as the language of the future, was an easier sell. But, as always, the developer community went with the tools it knew how to use, so Objective C never lost its dominance in OS X development. This latest move is just management bowing to that reality.
I'm going to go out on a limb an guess that this means that Apple isn't going to take Jonathan Schwartz up on his offer that they adopt Solaris 10 for the underpinnings of the Mac OS and adopt NetBeans as their development environment...
Shocking, I know.
Oye vey...
--
http://joshstaiger.org/
The OpenStep Story
NeXT Computer Inc, and Sun Microsystems Inc. teamed up in late 1993 to push a free object layer API based on the NeXTSTEP object system. This agreement evolved into the OpenStep specification which was published by NeXT in a first draft back in summer 1994.
GNUstep Hype and History
Early on many developers (educational and business) realized that the NeXTSTEP environment provided a great tool and reduced the amount of time necessary for writing applications. Still the portability issue was hard to solve since these application were tied to machines running NeXTSTEP.
It was the team around Paul Kunz at SLAC who decided to port their application differently than others did. Instead of rewriting HippoDraw from scratch on the new system and only "reusing" the overall app design and ideas, they rewrote the objects their application depended upon...the NeXTSTEP object layer.
As a result they created the first version of libobjcX which enabled them to port HippoDraw to UNIX systems running X-Window without changing a single line of their applications source.
After the OpenStep initiative became public, The next logical step was to make a new "objcX" which would adhere to the new APIs.
GNUstep Implementation
The first thing that needed to be done was implement the FoundationKit as specified in OpenStep. The libobjects library was around even before the GNUstep idea was born, but it needed to be extended and repackaged to fulfill the FoundationKit's job. This has resulted in libobjects being renamed to the GNUstep Base Library; its new name signifies its important role as the underlying support for all of GNUstep.
The ApplicationKit is closely tied to the Display Postscript System because all of the graphics drawing is to be implemented in the Postscript language. The GNUstep developers realized implementing a Display Postscript System would be an incredible task so they decided take an approach which would allow the ApplicationKit to be implemented without necessarily having the Display Postscript System implemented.
The design involved splitting up the ApplicationKit implementation into two parts; a front-end and a back-end. The front-end would be independent of the graphics display system, so it would only implement behavior without performing any display operations. The back-end would be specific to a graphics display system and it would only need to perform the display operations for that graphics display system. The front-end is called the GNUstep GUI Library. The backend is called, simply, the GNUstep Backend.
You can get more detailed and technical information about the GNUstep implementation at the Developer Suite page.
Beyond OpenStep
While implementing a free software version of the OpenStep specification is a great idea; GNUstep is growing beyond this initial task to become a powerful development environment and a sophisticated user environment.
The GNUstep Database Library and The GNUstep 3D Kit are examples of two auxiliary projects that take OpenStep as the base API for extending into other areas; the former into database programming and the latter into 3D graphics.
More and more
A number of people and institutions are helping in this project.
But there are even more efforts which might be of interest to everybody who likes the GNUstep idea. A bunch of them is listed on our Resources page.
OpenStep compliance
The motivation behind GNUstep is to make porting our applications easier, to leverage the benefits of the Objective-C language, and to push the idea of OpenStep as a common object oriented API; especially on systems which are not covered by commercial implementations of this standard.
Our Time frame
Most GNU projects have no real time frame since all development is done for free. The current team is very interested in pushing the project ahead but "time" and "space" will remain limited. So if things are moving too slow for you... join and help us!
There's quite a few Cocoa Java apps out there, and some seem quite good... but I've found that I'm using very few of them... probably due to the fact that I'm a low-end Mac user. Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030). Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.
On faster machines I'm sure it's a lot better, and I would assume that they'd run under native Java on Intel rather than adding Rosetta's overhead to the devilish mix, so I doubt that performance is a direct issue for Apple. But the lack of adoption of Java by users could be.
And of course there's a huge difference between the object models of Java and Objective C. Unlike languages like F-Script, I doubt that it's just a matter of translating the calling mechanism, so I suspect maintaining the interface has been pretty labor-intensive.
As for Swing, what does that do to the native look and feel? What's an example of an application that uses it that I can try on Mac OS X?
It's just because maintaining it is too much work considering how few people use Cocoa-Java.
Java itself will still be available.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
On the plus side, this hopefully means that there's some really good things coming out for Cocoa/Objective-C which simply aren't able to be duplicated in Java without significant effort or sacrifices in speed. Certainly Java compatibility won't be a potential hinderance anymore.
I thought that NeoOffice/J used Java to integrate with the OS X GUI, providing a Java layer for the OpenOffice innards to paint the screen through.
Or is this announcement something similar to the recent pronouncement that with 10.4, APIs were frozen, so developers would no longer have to target a morphing platform?
I believe that either the same or a similar situation exists with Camino.
It might be that Apple on Intel is a little to close to the Sun on Opteron workstation market for Sun's liking
Not likely.
Apple and Sun are really in two very different market segments.
Sun has really cool hardware tricks that make their servers popular. Apple has really cool software tricks that make their Desktops popular.
People are not likely to switch from Apple to Sun or vice-versa in any major numbers. The Apple folks and Sun folks are coming from very different perspectives.
What this is is nothing to do with Sun/Apple relationship. It's just that there are newer, better ways to do this, so Apple is not going to continue to add new features to the old API when they really want developers to move on to the new one.
... given the ongoing hardware switch - just think about it.
:P
JavaCocoa was _the_ way for a new app to use Cocoa, avoiding the universal binaries - getting and testing on a second platform - thingie.
Of course if you get your app right, universal binaries are OK, and there's no need to test on both plaforms... though if you always got it right the first time, there'd be no point testing at all...
Cocoa-Java apps are _not_ cross-platform. About the only advantages I could see getting from it is not having to make your developers learn Objective-C and being able to work in a garbage-collected environment.
But I don't think either of those advantages are great enough to make it worth Apple's while to spend money on maintaining Cocoa bindings for Java. Objective-C is really not difficult to learn, and has plenty of syntactic sugar to keep you happy - especially if you're using Apple's runtime. And reference counting isn't perfect, but it's also almost brainless to use after a few days of really getting used to it.
Much better in my opinion for Apple to put their Java efforts into trying to keep the JRE on OS X up to date, and possibly to put a bit more effort into getting it to run well.
Anyone else see a contradiction in that statement, or is it just me?
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
If there's really demand for Java support of new OS X features, someone else can write a bridge for it- how to do this is well understood. There are already third party Cocoa bridges for Python, Ruby, and Perl.
This is really a shame, it is cool how fast you can throw together a decent app using java.
Frozen Java. I love ice coffee...
(ducking from flying tomatoes)
I might know what I'm talkin' about, but then again, this is Slashdot...
you should have listened to Aaron Hillegass IMO :p
The bits on the bus go on and off... on and off... on and off...
Yaz, javaxman, I believe what Geek Dash Boy was trying to explain is that accessing Java from Objective-C and Cocoa-Java are different things. In that regard he is correct. Specifically, what Apple's documentation is refering to that will not be enhanced in the future are the classes and interfaces that are in com.apple.cocoa package. Cocoa-Java in this context refers to the Java interface to Cocoa, -not- the Cocoa interfaces to Java which will continue to be maintained/enhanced.
... at least, I think so :) Certainly makes the most sense to me given the context of the comment and the history of the Java and Objective-C bindings.
Yaz, in your case, where you have an existing Java library that you want to call from a native Cocoa application, that will continue to work just fine in the future. You'll just have to write the Cocoa parts in the native Objective-C Cocoa APIs. To access your native Java code you'll use the Objective-C/Java bridge directly. Have a look at NSJavaObjectNamedInPath() and NSJavaSetupVirtualMachine().
Does that make any more sense? You know that the com.apple.cocoa classes are mostly just bridged to the Objective-C implementation, right? So it's possible that Apple will add methods or classes to the Objective-C implementation and not update the com.apple.cocoa Java bindings, right? That's all the Apple documentation was referring to.
It's my opinion that a CPU-intensive Java application on Intel or AMD will almost always smoke SPARC by a major factor. (I work for BEA, but I don't speak for them.)
For thread/throughput intensive applications, SPARC may win vs. P4 or Xeon (especially the multi-core SPARC models), but against Opteron or Itanium it's probably going to be a wash.
Generally we look at SPEC benchmarks when capacity planning, there is no inherent CPU advantage on the Sun JVM on Intel vs. Solaris (though the Solaris VM does have extra memory options like using Intimate Shared Memory which can be a benefit for large heap garbage collection).
And then there's our JRockit VM which only runs on Intel and it's been known to be extremely fast... though we're eventually going to port it to other chip architectures.
-Stu
Swing isn't nearly high-level enough to create a single interface which works well everywhere. It'll always end up seeming odd on everything other than your primary platform, with buttons not in the conventional places and menus with unusual captions.
I think it's far better to implement a portable core and then build several user interfaces atop it. That way your UI can be made specifically for each platform and the user experience will be much improved. Of course, you can also write a Swing UI to handle the stuff you don't support directly. If you design it right, the platform-dependent GUI code should be minimal.
dont give a damn anyway.. java doesnt do it for me.
Apple has long struggled to deliver a first class Java implementation. There Java version is always 6-12 months behind the release from Sun. They do not have a -server option which is what most application servers use.
JBuilder 8 and 9 were not available for Mac because the Java was too broken.
Java 5 is not available in auto update but is a separate download. It does not some with the src.jar or the javadoc. At the moment you need to copy those missing files from the Linux version.
Java was missing from the 200 new features in Tiger, although they could have included Java 5.
So, this announcement is more of the limited support for Java that Apple has been giving us for a long time.
Isn't NeoOffice written in Cocoa/Java? Quite an important application for Mac OS X for some...
The Java version of Cocoa was never very well supported (lots of features not available) and the documentation always sucked. Plus, it was hard to use, as Java and ObjC have a lot of big differences which made using Cocoa APIs from Java very awkward. You pretty much had to learn the Objective C version of Cocoa first anyway, before trying to use the Java version, in order to really get it. And at that point you might as well just write your program in Objective C. (Unless you were just trying to put a native interface on top of existing Java code.)
Also, Cocoa and Carbon have yet to reach feature parity ... when you complain, Apple will just tell you to call the Carbon API, which of course you can't do from Java. So in addition to Cocoa features which weren't available in Java, there were plenty of things which aren't in Cocoa yet and were thus not available to Java.
The Java version of Cocoa was never terribly popular, because it was weird, hard-to-use, lacking features, and most Java programmers want to write platform-agnostic code anyway. (Although for any real application you have to, as Mac users tend to expect a GUI which matches the Aqua Human Interface Guidelines.)
Apple would be better off promoting the Python-ObjC bridge, PyObjC. (Or Camelbones for Perl). Python and Perl fit into the Cocoa model much better than java.
Of course, Apple needs to continue to improve their Java environment, with improved Swing support, and perhaps some new com.apple.swing.* classes to add some of the additional Cocoa widgets to Swing.
I'm guessing Apple dropped it because too few people were using it, and it was just too hard to support. (The big differences between ObjC and Java [such as memory management, and the whole late binding thing which makes ObjC so fun] made it a lot of work to expose Cocoa APIs in Java, and in some cases were really ugly and difficult to use as a result.) Also, future integration between Cocoa and Carbon (I want to see HIView and NSView cooperate in a single window, damnit!) may have further complicated things.
-- Tim Buchheim
Is Apple having problems with Sun over Apple's transition to the Intel platform?
No way. Sun doesn't have the luxury of snubbing anyone who wants to ship Java with their products.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
So what you're saying is that it's an IceCap. mmm. IceCap http://www.timhortons.com/en/menu/menu_products.ht ml
Having to take these extra steps defeats the object of a cross-platform UI library. The library should be handling this stuff.
Maybe they need to provide Java bindings for Tk, because it does a pretty good job of providing a compatible look and feel on any platform, including automatically putting the menu bar in the right place on Mac and Windows.
After upgrading, Cocoa apps have individual characters popping up in shadowed yellow boxes, as if I have moused over a button and a description popped up. It's very strange and very annoying.
(%i1) factor(777353);
(%o1) 777353
I don't give a damn