United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4300222 RFE: Object Oriented Callbacks
JDK-4300222 : RFE: Object Oriented Callbacks

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Affected Versions:
Fixed Versions:

Related Reports

Sub Tasks

Name: mc57594			Date: 12/16/99

java version "1.1.3"  (<<<-- 1.1.3, or 1.3? )

Has anyone considered the possibility of adding object-oriented callbacks to
Java?  The idea would be to define an object which can receive a reference to an
object and an associated member function for later execution.  Such an object
could be declared as follows:
    <b>callback</b> type <i>callbackName</i>(type1,type2,...);

The <i>callbackName</i> is initially empty.  If you call it as a function,
nothing happens and in the case of a non-void return type a <b>null</b> is
returned.  However, you could at some point make the following assignment:
    callbackName = myObject.myFunction;

This would be checked at compile time to make sure that <i>myFunction</i> is a
member of the class of <i>myObject</i> and that its argument and return types
match those of <i>callbackName</i>.  If <i>myFunction</i> is overloaded, the
appropriate version is selected.  At any rate, when <i>callbackName</i> is
called with the appropriate arguments, it is as though
<i>myObject.myFunction</i> is called with those arguments.  Later, if you assign
<b>null</b> to <i>callbackName</i>, subsequent calls to <i>callbackName</i>
would do nothing (or return <b>null</b>).
You could also compare <i>callbackName</i> to <b>null</b> and change the
behavior of the containing object depending on if anything is assigned to
<i>callbackName</i> or not (kind of like plugging in
an earphone to disable the loudspeakers on a radio.
Such a feature would be extremely straight-forward to deal with. Rather than
declaring a function to be overridden in a derived class (or anonymous class),
you would simply create your component objects and then, in effect, wire them
together.  You could even imagine graphical representations of these wires which
are objects with position and other visual characteristics.  These would simply
be objects with input functions and output callbacks which are in turn wired to
other visual objects.
Although this kind of thing can be implemented with Reflection, it would have
none of the complexity and overhead of Reflection.  Chances are it would be
widely used if it were available.
It also has none of the limitations of interfaces.  An Interface is sort of like
a set of standard bus pins on a card.  Plug it in and it does whatever it does.
That is all well and good but what you might really want is a chip you could
mount on a board with however many connections hooked together in whatever way
you need it.
Internally a callback would probably be stored in much the same way as an
interface reference is.  When you assign an object whose class contains an
interface to an interface object what is really stored is an object reference
and an offset into the method table for that object.  That is exactly what is
needed here.
Ben Jones
(Review ID: 98897) 

The page on which I submitted a bug fix was messed up first by not
taking my supplied HTML
tags into account and by not taking preformatting into account in my
followup post.  Here is the
corrected page.
There's nothing I can do about this.
Internally, the bug is as you sent us.
When the bugs are pulled out of the database
and put on the web site (nightly), they
do some conversions.

Looks like they convert all '>' to '&gt'.
Good idea, though.

Mark Chamness



This is essentially a request for closures (except that the requestor does not
seem to know what closures are). I'm all for it.

gilad.bracha@eng 1999-12-17

Name: mc57594			Date: 12/16/99

This is not a bug.  This is a serious idea for an improvement to the Java
Language which I hope you will consider carefully.  I have very detailed ideas
on this subject, if you are interested in hearing them.

Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot).

All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1.

This specific request to change the Java programming language is related to the work of OpenJDK Project Lambda. It will be considered further by that project, not here.

The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.

Hardware and Software, Engineered to Work Together