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