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?"
While it may not seem like such a big deal it complicates crossplatform toolkits, and the like. Of course the whole idea of having a "blessed" programming language seems rather old fashioned, and academic.
I'd do something interesting, but my server can't handle a slashdotting.
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?
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 :-)
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.
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.
What I'm listening to now on Pandora...
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.
Bad Panda! No Bamboo for you! In matters of importance ACs will not be responded to. Want to say something critical,OK
I wonder how this effects swt or if swt can provide similar functionality to java-cocoa?
Reality is nothing but a collective hunch.
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.
Mmmmmmmmm...frozen Cocoa Java
Cocoa is OS X only. Apple is ending Java support for Cocoa. Java Cocoa applications run only on OS X. Any OS X apps written in Java in the future will now be more likely to be regular, cross-platform Java apps. I wouldn't be surprised if Java Cocoa applications were harder to port to GNUstep than Objective-C applications. How does Apple discontinuing a specific closed platform choice (which was never very popular in the first place) constitute trying to force people to use a closed platform?
English is easier said than done.
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.
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.
Did you just get off the boat from 1996 or something?
As long as they would now commit those resources to swt support on Mac OS X, this would actually be a Very Good Thing ...
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
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).
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
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.
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/
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).
From the NeoJ Forum
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.
Look, I don't want to make you sound silly, Yaztromo already did a fine job of that, but when Apple says that the Cocoa-Java NSObject "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 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.
Cocoa-Java apps are _not_ cross-platform. About the only advantages I could see getting from it is not having to make your developers learn Objective-C and being able to work in a garbage-collected environment.
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.
Anyone else see a contradiction in that statement, or is it just me?
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
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.
you should have listened to Aaron Hillegass IMO :p
The bits on the bus go on and off... on and off... on and off...