But again, what you are describing, one can run into now if they do that with Entry. Does your current spaces implementation defend against what you are describing now?
Adding some type checks like Peter and Nick mentioned on the types used in lookup I believe would work there to fix that. This makes me think what I wrote about this should just be something which is documented versus coded against may be what should be done in the interim with a proper fix later. Thus, start working on the cases we are talking about below, while documenting, and then work on those generics pitfalls in the impl. The pitfalls can occur now, and are completely orthogonal to the changes we have been talking about. Were one to use any spaces impl, or any API for that matter, they would have to know the outcome of choices they made with calls into the API. In this case, were one to have some arbitrary API which wasn't remote and given a similar case of the spaces specifications use of Entry, this use you are showing would be problematic. We can safely say anything giving returns based on matching this way and using generics in this case would have the same issue. Adding generics where they work is completely different than the cases where they are problematic. Currently, we are specifically talking about making the JavaSpace API interface use generics. That would be the methods of JavaSpace/05 and MatchSet. Other cases can be reviewed after for the rest of the Jini APIs. Doing this for spaces allows one to merely write cleaner code when interacting with those interfaces. You write your Entry impl to the space. You can then retrieve it using a template of the same type and expect the return without using casting. The spaces specifications already dictate that an Entry is only matchable if it is of the same type. Thus making read and take actually work well for generics when talking about the parameters to the spaces interface. EntryExtension<X,Y> is something we can't control now, we are specifically talking about EntryExtension instance = space.read(myEntryExtensionTemplate, null, 30000); versus EntryExtension instance = (EntryExtension) space.read(myEntryExtensionTemplate, null, 30000); There are cases where generics will get you into trouble with remote code, and in this case you are mentioning, any code given the same expectations without checks under the hood. Wade ================== Wade Chandler Software Engineer and Developer NetBeans Dream Team Member and Contributor http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: Dan Creswell <dan.cresw...@gmail.com> > To: river-dev@incubator.apache.org > Sent: Sun, December 19, 2010 5:15:00 AM > Subject: Re: Fw: Re: Space/outrigger suggestions > > Is there a solid collection of use-cases anywheres? I've waded through this > email thread and didn't see anything.... > > Certainly I'd like to see a little more detail on just where/when/how we're > proposing to use generics as JavaSpaces users (forget implementors such as > me for now). i.e. I'd like to understand what users want to do, then we can > figure out what's viable. > > One area of concern for me would be how this could affect matching semantics > within a space - consider: > > public class Test<T, U> implements net.jini.core.entry.Entry { > public T aField; > public U anotherField; > public String anId; > } > > Would you expect all instances of Test regardless of T and U to be treated > as the same class of Entry and thus all searched? Similar questions arise > when considering Collections as fields of Entry's. Historically a Javaspace > would merely compare the marshalled value of the collection against other > collections with no "deep matching" such that to all intents and purposes > collections are used to carry objects around and matching is done on other > "simple" fields. > > This somewhat speaks to the problems we'd face as the result of two separate > compiles for two separate clients and runtime classloading. One dev > specifies an Entry: > > Test<Integer, String> > > Another specifies: > > Test<String, Integer> > > If we assume we match on Test instances ignoring the generics and only the > anId field is set, then each client could end up with an instance of Test > that doesn't fit with it's templated/specified at compile-time typing. > > At this stage, I'm not entirely sold on generics for JavaSpaces as I can't > think of some suitably neat use cases. I could imagine we might build some > wrapper for JavaSpaces that constrains a client to deal in only certain > types of Entry along the lines of the "check collection wrappers" Peter > mentions elsewhere. > > Cheers, > > Dan. > > On 19 December 2010 07:39, Peter Firmstone <j...@zeus.net.au> wrote: > > > Ok thanks Nic, that's interesting, I stand corrected on erasure, seems > > it's not entirely true. > > > > Any idea how we can enable runtime type checks for Generics? > > > > So far we can get the type information, I know it's preserved in > > bytecode from my experience with ASM and adding Generics support to > > classdep, however, how does it stop me from setting the field reference > > to another Collection, containing Integers, at runtime, then returning > > it to the space? > > > > Even with James' proposed javaspace method, which will work, the client > > typecast is unchecked, it relies on the javaspace implementation to > > return the correct type, which means you must trust the javaspace > > implementation. > > > > This places a significant burden on the service implementor. > > > > What about Generics in other Service API? > > > > I use Generics for it's added type safety, but type safety doesn't > > extend to distributed code, since it is a compiler check (hint: I'd love > > to be pointed to a runtime type checker for Generics) I'd understand > > the attraction of using Generic's if it was the case, but I'm failing to > > understand the relevance of Generic's without type safety, could someone > > please explain it for me? > > > > Or are we working on a tool to add type safety for Generic's to > > distributed code? > > > > Sorry, the direction so far just appears to be, add Generics to > > distributed code, without type safety checks, it seems type checks might > > interfere with performance or something. > > > > Regards, > > > > Peter. > > > > > > > > Niclas Hedhman wrote: > > > >> On Sat, Dec 18, 2010 at 4:11 PM, Peter <j...@zeus.net.au> wrote: > >> > >> > >>> if you have a field in an Entry declared: > >>> > >>> public Collection<String> names; > >>> > >>> In bytecode, because of erasure, its type is Collection, this means I can > >>> take from the javaspace and set the field to contain a Collection that > >>> doesn't contain String's and the next time your code accesses it, a > >>> ClassCastException will occur. > >>> > >>> > >> > >> That is not correct. For fields, method return values and parameters, > >> the Type is preserved (ParameterizedType it is called). So for the > >> above example, do > >> > >> Type[] types = names.getClass().getGenericInterfaces(); > >> > >> or something like this for the declaration itself > >> > >> Field field = Main.class.getDeclaredField( "names" ); > >> field.setAccessible( true ); > >> Type type = field.getGenericType(); > >> > >> > >> In fact, quite a lot of the things that people think are 'erased' are > >> actually not. > >> > >> For instance, in a declaration like; > >> > >> public interface Abc<K,V> > >> > >> you can even retrieve the variable names of 'K' and 'V' respectively > >> (those Type are called TypeVariable). > >> > >> > >> Say what you want about Sun's compromises in the generics system, but > >> it is far from "just compiler checks". > >> > >> > >> In my project Qi4j (http://www.qi4j.org), we use this extensively to > >> do sweet things like; > >> > >> Property<String> fullname(); // in an interface > >> > >> to declare a property instead of getter-setter-mania... > >> > >> > >> Now, I am not saying that any of this should be deployed into River at > >> all, just that more things are possible than you might think. > >> > >> > >> Also Note; There are some small bugs in Sun's JDK1.5 generics > >> compiler, where some corner cases are handled incorrectly. The ones > >> that we have found are fixed in 1.6. > >> > >> > >> Cheers > >> > >> > > > > > > >
