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?"
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 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'd say that any app that uses Cocoa, regardless of whether it is written in Obj-C or Java, is pretty hard to port to any other platform.
Oh, so that's the burning smell I suddenly noticed.
Discussion System prefs link: http://slashdot.org/users.pl?op=editcomm
I wonder how this effects swt or if swt can provide similar functionality to java-cocoa?
Reality is nothing but a collective hunch.
Note: Java is not being removed from OSX. It is just that you would not be able to access the OSX api from Java... which would mean your applications are not cross platform in the first place. You'll still be free to develope 'pure Java' Applications... so your comment about Apple wanting to kill Java doesn't follow.
Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant.
Ok... now tell me how supporting java applications, including cross platform applications, but dropping cocoa bindings (largely irrelevant or even a hindrance to cross-platform java applications) is indicative of Apple being scared that java will enable people to move away from their platform? They are freezing support for cocoa bindings, not the java API in general.
One of the main reasons I prefer OS X over most other platforms for most tasks is all the added benefits from the OS. The system services that are usable across all applications, for example, like the spell checking in this text field (and all other native text presented by applications and the OS). Cross-platform apps and java apps are weak because they have to reinvent the wheel for everything every time because they can't count on the OS offering all the useful features. It's fine for little games and whatnot, but for the most part, it is just not as good.
Mmmmmmmmm...frozen Cocoa Java
Cocoa is OS X only. Apple is ending Java support for Cocoa. Java Cocoa applications run only on OS X. Any OS X apps written in Java in the future will now be more likely to be regular, cross-platform Java apps. I wouldn't be surprised if Java Cocoa applications were harder to port to GNUstep than Objective-C applications. How does Apple discontinuing a specific closed platform choice (which was never very popular in the first place) constitute trying to force people to use a closed platform?
English is easier said than done.
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.
Huh.
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.
Did you just get off the boat from 1996 or something?
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
Nothing's being removed, including the ability to compile Cocoa/Java apps. They just won't be adding any new features to the C/J API; even features that are available to C/oC. All this means is that if Apple decides to add a hook for something like kCOM to Cocoa, Java-based apps won't be able to access this information.
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?
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.
No,
signed
Everyone
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/
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?
Whew, you saved my life ! Dam, I wouldn't go near the thing knowing what I know now.
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.
Here, I'll repost my response. It's already +5 Funny. Maybe I can double score on it.
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. Did you just get off the boat from 1996 or something?
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.
Objective-C _is_ portable, you idiot.
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
Apple is ending Java support for Cocoa.
s/ending/freezing/
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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."
Java scares companies like Microsoft and Apple because it has the potential to make their closed platforms irrelevant.
No, it had the potential to do so. They tried, and they failed. It was Game Over for Java as soon as you had to ask the question: "Which Java"?
-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