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

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.

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