Apple Computer is possibly in a better shape than it has been in for a long while. With the second coming of Steve Jobs and the renewed focus on innovation, Apple scrambled back from the brink to a relatively healthy company. The question is how will Apple ensure its position, if not strengthen it going forward?
Post a Comment
but seriously, from an "non developer" point of view. Java sucks. It's slow, clunky, and a nightmare to maintain.
And another thing... We have several Java apps that "clash" because one needs version 1.3 and the other needs version 1.4. Isn't the whole purpose of major.minor.bugfix releases to maintain binary compatibly within major releases?
until it said apple's user base was not increasing. It is increasing.
Someone who doesn't understand basic concepts like market share and units sold talking about long term apple strategy is like me explaining the finer points of spelunking when I have never been inside a cave.
I always thought NextStep was too well thought-out and well-designed to languish abandoned in the Objective-C ghetto.
I don't know how likely it is, but a java port would be one way to bring it back into the mainstream.
Apple has made a considerable investment in Java. They have done an enormous amount of work to ensure that Swing applications can have an Aqua look and feel, as well as added a number of other features such as VM sharing which other Java VM implementations are only now starting to get.
If all this effort has had a positive effect on Apple, they've certainly kept it quiet. When OS X was released it was touted as an excellent platform for Java applications, but that original fervor has all but dissipated. Perhaps Apple woke up and realized that no one wants to use a slower and more cumbersome Java application when there's such a large number of native code applications available which can do more or less the same thing, only faster.
Apple's future as a computer manufacturer still lies with its enormous base of creative professionals who prefer the Apple shared menu interface over the unwieldy Windows one, and the pro app developers whose Mac versions still outsell their Windows counterparts by an order of magnitude (e.g. Avid, Quark, Steinberg)
I agree wholeheartedly. I am ABSOULTELY not a developer, but the Java apps I use are awful – slow, clunky, ugly. I've seen better apps developed in HyperCard, Revolution and FaceSpan. Not being a developer I've always wondered if the problem was with Java, or just lousy programming. Maybe someone here can explain?
One exception is the excellent ImageJ from the US National Institute of Health. Have a look – http://rsb.info.nih.gov/ij/
Porting the whole Cocoa might be too big a task. It relys on other technologies which Java do not have.
But it's a very interesting idea nevertheless. Maybe a subset of Cocoa can be ported to Java. If they can improve Java-ObjC bridge, along with this port, they can attract a lot of developers.
jah... Limewire!!!! agggghhhhhhhh.... slow on any platform.
Maybe someone here can explain?
Yes, its a combination of things. Swing was really slow, and still isn't a speed demon by any means, but has gotten better. The look & feel is designed to be truly portable, so it doesn't integrate well with the OS or take advantage of native OS calls. At the same time, developers have to code with it correctly for it to be fast and efficient, and most don't.
Hopefully, SWT will take off more, since it fixes the responsiveness and OS problems by using native widget sets.
until it said apple's user base was not increasing. It is increasing.
Someone who doesn't understand basic concepts like market share and units sold talking about long term apple strategy is like me explaining the finer points of spelunking when I have never been inside a cave.
That's what I was thinking when I started reading the article. Sad.
Cocoa doesn't really mesh well with Java. If you read the Cocoa mailing lists you'll see over and over again recommendations that people use Objective C, rather than Java, for Cocoa programming. Why? Well, Cocoa's design uses a lot of the more interesting aspects of the Objective C language and runtime which really don't match up well with the Java way of doing things.
Yes, the Java-Objective C bridge is cool, and works well, but if you actually try to program Cocoa in Java you'll find that it's somewhat painful and certain things just don't work cleanly.
Objective C really is the way to go with Cocoa. If Apple wanted to make Cocoa available on Windows, they could dust off the OpenStep runtime for Windows. If they wanted it on Linux, they could port it to run on the GNU runtime, or better yet make the Apple Objective C runtime available.
Java has only three things going for it over Objective C. First, it is more widely known and used. Second, it is "prettier" by many developers' estimations. Third, it has integrated garbage collection.
And that's about it. I think most people who've used both languages extensively would agree with me that Objective C is superior, but obviously I cannot back this up statistically.
Objective C is very different from Java. Java is a statically-typed language, while Objective C is a dynamically-typed language.
I think the fundamental fact the author doesn't understand is that it is the specific language features of Objective C that make Cocoa possible. What's more, it is those features that make Cocoa so great.
Obviously you can write Java bindings for Cocoa. Apple has done it. (I never touch it.) But you simply could not port Cocoa to Java. It would be a total rethinking and reimplementation. In my opinion, it would be an inferior product.
I think the odds that Apple will do this are zero, because the developers there realize exactly what I'm talking about: It is Objective C that makes Cocoa possible.
If you have Cocoa, why on earth would you bother with Java? Cocoa is an awesome API! Why, why, why would you not use it if you developing on an apple? And since there is already a Cocoa-ized Java API why not just use that? What would be far, far nicer would be to see a solid, kick ass port of Cocoa to Win32/Unix (and no, GNUStep doesn't count, as it doesn't work well on Win32, and the last time I checked it was only so-so on linux), along with (finally) migrating over Apple's contributions to GCC (i.e. ObjectiveC++ and pre-compiled headers, among others).
Third, it has integrated garbage collection.
I do believe the Objective-C (or Cocoa framework) does have garbage collection. Well it might not be the same garbage collection as known with virtual machines, the idea is any class object derived from NSObject has an "auto release" attribute that will deallocate memory used during construction, rather than the programmer managing memory manually. Auto releasing occurs either during or before the destructor, parent objects will call the destructor for each child object so the framework is recursively freeing up memory as it destroys objects.
On the other hand, I think porting (rather than reimplementing) Cocoa to another dynamic language like Python or (better yet) Ruby is doable. But again, why bother when Objective C is so great? I prefer Ruby to Objective C overall, but not so much that I'd recommend a fundamental change in Cocoa.
Let's leave well enough alone.
What Apple did was let Java programmers access Cocoa objects through Java syntax. People (like myself) who don't like Objective-C syntax can at least use this method to develop decent OSX apps and not rely on Swing.
That's why I said "integrated garbage collection," because Objective C's garbage collection isn't integrated. It requires an AutoreleasePool object and an explicit call to release or autorelease, or the invocation of an autoreleased constructor, e.g., [NSMutableArray array].
That said, Objective C's reference-counted garbage collection is very simple to use. It sure beats the hell out of Microsoft COM's IUnknown:AddRef() and IUnknown::Release() calls. (Did I mention how much I hate COM?)
How would I...
call a method on an object whose type is unknown (without using reflection)?
Add methods to an already-defined class without subclassing?
Integrate easily with existing C APIs?
There are others, but these three capabilities are used extensively to make Cocoa work. Can anyone think of some more?
Steve Jobs likes to say that Apple is the BMW of computer companies. It could be, but it's currently not.
??? News to me. Lets examine that a bit further.
Take a look at BMW, Harley Davidson, Bose, or any other company that sells stylish equipment for premium prices.
Well that a check. Apple sells stylish PC's with (generally) superior, higher quality hardware, and great software at a premium price.
A Harley Davidson motorcycle uses the same roads as every other bike. A Bose radio plays all the same music as any other radio.
And this analogy fails for Apple where? Apple users can open any number of standard documents/files, through any number of different software packages such as MS Office, Adobe Photoshop/Illustrator, web browsers like Mozilla, Safari, etc. The machines can be easily networked with any other machine on a network, they support PCI hardware cards, they support common hardware like hardrives, and CD Roms, many of which are interchangeable with PC hardware, they support the same font files. They have support for zip files, they have support for USB and Firewire, lord the list just goes on and on. What more do you want?
Ahhh, that's right, you want the magic button that just lets you take you windows program and open it up on a mac. What you want is to have windows inside of a Mac. Hmm, last time I checked it's called Virtual PC. Not very difficult to use.
[RantModeOn]
Blech. Enough about Java. Java has had almost 10 friggin years to come up with compelling end user programs, and has failed, *every* single time. Numerous companies have attempted to port their desktop software to Java only to find that the reality of Java desktop performance just sucks. And this is after year after year of massive hardware improvements. Year after year we've heard about improvements to Java, and how great it is, yet where's the desktop software to back this up?
Eclipse is the *only* software I've used that even remotely runs at acceptable levels (and even then with big projects it can easily get bogged down). I can't think of a single Java desktop application that I have used that didn't jarringly standout in terms of it's UI, and that didn't run like molasses once you tried to use to for anything productive (TogetherJ - great tool, but quickly eats up every last resource on the PC for anything but trivial models).
[RantModeOff]
What Apple has managed to do is nothing short of brilliant given it's state in 1996-1997. And it sure as hell doesn't need Java for that.
Mono has got a pretty nice thing going, with a port towards OSX in the works. I haven't seen any cocoa# (since google ignores the # after cocoa I couldn't search that well) but I assume it is doable, just as there is GTK# and QT#.
Personally I think that having .NET on OSX will have a much larger real impact than running Java GUI applications ever will have.
For the love of God, give me access to the cocoa object in C++ form. I understand that I can call out to Obj-C from C/C++, but really, I want to avoid that whole syntax and stay in my preferred language.
Granted, since I've forced myself to stay in Obj-C I have picked it up and respect it in a few instances, but I don't understand the reason to force developers into a new language.
The only good thing about Java and C#, are their quality APIs and namespaces. The same can be said about the Cocoa/Obj-C combination. I'd really like to see something pair up with C++. Qt is excellent, and if Apple is unwilling to support Cocoa/C++, I'd like to see official support for Qt/C++ on the Mac from Apple. It'd really open up a range of ports and bring developers over to the platform.
Cocoa for Java exists, it ships with OS X and is documented here:
http://developer.apple.com/documentation/Cocoa/Reference/Applicatio...
It is really hard to make the rest of the world use something ou wrote. If apple did port cocca to java, I do not think people many would use it. The intall base isn't there.
If apple wants to expand its api compatibility to make it easier for developers to create mac ports of their applications, they should work on adopting something that is already in use. For the effort I think they would be farther ahead if they did something like bought trolltech (or at least bought a non gpl/qpl/pay version of qt for all of their developers) and made qt a native tookkit. Or they could port gtk to osx and make it a native tool kit.
I believe what Apple should do instead is released Cocoa for Windoze. They originally promised to do this (what was known as the "yellow box") but changed their minds.
I'm sure many people will point out the cons of this strategy, but think of the pros. Cocoa is already a great framework, if software developed on Cocoa can run on both platforms with a simple re-compile, lots of developers will move to Cocoa. Now imagine a world where most apps are written in Cocoa - that would mean most apps would run on OS X. Then it suddenly doesn't matter that Apple has a 3% market share!
Sure this strategy will cost Apple some sales, but Apple can still compete on implementation. Just because an app runs on both Mac and PC, it doesn't mean it cannot run better on a Mac. Besides, when it comes to the OS itself, OS X is still years if not decades ahead of Windoze.
My 2 cents.
I think Jay is right on the money. If Apple were to do anything, this is what they should do.
The author keeps talking about MS Visual Basic in the enterprise. If JAVA was a desktop standard then I would agree with him. JAVA is only used on Web servers!
What Apple should do is buy REALbasic, and develop that. It is cross platform for MAC and Windows, and they are planning a LINUX version. Basic is the programming language of choice for buisness. Even if it isn't the BEST language it is what people are actually using. So. . . it would make sense that Apple BASIC should show a return. With JDBC (a good use for JAVA) they can connect to enterprise databases and be back in the game. Buisnessnes use MS VB as a front end. If Apple is to give away a free development package, it should be REALbasic. The author is right about MS visual basic being a standard in the buisness world, and the only way to get back into the game is to have the same.
I've heard people praise Objective-C a lot. It looks a little weird, but no big deal. I've never used it because it seems to be mostly relegated to the Mac/OpenStep world. Doesn't objective-c have runtime performance issues of its own though?
The guy seems a little misinformed about .NET on Mac. Dotgnu already runs on it, but there's no JIT and windows forms is going to look like crap on it right now. For Mono, its just a matter of getting the JIT up to speed on powerpc, which should happen in the next few months. There's no Cocoa bindings right now for either platform though. Dotgnu is concentrating on winforms and Mono is doing gtk#(even though their wine-based winforms implementation continues). I don't know if either of these platforms would run into problems as aforementioned in doing bindings to Cocoa. I guess from a user perspective it doesn't really matter what framework it uses as long as its fast and it looks native. I don't see Apple investing any resources into either of these projects in the foreseeable future though.
I don't how porting Cocoa to windows and linux could hurt Apple, except from a resources standpoint.
Already does ... iTunes for windows use Cocoa !!
No, it doesn't. iTunes is a Carbon application, it doesn't use the Cocoa framework.
1) Swing on OS X is implemented by Apple. The speed of Swing is fine on OS X, and the look and feel is virtually indistinguishable from native Cocoa apps. The only reason Java apps look out of place is because they aren't coded to Apple's Aqua user interface guidelines.
2) You can write Java applications that use Cocoa in OS X. There is even an option to create a Java Cocoa application in XCode (and Project Builder).
3) Layout managers are there for a reason! Apps will look different on each platform due to different font families and sizes, different widget sizes, and the like. Hard coding the coordinates/sizes of components will just make it look odd on a different platform. Why do you think Qt has something similar? Ever tried implementing the resize code for a GUI? Try it, and you'll understand why layout managers are a boon. Sure, they are hard to begin with, but once you know them, you won't give them up.
Java on OS X is fine. The biggest problem is other platforms, namely Windows and Linux. Sun needs to fix Swing on those platforms, because they are the OSes that most users and developers use.
But some of their H/W sucks big time. F.e. their mice and keyboard.
> Yes, its a combination of things. Swing was really slow, and still isn't a > speed demon by any means, but has gotten better. The look & feel is > designed to be truly portable, so it doesn't integrate well with the OS
> or take advantage of native OS calls. At the same time, developers
> have to code with it correctly for it to be fast and efficient, and most
> don't.
Thank you for the explanation.
Someone mentioned Yellow Box - well, that was back when Mac OS X was called Rhapsody. Blue Box was the codename for Carbon, Yellow Box for Cocoa. The idea was that Yellow Box apps could be implemented on both Mac OS/Rhapsody and Windows NT. It's a shame that they didn't release it in the end as it would, I imagine, increase Apple's market share by helping to make more apps Mac native in the first instance and then ported to Windows Yellow Box.
Rhapsody developer release CDs are often sold on Ebay but they're probably for PPC, I've never looked into it. Of course, Black Hole Inc sell Open/NeXTSTEP for x86.
I'd love to see GNUstep catch up with Cocoa, but if Mono with all of its momentum is behind .NET I don't see GNUstep as having much chance, after all, far less people seem to work on it.
J...
>I agree wholeheartedly. I am ABSOULTELY not a developer, >but the Java apps I use are awful – slow, clunky, ugly. >I've seen better apps developed in HyperCard, Revolution >and FaceSpan. Not being a developer I've always wondered >if the problem was with Java, or just lousy programming. >Maybe someone here can explain?
I agree, java apps almost always look like something put together by a 5th grader. I think the reason is three fold, Java is not ideally suited to GUI apps (slow GUI), secondly most programmers who use Java, in my experience, are lazy when it comes to GUI design, they rely too much on the layout engine to design dialog boxes with the result that they just looks awful and thirdly, the look anbd feel style is ancient (true one can theme, but most programmers don't bother and rely instead on the native swing theme).
That wouldn't work, as having Cocoa used is not good enough. It also needs to follow the Apple HIG. If most Cocoa development happened for Window, then most of it would attempt to stay in like with the Windows look and feel, leading to apps that will run on Macs and Windows, but only look like they belong on Windows machines.
Alternately, it would create a large army of apps that look like iTunes for Windows, which is another thing I don't think they'd enjoy much. 
If we hold Apple as believing their machines/OS to be the BMW of computing, having apps that didn't fit the look of the OS would in many ways be worse then not having the app at all. The Apple systems are sold on the idea that all their apps look consistant, polished, and are easier to use then the Windows counterparts, and releasing a Cocoa for Windows in the hopes of seeing quick, easy ports has the potential to eat into that. Perhaps some abstraction could be used to keep the looks consistant for each OS, but for the limited gains they would get I don't know if I see that that as a valid plan of action if I were Apple.
Just MHO, of course. 
Should Apple really port their applications to other hardware platforms. I think basically they decided not to for the same reason they don't license their OS any more.
Apple is still a hardware company. They develop software to primarily sell more hardware. Until they convince corporate users to put an Apple on their desktop (probably the area where they would be perfect).
I doubt Apple will do much porting of their software to other markets unless there is an immediate benefit for them, whether its selling iPods, Music or whatever. They are far more likely to port MS/Unix technologies to Apple hardware.
Basically this whole port argument is a crowd of envious Windows and Linux users that want cool Apple stuff without paying the Apple hardware tax. Basically they want it for free. Even MS is cutting back on giving away free software for the anything but Windows (which effectively makes it non-free).
there's no doubt the mac needs to capitailize on its recent success but porting cocoa to java is too little too late. Java gui stuff is awkward at best. get real - the only way apple is going to thrive (survive they always have and always will, but come on now, enough is enough - let's go!) is to open cocoa for linux and light a fire under the business community, providing a REAL alternative to windows. Mac won't ever do it on non-commodity hw, but they don't want to either. but a new framework on 64-bit intel and AMD - on commodity hw, doing boring standard office type stuff, not apple digital hub lifestyle stuff - that's what they should aim for. the world needs it - why wait for the linux people to put together some pedestrian GUI when an amazing one already exists. free is up and let some real progress be made for once outside Macintosh's little world.
Java is a great language, and the most popular programming language today. Hands-down. Java has a lot to offer, has a familiar C++ -like syntax, has good garbage collection, and is truly cross-platform.
Swing sucks. AWT is a least-common-denominator, mostly peer class-based UI veneer. This does not mean you cannot build fast AWT applications (you can), or that Java is slow. This is a misconception.
Apple found that when they moved WebObjects from Objective-C to Java, they gained a significant performance increase. Netscape found that their Java-based "Rhino" JavaScript engine is substantially faster than their C-based "SpiderMonkey" one.
Objective-C code is not portable. What other platforms use Objective-C? Sure, you can wrap regular C code with Objective-C, but the fact of the matter is if you want to model your code as Objects, you have to either write it all in C and wrap it in Objective-C classes, or rewrite your code in another language for other platforms.
The Java Bridge is good, and could be improved. Moreover, more of the Cocoa libraries need to be bridged by Apple.
A good (far from perfect) example of a high-performance Cocoa Java app is my game, Aquataxx:
http://buzzlabs.com/aquataxx/
Download it, and e-mail me if you can "feel that it's Java." Full source included.
The December 2003 issue of MacTech magazine has an introduction to Cocoa Java. No point in covering all of that here.
Java code *is* backward-compatible, except when deprecated stuff is used. Java code is truly cross-platform. Any "debug everywhere" problems are generally the fault of the company that is porting the JDK, or discrepancies in window toolkits across platforms with regards to AWT, which Swing is based on. Yes it is. Go read the code -- included with the JDK.
Apple should dedicate more engineering resources to furthering Cocoa Java.
Apple's marketing, especially in the developer services area, is lacking.
Apple should be more open with developers, especially about Cocoa Java.
Amen.
Apple needs to start thinking beyond Macintosh.
Like they were doing in the 1990's.
I need to start writing again.
Simple. Re-use of code.
You're looking at 2% of the market with the Mac. That other 98% is Windows, Linux and other.
Depending on what you're writing, it might make sense to consider that other 98% of the market. That means three choices, really:
1. Write your code in C and "wrap it" with Objective-C or lose most OO design.
2. "Objective-C++," a mixture of Objective-C and C++.
3. Java.
Makes sense to use Java. Apple should step up to the plate and allow WebKit, Rendezvous, and more of Cocoa to work with Java. There is no reason not to.
Apple also needs to do a LOT OF WORK on thread-safety with Cocoa. This "everything UI runs in the main thread, oh, and so does QuickTime" madness has to stop. It's the nineties. ;o)
I would rather see Apple work on a better Java-based API than "port" Cocoa, but I would first like to see Apple finish the Cocoa Java path that it started. It is truly an excellent choice for software developers to come to the Mac and do their thing.
There is very little reason to learn Objective-C nowadays. C++ won, and Java borrows much of its syntax.
Steve
I have to admit that the article makes a LOT of sense. I'm surprised nobody thought of this before. I for one would be one jumping head first into a Java version of Cocoa. Like most posters here, I agree it is a pain to create nice-looking and responsive Swing Apps (it can be done, I've done it, but it's a big pain and it takes a lot of time; swing is just too complex for its own good).
So how can we support this idea? I'm open to helping out, at least with testing.
This is not a popular opinion, but I think that Apple would benefit more by implementing something like WinFS or GNOME Storage for one of their upcoming releases. It is something that could have a large, positive impact on the capabilities of the system.
That means three choices, really:
1. Write your code in C and "wrap it" with Objective-C or lose most OO design.
2. "Objective-C++," a mixture of Objective-C and C++.
3. Java.
Seems like the sane choice here would be 2. Keep core functionality in portable C++ and write native interfaces is Cocoa, MFC, Qt, or whatever else you want.
Everybody's excited about .NET allowing development in many different languages, yet nobody is willing to take the 2 days that anybody with a working knowlege of C and understanding of OO concepts needs to learn Obj-C. Compared to the time needed to learn to effectively use the Cocoa API, the time spent picking up Obj-C is negligable.
I seriously doubt the author has used Cocoa in both Obj-C and Java. Compatively, Cocoa in Java is a nightmare as Cocoa takes heavy advantage of the dynamic nature of Obj-C. The only really sane thing to do would be port Cocoa to other platforms, but even then you're going to break the parts of Cocoa that are dependant on Quicktime, CoreFoundation, etc, so portability is just not going to happen. I just don't get why everybody goes nuts over C# but refuses to give Obj-C a look.
@Kingston
This is not a popular opinion, but I think that Apple would benefit more by implementing something like WinFS or GNOME Storage for one of their upcoming releases. It is something that could have a large, positive impact on the capabilities of the system.
This is actually a very popular opinion. Ever since Dominic Giampaolo joined Apple we've been expeciting some advances in the file system. More likely than not Apple is just waiting until legacy support for OS9 systems with HFS+ is no longer as big an issue.
sorry I couldn't get past page 1 because of several problems:
1)author tried to argue that a Mac isn't much more than a wintel machine. That's so false its absurd a mac configured the same way my rig is would run me over $500 extra and until the G5 cpu came out it would be 500 MHz slower.
2)author made mention that Apple has an open source philosophy. This is so untrue its laughable. Open source implies you give something back. Have we seen anything back from Apple? Any bones at all? A linux installable version of QuickTime would have been a nice bone to throw us all for their use of any open source software. An iTunes client would be even better or at least don't use internet explorer code or whatever they did to make it so proprietary (you programmers know the proper term I'm searching for here fill us in thx) so it can be run in wine!
Have we seen anything back from Apple? Any bones at all?
hi troll, most notably KHTML, the Mach kernel, BSD and Apache, AppleTalk, the HFS+ file system and the NetInfo distributed database ...
Are you implying Apple is the inventor of BSD which they subsequently open sourced..?! LMAO !!!
As someone who is currently writing a decent-sized Java app using Cocoa, I feel I have something to say here to butress Steve's argument.
I chose to write my app using Java+Cocoa for several reasons:
1) Cross-Platform--In the app that I'm writing, the stuff that isn't being used for the UI can be used on other platforms. While I don't see in the immediate future releasing my program for Windows/Linux, I still have that option if need be, and I don't have to rewrite 100% of the program. Or even worse, code in C.
2) Complete set of libraries--Sure, Foundation/Objective-C is nice, but it is *extremely* lacking in API's and libraries to get the job done. For my app, I needed a good set of API's for things like X509 certificates, https sockets, and most importantly, regular expressions. Java gave me those API's, Foundation/Objective-C did not. The biggest deal-breaker of them all was the lack of a good set of API's for regular expressions; if you are writing any kind of app that works with raw html source (e.g. screen-scraping), regular expressions are absolutely essential. Sure, there are some indepedant Objective-C libraries out there that are *supposed* to do regular expressions, but either they have very non-standard syntaxes that don't mesh at all with those in scripting languages (no cutting or pasting between python or perl), or they were unreliable and didn't capture the information they were supposed to.
So Apple, please, please release in 10.4 a Foundation class called NSRegularExpression that lets me paste in regexp strings that are compatible with those in perl/python/whatever, and that work just as reliably.
3) XML--I'd put this under #2, but this really deserves a category on its own given the ever-increasing importance of XML in the development world. Prior to Panther, there was no official object-oriented Cocoa API for XML. If you wanted to work with XML DOM stuff in any kind of way, you had to resort to doing stuff in C (yuck) with Core Foundation's DOM stuff. I haven't yet gotten Panther, but from what I understand NSXMLParser only gives you basic SAX capability. While there might be 3rd party Frameworks that do DOM stuff, there is really no excuse for Apple not to have an NSXMLDOM class. Java at least shipped with a full set of object-oriented XML API's, and has been doing so for years, so it was a natural choice for the app I was writing.
Really, except a few missing class and the fact that GNUstep is too gray.
What makes Cocoa better than GNUstep?
It's rare that you find such gems! Had me
laughing my guts out all along. Wait! --you
mean it wasn't supposed to be funny?
Also, regarding the comment:
"until it said apple's user base was not increasing. It is increasing. Someone who doesn't understand basic concepts like market share and units sold talking about long term apple strategy is like me explaining the finer points of spelunking when I have never been inside a cave."
Well, glad there are people that understand "basic concepts" like "market share and units sold". Too bad they DON'T understand that it DOESNT MATTER if the number of your units sold increases. If you don't gain market share in a shifting market, you are STILL DOOMED!
which magic hat did you pick the word "invent" from? LMAO!! read the quote before you decide to open your gap
sorry ruckus... the matter was "giving back". Now, you can only give something _you_ made in the first place. Apple didn't even base their efforts on the latest BSD-release, so there is not much "giving" related to BSD at all.
A Mac can play well in a Windows network, but it's not going to run the multitude of Visual Basic and Access applications that infest every office
How will porting Cocoa to Java help run MS Office VBA??
On my office there are more Swing apps in use than vba ones, as it happens. Corporates don't care about fancy UIs for intranet apps but functionality - Swing is adequate.
When Apple acquired NeXT, they killed cross platform support. When you consider that Apple is a single company and it doesn't have the resources to develop an up to date, cross platform GUI API, this makes sense.
Apple has far more resources than NeXT ever did. The decision was a political one, not a technical one. Just like the Newton...
Furthermore, they have far more resources than trolltech (QT).
Don't forget that the brains behind cocoa at Apple comes from NeXT employees with a decade or more of experience with objective-c. Bolting this onto Java isn't likely.
Try learning objective-c on a Mac; you might find you enjoy it better than Java.
Anyway, what compelling features does Cocoa have that Java doesn't? Honestly, first you troll against Swing, then SWT, then Java IDEs as if Cocoa were the perfect framework with the perfect dev tools. The grass is always greener...
I'm a Java developer by trade, as it happens. I've heard lots of nice things about OSX as a platform but haven't yet been tempted to buy a Mac just to try out Cocoa.
Darwin is BSD. Darwin is improved and open. Its used in OSX so its latest enough. Apple can base OSX upon Darwin, an OS that's commercial success ... that's giving related to BSD.
People have already pointed this out, but it bears mentioning again. The reason Cocoa works so nicely for GUI development is due to the dynamic typing of Obj-C, it makes the design very clean.
This is very obvious the first time you make a java-cocoa app.
I harbour this vain wish for a java-like language with
1) dynamic typing like objective-c
2) clean, simple syntax like java (objective-c drives me nuts with how everything can be done about 20 different ways, from hardcore c to very nice oo design. I like how Java makes the oo design easy and hacks hard)
3) Cocoa-like native interface design
4) Fast and efficient runtime
5) Complete and well designed libraries like Java (mostly anyway)
Something like take Cocoa (Obj-C), Java and C++ and pick the best.
it sounds to me like you want Smalltalk binding?
Can someone please explain to me what the advantage of doing dynamic binding the way Objective-C does it? I've read Apple's Objective-C book (that PDF is just too long to read at a computer), and I don't see how it ends up being anything but a problem when, invariably, a message is passed to an object that isn't designed to respond to it. And, using assert to check beforehand is wasted work.
This post from Ken Dyke is probably the best essay I've seen on the subject:
http://groups.google.com/groups?selm=DCxz5.246037%24i5.3339013~...
to Jason
In my opinion computers are very stupid. Sometimes you know you send the right message to a object but try telling your stupid java compiler that. even worse is trying to explain somthing like a proxy object to your computer. Maybe your computer is better of leaving you in charge instead of complaining it knows better?
Remco
I think there is a central mis-understanding by the author - that Cocoa is just an API. It sits on top of Quartz, Core Foundation, Mach and BSD. Yes, there is a Java version of the Cocoa API for development on the Mac, but it maps back to C calls in the above mentioned library. In order to port the current NSBezierPath, for example, one would have to port Quartz. It is because of Quartz that drawing when using Cocoa (even complicated vector images) is a fast and simple process. If Apple did port Cocoa to Java - it would be accompanied by many native platform implementing features like Quartz.
I think it was a mistake Apple chose to switch WebObjects to Java instead of improving what they already had in Objective C. I almost believe that they should convert WebObjects back to Objective C. Java does give you some edge in specific areas but it obviously isn't the best way to go for every problem. Apple as a 24/7/365 company has to emphasize their own offerings in a highly competitive stand, they can't do that by holding in the forefront with a cross-platform formula, they can only do that emphasizing their own unique offerings. Switching Cocoa to Java buys Apple nada.
To Remco,
Well, I'm certainly not a very experienced programmer, so I've never come across an instance where a Java compiler can't figure out whether a particular method signature belongs to a particular class. However, if a compiler, any compiler, doesn't try to make that connection for the programmer, it leaves an even greater responsibility on the original developer of the code to properly document what exactly a method does. Then, that code is really only useful if the person who inherits/re-uses it reads, and can fully understand, what the original intent of the function was.
In response to a comment above, we're supposed to take seriously framework design advice from a guy who uses regular expressions to parse HTML? No thanks.
Also, if I want to use regular expressions in my Cocoa programs, I just #include <regex.h>, which is part of the libc that ships with OS X. If you need to "cut and paste" from Perl or Python, then install the pcre library.
It makes no sense to put implement Cocoa through Java. Currently OSX implements Java through Cocoa.
RealBasic is the best option for companies to convert their VB apps into multi-platform applications. Heck, the same RB app runs roughly as fast on a 1.25 GHz AMD Duron system than on a DP G5. RealBasic allows you to import Visual Basic code and the IDE (IMHO) is easier to use than VB. Would companies pay extra to convert their in-house apps to OSX? Dont't know. Would they pay to convert them to Linux? For sure. In that case, RealBasic would be the killer app for the Mac, that ironically would gain by being an afterthought in business app development.
I am also not a very experienced programmer but i am learnig cocoa and i am like wat i learn at several places in cocoa you see tricks/patterns that i think will be imposible to do in a general way if it was not obj-c (or smalltalk?) for example distibuted objects uses proxy objects the proxy objects do not undestand the message it is send but can react in a general way to that message. I imagine that this also make it easy to connect interface builder nib files to your program without inteface builder generating code you have to compile or maybe even in using java objects with the objective-c java bridge.
Well, I'm certainly not a very experienced programmer, so I've never come across an instance where a Java compiler can't figure out whether a particular method signature belongs to a particular class. However, if a compiler, any compiler, doesn't try to make that connection for the programmer, it leaves an even greater responsibility on the original developer of the code to properly document what exactly a method does. Then, that code is really only useful if the person who inherits/re-uses it reads, and can fully understand, what the original intent of the function was.
I don't see how a compiler can enforce human-interpretable coding conventions. Properly naming a method and its parameters should provide just as much documentability.
Anyone who spends a day or two with Objective C programming will understand the power available when the developer is in control of what messages get sent to an object. Imagine not having to recompile all of your code because you decided to add a method to one of your (or somebody else's) classes.
Why would you want/need to test whether an object responds to a message before sending it? Surely you know whether the objects you're using can handle the message you want to send. It is awfully convenient, though, to be able to add functionality to any class at runtime, and use its instances in ways its original author never considered.
...is basing their opinions on poorly-written applications, on the fact that for the most part, Swing sucks, or is not a very good programmer.
Them's the facts.
If you want the NeXTSTEP API's in Pure Java form, it's called WebObjects, and its a popular and powerful web application suite. Otherwise, you can use Java to access Cocoa on the Mac (Though it compiles to Native host bytecode and not Java bytecode)
Mac OS X is a UNIX system. And UNIX goes hand in hand with C. This is why Objective-C makes so much sense for Mac OS X programming: total access to C level stuff in the OS, and a very nice object model with an awesome framework. BTW, don't think about Objective-C as a equivalent to C++. They have nothing in common (except C). Objective-C is so much simpler and powerful than C++ !
Apple is on the right track with Objective-C.
Apple is on the right track with Objective-C.
I agree, but it is still (primarily) an Apple-only thing. GNUstep aside, there is virtually no Objective C activity out there. As long as it is only in use by Apple, others will look on it with disdain, and newcomers to Apple will struggle with Cocoa Java and Swing and Carbon, just to avoid learning a very easy and powerful foreign language.
How about some sort of "Objective Java" or "Objective C# for .NET" to get at the masses? Maybe combine that with a subset of Cocoa for Java/.NET (enough to provide simpler, more powerful user interfaces, but without all of the extras that make Cocoa everything it is on Mac OS X) we can get away with some of the bigotry.
I admit to some self-interest here. When I first came to Mac OS X, I didn't understand why anyone would want to use that weird Objective C syntax, when there was perfectly good C++ or Java available. After forcing myself to learn what Objective C can do, I realllly wish I could use it in my day job. They already let me use a PowerBook for UNIX development. Any possibility for creating instantly cross-platform applications would make it a shoo-in for a development platform. (Their current thinking is to use .NET and Windows Forms. Yuck! This is why I think that minimal Cocoa/Objective-C# would be almost necessary for Apple.)
The article is wrong on so many levels, let me just pick out a few:
1) Porting Cocoa to Java doesn't solve a single GUI-related problem, not one. Most of the APIs in Cocoa have equivalent counterparts in Java. This means that you don't gain any functionality by porting Cocoa to Java, you only get a different set of APIs that provide the same functionality as existing ones. What the author seems to want (from what I understand) is a single, efficient, and easy way to build GUI applications using something like Interface Builder. Wanting a tool similar to Interface Builder does not mean that you need the Cocoa APIs ported to Java.
2) Simply porting Cocoa APIs to Java does not solve the layout problem for cross-platform GUIs. The reason Interface Builder is so easy to use to build GUIs is because it doesn't have to worry about variable control sizes or font sizes, etc. NeXTStep and OpenSTEP solved this problem by having different nib files for different platforms. Sure you had to build multiple nib files, but they could be built according to each platforms design guidelines.
3) Porting the Cocoa APIs to Java does not solve the speed problem. Java GUI responsiveness suffers from using non-native widgets as well as performance problems in the Java VMs used. Unless you want Apple to undertake the burden of providing a native-GUI implementation for each and every platform then a Cocoa GUI based on Java will still be slow to the end user.
4) Porting Cocoa to Java does not magically increase Apple's market-share. The suggestion that Apple become a software company and open up more of their technologies to the open source movement is also a bad suggestion. Apple is, and will always be, a hardware company. Furthermore it is hardware companies that will do better in an open source marketplace. For example, IBM makes tons of money off of Linux by selling their hardware installed with Linux along with their own proprietary software and services. Sun on the other hand, has a declining UNIX business because they sell hardware with UNIX and not much else. They don't provide any value over purchasing commodity PC hardware and running Linux. Apple will thrive in an open-source marketplace because they sell great hardware and provide one of the best operating systems in the world along with great consumer software.
I won't even address the benefits of Objective-C and Cocoa. Much of what makes Cocoa great is because of its dynamic nature and the power of Objective-C that cannot be reproduced easily in other languages. The author is just wrong on so many levels.
What would be much more useful is if Apple would again port Cocoa and the Objective-C runtime to Windows and Linux. Doing this, and not porting it to Java, would be much easier and more valuable. CoreFoundation is already open via Darwin and I believe has already been ported to Windows and Linux (either via GNUStep or other means). Though I believe that this would be a good move for Apple I doubt that they'll do it in the near future.
As a community we should take it upon ourselves to port Cocoa to Windows and Linux via GNUStep. I know that the project desperately needs more Windows developers. Why should we wait for Apple to give us what we want? We need to do the work ourselves so that we will always have what we need.
I like your comment because it sees things very clear. Only one point I want to add a thought:
3) Porting the Cocoa APIs to Java does not solve the speed problem. Java GUI responsiveness suffers from using non-native widgets as well as performance problems in the Java VMs used. Unless you want Apple to undertake the burden of providing a native-GUI implementation for each and every platform then a Cocoa GUI based on Java will still be slow to the end user.
There are several implementations of serious algorithms in several languages on the web that have been written in C, Java, C#... whatever. Also you can easily test yourself. Except very special cases like trigonometric functions Java is not more than around 30% slower than pure C. This even turns wrong on multiprocessor machines, as Java scales, pure C/C++ does not. The reason is the possibility of Java to optimize running code, something C/C++ cannot do. When doing OO programming Java (and C#) even beats C++. So I don't think speed of the VM is a serious argument. (The only speed argument would be startup speed, something where the current Apple Java implementation really sucks).
Go and download a really good written Java program like jEdit (its free !) and run it with the current Sun VM on Windows and you immediately realize, that all this talking of slow Swing GUIs is only brainless repetition of something you do not understand. One can find countless slow GUI programs on sourceforge written in C/C++ and no one reasons from this that C/C++ is slow. They are simply poorly written.
The "non native" GUI implementation of Swing even has the advantage to implement graphics in OpenGL and use hardware acceleration, as will we started in the XWindows versions in Java 1.5. So, it will be hard to get a better GUI speed, which will, by the way, hard to sabotage by M$ on Windows.
The much-discussed Windows Implementation of OpenStep also did not use native widgets, just like Swing.
The problem with Objective C in the future will be, that in the moment C# gets large market share every new programmer will take garbage collection, bound checking, security, scaling on multiprocessors ect. for granted. As C# and Java will be the overwhelmingly used languages: Who will want to spend hours to track down memory leaks when not being a systems programmer. This is reminiscent to the usage of higher-level languages instead of assembler. Back then all "real programmers" stated that code from compilers is too slow, now assembler is used only in very special circumstances, as will be native compiling in future.
But Apple simply does not have the resources to create its own virtual machine and spread it. So they should work very hard on their Java implementation and maybe provide something like Cocoa or at least Interface Builder for pure Java
Except very special cases like trigonometric functions Java is not more than around 30% slower than pure C.
Yes, overall Java performance is very good. It is especially good when used in server applications. But GUI performance has lagged, at least on the Mac. I hardly ever use Windows or Linux, but on the Mac Swing and AWT performance has been very bad until recently. And even the latest 1.4.2 has its problems. The problem for this on the Mac has been less than stellar drawing/graphics performance in their Java implementation.
This even turns wrong on multiprocessor machines, as Java scales, pure C/C++ does not.
This isn't true. Java does scale well on multiprocessor machines when it is running a multi-threaded application, but a single-threaded GUI app will not and does not scale just because it is running on a machine with multiple processors.
Go and download a really good written Java program like jEdit (its free !) and run it with the current Sun VM on Windows and you immediately realize, that all this talking of slow Swing GUIs is only brainless repetition of something you do not understand.
No, I understand it very well. I have done a lot of Swing programming and it is much more difficult to achieve good GUI performance using Swing and Java than it is with the native toolkit (Cocoa). It can be done, but I've found it much easier to achieve good performance using native tools than with Java. Again, this is speaking from mostly a Mac perspective. It's mainly that the Mac Swing implementation has been lacking for a long time. I was always impressed by the Swing performance that I saw on my Windows coworkers' machines, it was always much better than on the Mac. Though I don't know how well it compared to native application performance.
The much-discussed Windows Implementation of OpenStep also did not use native widgets, just like Swing.
Yes it didn't use native widgets, but who's to stop anyone from making a native-widget implementation for GNUStep?
But Apple simply does not have the resources to create its own virtual machine and spread it. So they should work very hard on their Java implementation and maybe provide something like Cocoa or at least Interface Builder for pure Java
Why should it be Apple's responsibility to do this? Yes they should improve their own Java implementation, which they have been doing with their 1.4.1 & 1.4.2 releases. But why should Apple provide something like Cocoa or Interface Builder for pure Java? I think they should put their resources into making the current implementation of Cocoa better, not porting it to another platform. Apple should focus on making their OS, iApps, and development environment better. If the Java community wants a tool such as Interface Builder, then they should develop it themselves.
"I don't see how a compiler can enforce human-interpretable coding conventions. Properly naming a method and its parameters should provide just as much documentability. Anyone who spends a day or two with Objective C programming will understand the power available when the developer is in control of what messages get sent to an object. Imagine not having to recompile all of your code because you decided to add a method to one of your (or somebody else's) classes.
Why would you want/need to test whether an object responds to a message before sending it? Surely you know whether the objects you're using can handle the message you want to send. It is awfully convenient, though, to be able to add functionality to any class at runtime, and use its instances in ways its original author never considered."
The topic was Dynamic Binding which is a language feature (be is Java or Objective-C). The compiler and run time that must implement it, so the compiler should make sure that the programmer is following the proper definition of feature. If you're assuming that an object will respond to a particular message, then what's the point of using Dynamic Binding (at least the way it is defined by Objective-C)?
Poor touch typing + no glasses = lots of typing mistakes
The topic was Dynamic Binding which is a language feature (be iit Java or Objective-C). The compiler and run time must implement it, so the compiler should make sure that the programmer is following the proper definition. If not, could a debugger even tell you where the problem lay?
If you're assuming that an object will respond to a particular message, then what's the point of using Dynamic Binding (at least the way it is defined by Objective-C)?