Clarification: Varargs and Heap Pollution

Question

My reply -- somewhat late -- to yesterdays [debate on varargs|http://forums.sun.com/thread.jspa?messageID=10941372#10941372].
jduprez wrote:
OK let's approach this with care...
In Java variable arity methods are implemented by boxing into arrays whose types are reified and covariant. Coupled with generics and erasure this opens the door to heap pollution
I don't understand the part I underlined in your statement. Can you clarify it?Well there is a reason one can not construct an array of a non-wildcard parameterized type, the potential for heap pollution:
Whatever<Integer>[] ints = new Whatever<Integer>[1]; // error
Object[] objs = ints;
objs[0] = new Whatever<String>(); // no ArrayStoreException
Whatever<Integer> wi = ints[0]; // no ClassCastException
// sometime much later in unrelated code:
int i = wi.gimme(); // ClassCastException -- where does that come from??Heap pollution is bad and the reason we get an error, it does not compile. However, varargs let you implicitly do, what you can not do explicitly, all you get here is a warning:
<T> T[] makeArray(T... ts) { return ts; }
Whatever<Integer>[] ints = makeArray(new Whatever<Integer>(1));
I don't understand why some here have such an aversion to truth.Seeing George as a poster with a history of helpfulness and good judgment, I'm a bit deterred by this absolute satementWell, my statement was all facts and he answered with :headdesk:; I understand he was just frustrated and I misinterpreted.
You have no problem disagreeing with others' opinions, but when you make a factual error and are corrected then that's outrageous.George might have been more explicit. Maybe he doesn't see the factual error that you corrected in your post - I don't either.He said varargs were not uncharted territory, but -- as explained above -- they are in Java.
Perhaps there is some other way I should be interpreting your response?He might hypothetically have been astonished by what he possibly perceived as a slightly misinformed reply on your part, and didn't care to elaborate on it, as the statement itself was not argumented...
Myself had the (deliberately provoked?) knee-jerk reaction that you were just spelling Fear, Uncertainty, and Doubt in a topic that doesn't really need these;I apologize, I suppose I was just nitpicking and, worst of all, unclear about it; I really should have left it alone.
but as I understand from your posting history that you're interested in memory and generics issues and that you have certainly studied those fields more than I have, I have no doubt that you can explain your position in a more elaborate reply.Thank you, I hope to have done that with this post.
You might be better offf starting a new topic, preferrably in the Java Programming forum, as I suspect that your arguments are a bit too elaborate for "New to java", plus the current topic is already plagued by a lot of off-topic remarks! Absolutely.
With kind regards
Ben

Answer 1

Hello Ben,
thank you for this clarification. I discovered it only today - I added a link in the original discussion.
As stated in the post you linked to, I stumbled on the officially-defined meaning of heap pollution a couple of days after we had this "argument" (until that I had completely mistaken the meaning of this expression), and I edited my reply at that time to open the possibility that, well, you might be right after all...
I stand by my claim that your comment in the other discussion was way too terse to be taken seriously - this new elaboration is very welcome, and proves your point.
As you note, however, the occurence of the problem must have been deemed rare enough that it justified a mere warning instead of banning varrags.
I'd say that removing the warning in 7 is rather unfortunate: rare as it may seem, such a problem is certainly very troublesome to diagnose if we're left with the runtime ClassCastException as the only clue...
Thanks again, and regards.
Jerome