DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27231>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27231 [collections] Change to HashEntry inner class of AbstractHashedMap ------- Additional Comments From [EMAIL PROTECTED] 2004-02-26 16:00 ------- I think there is a subtle twist missing in this document: http://www.eclipse.org/eclipse/development/ java-api-evolution.html Namely: if you add to an API class an API method one of whose arguments is of a new API type, then there is no binary compatibility problem. Method overloading will make sure that nobody will ever have been able to create such a method. This is the situation we would be facing here, were we to overload the methods, except for the HashEntry getEntry(Object method), since java does not overload on return types. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
