RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields (original) (raw)
Ivan Gerasimov ivan.gerasimov at oracle.com
Fri May 29 16:42:48 UTC 2015
- Previous message: RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields
- Next message: JEP 119 / Implementation of javax.lang.model.util.Types
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thank you Martin for review!
On 29.05.2015 3:03, Martin Buchholz wrote:
Approved.
On Thu, May 28, 2015 at 3:43 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote: Good naming is one of the most difficult part of coding IMO. The chosen names were meant to be read literally: "optimal capacity of ArrayList", etc. I agree, 'assert' would tell more about these methods' intention, but I'm not sure how to include it in the names. Maybe rename the class to AssertOptimalCapacity?
Assertions are a class of names we are used to importing statically. Junit and Testng both have collections of static methods named assertXXX. For ArrayLists, I would have been happy enough just testing that we have 100% utilization, i.e. size of array is the same as size of the List, without checking the initial capacity. But then the test wouldn't have caught the "bug" in src/java.base/share/classes/sun/security/ssl/ExtensionType.java The ArrayList was pre-sized to 9, and after reallocation the capacity happened to become (9 + 9/2) = 13, which by coincidence is the final size of the List. It's a tradeoff of maintenance burden vs performance. Note also that oversize is a much bigger performance bug than undersize because you pay for it for the entire process, not just startup.
- Previous message: RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields
- Next message: JEP 119 / Implementation of javax.lang.model.util.Types
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]