Re: NO future for Cocoa-Java ?
Re: NO future for Cocoa-Java ?
- Subject: Re: NO future for Cocoa-Java ?
- From: The Karl Adam <email@hidden>
- Date: Fri, 8 Jul 2005 11:18:27 -0400
I'm not actually sure that is the case. While bridget requires you map
your selectors to method names for multipart selectors, it does
specify that the default is the first part of the selector. At the
same time, I don't think that the Cocoa-Java bridge is built on it,
but rather on what makes bridget work since WrapIt is dead and .jobs
files still work merely because Xcode still has code for dealing with
them.
I'd love for an open source alternative to the Java bridge to exist, I
myself have played in joining the runtimes manually and it is no small
feat. So, are there any plans or a budding project to provide an OSS
java bridge for ObjC?
-Karl
On 7/8/05, Bob Ippolito <email@hidden> wrote:
> On Jul 7, 2005, at 11:00 PM, Yvon Thoraval wrote:
>
> > Following XCode documentation latest's update i've seen that :
> >
> > - apple advise to switch from java to Obj-C ;
>
> Everyone else has been advising that since the beginning!
>
> I'm not really sure why anyone ever trusted it. Apple never really
> used it much themselves (publicly, anyway), so they don't have any
> internal pressures to keep it functional.
>
> > - no more bindings from java to cocoa interfaces after 10.4.
> >
> > the seems to be linked to apple's switch to Intel proc ...
>
> I highly doubt that it has anything at all to do with that. It's
> been languishing for a long time, they might as well put it out of
> its misery.
>
> > does that means that Cocoa-Java, never been really alive, i dead ?
>
> Cocoa-Java has never really worked quite right, and the way they
> decided to implement it was a massive burden on their developers.
> Basically, Apple made several huge mistakes. The Cocoa-Java bridge
> requires:
>
> - Mappings from every single Objective-C selector to some Java method
> - A completely separate set of documentation
> - Separate tests to make sure they didn't screw up anything in the
> mapping (I'm not convinced these ever really existed, but proper
> maintenance would've required them)
>
> This is obviously way too much work for little benefit. It *might*
> been worth it if a lot of people were using the Java bridge, but
> they're not. The Cocoa-Java bridge has never been reliable nor
> complete.
>
> Apple was never eating their own dog food with the Cocoa-Java bridge,
> despite the fact it's been available for years. There aren't any
> Apple applications that I'm aware of that use the Java bridge for
> anything, other than the maybe some WebObjects dev tools and possibly
> little bits of Xcode, so the Java-Cocoa bridge only really *has* to
> work well enough to support that. If the Cocoa-Java bridge was
> really a worthwhile technology, Apple would've shipped a product or
> two that used it in the past 5 years.
>
> Fortunately, other bridges have taken a different and sane approach,
> giving a 1:1 mapping between Objective C to/from the target
> language. Apple's Cocoa-Java bridge is actually the only one that
> does things the wrong way. Many of these bridges have real
> applications written in them and are an active target platform for
> new applications, so their maintenance is guaranteed (the open source
> bridges, anyway).
>
> There's no reason a third party couldn't develop a Cocoa-Java bridge
> that was done in a sane way, people have already done it for many
> other langauges (Python, Ruby, Perl, LISP, SmallTalk, etc.). Many of
> these are open source, so if someone wanted to develop a Cocoa-Java
> bridge that worked, they wouldn't have to look much farther than the
> PyObjC source code (the most functional and stable bridge) to see
> what's necessary to do it correctly.
>
> -bob
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden