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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
