river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Migration to Java 5
Date Mon, 30 Mar 2009 18:39:38 GMT
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

Mime
View raw message