public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Sturm <jsturm@sigma6.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: Maury Markowitz <maury@oaai.com>, java-discuss@sourceware.cygnus.com
Subject: Objective-C vs. gcj (was: Re: Newbie questions)
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <387CF708.C0499BC7@sigma6.com> (raw)
In-Reply-To: <200001121931.LAA05872@ferrule.cygnus.com>

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

  reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-01  0:00 Newbie questions Maury Markowitz
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Jeff Sturm [this message]
2000-04-01  0:00     ` Objective-C vs. gcj (was: Re: Newbie questions) Per Bothner
2000-04-01  0:00     ` Kresten Krab Thorup
2000-04-01  0:00       ` [OFFTOPIC] " Joerg Brunsmann
2000-04-01  0:00 Maury Markowitz
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00 ` Jon Olson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=387CF708.C0499BC7@sigma6.com \
    --to=jsturm@sigma6.com \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=maury@oaai.com \
    --cc=tromey@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).