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?"
Probably not a big deal (Score:5, Informative)
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... (Score:5, Informative)
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? (Score:5, Informative)
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:What about SWT? (Score:3, Informative)
Not a big deal (Score:3, Informative)
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).
Re:This only affects one app that I use... (Score:3, Informative)
Re:What does this mean for WebObjects? (Score:4, Informative)
Hello! I'm here!
I'm doing some development using Cocoa-Java, and this could impact me, although as the information is extremely brief, I haven't figured out yet how or how much it will affect my work.
I'm in the situation where I already have a very large Java library which was written on other platforms (which has taken ~8 man-years of development effort, and has been heavily debugged and tested int hat time), but works flawlessly on OS X. The Swing application built atop it works on OS X, but many portions of its basic design don't work too well on OS X in terms of UI integration (it works, but it really looks like it was designed for another platform).
As such, to better support the Mac community, I decided one evening to create a Cocoa version using Cocoa-Java. It took me only about 2 hours of effort, and I had a native Mac version of my application that looks and acts like an OS X application, supporting all of the standard OS X controls and menu items.
Yes, Apple says I should just use Objective-C, but honestly I have years and years worth of work that has been put into the Java library and engine code. It's completely multi-platform, and is used on multiple platforms. Rewriting it in Objective-C isn't feasible from either a time standpoint, or from a platform availability standpoint (even if I did have years to rewrite and retest all this code in Objective-C, it would then only compile and run on OS X, and perhaps Linux if I was very careful). So it's not going to happen.
As such, I'm quite possibly impacted by this decision. However, the wording of the "annoucement" leaves much to be desired. Presumably based on their wording, they aren't dropping Cocoa-Java completely -- only that new Cocoa features won't be bridged. The GUI needs for my application are well served by the existing Cocoa-Java bindings, so if Cocoa-Java continues to be installed as a part of OS X, at least my application won't be unusuable before it is released to the public.
I am a bit surprised in some ways, however. With the announcement a few weeks ago of the move to Intel-based processors, I thought they might actually work to improve Cocoa-Java, due to its immediate cross-platform benefits (although Xcode 2.1 won't generate Universal Binaries for Cocoa-Java projects).
I'm holding out hope that OS X 10.5 and 10.6 don't drop the existing level of Cocoa-Java support. To be honest, I don't expect every feature of Cocoa to be made available to Java (as it doesn't always make sense to do so), so not putting anything new in, while disappointing, doesn't bother me a whole lot. It's the concern that at some point in the next few years Cocoa-Java could be dropped altogether that worries me.
Yaz.
Re:What does this mean for WebObjects? (Score:3, Informative)
Re:You are completely wrong (Score:5, Informative)
That's better advice for your response, as opposed to the grandparent post.
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.
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...):
Sorry, but you're talking out of your ass, and have no idea what you're talking about.
Yaz.
(Cocoa-Java Developer).
Re:Toolkits (Score:3, Informative)
If you know C, a very small language, and are comfortable with objects, then you are an afternoon away from knowing Obj-C. The runtime delivers amazing flexibility, the reason why all the apps on OS X are so feature rich. The GNUStep implementation needs more, but is very powerful as is. It's a fabulous choice for a large system, where the "system" part is very important.
Again, the C to Obj-C transition is so easy that everyone who knows C should add it to their toolbox.
As I understand it, work on GNUStep themeing is coming along. I haven't checked it out in a while. The visuals really need freshening up.
Re:Where does this leave the NeoOffice/J project? (Score:4, Informative)
From the NeoJ Forum [neooffice.org]
The Java that's used within NeoJ is "pure" Java, AWT and Java 2D at present, and perhaps some Swing in the future. Anything that's using OS X specific frameworks is written in either C++ or Obj-C. Since the majority of the application is already C++ based, we just call the frameworks directly. There's no need for us to add an extra layer with the CocoaJava language bridge and never will be.
Re:What does this mean for WebObjects? (Score:3, Informative)
I am. We ship a commercial app for OS X which is Java/Cocoa. We wanted to have a good, native look and feel so we isolated the UI specific portions using a Model-View-Controller setup and have it running ontop of Cocoa and Swing. Swing does not provide a good enough Mac experience for a commercial app and SWT is not quite right either (the menu bar tends to go wonky, there's no support for sheets...)
Re:Toolkits (Score:3, Informative)
The Apple stuff [apple.com] is well done, and much applies to GNUStep. The Apple community is the most active, of course.
Third party bridge (Score:5, Informative)