[108] in java-interest
Binding in Java
daemon@ATHENA.MIT.EDU (David Hopwood)
Mon May 22 20:01:08 1995
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
To: java-interest@java.Eng.Sun.COM
Date: Tue, 23 May 1995 00:47:03 +0000 (BST)
> > > > #3. Am I correct in thinking that, like C++, the compiler
> > > > knows either
> > > > A) The address of the destination method, or
> > > > B) The address of a pointer to the destination method
> > > > in every case, at compile time?
> > >
> > > No. Everything is bound lazily at runtime.
> >
> > Yes, but there are various ways of doing runtime binding.
> > In C++, each class has a vtable (array of pointers to methods),
> > and the offset within that table for each call is known statically.
> > The code for a dynamic call is something like:
> > *((*(receiver->vtable)) [offset]) ();
>
> Unfortunately, if the offset changes you have to recompile your
> program. That makes C++ a very bad choice for writing long lived
> libraries.
Yes, I agree.
> Changes the API of objects often means that you have
> to recompile all the code that uses the API. This is avoided in
> Java by determining the offset at link time.
At link time? I haven't come across that solution before. Let me
make sure I understand this.
In the unlinked form of a class, method calls specify a global
selector (the same on all systems, and unique to that method).
When you link the class into a particular system, the calls are
patched to use the local offsets for each selector (so the
loader or whatever must maintain a map between these two forms).
From then on, you can do binding much as in C++, providing you
are calling objects declared as classes, not interfaces.
If you are calling something declared as an interface, the binding
has to be determined entirely at run-time, similar to Smalltalk
or Objective-C. Ie. you look up the global selector in a hashtable,
then cache the results for later.
Is this right?
(BTW, this stuff is not at all obvious from the docs. I think it
would help a lot of people to know how it is implemented).
>
> > > > Q2: Since C programs can do this, and since they might
> > > > make a non-existant call, don't you need a
> > > > NoSuchMethod exception as well? (or did I miss that
> > > > while reading the manual)
> > >
> > > C programs are "unsafe". If the method does not exist you
> > > will get an IncompatibleClassChangeException.
> >
> > What if the method does exist, but the arguments are of
> > incompatible types (or you have the wrong number of arguments)?
> >
> > Also, what happens if that method name is overloaded? Which method
> > gets called?
>
> The C program must specify an exact method signature. If the
> method signature doesn't match exactly you will get an exception
> and the method won't be called.
If I read the docs in http://java.sun.com/1.0alpha2/doc/rpi/rpi_1.html
correctly, there is no way for the C program to know the call is safe.
I'd really like some way of checking this from C (for arbitrary calls).
David Hopwood
david.hopwood@lmh.ox.ac.uk
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
