I suppose I should point out that the Javaspace specification does guarantee that the type returned in these cases is the type of the template. If something else is returned, then the space implementation is severely broken. That being the case, why should we ask users to check-and-cast?
Much more likely to my mind is that this change could expose some bugs in the client code before they happen, as potential mis-casts would be discovered by the compiler (unless it is a downcast, in which case traditional debugging would reveal the issue). jamesG -----Original Message----- From: "Tom Hobbs" <[email protected]> Sent: Friday, December 17, 2010 11:09am To: [email protected] 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 > >
