Re: Question about Java updates installed?

In comp.lang.java.advocacy, Tor Iver Wilhelmsen
<jadedgamer@xxxxxxxxxxx>
wrote
on 26 Jun 2006 23:48:33 +0200
<uzmfzoafi.fsf@xxxxxxxxxxx>:
The Ghost In The Machine <ewill@xxxxxxxxxxxxxxxxxxxxxxx> writes:

But these things happen. :-)

However, it's apparently good when Sun/JCP does it, and bad when
Microsoft did it. :P

("delegate" and "multicast" in J++ 1.1 and the MS JVM, in case you've
forgotten.)

There's a few other thingies in there as well but I'd frankly have to
look. The good news: Sun and MS have kissed and made up.

The bad news: according to

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnjpp/html/msdn_delegates.asp

J++ allowed such things as:

delegate long IntOp(int a, int b); // not sure *where* this was put

public class K1 {
public long add(int a, int b) { return a+b; }

}

public class K2 {
public void test()
{
K1 k1 = ...;
IntOp op = new IntOp(k1.add);
long c = op.invoke(2,3);
}
};

This is actually pretty interesting syntax, but now there
are easier methods by which one can invoke add(); one can
either encapsulate the add method in an interface and then
use static JMX MBeans, if one's within a web context (e.g.,
JBoss) that allows such:

import javax.management.*;
public interface K1MBean {
public abstract long add(int a, int b);
};

public class K1 implements K1MBean {
public long add(int a, int b) { return a+b; }
};

public class K2 {
ObjectName k1Name = "...";
MBeanServer server = "...";

void test() throws Exception {
int c = ( (Integer) (server.invoke(k1Name, "add",
new Object[]{new Integer(2), new Integer(3)},
new String[]{"int", "int"}))).intValue(); }
};

or use introspection:

import java.lang.reflect.*;
public class K1 {
public long add(int a, int b) { return a+b; }
}

public class K2 {
void test() throws Exception
{
K1 k1 = ...;
Method m = k1.getClass().getMethod("add",
new Class[]{Integer.TYPE, Integer.TYPE});
m.invoke(k1,
new Object[]{new Integer(2), new Integer(3)});
}
};

or simply use interfaces:

public interface I1 {
public abstract long add(int a, int b);
};

public class K1 implements I1 {
public long add(int a, int b) { return a+b; }
};

public class K2 {
void test() throws Exception
{
I1 k = ...;

long c = k.add(2,3);
}
};

depending on one's needs and the interface hierarchy.
One of the more interesting constructs in Java, which was
first introduced either in 1.2 or 1.3, is

I1 k = new I1() { public long add(int a, int b) { return a+b; } }

which, IINM, is called an anonymous class declaration, with
method overrides. Very neat stuff for this sort of thing.

A multicast delegate was also possible.

multicast delegate void
MouseEventHandler(Object sender, MouseEvent e);

...

class MyForm extends Form {

Button myButton = new Button();
void myButton_mouseMove(Object sender, MouseEvent e)
{
...
}

void initForm()
{
myButton.addOnMouseMove(new MouseEventHandler(
this.myButton_mouseMove));
}
}

This is not Java, of course. Java might replace this code with:

class MyPanel extends Panel {
Button myButton = new Button();

public MyPanel() { super(); initForm(); }

void myButton_mouseMove(Object sender, MouseEvent e)
{...}

void initForm()
{
final MyPanel thisPanel = this;

myButton.addEventListener(new MouseMotionListener() {
public void mouseDragged(MouseEvent e) { }
public void mouseMoved(MouseEvent e) {
thisPanel.myButton_mouseMove(this, e);
}
});
}
};

(there is no Form in AWT; Panel is a rough equivalent).

The contract for widgets who generate mouse movements
is to call all listeners in an indeterminate order.
Therefore, 'multicast' is largely unnecessary now.

Slightly more cumbersome since one has to implement all the
methods, but that's usually not a big deal, though
one can also use

myButton.addEventListener(new MouseMotionAdapter() {
public void mouseMoved(MouseEvent e) { ... }
});

instead.

I'm of two minds of the perversions in C# that allow

a.f = 1;

to pervert into

a.setF(1).

Neat and convenient, on the one hand, but on the other,
how do we know this is being done? And when will it be done?

The aforementioned webpage has some interesting commentary, proudly
declaring that:

Interfaces have a number of shortcomings that limit their
usefulness:

[1] A class can only implement an interface once.

[2] Name collisions between interface members sometimes make it
impossible to implement multiple interfaces.

[3] A class that implements an interface must expose the implemented
members publicly.

and that:

Delegates do not suffer the same problems as interfaces. Taking the
points above individually:

[4] A class can implement as many methods as it pleases, and
create any number of delegate instances that wrap these
members. This makes it possible to define all event handlers
for a form on the form class itself; adapter classes are not
needed.

[5] There is no such thing as a "name collision" for a
delegate. A method is compatible with a delegate if its
signature and return type match the delegate's; the name
of the method is immaterial.

[6] Delegates can wrap private members, so it is possible
to keep event handlers private--a highly desirable
capability--without using adapter classes to hide them
away.

[1] is true enough, although anyone who knows about the "diamond"
multiple inheritance problem knows *why* a class should only implement
an interface once. Besides, which one would the caller want? If this
is a real problem unnamed adapters would be a perfect choice; one
can declare as many as necessary.

[2] is not a bug, but a feature.

[3] The whole point of an interface is to expose selected members of a
class. It's a *contract*, as in "if you implement this interface,
callers must be able to call you through this interface and get at least
somewhat expected results". Java's innovation -- if it is Java's,
admittedly -- is to allow multiple contracts with the same signature,
without allowing multiple inheritance and neatly avoiding the "diamond"
problem.

[4] One can use unnamed adapters here.

[5] There's not much of an issue with name collisions on an unnamed
adapter class, either.

[6] I'm not sure event handlers are all that visible here anyway,
although in a pinch I suppose one could get the list and start poking
through it. What good that'll do, I for one don't know.

--
#191, ewill3@xxxxxxxxxxxxx
Windows Vista. Because it's time to refresh your hardware. Trust us.
.