<P><FONT SIZE=2>&gt; I am not overwhelmed by this proposal.&nbsp; Not because the ideas aren't good,</FONT>
<BR><FONT SIZE=2>&gt; but because they aren't that much improved over the current api.</FONT>
</P>

<P><FONT SIZE=2>The API is showing a bit of maturity. :)</FONT>
</P>

<P><FONT SIZE=2>&gt;&gt; Is that true?&nbsp; Naming this method getContent() might be nicer but that</FONT>
<BR><FONT SIZE=2>&gt;&gt; will cause subtle bugs to existing code.&nbsp; This also makes it clear the</FONT>
<BR><FONT SIZE=2>&gt;&gt; List may contain various types of objects.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; getContent would be better of course.&nbsp; Fine with all whitespace.&nbsp; Since the</FONT>
<BR><FONT SIZE=2>&gt; old getContent returned a String, wouldn't the compiler catch those?</FONT>
</P>

<P><FONT SIZE=2>Actually, given that this is pre-1.0 and you have a chance to fix something</FONT>
<BR><FONT SIZE=2>-- and everybody using this code *should* know that things can change willy</FONT>
<BR><FONT SIZE=2>nilly -- are we sure that this isn't a good time to cut to the chase and</FONT>
<BR><FONT SIZE=2>just name getContent what it is?</FONT>
</P>

<P><FONT SIZE=2>I know that the door is closing fast -- but the door will never be open</FONT>
<BR><FONT SIZE=2>again and you'll have to live with this for a long time. OTOH The most</FONT>
<BR><FONT SIZE=2>compelling argument is that it's documented in the book.. So there's legacy</FONT>
<BR><FONT SIZE=2>there that cannot be recaptured.</FONT>
</P>