|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 30
Messages: 30
Messages: 30
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Cocoa-Java Bridge collapse
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?
|
|
|
Message #177481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It shouldn't affect *Server Side* java
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.
|
|
|
Message #177493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not an issue
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.
|
|
|
Message #177496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cocoa-Java Bridge collapse
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?
|
|
|
Message #177501
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only...
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.
|
|
|
Message #177512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not bad news
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.
|
|
|
Message #177520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not an issue
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.
|
|
|
Message #177551
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only...
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.
|
|
|
Message #177552
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only...
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
|
|
|
Message #177597
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only
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.
|
|
|
Message #177598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only
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.
|
|
|
Message #177600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cocoa advantage : Interface Builder
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
|
|
|
Message #177601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Native Cocoa only...
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.
|
|
|
Message #177612
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177613
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interface Builder with Other IDEs
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.
|
|
|
Message #177614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not an issue
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.
|
|
|
Message #177624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not an issue
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...)
|
|
|
Message #177628
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177640
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177641
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177649
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177652
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT still bad on Mac OS X
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.
|
|
|
Message #177741
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SWT on OS X is possible, but...
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
