[Samad]

What's the point of having an Obj-C to Java bridge for Cocoa? It seems pretty pointless to develop Cocoa applications in Java. Java already has its own windowing toolkit. Why did Apple decide to include Cocoa for Java?

[Chuckit]

I'm not one of the creators of Cocoa, but I'd imagine it's because Cocoa allows you to create native applications with ease, which Java's platform-homeless toolkits do not. And if you think Swing out of the box is as simple and elegant as Cocoa and Interface Builder, you've got another think coming.

[Angus_D]

Well, two reasons spring to mind.

Firstly, if you have a Java app you can give it a proper native OS X UI. Swing doesn't "feel" right.

Secondly, when OS X came out there was some suspicion of Obj-C, as it's kind of weird and nonstandard, and Java had been threatening to overtake the world. This is largely why WebObjects went Java - the market demanded it. That's where the bridge came from. I guess maintaining it for Cocoa was kind of hedging their bets in case everybody rejected Obj-C, or something.

Anyway, the bridge itself is deprecated and legacy, and I'd kind of expect Cocoa-Java to go that way at some point in the future too.

[larkost]

a) Swing and AWT both suck in comparison to what ProjectBuilder produces (both in speed and in methodology)

b) A good chunk of the work was already done for the with-good-reason transition of WebObjects from Obj-C (script) to Java

c) There are a lot of developers out there that know Java, fewer that know Obj-C

d) Java is a great language and has advantages over Obj-C in being more Object oriented in some aspects (Obj-C has advantages in others... like categories)

e) It allows developers to include existing codebases written in Java, even if they are writing their programs in Obj-C. There are many great libraries out there for Java.

f) Using the bridge method allows Apple to fairly easily keep (Obj-C) Cocoa and Cocoa-Java in sync

g) Why not?

[Samad]

Unix went through a phase during the 80's where many companies developed their own versions. As each company's Unix evolved, each began to have different APIs, data structures, etc. This greatly fractured the Unix community and nearly killed it. A program on one Unix became difficult to port to another Unix. Sun recognized this, and has tried very, very hard to maintain a uniform Java. If each company made their own Java GUI toolkits and APIs, this would, like what happened to Unix, greatly fracture the Java world. Microsoft has tried to fracture the Java community by a) introducing APIs specific only to Windows and b) introducing C#. Sun seems to be doing well in maintaining uniformity across Java, because Microsoft's attempts haven't been very successful. Even though Cocoa is far easier than Swing (or the God-forsaken AWT), it would seem logical that Apple would respect the continuity of Java.

[larkost]

Apple offers a fully functional Java environment. They are not subtracting anything. Are you proposing that they not allow access to any of the frameworks that make MacOS X what it is in order to keep the "continuity of Java"? Because that is what we are talking about here.

[Chuckit]

Originally posted by larkost:
d) Java is a great language and has advantages over Obj-C in being more Object oriented in some aspects (Obj-C has advantages in others... like categories)

In what aspects is Java more OO than Objective-C, aside from the fact that it can't include C? My Java knowledge is a little bit limited, but I would have thought the opposite was true.

[itistoday]

Take a look at Acquisition. That's an application with an amazing UI written using cocoa-java. It would be impossible to write that application using Swing/AWT or even SWT. Cocoa-java provides java developers with an extremely fast UI (compared to anything else that java has), OS X integration, ability to subclass any cocoa class, etc. It basically means that if you don't like Obj-c, and prefer Java (a lot of people do), then you can write Cocoa applications in Java, that will have virtually the same features as Cocoa apps (ability to use Services, built-in spell checking, etc).

Also, even if you're intending to write a cross-platform application, you can have the GUI on OS X done in cocoa-java, and something else for the other platforms, while keeping the rest of the code (none UI stuff), completely Java.

[Angus_D]

Originally posted by itistoday:
Take a look at Acquisition. That's an application with an amazing UI written using cocoa-java.

Actually, I'm fairly sure Acquisition's UI is written using Cocoa-ObjC. The core is written in Java, and runs in a separate process to get around the GPL issues - they communicate with a pipe.

[itistoday]

Originally posted by Angus_D:
Actually, I'm fairly sure Acquisition's UI is written using Cocoa-ObjC. The core is written in Java, and runs in a separate process to get around the GPL issues - they communicate with a pipe.

Hmmm... you sure? Why would he choose to write the UI in ObjC? That seems to complicate things for no reason. I think I downloaded the source one day and all I saw was .class files.

[Chuckit]

Originally posted by itistoday:
Hmmm... you sure? Why would he choose to write the UI in ObjC? That seems to complicate things for no reason.

If you're communicating through a pipe anyway, it doesn't particularly complicate things to use a different language on each end.

I think I downloaded the source one day and all I saw was .class files.

Where did you get the source? As far as I can tell, only the LimeWire part of Acquisition is open-source.

[itistoday]

Originally posted by Chuckit:
If you're communicating through a pipe anyway, it doesn't particularly complicate things to use a different language on each end.
Where did you get the source? As far as I can tell, only the LimeWire part of Acquisition is open-source.

Uh, can't find the site now... somewhere on xlife.org I think, some sub-directory...