You are talking about a a field of an Entry, but it does aim at generics type safety. Too, the fields of an Entry as returned per the specification are not to be of different class types than what were given. If the instances contained in the collection given during a write are String...they will be String on retrieve. Sure, if some other processes write does something or if the serialized format is changed or manipulated you may be dealing with something particularly strange; but then again, we're talking about a bug in the application using spaces not in generics per se. That would be a different bag of worms.
On the Entry returned, one is going to perform a cast of this class to the expected type to be able to access the fields in the Entry. There is no magic which is going to make that cast work if it is not at least some byte code modified extension of that same class type; that same cast is happening for generics...no other magic there either. Even the spec states: "An entry is a typed group of object references represented by a class that implements the marker interface net.jini.core.entry.Entry. Two different entries have the same type if and only if they are of the same class." I would very much like to see the generics changes in Jini myself. I am willing to work on that as a change with who ever initially proposed it if they would like. We can come up with something you can poke holes in. I don't see an implementation breaking things unless it is not following the specs though, but I'm always willing and up for being schooled. It is great to learn something new every day :-D Perhaps you can point me to the area in the specs which says the Entry or the field can be returned as some other type than that which was written; I couldn't find it, but did look around and am curious about it. Thanks, 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: Peter <j...@zeus.net.au> > To: river-dev@incubator.apache.org > Sent: Fri, December 17, 2010 7:03:25 PM > Subject: Re: Space/outrigger suggestions > > There is one additional problem, the use of generics causes a narrowing of >scope, the template and return value must be the same type. The entry spec >currently allows the template to be a different class, a dummy class can be >used >instead. > > > Once Generics are introduced into service api, at the boundaries of > separately >compiled code, without the type safety checks performed by javac, only ill >will >come of it. Welcome to the slippery slope of complication. > > Time is precious, but seeing as you require me to do some work, it's only > fair >that you provide me with an implementation, for me to break with a test case. > > This implementation will require an Entry that contains a collection and a >client that uses objects from the collection. > > The test case will put new entries into the space that contain collections >also, these collections will contain objects of a different type. > > Your implementation will need to use a template that uses a wildcard for the >collection, and your client will need to access the objects contained within, >using Generics to access their implementation methods. > > Then after I break it, I'll demonstrate that without Generics in a similar >implementation, the collection can be handled in a typesafe manner. > > From my experience, consistant reliable results build better developer >confidence than nice looking but broken api's. > > > Peter. > > ----- Original message ----- > > In this case, I believe one must first prove the contrary; prove there is a > > problem with generics in this case. Is there an example of where this >proposal > > for JavaSpaces causes an issue. I don't know of any. I would be very >surprised > > if one could give a working example of such an issue. We are talking about >an > > Entry type. Whether this entry were passed into this call using generics > > or >not, > > one could have a generic List in some field of some instance of their Entry. > > This can happen right now. > > > > 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: Peter <j...@zeus.net.au> > > > To: river-dev@incubator.apache.org > > > Sent: Fri, December 17, 2010 5:09:47 PM > > > Subject: Re: Space/outrigger suggestions > > > > > > There seems to be support for using generics in this case. > > > > > > If we can develop some good documentation to explain why it works and why > > > it's the exception to the rule for using generics in service api, if >this is > > > indeed the case, then I think it is acceptable. > > > > > > Do we have any good wordsmith's on the list? > > > > > > I think we must do our due diligence and check for potential problems. > > > > > > This will work for the simple case, but what about an entry that > > > contains >a > > > collection, the user will expect the generic collection to be typesafe >but > > > runtime checks can't be performed. > > > > > > Instanceof List<String> doesn't work for example. > > > > > > I'm worried this won't work in all cases as expected. > > > > > > Are you prepared to do some research to proove runtime type safety? > > > > > > If boilerplate code is the problem, is it possible to use annotations to > > > perform checked type casts instead? > > > > > > Cheers, > > > > > > Peter. > > > > > > ----- Original message ----- > > > > public Entry read(Entry template, Transaction txn, long timeout); > > > > > > > > That is indeed the original/current method's signature. > > > > > > > > A couple of points. > > > > 1) "The client knows the []'s class type, the class cast isn't much >work" > > > > is > > > an > > > > argument against all generics, not just generics in this case. It > > > > ignores > > > the > > > > additonal specification power and type safety that the generic >provides. > > > > > > > It > > > > also discounts the work of adding the cast every time (mandatory > > > > boilerplate > > > is > > > > bad). > > > > > > > > 2) Returning "Entry" is what the method signature promises now, but >it's > > not > > > > what the space specification promises. The read/take family of >methods > > > has a > > > > semantic gap between what is contractually promised and what is > > > > checked >by > > > the > > > > compiler, and generics can close that gap. > > > > > > > > --- > > > > > > > > I think I may still be missing something when it comes to your point >about > > > > "separate compilation". In the case of using generics at the >method > > level > > > > (again, not the class level), the compiler not resolves on each method > > > call, > > > > does it not? How then would we get in trouble with different >compilation > > > times? > > > > > > > > With the definition: > > > > public <T extends Entry> T read(T template, Transaction txn, long > > timeout) > > > > > > > > Foo foo = space.read(someFoo,t,0); //Fine > > > > Bar bar = space.read(someBar,t,0); //Also fine > > > > > > > > Granted, if the space had previously seen some prior version of Foo, >that's > > > a > > > > runtime kind of problem, but that's a runtime problem with or without >the > > > > generic... > > > > > > > > Perhaps another example or a pointer to some resources to read would > > clarify > > > > this for me. (If you have the time.) > > > > > > > > jamesG > > > > > > > > -----Original Message----- > > > > From: "Peter Firmstone" <j...@zeus.net.au> > > > > > > > > The alternative method signature that is typesafe for James: > > > > > > > > public Entry read(Entry template, Transaction txn, long timeout); > > > > > > > > The client knows the template's class type, the class cast isn't much > > > > work for the client developer. Simpler is best I think, Generic's >offer > > > > no benefit for Service API. > > > > > > > > Hope this helps to clear it up. > > > > > > > > Cheers, > > > > > > > > Peter. > > > > > > > > > > > > > > > > Patricia Shanahan wrote: > > > > > I'm working on a replacement FastList that assumes JDK1.5 or > > later, >so > > > > > that I can depend on the new memory model and some of the > > > > > java.util.concurrent features. > > > > > > > > > > Do you advise using, or avoiding, generics in its definition? > > > > > > > > > > Patricia > > > > > > > > > > > > > > > On 12/14/2010 2:22 PM, Peter wrote: > > > > > > Generics are replaced with casts in bytecode. All typesafe checks > > > > > > are done at compile time and the generic replaced with a cast. If > > > > > > clients are compiled separately, this check won't occur, and the >cast > > > > > > will be unchecked at runtime. > > > > > > > > > > > > If clients with identical bytecodes or type casts use javaspace it > > > > > > will work, if separately compiled clients with different type casts > > > > > > try to use the same space service, it will fail with class cast > > > > > > exceptions at runtime. > > > > > > > > > > > > However since your T template is declared as a method parameter, >the > > > > > > javaspace service can check the class name at runtime and only >return > > > > > > that type. This must be done in the javaspace service >implementation. > > > > > > > > > > > > Only then will your generic method be typesafe. So yes it will >work, > > > > > > but I want to make sure the complications of generics in separately > > > > > > compiled code is well understood. It is not simple, but can be done > > > > > > with due care. > > > > > > > > > > > > Users are going to have a hard time understanding how to implement > > > > > > generics in their service implementations, it is fraught with > > > > > > pitfalls that may not bite until after deployment. > > > > > > > > > > > > User devs expect generics to make life simpler, but it has the > > > > > > opposite effect in remote code. > > > > > > > > > > > > We're either going to have to document the use of generics in >service > > > > > > api really well, or prohibit them. > > > > > > > > > > > > I think because it's possible it should be allowed, but we have to > > > > > > document it well as an advanced feature that places the type check > > > > > > burden on the service implementation. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Peter. > > > > > > > > > > > > ----- Original message ----- > > > > > > > Perhaps you could unpack your statement about generics for me a > > > > > > > bit. Are you > > > > > > > saying this wouldn't work? > > > > > > > > > > > > > > public<T extends Entry> T read(T template, Transaction txn, >long > > > > > > > timeout) > > > > > > > (... with similar modifications to the other methods) > > > > > > > > > > > > > > The generic is defined at the method-level, enforcing that the >type > > > > > > > returned is > > > > > > > the type of the template (and that the template extends Entry). > > > > > > > > > > > > > > This is, > > > > > > > indeed, the current contractual obligation of the method. > > > > > > > > > > > > > > It would be unfortunate if we couldn't add this, because this >would > > > > > > > save our > > > > > > > users a cast every time they used JavaSpace, but there may be a > > > > > > > technical hurdle > > > > > > > which I'm not understanding. > > > > > > > > > > > > > > Anyway, thought I'd attempt to clarify, since last time there >was > > > > > > > confusion over > > > > > > > whether I was asking for method-level generics or class-level > > > > > > > generics (the > > > > > > > latter would break JavaSpace generally). > > > > > > > > > > > > > > jamesG > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: "Peter"<j...@zeus.net.au> > > > > > > > Sent: Tuesday, December 14, 2010 6:28am > > > > > > > To: river-dev@incubator.apache.org > > > > > > > Subject: Re: Space/outrigger suggestions > > > > > > > > > > > > > > I believe we can create jini community standards. > > > > > > > > > > > > > > If the service api is different, it is not breaking backward > > > > > > > compatibility, it > > > > > > > is simply a different service. A bridging service smart proxy >can > > > > > > > implement > > > > > > > javaspace and utilise the new service, allowing legacy clients to > > > > > > > utilise the > > > > > > > new service. > > > > > > > > > > > > > > You could call it Balinda, Borne again Linda. ;) > > > > > > > > > > > > > > With generics and service api, compile time generic replacements > > > > > > > must be the > > > > > > > same, otherwise a runtime class cast exception will occur. >This > > > > > > > will work when > > > > > > > T is replaced by the same class, but will break when it isn't in > > > > > > > separately > > > > > > > compiled code. Generics that are specific will work. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Peter. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original message ----- > > > > > > > > Who controls the JavaSpace API specification? Is it something >we > > can > > > > > > > > change, as part of River, or do we just have an >implementation? > > > > > > > > > > > > > > > > Should we be considering designing RiverSpaces, similar to > > > JavaSpaces > > > > > > > > but with an updated API, including generics, more use of > > > collections, > > > > > > > > and better naming? > > > > > > > > > > > > > > > > James - if you have time, could you file a Jira issue? That >way, > > > these > > > > > > > > ideas will not get lost in the mail archives. > > > > > > > > > > > > > > > > Patricia > > > > > > > > > > > > > > > > On 12/14/2010 12:33 AM, James Grahn wrote: > > > > > > > > > I have a small list of suggestions for javaspace/outrigger, > > > largely > > > > > > > > > derived from my experience creating a wrapper for space > > > functionality > > > > > > > > > and direct usage prior to the creation of that wrapper. > > > > > > > > > > > > > > > > > > Many of these suggestions involve breaking backwards > > > > > > > > > compatibility, so > > > > > > > > > many tears will be shed and perhaps we'll decide against > > > implementing > > > > > > > > > any of these. But, I'm hoping this might lead to some >discussion > > > and > > > > > > > > > perhaps some improvements. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > 1) Generic methods. > > > > > > > > > First, use generics in the method signatures to minimize >casting, > > > in > > > > > > > > > this manner: > > > > > > > > > > > > > > > > > > public<T extends Entry> T read(T template, Transaction > > > > > > > > > txn, >long > > > > > > > > > timeout) > > > > > > > > > > > > > > > > > > Seems broadly like a win, if use of Java 1.5 idioms is > > > acceptable. > > > > > > > > > This > > > > > > > > > is the only one I've mentioned before, and the reaction was > > fairly > > > > > > > > > positive on this list. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > 2) More collection-like naming of space methods, more > > consistency. > > > > > > > > > > > > > > > > > > read, take, readIfExists, takeIfExists, write, snapshot, >notify, > > > > > > > > > registerForAvailabilityEvent all have fine names. That is, >they > > > > > > > > > properly > > > > > > > > > describe the functionality and how the methods themselves >relate > > > > > > > > > to one > > > > > > > > > another. > > > > > > > > > > > > > > > > > > I do, however, take issue with "contents", "take (with a > > > > > > > > > collection)", > > > > > > > > > and "write (with a list)". > > > > > > > > > > > > > > > > > > I would suggest the following renamings: > > > > > > > > > contents -> readAllExisting > > > > > > > > > take (with collection) -> takeAny > > > > > > > > > write (with list) -> writeAll > > > > > > > > > > > > > > > > > > This would eliminate the awkward overloading of "take" and > > "write" > > > > > > > > > while > > > > > > > > > bringing "contents" into a consistent naming plan. > > > > > > > > > > > > > > > > > > The goal is a naming scheme which clearly communicates > > > functionality: > > > > > > > > > "exists/existing" suffix = nonblocking call > > > > > > > > > "any" suffix = one or more templates will be satisfied, > > > multi-return > > > > > > > > > "all" suffix = all templates will be satisfied, multi-return > > > > > > > > > If unmodified, standard blocking call. > > > > > > > > > > > > > > > > > > The clearer naming also points to new functionality we could > > > > > > > > > choose to > > > > > > > > > support, namely: > > > > > > > > > readAll - blocking call with all templates > > > > > > > > > readAny - blocking call on any template > > > > > > > > > takeAllExisting - nonblocking call with multiple templates. > > > > > > > > > takeAll - blocking call with all templates > > > > > > > > > > > > > > > > > > > > > > > > > > > Addendums: > > > > > > > > > 1) I'll admit that "any" is the weakest part of the > > > > syntax, >as it > > > > > > > > > fails > > > > > > > > > to connote the multi-return. I was stretching to cover the > > > current > > > > > > > > > "take > > > > > > > > > (with collection)" semantics, which blocks until at least one > > > > > > > > > template > > > > > > > > > match is available. Open to better suggestions. > > > > > > > > > > > > > > > > > > 2) Though generally I dislike overloading methods, there > > > is >one > > > > > > > > > case I'm > > > > > > > > > sympathetic to: overloading "all" and "allExisting" methods >to > > > > > > > > > take in a > > > > > > > > > single template or multiple templates. This would save some >calls > > > to > > > > > > > > > Collections.singleton() for our users while maintaining a > > > consistent > > > > > > > > > return type for the method. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > 3) Collections or remote iterators, not both. > > > > > > > > > "contents" returns a remote iterator named "MatchSet", while > > "take > > > > > > > > > (with > > > > > > > > > collection)" returns a collection. I can understand the >argument > > > > > > > > > behind > > > > > > > > > both use cases, but not necessarily the argument for using > > > > >both > > > > > > > > > simultaneously. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > 4) Exception soup. > > > > > > > > > Javaspace methods return a vast cornucopia of possible > > > > > > > exceptions. > > > I > > > > > > > > > would propose wrapping any Exceptions bubbling up to River >users > > > > > > > > > to be > > > > > > > > > wrapped in RiverException. Those few(?) who have special > > > > > handlers > > > to > > > > > > > > > deal with problem conditions can peek into the cause. > > > > > > > > > > > > > > > > > > From my observation, most libraries are either >taking this > > > > > > > > > route (ala > > > > > > > > > JAXB) or wrapping everything in runtime exceptions (Spring, > > IIRC). > > > > > > > > > > > > > > > > > > Presumably this suggestion could be applied to all of > > > > > > > > > River, >not > > > just > > > > > > > > > JavaSpaces. > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > 5) Clearer javadocs. > > > > > > > > > The current Javaspace docs are part protocol specification, >part > > > > > > > > > implementation with some vital bits of information >squirreled > > > > > > > > > away > > > in > > > > > > > > > obscure reaches. > > > > > > > > > > > > > > > > > > For instance, in the 9 paragraphs describing the behavior of > > "take > > > > > > > > > (with > > > > > > > > > collection)": > > > > > > > > > "If there is at least one matching Entry available in the >space, > > > an > > > > > > > > > invocation of this method must take at least one Entry. If > > > >more > > > > > > > > > than one > > > > > > > > > matching Entry is available, the invocation may take >additional > > > > > > > > > entries. > > > > > > > > > It must not take more than maxEntries, but an > > implementation >may > > > > > > > > > chose > > > > > > > > > to take fewer entries from the space than the maximum >available > > or > > > > > > > > > the > > > > > > > > > maximum allowed by maxEntries." > > > > > > > > > > > > > > > > > > The above is a broad protocol specification to implementers > > > > > >(even > > > > > > > > > allowing that the method may always return an empty list > > > > > > > > > ;-) >). > > > > > > > > > Frustrating to users because the definition is so amorphous. > > > > > > > > > > > > > > > > > > It also takes some doing to track down the fact that the > > > > > > > > > implementation > > > > > > > > > does, in fact, limit the number of entries returned from a >"take > > > > > > > > > (with > > > > > > > > > collection)". That tidbit is stored within the outrigger > > > *package* > > > > > > > > > documentation, which reveals the setting and default (only >100). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Aside: In prior discussion, I believe the reason for using >that > > > limit > > > > > > > > > was that the implementation creates an array of size > > > Minimum(limit, > > > > > > > > > maxEntries)... and I think there's already a JIRA bug to >switch > > > > > > > > > from the > > > > > > > > > array to a collection. When we do, we should be a bit more > > > > > > > > > generous with > > > > > > > > > the default (or remove the setting). > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Anyway, hope this stirs some discussion. > > > > > > > > > > > > > > > > > > I'll be on vacation the rest of the month, so > > unfortunately >my > > > > > > > > > participation in said discussion will likely be spotty >(though > > > > > > > > > I'll try > > > > > > > > > to look in). I've been meaning to push out these >recommendations > > > for > > > > > > > > > some time, though, so I figured better now than waiting >another > > > > > > > > > month. > > > > > > > > > > > > > > > > > > jamesG > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
