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?"

Comments

What does this mean for WebObjects?

[Millennium]

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?

Re:What does this mean for WebObjects?

[Feral Bueller]

"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?"

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.

This only affects one app that I use...

[Teancom]

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 :-)

Probably not a big deal

[jtshaw]

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.

To clarify...

[Otter]

After reading the comments at MacSlash, I figured it's worth clarifying here -- this has nothing to do with cross-platform Java applications (i.e. what "Java support" normally means). What's being pulled is the ability to write to the native Cocoa API in the Java language.

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.

Apple has been advising against integration for so

[Hungus]

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.

Ob Homerism

[NiceGeek]

Mmmmmmmmm...frozen Cocoa Java

How?

[hargettp]

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.

Re:Java scares the crap out of people!

[Quarters]

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?

To put this in perspective:

[tod_miller]

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.

C++ is not a replacement

[mariox19]

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?

[TheRaven64]

Why was anyone using it in the first place?

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.

Jonathan Schwartz ramblings

[joshstaiger]

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/

Re:You are completely wrong

[Yaztromo]

Mod the parent down. It's not "Informative", it's "Misleading"

That's better advice for your response, as opposed to the grandparent post.

The Java platform (i.e. java.lang.*), never enters into it.

That's not true. All of the java.lang.* classes are available. In fact, you can even make calls to javax.swing.* classes (although you have to be really careful in terms of event threads, so it's dangerous to do so). Cocoa-Java still uses java.lang.Class, java.lang.Object, java.lang.String, java.lang.Classloader, and any of the other java.lang classes.

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.

That is also not true. Cocoa Java bundles include the JAR files for their Java components. Only a small stub is compiled natively. Just view the package contents of any Cocoa Java application and you'll find the JAR file. Or build a Cocoa Java application in Xcode, and see something like the following in the build log (with lots of snippage...):

JavaCompile.default Cocoa blah.app
frameworkjars=""
for i in `echo /System/Library/Frameworks/Cocoa.framework/Resourc es/Java/*.jar /System/Library/Frameworks/Cocoa.framework/Resourc es/Java/*.zip ` ; do if [ -f "$i" ] ; then frameworkjars="$frameworkjars":"$i" ; fi ; done
classpath="/blah:"`/usr/bin/javaconfig DefaultClasspath`
/usr/bin/javac -J-Xms64m -J-XX:NewSize=4M -J-Dfile.encoding=UTF8 -g -encoding MACINTOSH -sourcepath ...

Sorry, but you're talking out of your ass, and have no idea what you're talking about.

Yaz.
(Cocoa-Java Developer).

Third party bridge

[Have Blue]

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.