James Grahn wrote:
I'm in the Java 5 camp.
JavaSpace in particular could benefit from using generics, and I believe
the implementation wouldn't break any code. (All casting from a read
or take would just become redundant.)
Well, alright... it wouldn't break any _correct_ code (incorrect casts
wouldn't compile).
One thing to understand about JavaSpace and Generics, is that there isn't
anything new or different that Generics could provide for the JavaSpace API. An
Entry is an Entry, period. If you need something different than an Entry
(narrowing to a specific type), than you still have to create a concrete type
that expresses that type, because erasure doesn't transport a type anywhere.
So, if you have a JavaSpace reference and want a specific typed Entry to be
conveyed in and out, the best thing is to just do something like
public MyEntrySpaceType<T extends Entry> {
private JavaSpace theSpace;
public MyEntrySpace( JavaSpace pxy ) {
theSpace = pxy;
}
public T read( T e, Transaction txn, long timeout ) {
return (T)theSpace.read( e, txn, timeout );
}
... the other API methods with this type ...
}
The reason is that there is no "factory" method that you can call anywhere in
the Jini lookup API or otherwise which would allow you to provide the narrowing
type expression.
We could consider providing a factory method on the JavaSpace proxy via some
other interface implementation which would allow you to get a more narrowed type
proxy implementation to help with controlling which types could go in and out of
the JavaSpace.
Gregg Wonderly
