Michael Herrmann

That's a pity but good to know - thanks!

Hi everyone,

I have the following class declaration:

public class EventBroadcaster<E extends Event<?>, L extends EventListener<E>> { ... }

I would like to remove the (redundant) declaration of E as follows:

public class EventBroadcaster<L extends EventListener<E>> { ... }

Note that the information about E is still there, as it is a generic parameter to EventListener<E>. Does anyone know whether that is possible? It does not compile.

Thank you very much in advance!

The first few chapters of this book (which you can legally read online if you follow the link) concern exactly what you've asked about.

I just generified Constraint (David Saff mentioned generified generics on the junit mailing list). It looks like this (I don't need instanceOf any longer):

package at.mherrmann.test; public abstract class Constraint<T> { protected final Constraint<T> predecessor; protected Constraint() { this(null); } protected Constraint(Constraint<T> predecessor) { this.predecessor = predecessor; } public static final <T> Constraint<T> eq(final T a) { return new Constraint<T>() { public boolean evil(T b) { return a == null ? b == null : a.equals(b); } }; } public static final <T> Constraint<T> g(final Comparable<T> a) { return new Constraint<T>() { public boolean evil(T b) { return a.compareTo(b) < 0; } }; } public static final <T> Constraint<T> geq(final Comparable<T> a) { return new Constraint<T>() { public boolean evil(T b) { return a.compareTo(b) <= 0; } }; } public static final <T> Constraint<T> l(final Comparable<T> a) { return new Constraint<T>() { public boolean evil(T b) { return a.compareTo(b) > 0; } }; } public static final <T> Constraint<T> leq(final Comparable<T> a) { return new Constraint<T>() { public boolean evil(T b) { return a.compareTo(b) >= 0; } }; } public static final <T> Constraint<T> not(final Constraint<T> c) { return new Constraint<T>() { public boolean evil(T o) { return !c.evil(o); } }; } public static final <T> Constraint<T> same(final T a) { return new Constraint<T>() { public boolean evil(T b) { return a == b; } }; } public final Constraint<T> and(final Constraint<T>... constraints) { return new Constraint<T>(this) { public boolean evil(T o) { for (Constraint<T> c : constraints) if (!c.evil(o)) return false; return this.predecessor.evil(o); } }; } public abstract boolean evil(T o); public final Constraint<T> or(final Constraint<T>... constraints) { return new Constraint<T>(this) { public boolean evil(T o) { boolean result = this.predecessor.evil(o); for (int i = 0; i < constraints.length && !result; i++) result = constraints[i].evil(o); return result; } }; } }

Then practice on a daily basis. Go out often and talk to every woman that attracts you everywhere (in the train, the mall). Make picking up women a game. Try things out. Find things they respond positively to. Be confident. You've got nothing to loose. And, for god's sake, don't try to persuade women into liking you by bringing them flowers, paying for dinner etc. -> Don't act needily (it's all supply and demand: if you chase a woman there's supply but no demand, if you act confident and show NO interest in her and make it look like she's the one who's chasing you, you create demand).

And looks are not as important to women as they are to men. How you behave is much more important.

So your goal is to be good with women?

Ok, so there's no choice but to suppress the warnings. I'll do that, thanks.

Noone has got an idea?

Oh. It seems that I can write eval but not eval followed by a parenthesis.

Originally posted by Ernest Friedman-Hill:
...The common solution to the "event handlers adding/removing listeners" problem is to clone the Collection of listeners before iterating over it...

Doesn't that kill performance?


"Finally, whether or not to use a Thread to deliver events depends entirely on the application. Note that AWT and Swing use a thread whose sole purpose is to deliver events."
What advantages does using an additional Thread have? What do you think of AWTEventMulticaster's way of storing listeners (I personally think the idea behind it, namely using a chain of listeners, is quite elegant).

Java doesn't use multiple inheritance mainly because of the possibility that two parent classes could have members with the same names and signatures, not for simplicity.

Regarding your ignore keyword: Couldn't you just literally ignore the members you don't need (by not accessing them)? What if you keyword-ignore a member that is crucial for the superclass? You can't completely remove it (you don't know if the superclass needs it), so there would be no performance gain. You could only hide it, gaining space for own variable definitions which would then easily be confused with the respective superclass member.
Another point is that you can use a subclass wherever a superclass is required (polymorphism). What if an ignored method is invoked?

The ignore keyword wouldn't make multiple inheritance possible, either. A variable in two parentclasses can, although it may have the same name, represent completely different things. The system is guaranteed to break if classes manipulate each others members while thinking they are their own.

Stumbled across this post on Joe Walnes' blog. How cool is that?

I love it !

My own implementation (which is not yet self describing, but does work) is:

package constraint; public abstract class Constraint { protected final Constraint predecessor; protected Constraint() { this(null); } protected Constraint(Constraint predecessor) { this.predecessor = predecessor; } public abstract boolean evil(Object o); public static final Constraint eq(final Object a) { return new Constraint() { public boolean evil(Object b) { return a == null ? b == null : a.equals(b); } }; } public static final Constraint l(final Object a) { return new Constraint() { public boolean evil(Object b) { return ((Comparable) b).compareTo(a) < 0; } }; } public static final Constraint g(final Object a) { return new Constraint() { public boolean evil(Object b) { return ((Comparable) b).compareTo(a) > 0; } }; } public static final Constraint leq(final Object a) { return new Constraint() { public boolean evil(Object b) { return ((Comparable) b).compareTo(a) <= 0; } }; } public static final Constraint geq(final Object a) { return new Constraint() { public boolean evil(Object b) { return ((Comparable) b).compareTo(a) >= 0; } }; } public static final Constraint not(final Constraint c) { return new Constraint() { public boolean evil(Object o) { return !c.evil(o); } }; } public final Constraint and(final Constraint... constraints) { return new Constraint(this) { public boolean evil(Object o) { boolean result = this.predecessor.evil(o); for (int i = 0; i < constraints.length && result; i++) result = constraints[i].evil(o); return result; } }; } public final Constraint or(final Constraint... constraints) { return new Constraint(this) { public boolean evil(Object o) { boolean result = this.predecessor.evil(o); for (int i = 0; i < constraints.length && !result; i++) result = constraints[i].evil(o); return result; } }; } }

Works for code like:

(i >= -2 && i < 1) || (i == -5 || i == -4) || (i > 2 && i != 4) // is equivalent to: geq(-2).and(l(1)).or(eq(-5), eq(-4)).or(g(2).and(not(eq(4)))).evil(i);

P.S.: I'm sorry to say this but I HATE the software of this forum which doesn't let me write ev al!

I read this and I think that it's absolutely great. Now I'm trying to implement my own version which works fine, but I can't seem to get rid of some generics warnings.

My class looks like (simplified, evil stands for ev al which the forum doesn't allow ):
public abstract class Constraint { public abstract boolean evil(Object o); public static Constraint isLessThan(final Object a) { return new Constraint() { public boolean evil(Object b) { return ((Comparable) b).compareTo(a) < 0; } }; } }

This gives me the following warning:
Type safety: The method compareTo(Object) belongs to the raw type Comparable. References to generic type Comparable<T> should be parameterized

Parameterizing to the following:
public abstract class Constraint { public abstract boolean evil(Object o); public static <T> Constraint isLessThan(final Comparable<T> a) { return new Constraint() { public boolean evil(Object b) { return a.compareTo((T)b) >= 0; } }; } }
Gives me the warning:
Type safety: The cast from Object to T is actually checking against the erased type Object

How can I get rid of these warnings without using @SuppressWarnings?

Thanks in advance.

Hi,
I'm currently trying to find a practical solution to broadcast events. How do you do this? You don't just store all listeners in an array and iterate over this array do you? If you do so, how do you deal with listeners being removed while an event is broadcasted? Do you broadcast your events synchronously or with an additional thread?

I'd love to hear your reply on this, because I neither want to use arrays nor reflection.

Thank you very much, Satish.
My explanation (which repeats yours but seems clearer to me) is: If getThis returns an object of type A, one can't know whether this object secretly is of type B. B only has access if this is the case.

-> Changing getThis to the following removes the error:
protected B getThis() { return (B)this; }

If B had access to the protected fields of any A it could modify protected fields of other subclasses of A.

Thanks again