Code Review Request: 7157893: Warnings Cleanup in java.util.* (original) (raw)

Rémi Forax forax at univ-mlv.fr
Wed Apr 11 21:34:21 UTC 2012

On 04/11/2012 10:06 PM, Mike Duigou wrote:

This thread has gone on long enough I've lost track of the reasoning behind some of the choices.

Specifically, I'm wondering why Entry[] is preferred over Entry<K,V>[] for HashMap and Hashtable. Understandably is needed to the array creation but the technique used by WeakHashMap would seem to be equally appropriate for the other hash base Map implementations. Rémi?

WeakHashMap was already warning free so I haven't modified it, I've just removed one or two raw type warnings.

The main issue with the translation chosen by WeakHashMap is that an array of parametrized types is something that is unsafe (the VM doesn't do a runtime check for the array store) so you can easily add code that you think innocuous but that that will introduce a bug.

Mike

Rémi

On Apr 10 2012, at 16:15 , Kurchi Hazra wrote:

Hi Stuart,

Please find the updated webrev here: http://cr.openjdk.java.net/~khazra/7157893/webrev.01/ I hope to have included all the suggestions correctly. Also, note that I made some new changes in Hashtable.java at lines 185, 355 and 910 to get rid of some additional warnings. Thanks, Kurchi

On 4/6/2012 5:35 PM, Stuart Marks wrote: Hi Kurchi, I think we've converged on the code changes. Please prepare and post another webrev for a final cross-check before pushing. What follows is I think merely residual disagreement over the philosophy of how to handle generic casts vs reification. :-) On 4/6/12 3:06 AM, Rémi Forax wrote: On 04/05/2012 11:04 PM, Stuart Marks wrote: I'm somewhat skeptical of making code changes now based on potential future benefits when/if generics become reified. This was discussed before; see

http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000454.html In that message, John Rose said "If the best practices have to change, then we'll have to change that code again. Or maybe the retrofit strategy will have to take account of the existing code idioms. In any case, we'll cross that bridge when we get to it. (Coping with reification in this case is a decision to make tomorrow, not today.)" I disagree with John. The main issue with generics nowadays is that most of the people doesn't care about a cast to a type variable because everybody knows about erasure. So codes are written with an implementation glitch in mind. Frankly, I don't know if reification will appear (yes it's a kind of magical) or not but I think it's a sloppy path to not consider all casts as equals. In order to program effectively with generics, I think you have to understand erasure and its implications. It may have been an unfortunate choice, but erasure is part of the language and we have to deal with it and in some cases rely on it. I don't think it's merely an "implementation glitch." The difficulty I have with reification is that while there are proposals floating around for how it could be done, nobody really knows how it will eventually turn out, nor whether it will actually be done. If it is eventually done, there will legal and illegal constructs, constructs that generate warnings, and perhaps a style guide for how to use reified generics properly. Right now, we can imagine what these future rules might be, but it seems untenable to me to try to make today's code conform to those imaginary future rules, especially in the absence of tools to help support those rules. If unmaskNull return a V, the code of equals will upcast the value from Object to V to just after downcast it from V to Object, I think it's better that unmask to return Object and upcast it to V when it's necessary. Certainly there are cases where there's a redundant downcast and upcast. In a reified world, will this be a significant expense? Really, I have no idea. s'marks -- -Kurchi

More information about the core-libs-dev mailing list