I don't know. Checks etc in this case, before calling read on the return or parameter type, just doesn't make any sense to me. If Jini returns an incorrect instance then it is simply in error per the specification. If you pass in a template, you expect to have that exact type, possibly an extension, returned. The only case I can imagine in my mind where that isn't the case, is an error in the underlying spaces impl. If that happens and needs to be checked for, then I would suggest using a different impl if you have production code, so I'm still confused to the counter argument to this proposal. This seems like over thinking it to me; which isn't always a bad thing. That or I'm just not yet convinced.
To me, if an impl dev is concerned about the impl working correctly, which they should be, there should be a check in the client API whether the returned is of the expected type. This should also be done on the impl server side per the specification (a match on an Entry must match the type or a sub type of the Entry). A correctly structured message should then be returned in the form of an Exception and logged as the impl is in error. I don't see that as a consumer concern. Can anyone explain why it should be? My argument is based on the specification where these are not arbitrarily loaded classes. 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: Tom Hobbs <[email protected]> > To: [email protected] > Sent: Fri, December 17, 2010 11:09:55 AM > Subject: Re: Space/outrigger suggestions > > I think the difference between generics vs not-generics in this case > is to do with expectations. > > If generics are used on the method signature then the client developer > *expects* not to encounter any runtime issues. In certain > circumstances this expectation is incorrect. > > The method signature without generics forces the client developer to > do a runtime check and a cast. This is the only way to be safe in all > cases. Of course every developer does a type check before they cast, > don't they? ;-) > > I think this (no generics) is the correct approach for Outrigger, > because it places 100% of the enforcement of this kind of safety on > the client developer. That may not be the most convenient thing for > all developers, but it prevents a potentially difficult bug hunt > trying to work out why a cast failed when the developer is convinced > that it's the correct type - and the use of generics "proves" that > it's the correct type... > > On Fri, Dec 17, 2010 at 3:58 PM, Wade Chandler > <[email protected]> wrote: > > > > > > ----- Original Message ---- > > > >> From: Peter Firmstone <[email protected]> > >> To: [email protected] > >> Sent: Fri, December 17, 2010 7:02:26 AM > >> Subject: Re: Space/outrigger suggestions > >> > >> [email protected] wrote: > >> > 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. > >> > >> This is a very important comment, as it reflects the common understanding > >>developers have of Generic's, this is true for code at compile time, >however > >>Java's generic implementation suffers from erasure, the type safety >disappears > >>after compilation and relies on the fact that the code has been audited > >>by >the > >>compiler. > >> > >> The binary signature of your method is the same as it is in bytecode now, > >>adding generic parameters won't change the binary method signature. > >> > >> It is unfortunate that your example will work with generic's, which is > due to > >>the template being passed as a parameter, restricting the return type to > >>matching that of the template, the problem is, people don't understand > >>why >this > >>works and just assume that generic's will work in all cases for >distributed > >>programming, then start using generics in their service api, it will work >at > >>first, but at some point in time, separately compiled code will be mixed, >the > >>class cast's won't have been checked by the compiler, then they'll get >burnt by > >>class cast exceptions, after deployment, the worst time to catch the >problem, > >>hence my comment, the type cast is simpler if performed by the client, >where it > >>can be checked at runtime. > >> > >> The type casts weaved into bytecode by the compiler are checked at compile > >>time, by the compiler and are not checked again at runtime. These checks >are > >>not performed in code that has been compiled separately. > >> > >> Check out Jim Waldo's book: > >> > >> http://www.amazon.com/Java-Good-Parts-Jim-Waldo/dp/0596803737 > >> > >> See also: > >> > >> http://gafter.blogspot.com/2006/11/reified-generics-for-java.html > >> > > > > That taken into account, the proposal does make things better and works. >Sure, > > there are some gotchas with generics, but you have to go on a case by case > > basis. Making something simpler makes a heap of sense, and in this case, it > > works well. I don't see the down side to this request. The same argument >here > > can be made for the cast. The client is assuming it is this "type" so they >cast. > > Same with the generics. The client assumes it is this "type" which they are > > programming into the case...lookup this type with this template. Were > > there >some > > runtime mishap it would affect it just the same. Just using a cast doesn't > > ensure anyone builds in some extra safety which will some how work around >that > > issue. Am I missing something else about this proposal? > > > > 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 > > > > >
