DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-09 12:55 ------- (In reply to comment #64) > Another question: > > http://java.sun.com/j2se/javadoc/writingdoccomments/index.html > > According to sun's javadoc principals (above link) > # The Java Platform API Specification is a contract between callers and > implementations. Leon, Can you publish your TC+HashMap finding you based your comment #55 ? I've always tried to program for the worst case scenario, assume thread-unsafe unless otherwise stated. Probably my 'C' language background thinking here. So it interests me to hear this stated in reverse for Java (not a bad thing at all). Where within the reference is that implicit thread-safe notion stated ? Is a HashMap really needed for session attributes, exactly how many attributes does an average application have set ? Replacing the collection with a bespoke TC internal class based on something as silly as a linked list or fixed hash bucket redirect into linked list should serve most users well. Then making the exact collection implementation class a configurable item so those users that would benifit from a safe HashMap for scalabilty of key count would be happy to fix their performance with a config change. It would please me greatly to see a more proper collection class for the job with a safe write operation whilst allowing simultenous mutiple reads. But trying to bend the HashMap API into something its not is wrong. Java Moto #1: "You program to interfaces" -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]