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?"
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.
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.
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.
- learn to swim.
As long as they would now commit those resources to swt support on Mac OS X, this would actually be a Very Good Thing ...
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.
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.
- learn to swim.
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
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.
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.
I am TheRaven on Soylent News
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.