public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Objective-C vs. gcj (was: Re: Newbie questions)
  2000-04-01  0:00 Objective-C vs. gcj (was: Re: Newbie questions) Maury Markowitz
@ 2000-04-01  0:00 ` Jon Olson
  2000-04-01  0:00 ` Jeff Sturm
  1 sibling, 0 replies; 6+ messages in thread
From: Jon Olson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Maury Markowitz, Jeff Sturm; +Cc: java-discuss

On Thu, 13 Jan 2000, Maury Markowitz wrote:
>> with GCC in the gcc/objc directory) and is useless without it.  It 
>> handles all the method dispatching and dynamic binding required by the 
>> Obj-C language.
>
>  Right.  That method dispatching and dynamic binding is rather  
>similar to Obj-C's though, and not by coincidence.
>

Java actually has binding semantics much more akin to C++ than
Obj-C.  In addition to the relative unpopularity of Obj-C, C++ was
a much better choice for the CNI interface than Obj-C would have been.
Java doesn't do dynamic binding like does Obj-C, but rather performs
run-time checking of downcasts.

In Obj-C, all bindings are made at run-time via signatures generated
by the compiler.  This is because Obj-C allows a method to be dispatched
on an `id' without any compile time knowledge of whether or not that object
actually implements that method.  Thus, at run-time each object references
its class metadata via an `isa' pointer, and each class references some sort
of hash table or sparse array as in the following diagram:

				Superclass metadata
				        ^
	-----------   isa	        |
	| Obj-C object | ----> Class metadata ---> run-time hash-table
            ----------- 

C++ and Java, on the other hand, are strongly typed and only dispatch
methods to objects known to actually have the method.  Their run-time
representation is typically much different:
 
            ------------- vtable
	| C++/Java object | ----> Method Dispatch Table
	-------------		|
					v
				  Class metadata, if it exists

In C++ and Java, method dispatch (except for interfaces) is performed based
on indices unique only to the class being dispatched;  in Obj-C, method dispatch
must be performed on selectors which are GLOBALLY unique.  Because of Obj-C's
radically different binding semantics, it would be a poor language for
implementing any sort of compile-time binding.

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
INTERNET:  olson@mmsi.com
PHONE:     (520)746-9127
FAX:       (520)889-5790

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Objective-C vs. gcj (was: Re: Newbie questions)
@ 2000-04-01  0:00 Maury Markowitz
  2000-04-01  0:00 ` Jon Olson
  2000-04-01  0:00 ` Jeff Sturm
  0 siblings, 2 replies; 6+ messages in thread
From: Maury Markowitz @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

> with GCC in the gcc/objc directory) and is useless without it.  It 
> handles all the method dispatching and dynamic binding required by the 
> Obj-C language.

  Right.  That method dispatching and dynamic binding is rather  
similar to Obj-C's though, and not by coincidence.

> These two libraries can probably coexist in one address space, but that 
> isn't very useful unless Obj-C code can call Java code, which it can't 

  Exactly.

> strongly suspect the answer has mostly to do with the popularity of C++ 
> and relative obscurity of Obj-C, though there may be technical  
issues as
> well.

  And of course the popularity of Java and "impopularity" of Obj-C  
is why I'm here.

> some other language could share the libgcj runtime.  If the Obj-C
> frontend is to have a meaningful existence in the future, it should 
> probably abandon its current runtime and embrace libgcj.

  Right, this is exactly what I am interested in.  Essentially if a  
little bit of API was added to the libgcj runtime I think you'd have  
enough support to also run Obj-C code with the same runtime.  Now you  
have a lib that works on two languages.  This would need some  
changes in the Apple base class, NSObject, but I'd want to do that  
anyway to take advantage of reflection and gc, which is LONG overdue  
in Obj-C anyway.

  But what exactly would this entail?  I'm not a compiler guy  
although my boss is pretty good at this, and is pretty excited by  
these prospects as well.  What I'm trying to fathom is just what  
level of effort would be required.  If I can get a good list of  
"here's the tasks", I can take that and start working.

  A guess right now...

1) Obj-C has a "2nd guess" attempt to deliver messages to objects.   
This is done via a combination of support in Obj-C's runtime and some  
minor support in the root object.  Essentially when a method is  
called on an object it does a lookup in the same way that Java does.  
If that method is not supported the runtime then creates a new object  
(in Obj-C this is an NSInvocation object) and then passes that  
invocation back into the original object, calling "forwardInvocation"  
I believe.  NSObject's default behaviour is to raise a "method not  
supported" exception, but if you override that method you get the  
invocation (which is a wrapper of the name of the method and the  
types of arguments) so you can break it out and do something with it,  
like forward it to another object.

2) Obj-C includes categories.  This would require a new function in  
the runtime to allow function pointers in the method lookup table to  
be replace with new function pointers, and the addition of new  
methods into the dispatch table.

3) Obj-C includes the concept of a "Selector" (type SEL) which is a  
unique string associated with any particular method.  This is used   
to uniquely identify object/message names.

4) Obj-C allows for one object to replace some other.  This would  
require API in the runtime to deal with this.  Essentially it means  
that all calls to "MyObject" simply get forwarded to "MyOtherObject".

5) One missing piece from both runtimes is the ability to re-link  
objects at runtime.  All this means is that you want to be able to  
push a class out and then back in at runtime (Java kinda supports  
this already).  Combined with some support at the IDE level, this  
allows for "link and go", you recompile just that object and keep  
running your app - this makes debugging a lot more fun!

  Changes to the Obj-C compiler would also be needed, to call any  
different API in the runtime, and the Apple object set would likely  
need some updates to support it.  However one thing I would want was  
a re-write of these classes to make sure they are directly callable  
from Java anyway.

> handy.  The Object class differs somewhat from java.lang.Object, but 
> that could be possibly be remedied by making Object a subclass of
> java.lang.Object, or maybe even introduce a new root class.

  Actually for my needs I'd be changing NSObject, although I see the  
benefit here.  I'm curious though, does anyone outside the OS-X  
world actually use Obj-C for deployed apps any more?

> He means Objective-C doesn't do any compile-time binding or even
> checking of method invocations.  Every instance variable can be  
declared
> as "id" which is equivalent to Java's java.lang.Object class.  If a 

  Although this has very practical reasons for existing. It makes  
the creation of interactive GUI editors far easier for instance.

> Note that the Java _language_ is strongly typed though bytecode is 
> not... all names are dynamically resolved from bytecode, just as in 
> Obj-C.

  Which is interesting if you think about it.

> categories.  It's not the same as inheritance, somehow.  Sort of like 
> peer objects, as in java.awt, only more transparent.

  Exactly.  The functionality is doable with Java, but it's simply  
WAY easier and invisible under Obj-C.

> Objective-C has a neat feature which makes it extremely simple to write 
> delegate classes.  The runtime attempts to dispatch a method invocation 
> [snip]
> Similar tricks could be performed with Java reflection, I'd guess. 

  That's interesting.  Ahhh, do you mean that we could use the  
reflection API in the runtime to see if the method is there and then  
re-dispatch?  Hmmm, that might be a "better" (as in leveraging  
existing functionality) solution that Obj-C's in fact.

Maury

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Objective-C vs. gcj (was: Re: Newbie questions)
  2000-04-01  0:00 Objective-C vs. gcj (was: Re: Newbie questions) Maury Markowitz
  2000-04-01  0:00 ` Jon Olson
@ 2000-04-01  0:00 ` Jeff Sturm
  1 sibling, 0 replies; 6+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Maury Markowitz; +Cc: java-discuss

Maury Markowitz wrote:
> > Objective-C has a neat feature which makes it extremely simple to write
> > delegate classes.  The runtime attempts to dispatch a method invocation
> > [snip]
> > Similar tricks could be performed with Java reflection, I'd guess.
> 
>   That's interesting.  Ahhh, do you mean that we could use the
> reflection API in the runtime to see if the method is there and then
> re-dispatch?  Hmmm, that might be a "better" (as in leveraging
> existing functionality) solution that Obj-C's in fact.

Yes, Java reflection can do that.  In fact, if we fully supported JNI,
you could implement a proxy in Obj-C that would forward messages to the
libgcj runtime.  Essentially you could wrap a Java class in an Obj-C
class that way.

Without JNI, it would be harder... the libgcj runtime is mostly C++ and
Java, and you'd have to find some way to interact with the GC.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Objective-C vs. gcj (was: Re: Newbie questions)
  2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
  2000-04-01  0:00     ` Per Bothner
@ 2000-04-01  0:00     ` Kresten Krab Thorup
  1 sibling, 0 replies; 6+ messages in thread
From: Kresten Krab Thorup @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Tom Tromey, Maury Markowitz, java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> > When you say "weak" typing, what do you mean?
> 
> He means Objective-C doesn't do any compile-time binding or even
> checking of method invocations.  Every instance variable can be declared
> as "id" which is equivalent to Java's java.lang.Object class.  

Equivalent is not quite right.  The type `id' is a super-type for all
other types (including root classes such as Object); and indirections
(i.e., method calls) via a reference of type `id' are runtime
type-checked.  The compiler will issue warnings in some cases, i.e.,
if it has not "seen" a method declaration with the given name.

> method name is misspelled or can't be resolved at runtime for any
> reason, a runtime error is thrown and the program generally aborts
> (which I consider a drawback of the language).

Right.

> Note that the Java _language_ is strongly typed though bytecode is
> not... all names are dynamically resolved from bytecode, just as in
> Obj-C.

Java byte-code is stronly type checked.  The Verifier implements
almost the exact same semantics checks as the compiler does.

> > What is categorization?

The term `categories' stems from Smalltalk terminology.  In the file
format for `filing in' code in a ST system, there is syntax that
allows methods to be added to existing classes.  This is exactly the
functionality of categories.  In Objective C, such categories can be
loaded at runtime.

> Objective-C has a neat feature which makes it extremely simple to write
> delegate classes.  The runtime attempts to dispatch a method invocation
> to the named method, but if a method is not found it defaults to the
> "forward:" (?) method, which can be overridden to route the invocation
> to another object, or even marshal the arguments for delivery to a
> remote object.  Obj-C had a very elegant solution to distributed
> programming that way.
> 
> Similar tricks could be performed with Java reflection, I'd guess.

In Java, this is not possible; it would require a change to the
language semantics.  The new 1.3 proxy stuff does something that comes
close, though.

-- Kresten

 Kresten Krab Thorup           "I like my eggs ploded"
 Department of Computer Science, University of Aarhus
 Aabogade 34, DK-8200 Aarhus N, Denmark
 +45 8942 5665 (office), +45 2343 4626 (mobile)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Objective-C vs. gcj (was: Re: Newbie questions)
  2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
@ 2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00     ` Kresten Krab Thorup
  1 sibling, 0 replies; 6+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Back when the GCJ project first became public, I was a little curious
> why the C++ frontend was chosen for native integration, when Obj-C is
> available and much closer to Java in spirit (both languages rely heavily
> on runtime method dispatch, both have single-inheritance, etc.).  I
> strongly suspect the answer has mostly to do with the popularity of C++
> and relative obscurity of Obj-C, though there may be technical issues as
> well.

Using Obj-C never ocurred to us, and I suspect it wouldn't have made sense.
One reason is that Cygnus has never supported Obj-C in its products
(customers get it as an unsuuported freebie), or done noticable work on it,
so we didn't have in-house expertise.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Objective-C vs. gcj (was: Re: Newbie questions)
  2000-04-01  0:00 ` Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00     ` Kresten Krab Thorup
  0 siblings, 2 replies; 6+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Maury Markowitz, java-discuss

Tom Tromey wrote:
> Maury> First and foremost I'm curious about the ability for gcj's
> Maury> compiled code to be used as libraries for Obj-C code on top.
> Maury> IE, if I were to use gcj and it's associated libs, what sort of
> Maury> work effort would it be to have them work as Obj-C libraries?
> Maury> Is library format an issue at all? (I'm assuming not, but I'll
> Maury> ask to be sure) Is the main issue going to be supplying a
> Maury> selection of wrappers in the form of .h files?  It "feels" like
> Maury> there is a runtime changed needed to Obj-C, and I'm curious if
> Maury> anyone could comment on the level of change needed, if any?

Wow.  It's been awhile since I've even heard Obj-C mentioned, let alone
done any  work with it... I'll take a stab at your questions though.

> libgcj is just a library like any other library.  It just happens to
> be implemented in a miaxture of C++ and Java.  However, it has some
> requirements that other libraries probably don't have.  For instance,
> it relies on the existence of a garbage collector (this isn't the only
> requirement, but it is one of the big ones).

But libgcj is gcj's runtime, and gcj-compiled code can't run without
it.  Similarly, the Objective-C compiler has a runtime (it is bundled
with GCC in the gcc/objc directory) and is useless without it.  It
handles all the method dispatching and dynamic binding required by the
Obj-C language.

These two libraries can probably coexist in one address space, but that
isn't very useful unless Obj-C code can call Java code, which it can't
right now.  (It could via JNI, once JNI is implemented, but that's not a
very pretty way to go about it.)

> You can use this library from C++ right now.  Using it from ObjC would
> require knowing how to make the library bootstrap (not too hard), plus
> a knowledge of how to call C++ from ObjC (we've purposely made
> compiled Java mostly compatible with compiled C++; I don't know
> anything about ObjC so I can't help you there).

Unfortunately, the Obj-C and C++ frontends don't work together.  (NeXT
had made the changes necessary to mix C++ and Obj-C, even within one
source file, but their changes never made it back into the GCC
distribution.)

Back when the GCJ project first became public, I was a little curious
why the C++ frontend was chosen for native integration, when Obj-C is
available and much closer to Java in spirit (both languages rely heavily
on runtime method dispatch, both have single-inheritance, etc.).  I
strongly suspect the answer has mostly to do with the popularity of C++
and relative obscurity of Obj-C, though there may be technical issues as
well.

> However, that doesn't mean I'm necessarily in favor of making any
> extensions to the Java language.  I'm pretty sure you'd be on your own
> in terms of implementing the changes; there are too many pieces still
> missing for us (meaning those of us at Cygnus hacking gcj, or at the
> very least just me) to do this sort of thing.  Another factor is that
> every extension makes the compiler more difficult to understand and
> modify.  I'm told the C++ compiler hackers have found random g++
> extensions to be a real pain over time, so this is something to be
> wary of.

I would personally steer clear of extending the Java frontend, for the
same reasons as Tom.  That doesn't rule out the possibility though that
some other language could share the libgcj runtime.  If the Obj-C
frontend is to have a meaningful existence in the future, it should
probably abandon its current runtime and embrace libgcj.  Most of what's
there is Java-centric, but it could likely be used for Obj-C as well. 
The Java reflection stuff that Tom just finished would certainly come in
handy.  The Object class differs somewhat from java.lang.Object, but
that could be possibly be remedied by making Object a subclass of
java.lang.Object, or maybe even introduce a new root class.

(These are just ideas off the top of my head... I won't be working on it
since I quit Objective-C programming at least 5 years ago.)

> When you say "weak" typing, what do you mean?

He means Objective-C doesn't do any compile-time binding or even
checking of method invocations.  Every instance variable can be declared
as "id" which is equivalent to Java's java.lang.Object class.  If a
method name is misspelled or can't be resolved at runtime for any
reason, a runtime error is thrown and the program generally aborts
(which I consider a drawback of the language).

Note that the Java _language_ is strongly typed though bytecode is
not... all names are dynamically resolved from bytecode, just as in
Obj-C.

Java still provides class casts, which allows you to sort of defeat the
type system, though ClassCastException is thrown on illegal casts. 
Casts tend to be widely used anyway in Java, especially with
collections, since (as in Obj-C) Java has no support for templates or
generic types.

> What is categorization?

I can't think of a good analogy... IIRC Obj-C supports extending
existing classes (adding methods, instance members, etc) using
categories.  It's not the same as inheritance, somehow.  Sort of like
peer objects, as in java.awt, only more transparent.

> When you say "proxies", what do you mean?

Objective-C has a neat feature which makes it extremely simple to write
delegate classes.  The runtime attempts to dispatch a method invocation
to the named method, but if a method is not found it defaults to the
"forward:" (?) method, which can be overridden to route the invocation
to another object, or even marshal the arguments for delivery to a
remote object.  Obj-C had a very elegant solution to distributed
programming that way.

Similar tricks could be performed with Java reflection, I'd guess.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Objective-C vs. gcj (was: Re: Newbie questions) Maury Markowitz
2000-04-01  0:00 ` Jon Olson
2000-04-01  0:00 ` Jeff Sturm
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Newbie questions Maury Markowitz
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00     ` Kresten Krab Thorup

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).