Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming Businesses OS X Operating Systems Apple

Apple Freezes Java Support for Cocoa 154

Posted by timothy from the like-a-moolatte dept.
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?"
This discussion has been archived. No new comments can be posted.

Apple Freezes Java Support for Cocoa More

Apple Freezes Java Support for Cocoa

Comments Filter:

  • Toolkits (Score:3, Interesting)

    by yasth ( 203461 ) on Monday July 11, 2005 @03:23PM (#13035681) Homepage Journal
    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.

    • How? (Score:5, Informative)

      by hargettp ( 74445 ) * on Monday July 11, 2005 @03:56PM (#13036001)
      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 registers "Numbers".
      Cocoa Java frozen.

      I have to wonder how will this affect the OpenOffice.Org port NeoOffice/J.

  • What does this mean for WebObjects? (Score:5, Interesting)

    by Millennium ( 2451 ) on Monday July 11, 2005 @03:24PM (#13035692)
    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?
    • Let's hope so.
    • I don't think this means anything for WebObjects. The announcement was very specific to the Cocoa-Java interface post-10.4 and nothing else.

      This doesn't mean Apple doesn't want you using Java, it means they don't want people using Java for Cocoa applications after 10.4.

    • Re:What does this mean for WebObjects? (Score:5, Insightful)

      by Feral Bueller ( 615138 ) on Monday July 11, 2005 @04:15PM (#13036222) Homepage
      "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.

      • Re:What does this mean for WebObjects? (Score:4, Informative)

        by Yaztromo ( 655250 ) on Monday July 11, 2005 @06:22PM (#13037427) Homepage Journal
        I'd be interested in hearing from an actual developer who *is* impacted by this.

        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.

        • I think that you are fairly safe. Apple has mearly announced that they are not going to produce new bindings for anything after 10.4. They have not marked them depreciated in 10.4 (even then the old bindings would still work), so you have at least through 10.5, and quite likely through 10.6 until your apps are no longer supported. You might even make it to 10.7...

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

          Ok, then write the controller part of the app using Objective C, and keep the model in Java. Problem solved. If you need some help

        • My guess is the Java/ObjC bridge will continue to be supported, it's just that new Cocoa-Java apps won't have bindings to any new appkit classes. The bridge is still needed for Cocoa/EOF apps, since all of EOF is now written only in Java. And Cocoa/EOF is so much better than Java Client apps, even with the overhead from the bridge. They don't need a WO server and the interface and logic can all be written in ObjC, you just call the EOF stuff from ObjC.
      • I'd be interested in hearing from an actual developer who *is* impacted by this.

        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: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • This only affects one app that I use... (Score:5, Interesting)

    by Teancom ( 13486 ) <david&gnuconsulting,com> on Monday July 11, 2005 @03:24PM (#13035695) Homepage
    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 (Score:5, Informative)

    by jtshaw ( 398319 ) * on Monday July 11, 2005 @03:27PM (#13035719) Homepage
    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... (Score:5, Informative)

    by Otter ( 3800 ) on Monday July 11, 2005 @03:28PM (#13035737) Journal
    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.

    • With the Aqua LAF for Swing having Cocoa available through Java doesn't do anyone much good. With a very simple "am I running on a Mac? [java.net]" if statement you can turn on the Aqua LAF and have a JMenuBar become the application's Mac menu bar. While being able to build a Java GUI in Interface Builder is nice it isn't something a whole lot of people are doing.

      The biggest issue is in order to write Cocoa applications using Java you have to learn Cocoa. If you're going through that effort it is a lot simpler to spe

      • Re:To clarify... (Score:4, Insightful)

        by Yaztromo ( 655250 ) on Monday July 11, 2005 @04:36PM (#13036419) Homepage Journal
        The biggest issue is in order to write Cocoa applications using Java you have to learn Cocoa. If you're going through that effort it is a lot simpler to spend the two days learning Objective-C and getting used to retain counts. You'll find there's a lot more support and documentation than writing Cocoa apps in Java.

        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.

        • Exactly how hard would it be to develop a Cocoa-Java bridge? If only to add extra features from Cocoa or even Carbon? I know Java can call C, so it can't be that hard, can it? Surely no worse than what went into the Cocoa-Python bridge.
          • Exactly how hard would it be to develop a Cocoa-Java bridge?
            Ask Apple, they already built that bridge, years ago (since like WO 4.5 IIRC). You use it when you write Cocoa/EOF apps, but I suppose you can use it in other types of apps, like this situation where you have a large codebase in Java and just want to use it from a Cocoa app.

            Or, you can write a Swing or SWT app instead of using Cocoa/ObjC.

    • Re:To clarify... (Score:4, Insightful)

      by Feral Bueller ( 615138 ) on Monday July 11, 2005 @04:37PM (#13036433) Homepage
      This does significantly raise the barrier of entry for hobbyist coders, though. Seems like a typical Apple decision, certainly.

      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.

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

        And therefore eliminating the Java option raises the barrier to entry for Cocoa! We're basically agreeing, so I don't understand what you're objecting to.

        Macslash makes PowerPage seem like ArsTechnica.

        Well, these days Ars Technica seems a lot like Slashdot [slashdot.org]...

      • AppleScript and Perl generally are [the traditional point of entry for a hobbyist coder]

        Is Perl really the hobbyist point of entry? Why?

        I am, for all practical purposes, a Perl fanatic. I love the language. The combination of power and breaking all "normal" language rules is, in a word, fun!

        But to really learn the culture etc, was more work than when I learned assembly (68k, regular though) and C in the .. hrm, let us say -- a long time ago.

        The disadvantage to Wall's linguistic influences i

        • Is Perl really the hobbyist point of entry? Why?

          I think you answered your own question in the next paragraph....

          I am, for all practical purposes, a Perl fanatic. I love the language. The combination of power and breaking all "normal" language rules is, in a word, fun!

          But to really learn the culture etc, was more work than when I learned assembly (68k, regular though) and C in the .. hrm, let us say -- a long time ago.

          If you mean a long time ago, Perl wasn't even an option. Also note that I'm talkin

    • History reconstructed (maybe) (Score:4, Insightful)

      by fm6 ( 162816 ) on Monday July 11, 2005 @06:43PM (#13037601) Homepage Journal
      Good idea? As far as large software makers go, it probably doesn't matter. Adobe's Mac developers have all learned Objective C already.
      When I interviewed at Apple in 97, the party line was that Java was going to replace Objective C as the standard language for accessing the NeXTSTEP APIs. But some of the NeXTSTEP people who came over to Apple after the buyout seemed less than convinced.

      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.

      • Re:History reconstructed (maybe) (Score:4, Interesting)

        by metamatic ( 202216 ) on Tuesday July 12, 2005 @10:16AM (#13041855) Homepage Journal
        When I interviewed at Apple in 97, the party line was that Java was going to replace Objective C as the standard language for accessing the NeXTSTEP APIs.

        Yeah, well, it's worth remembering that back in 1997, Netscape's new browser was going to be written in Java, Corel were going to sell an office suite written in Java, and everyone was going to run 'thin client' systems based on Java. The great Java hype machine was just winding down.

      • Comment removed based on user account deletion
        • Language features are kind of beside the point. The whole Java strategy was based on the assumption that programmers would slap themselves on the forehead and say, "Java is so much better! Why am I wasting my time on C++/Visual Basic/Fortran/Whatever?" Even if Java had had all the features that people wanted (and the whole point of Java was to resist feature bloat!), they still would have been reluctant to abandon familiar tools.

          Microsoft must have had that in mind when they decided that .NET would suppor

  • Apple has been advising against integration for so (Score:4, Interesting)

    by Hungus ( 585181 ) on Monday July 11, 2005 @03:31PM (#13035762) Journal
    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.

  • What about SWT? (Score:2, Interesting)

    by chroot_james ( 833654 )
    I wonder how this effects swt or if swt can provide similar functionality to java-cocoa?

    • Re:What about SWT? (Score:3, Informative)

      by Anonymous Coward
      Apple is currently porting SWT to cocoa (SWT is currently based on carbon). I wouldn't be surprised if thats why Apple's doing this. If you want to use native cocoa, SWT is the roadmap.

  • Ob Homerism (Score:5, Funny)

    by NiceGeek ( 126629 ) on Monday July 11, 2005 @03:53PM (#13035962)
    Mmmmmmmmm...frozen Cocoa Java

  • Its really not a big deal (Score:4, Insightful)

    by PierceLabs ( 549351 ) on Monday July 11, 2005 @03:59PM (#13036032)
    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.

  • swt (Score:3, Insightful)

    by jandockx ( 561203 ) on Monday July 11, 2005 @04:19PM (#13036281)
    As long as they would now commit those resources to swt support on Mac OS X, this would actually be a Very Good Thing ...
  • NeoOffice/J [planamesa.com] is the port of OpenOffice.org to MacOSX [openoffice.org]. It does make full use of the Java Cocoa interface.

  • To put this in perspective: (Score:5, Insightful)

    by tod_miller ( 792541 ) on Monday July 11, 2005 @04:44PM (#13036502) Journal
    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.
  • I don't understand why anyone cares about the end of Cocoa-Java support in the first place. Why was anyone using it in the first place?

    Java is a good language but restricting it to Cocoa destroys the cross-platform compatibility, which is pretty much why you'd use Java in the first place. I would understand if Cocoa were garbage and the Java class library was needed as an alternative, or if Objective-C were a complicated language to learn. But Cocoa is a great API and Objective-C is just a small and ele

    • Re:Why did anyone use it in the first place? (Score:5, Insightful)

      by TheRaven64 ( 641858 ) on Monday July 11, 2005 @05:34PM (#13036936) Journal
      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.

    • "I don't understand why anyone cares about the end of Cocoa-Java support in the first place. Why was anyone using it in the first place?"

      I've no idea. I think it was created because Apple was concerned that Objective-C would be too alien and would be rejected. So they created Cocoa-Java, sort of a comfy security blanket insulating the programmer from Objective-C.

      Around the time of the Apple/NeXT merger, there was even some thought given to redoing Objective-C to have a Java-like syntax. Thankfully, they d
      • But maintaining Cocoa-Java means they need to create a Java facade for the Objective-C APIs, and they need to create Java equivalents for C constructs and Objective-C Categories which don't quite map cleanly onto Java.

        Exactly. It's much easier for Objective-C to call Java than vice versa because all ObjC method calls are resolved at runtime. (Which allows an ObjC proxy object to take the invocation and transparently forward it to a Java object). Note that more dynamic languages can be better integrated w
      • Comment removed based on user account deletion

  • Not a big deal (Score:3, Informative)

    by SteeldrivingJon ( 842919 ) on Monday July 11, 2005 @04:51PM (#13036577) Homepage Journal

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

  • Bad for Cocoa-Java... very few give a damn anyway. (Score:4, Insightful)

    by javaxman ( 705658 ) on Monday July 11, 2005 @05:01PM (#13036689) Journal
    If you don't know what Cocoa-Java is, it's a way of gluing a Cocoa native interface onto a Java bytecode program. I suppose the idea is that you have a Java application, for portability, but don't want a Swing UI ? That description is a little simplistic, really, but it's the general concept.

    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.

    • If you don't know what Cocoa-Java is, it's a way of gluing a Cocoa native interface onto a Java bytecode program.

      no, no, no. Cocoa-Java is a way to write native Mac OS X applications using the Java programming language. The Java platform (i.e. java.lang.*), never enters into it.

      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.

      Reading articles such as t [apple.com]

      • Re:You are completely wrong (Score:5, Informative)

        by Yaztromo ( 655250 ) on Monday July 11, 2005 @07:46PM (#13038042) Homepage Journal
        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).

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

        Look, I don't want to make you sound silly, Yaztromo already did a fine job of that [slashdot.org], but when Apple says that the Cocoa-Java NSObject [apple.com] "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 [apple.com] 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

    • There's quite a few Cocoa Java apps out there, and some seem quite good... but I've found that I'm using very few of them... probably due to the fact that I'm a low-end Mac user [lowendmac.com]. Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030). Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.

      On faster machines I'm sure it's a lot better, and I would assume that they'd run
      • Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030).

        You're right there- if you're running on a machine with a non-hardware-acceleration graphics card, you really do need to try the turn-off-the-eye-candy tricks ( disable bouncing dock icons, window and sheet effects, etc ), and if you're on an early G3, ouch. Tiny delays imposed by Objective-C message passing are just that- tiny.

        Java just gave it that little extr

        • There are a few things you can do in Java to make your app look more like a real OS X app, though- use a screen ( instead of window ) menu bar, have Apple UI-compliant menus, support the Application menu commands ( about, preferences, quit )... that takes a small amount of actual code, but there are plenty of apps out there that just don't take that extra step.

          Having to take these extra steps defeats the object of a cross-platform UI library. The library should be handling this stuff. If it can't, then

          • Having to take these extra steps defeats the object of a cross-platform UI library. The library should be handling this stuff.

            Maybe they need to provide Java bindings for Tk, because it does a pretty good job of providing a compatible look and feel on any platform, including automatically putting the menu bar in the right place on Mac and Windows.

  • Jonathan Schwartz ramblings (Score:4, Funny)

    by joshstaiger ( 213677 ) on Monday July 11, 2005 @06:52PM (#13037666) Homepage
    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... [sun.com]

    Shocking, I know.

    Oye vey...

    --
    http://joshstaiger.org/ [joshstaiger.org]
  • I thought that NeoOffice/J used Java to integrate with the OS X GUI, providing a Java layer for the OpenOffice innards to paint the screen through.

    Or is this announcement something similar to the recent pronouncement that with 10.4, APIs were frozen, so developers would no longer have to target a morphing platform?

    I believe that either the same or a similar situation exists with Camino.

  • Never saw the point (Score:3, Insightful)

    by Bastian ( 66383 ) on Tuesday July 12, 2005 @02:03AM (#13039740)
    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.

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

      C# anyone?

      Interface Builder/Obj-C/Cocoa's supposed advantage is building first-class applications (native look-and-feel) in a "modern" environment (not raw C with Pascal-interface APIs).

      "Modern" (moving away from the solution domain towards the problem domain and letting the coder ignore details like memory management that the computer

      • "Modern" (moving away from the solution domain towards the problem domain and letting the coder ignore details like memory management that the computer can handle itself) is evolving to mean garbage collection, dynamically typing and higher-order functions for some people.

        I would argue that Objective-C has a higher overall score for those three features than Java. But moving on, if I were looking for a truly high-level language for my app development (which I am), I wouldn't want ObjC or Java. ObjC is n

  • Third party bridge (Score:5, Informative)

    by Have Blue ( 616 ) on Tuesday July 12, 2005 @09:18AM (#13041359) Homepage
    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 [sourceforge.net], Ruby [sourceforge.net], and Perl [sourceforge.net].
  • This is really a shame, it is cool how fast you can throw together a decent app using java.
    • Most decent apps that could be thrown together because of the Cocoa framework can still be thrown together in Objective-C, and most that could be thrown together because of the Java frameworks can still be thrown together in the same way.

      When Java was fresh on my memory, I tried to write a Cocoa-Java app to learn Cocoa. The Java parts weren't hard, but few Cocoa frameworks are available because there's sizable effort in making your frameworks work with Cocoa-Java. I ended up having to learn Objective-C and
  • Frozen Java. I love ice coffee...

    (ducking from flying tomatoes)
  • you should have listened to Aaron Hillegass [bignerdranch.com] IMO :p

  • The Java version of Cocoa was never very well supported (lots of features not available) and the documentation always sucked. Plus, it was hard to use, as Java and ObjC have a lot of big differences which made using Cocoa APIs from Java very awkward. You pretty much had to learn the Objective C version of Cocoa first anyway, before trying to use the Java version, in order to really get it. And at that point you might as well just write your program in Objective C. (Unless you were just trying to put a

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close