Home

News: Cocoa-Java Bridge collapse

  1. Cocoa-Java Bridge collapse (30 messages)

    OSNews has pointed out a paragraph in Apple's "Introduction to Cocoa-Java Integration Guide" that indicates that Cocoa 10.4 looks like the end of the road for Java/Cocoa integration.
    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.
    What do you think this means for future Apple Java implementations? With JDIC becoming increasingly capable and relevant on Windows, Linux, and Solaris, is the Mac becoming less relevant for Java? How might this affect serverside Java on the Mac?

    Threaded Messages (30)

  2. I don't think it should really affect *Server Side* java. Server side applications typically don't have a GUI which is what Cocoa is most useful for.

    If you really need to get at some low-level OS X stuff, you can still do it with JNI.
  3. Not an issue[ Go to top ]

    Just use SWT.
  4. Not an issue[ Go to top ]

    I don't mean to start a swing bashing thread here (even though I ahve never been a huge fan). I do think it is telling though that both Apple and IBM were so unhappy with Swing that they created seperate GUI toolkits for Java to make Java UI's more native looking. While SWT did not exist when Apple created OSX, I am guessing that they would have used SWT had it been an option.
  5. Not an issue[ Go to top ]

    Windows programming is now moving from C++ to C#.
    Like that, MacOS X Programming is moving from first Carbon & C++, and next Cocoa & Objective-C, and then to SWT & Java.
    Cocoa unsupporting Java is only just such movement, I beleive.
  6. Not an issue[ Go to top ]

    I don't mean to start a swing bashing thread here (even though I ahve never been a huge fan). I do think it is telling though that both Apple and IBM were so unhappy with Swing that they created seperate GUI toolkits for Java to make Java UI's more native looking. While SWT did not exist when Apple created OSX, I am guessing that they would have used SWT had it been an option.

    SWT was a short-term workaround for Swing issues back when it was originally created. Now there is little/no point to it. For instance, in Java 5, NetBeans is on par with Eclipse in terms of speed, looks nice, etc. Java 6 improves on this further tackling the last few Swing issues I'm aware of as compared to native widgets. Unless you're a full bore latest native widget biggot and could care less about cross platform consistency, SWT's time has past. [Not to mention the issues with deploying it, e.g. for use in applets...]

    Apple's bridge is an entirely different story, however. It was never meant as a replacement for cross-platform Java GUI APIs. Rather it was intended to allow you to do (nearly) full out native Mac OS X development via Java. This is more than just a GUI thing and has no intent to be cross platform. I always thought it was rather cool that Apple had this bridge allowing this option (and didn't arbritrarily remove Java features to try to lock developers into their platform ala Microsoft...)
  7. Not an issue[ Go to top ]

    There are valid options for GUI development for Macosx. With Java and without. No need for a Objective C Bridge, which takes away all advantages of Objective C. Stick to Objective C or yes if it has to be Java: SWT. Swing? What for? What's the payoff ... portability? Don't need Java for portability.
  8. Cocoa-Java Bridge collapse[ Go to top ]

    What do you think this means for future Apple Java implementations?

    They will use portable GUI systems like Swing and SWT.
    is the Mac becoming less relevant for Java?

    I would say not. After all, Apple are promoting Java as one of the major development systems to use on the Mac.
    How might this affect serverside Java on the Mac?

    Why should it affect server side Java at all?
  9. Native Cocoa only...[ Go to top ]

    Apple is only discontinuing the native Cocoa API. I've never even seen anyone use the native Cocoa API from Java. It's always been behind and missing pieces anyway. I'm sure they will continue to maintain the OS X Swing L&F.

    Also, the article said, "Cocoa applications," not all, "client applications," should be implemented in Obj-C instead of Java. If you use Java, you should use Swing or write your own JNI wrapper (which someone may do as they've already done for scripting languages).

    To the SWT fanboy, the SWT API sucks, though the implementation is pretty decent on Windows. The SWT implementation on OS X is horrid, so much so that I had to switch from Eclipse to IDEA (which uses Swing) on OS X.
  10. Not bad news[ Go to top ]

    Yeah, this isn't really bad news at all. Cocoa on top of Java never made much sense to anyone, including Apple, beyond an "isn't that nice" feeling. (An early, slow version of System Preferences was in Java, until it was rewritten in Obj-C.) If you're making an application in a Mac-only framework, it may as well benefit from native compilation and perfect framework-language integration.

    Now that Apple isn't wasting effort building a bridge nobody wants, perhaps they can devote more resources to improving standard Java on Mac.
  11. Native Cocoa only...[ Go to top ]

    The SWT implementation on OS X is horrid, so much so that I had to switch from Eclipse to IDEA (which uses Swing) on OS X.

    Same story for me, but I switched to Netbeans. JDeveloper seems to run fine on OSX too.

    I still use Eclipse on Windows, as it runs fine there.
  12. Native Cocoa only...[ Go to top ]

    The SWT implementation on OS X is horrid, so much so that I had to switch from Eclipse to IDEA (which uses Swing) on OS X.
    Same story for me, but I switched to Netbeans. JDeveloper seems to run fine on OSX too.I still use Eclipse on Windows, as it runs fine there.

    I would like to add a disclaimer to my statement:

    When I had problems with Eclipse on OSX I was using a later M build of v3. Things may be better with the offical 3.1 release, I have not tried since.

    ~Matt
  13. SWT still bad on Mac OS X[ Go to top ]

    Things may be better with the offical 3.1 release, I have not tried since.~Matt

    No, things are still horrible outside of windows, see

    http://www.coolandfriends.com/Eclipse_and_SWT.pdf

    Beside that, in the last 4 years with Java development on Mac OS X with Swing, I didn't even know there was a Cocoa bridge.
  14. things are still horrible outside of windows, see http://www.coolandfriends.com/Eclipse_and_SWT.pdf

    I read the PDF you link to, and found it quite not to the point. The PDF continues to put features of eclipse and IDEA next to each other and then claims that IDEA has done a better job. For instance the squigly line under an error in Eclipse versus rendering the identifier red in IDEA. I think this is a matter of taste and usability. Considering that 5-10% of all men are color blind, the squigly line actually is a better demarcation of a problem than making the identifier red.

    The document also fails completely to mention the quick fixes Eclipse has built in since 3.0. Etc.

    As far as developing applications using SWT versus Swing, I can't comment. I can imagine that the SWT support on other platforms is behind, as both the number of bugs reported and the number of affected users is relatively low when compared to the Windows platform. Which is a bad excuse though.

    Eclipse on Mac may not be completely bug free, but it is far from the 'horrible' experience you try to describe.
  15. SWT still bad on Mac OS X[ Go to top ]

    I wasn't impressed with the PDF, either. It failed to mention what I consider the biggest problem with Eclipse (and SWT in general) on Mac OS X. This bug:

    http://bugs.eclipse.org/bugs/show_bug.cgi?id=67384

    That one is a killer that pretty much breaks the cross platform promise of SWT. The short story is that you can't mix AWT and SWT on Mac OS X, which results in problems like all those RAD GUI-designer and graphic reporting tool plug-ins for Eclipse not working on Mac OS X. It's a direct result of SWT's approach (i.e. wrapping the native widgets instead of drawing its own lightweight ones), and it's not an easy problem to solve. SWT developers tend to point to Apple: "Hey, this works on Windows -- if Apple will change the OS to allow more than one thread to access the event queue the problem goes away". Apple just shrugs and says: "It's you're library -- not our problem".

    I think Swing has the better approach (i.e. lightweight widgets) for a cross-platform widget library.
  16. SWT still bad on Mac OS X[ Go to top ]

    Sorry to hear that, but the PDF was not written to impress you. I might have written different things if that would have been my intention.

    In the context of developing applications with SWT, I don't care if plugins work or don't work. But I care a lot if widgets work or don't, because I have to explain widgets which don't work to my customer. ("Well, I know this is in the requirements, but SWT on Mac OS just doesn't fire the right events." - "But it's in the requirements!" - "Well, I know this is in ...")

    And as long as Windows developers call SWT cross platform I have to deal with customers who want SWT cross platform solutions.
  17. SWT still bad on Mac OS X[ Go to top ]

    Sorry to hear that, but the PDF was not written to impress you.

    Aww, darn! There went my entire sense of self-importance, too. :)
    In the context of developing applications with SWT, I don't care if plugins work or don't work. But I care a lot if widgets work or don't, because I have to explain widgets which don't work to my customer.

    Often the same thing. My example of plugins was just an example, and the underlying reason it doesn't work is not because of plugins/Eclipse, but because of SWT. On OS X, you can't mix SWT with AWT (or Swing) because of the event-loop conflict (doesn't matter if we're talking about Eclipse or another application). In other words, the widgets don't work.
    And as long as Windows developers call SWT cross platform I have to deal with customers who want SWT cross platform solutions.

    Oh yeah, I agree completely. SWT works pretty well on Windows, but it isn't a viable cross-platform solution, IMO.
  18. SWT still bad on Mac OS X[ Go to top ]

    Thanks for the feedback, I'll add the AWT problem to the paper.
  19. SWT still bad on Mac OS X[ Go to top ]

    I wasn't impressed with the PDF, either. It failed to mention what I consider the biggest problem with Eclipse (and SWT in general) on Mac OS X. This bug:http://bugs.eclipse.org/bugs/show_bug.cgi?id=67384That one is a killer that pretty much breaks the cross platform promise of SWT.
    My reading of this is different. The problem not being so much
    SWT, but the fact that Macosx allows only a single UI thread
    in any process and that the ui thread has to be the main thread.
    As i see it, any coexistence or interoperability of different GUI frameworks with a dedicated ui event loop in a single process is "impossible".
    I really believe Apple should adress this.
  20. SWT still bad on Mac OS X[ Go to top ]

    My reading of this is different. The problem not being so muchSWT, but the fact that Macosx allows only a single UI thread in any process and that the ui thread has to be the main thread. As i see it, any coexistence or interoperability of different GUI frameworks with a dedicated ui event loop in a single process is "impossible". I really believe Apple should adress this.

    Well, it's not outright impossible, but it's certainly difficult and error-prone; I wouldn't want to do it.

    That aside, your comment perfectly illustrates the "not our problem" situation that exists on both the Apple and SWT sides. Unless Apple sees a big need for that feature, it isn't going to happen on the OS side, and as far as I can tell, it's extremely hard (almost impossible) to fix on the SWT side. Who loses? Developers.

    And I do see it as SWT's problem, because SWT is positioned as a cross-platform toolkit. SWT's design uses heavyweight widgets, and this bug (and other similar bugs SWT has run into) is a direct result of trying to wrap a library around native widgets on disparate operating systems that don't necessarily work the same. Heck, Sun predicted exactly these kinds of cross-platform problems with heavyweight widgets; that's why they moved to lightweight widgets in the first place. Widgets toolkits that make use of lightweight widgets don't have this problem, and I think they're a better choice if you're aiming for cross-platform capability.

    I think SWT works fine if you're targeting Windows, but if you want cross-platform capability, you're much better off with Swing.
  21. SWT on OS X is possible, but...[ Go to top ]

    It's definitely doable. I've worked on a large-scale app which uses SWT entirely to do the client portion. However, the single thread problem is pretty huge. It keeps you from integrating many libraries, including things which you think should be fine. All they have to do is make one reference to AWT graphics and you're done for. One example where this was a big problem was JasperReports -- we had to write a helper app instead of running them inside the SWT app. We also did an app in Swing and porting it to OS X was fairly trivial.

    Unfortunately, there *are* still problems with Swing, including niggling issues with table rendering, drag and drop, and JTree. You can work around each and every one of them, but unless you're willing to spend days doing so for each bit of weirdness, your app will end up being less usable. SWT's API tends to be much less abstract in how it deals with these things, and we've found it to be much easier to get good results on Windows. Since that's 99% of our user base, this was compelling enough to put up with its issues on OS X.
  22. As I thought we were talking about SWT, I assumed all readers of the PDF, which was obviously not written for this discussion, would skip the eclipse part and read the SWT part.

    " The PDF continues to put features of eclipse and IDEA next to each other and then claims that IDEA has done a better job"

    Also obviously wrong, which is one feature, not features. You give the wrong impression about the PDF, it is not a feature comparison of IDEA and Eclipse.

    "As far as developing applications using SWT versus Swing, I can't comment."

    Well, and as before, I thought this discussion was about SWT being suitable for Mac OS X development as suggested, so why answer if you can't comment?

    "Eclipse on Mac may not be completely bug free, but it is far from the 'horrible' experience you try to describe."

    If you run in a lot of bugs with widgets, which just don't work on Mac OS X and lead to days of debugging sessions and a lot of discussion with the customer, then yes, I call this experience horrible.
  23. The document, written by the poster, mainly compares IDEA and Eclipse, although stated otherwise.... and this in quite superficial way. One small chapter, which is mostly a large picture, adresses SWT.
    That's the problem with words like "horrible", they are really "horrible" in a discussion, which pretends to be objective.
  24. Yes, words are hard to use. The PDF contains 10 pages, of which 2 pages explain that Eclipse has insufficient visual aids for error flagging and compares this to the way IDEA handles the problem.

    Then there are 2 pages with screenshots how Eclipse shows different refactorings options for the same class in different contexts (IDEA is not mentioned).

    " One small chapter, which is mostly a large picture, adresses SWT."

    Then there are 3 pages which make some points about SWT and have a screenshot, which covers 30% of 1 page and shows that the look and feel of SWT is not native. I can't see any other way to show that SWT as used by Eclipse is not native but using a screenshot. (IDEA is not mentioned). Then there is 1 references page which doesn't mention IDEA either.

    So only one section contains an IDEA comparison, instead of

    "mainly compares IDEA and Eclipse".

    I didn't expect otherwise because in nearly every Eclipse and SWT discussion people distort facts.

    "The document, written by the poster, ..."

    Yes, as the the second line of the paper contains my name as do all of my posts. But you make it look like I tried to hide the fact in any way.

    It would be much more useful if you could point out mistakes in the PDF instead of making wrong claims about it's contents.

    And I still call essential widgets which just don't work on Mac OS X a "horrible" experience.
  25. Perhaps I made my intentions not clear enough, sorry for that.

    I'm not interested in bashing Eclipse and promoting IDEA or Netbeans. I'm interested in exchanging experiences with other developers who need to develop cross platform SWT applications.

    Here our customers ultimately define which platform to use: IDEA Plugin, Swing, Eclipse RCP, Spring RCP, .NET or pure SWT. So experiences with these platforms and identifying wrong claims surrounding them help us avoid problems on this platforms during development.
  26. Native Cocoa only[ Go to top ]

    Eclipse 3.1 runs great. I work almost daily with it.
    SWT seems like a valid alternative to Swing, Cocoa, Carboon and others on Macosx.
  27. Native Cocoa only[ Go to top ]

    Eclipse 3.1 runs great. I work almost daily with it. SWT seems like a valid alternative to Swing, Cocoa, Carboon and others on Macosx.

    That's the problem with words like "great", they depend on your expectations.
  28. In fact, the main advantage of using COCOA / java for mac OS X desktop applications is, from my point of view, the capability to use Interface Builder to design the GUI.

    But the main problem is that XCode is definitively a bad java IDE...

    Has anybody ever tried to use both of Interface Builder (for designing the GUI and mapping it to the model) and Eclipse (or another real java IDE) ?

    Sebastien
  29. Has anybody ever tried to use both of Interface Builder (for designing the GUI and mapping it to the model) and Eclipse (or another real java IDE) ?

    Check this out:
    http://www.nib4j.com/

    Use Interface Builder to create Swing interfaces.
  30. Native Cocoa only...[ Go to top ]

    The SWT implementation on OS X is horrid, so much so that I had to switch from Eclipse to IDEA (which uses Swing) on OS X.
    Same story for me, but I switched to Netbeans. JDeveloper seems to run fine on OSX too.I still use Eclipse on Windows, as it runs fine there.

    +1 : I've switched to NetBeans on mac OS X while using eclipse on my PC. In my own case, java programming on a 12' powerbook with an azerty keayboard is a real pain of the ass.
  31. yes, actually i'm using Interface Buider and eclipse in order to develop Cocoa-Java apps.

    i've been following a knwon article :
    Building Cocoa-Java Apps with Eclipse
    by Mike Butler
    04/22/2005
    (see http://www.macdevcenter.com/pub/a/mac/2005/04/22/eclipse.html?page=1)

    hope this could be of any help °;-)