Apple Freezes Java Support for Cocoa 154
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?"
Re:What does this mean for WebObjects? (Score:2, Insightful)
This doesn't mean Apple doesn't want you using Java, it means they don't want people using Java for Cocoa applications after 10.4.
Re:Java scares the crap out of people! (Score:4, Insightful)
Re:Java scares the crap out of people! (Score:4, Insightful)
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.
Re:Java scares the crap out of people! (Score:3, Insightful)
Its really not a big deal (Score:4, Insightful)
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.
Re:What does this mean for WebObjects? (Score:5, Insightful)
Not. Really. It indicates that Apple wants you to use Java for Web services and Objective-C for applications. As previous poster already mentioned they are merely killing support for the Cocoa-Java API so I don't see there being much of an issue: I worked on a number of custom OS X apps at my last gig: this announcement would not have influenced any of our projects then and certainly wouldn't impact anything moving forward.
I'd be interested in hearing from an actual developer who *is* impacted by this.
swt (Score:3, Insightful)
Re:To clarify... (Score:4, Insightful)
This line of reasoning bugs me, because it presupposes that you're building an application from scratch.
However, what if you have a large and specialized existing Java library that has taken years to write and has been very strenuously tested, and want to use it inside a Cocoa application? Cocoa-Java was excellent for this -- it took me less than an hour to build a Cocoa interface atop such a Java library, giving me much better integration with OS X's UI than Swing with an Aqua L&F ever would, with a lot less coding.
Yes, if you're building an application from scratch, Objective-C is a better option (I've developed some Obj-C Cocoa applications as well). But if you have an existing library which has taken you years to write in Java, why would you want to re-do all of that work in Objective-C, when you can just use Cocoa-Java?
I'm hoping we few of the Cocoa-Java community can convince Apple to release the Cocoa-Java framework to the Open Source community so we could contain to maintain and update it. The only consoltaion I'm gaining from the current "announcement" (if you can call it that) is that it looks like future versions of OS X will support Cocoa-Java -- they just won't be adding anything new to Cocoa-Java past 10.4. So at least my existing Cocoa-Java application (which is only in limited release at the moment) won't be completely obsolete the day it is released.
Yaz.
Re:To clarify... (Score:4, Insightful)
How?
Objective-C is not the traditional point of entry for a hobbyist coder... AppleScript and Perl generally are. If I was going to recommend a programming language for such a person, it would be Java, on the strength of the API documentation alone, but certainly not Objective-C.
Who reads macslash anyway? Their headline for this article is Apple: You Can't Develop In Java Anymore , which besides being inflammatory is incorrect.
Macslash makes PowerPage seem like ArsTechnica.
To put this in perspective: (Score:5, Insightful)
+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.
Bad for Cocoa-Java... very few give a damn anyway. (Score:4, Insightful)
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.
C++ is not a replacement (Score:4, Insightful)
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.
Re:Why did anyone use it in the first place? (Score:5, Insightful)
I can think of one reason for using it. If you have an existing Java application and want to release if for the Mac, it makes a good choice. If you run a Swing or SWT Java app on OS X without any changes, it will look native, and it will almost feel native, and that almost is enough to really irritate users (including me). Replacing the original GUI with one drawn in IB (so you get the HIG spacing guide lines) and with controllers written in Java as a thin wrapper around the existing model code would be a significant benefit in terms of usability.
No, actually, it won't bother many developers (Score:2, Insightful)
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.
History reconstructed (maybe) (Score:4, Insightful)
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.
Re:You are completely wrong (Score:3, Insightful)
Look, I don't want to make you sound silly, Yaztromo already did a fine job of that [slashdot.org], but when Apple says that the Cocoa-Java NSObject [apple.com] "inherits from Object", exactly what "Object" class do you think they're talking about ?
Hint : it's in the package you don't have to import in the Java language.
Further hint: NSObject [apple.com] in Objective-C ( native Cocoa as opposed to Cocoa-Java, I suppose ) doesn't inherit from anything else, it's a root class.
It's hard to blame you too much for your misconceptions about Cocoa-Java, though, if you're using the Apple "Cocoa Tutorial for Java Programmers" you linked as your guide. I think they're almost intentionally misleading you there... notice there's actually no talk at all of what compiler is being used or what's going on behind the scenes ( it's javac ). Really, Cocoa-Java, IMHO, is there to lure Java programmers into Cocoa. It's a hook to get you to see how easy Objective-C really is...
Basically, there are enough application developers for OS X that Cocoa-Java serves no real purpose now. Just my own little theory, that.
Never saw the point (Score:3, Insightful)
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.
ID-10-T Error (Score:3, Insightful)
Comment removed (Score:3, Insightful)