Whoops, I had one other comment.... On 19 December 2010 15:28, Wade Chandler <hwadechandler-apa...@yahoo.com>wrote:
> 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); > > I'm not sure this helps so much in cases where one is doing a superclass-type match where the template can match a bunch of subclasses. It doesn't do any harm either but I'll have to cast anyway.... > 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 > > >> > > >> > > > > > > > > > > > >
