Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: looping through a list, starting at 1 References: <4e3745a2$0$305$14726298@news.sunsite.dk> <62239393-929c-4764-8c8e-9620a03a7b81@c29g2000yqd.googlegroups.com> <80346568-647c-4e27-8192-33e1765a09ce@glegroupsg2000goo.googlegroups.com> <76X0q.575768$SG4.251613@newsfe03.iad> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: 12 Aug 2011 08:09:33 GMT Lines: 22 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1313136573 tunews.univie.ac.at 71616 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7033 Arved Sandstrom wrote: > Since you insist on JDK examples, you might also want to read the bit in > Item 37 where Bloch explains how Serializable _could have been_ written > so as to take advantage of that marker interface statically rather than > at runtime. Sounds interesting (I'll ask colleagues if they have a copy of that book) but not entirely relevant for RandomAccess. There typically is no "plan B" for code that expects a serializable object but got a non-s'able one. Making things static is a good means to detect *errors* earlier, namely at compile-time. For that it is also worth some effort like duplicating other methods (that pass through objects, but do not care about serializability, themselves) for both variants to preserve the static information. I don't yet see the benefit of making decisions between "plan A" and "plan B" static if neither is an error. If the answer is "performance", I'm tempted to refer to Item 37 in the *first* Edition of above-mentioned book.