JDK 12 RFR of JDK-8146726 : Refactor AbstractProcessor to use Set.of and related methods (original) (raw)
Ivan Gerasimov ivan.gerasimov at oracle.com
Thu Nov 29 02:52:49 UTC 2018
- Previous message: JDK 12 RFR of JDK-8146726 : Refactor AbstractProcessor to use Set.of and related methods
- Next message: JDK 12 RFR of JDK-8146726 : Refactor AbstractProcessor to use Set.of and related methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Joe!
In two places the expected numbers of elements is used instead of the initial capacity of a new HashSet:
new HashSet<>(values.length);
Wouldn't the default initial capacity (i.e. new HashSet<>()
) be
better choice here, as the number of values is likely to be small and
the HashSet is temporary anyway?
With kind regards,
Ivan
On 11/28/18 6:09 PM, joe darcy wrote: > Hi Ron, >> Adding Stuart for a collections consult; Stuart, what is the currently > recommended idiom to construct a unmodifiable collection with the same > elements as a existing collection? In particular, for a set of Strings > is something like >> Set.of(stringSet(new String[0])) >> preferred over >> Collections.unmodifiableSet(stringSet); >> Assume serialization is not a concern. >> On 11/27/2018 1:23 PM, Ron Shapiro wrote: >> Set.of() throws if there are duplicate elements - but arrayToSet() >> didn't do so. Is it intended to throw if either of these take >> duplicates? >>>> Good catch. >> After some pondering, I think it is preferable for AbstractProcessor > to not treat duplicates as an error, but to issue a warning in if > duplicates are found. Arguably, it would have been reasonable to treat > such condition as an error initially when the API was introduced, but > adding such a check now could have some unnecessary behavioral > compatibility impact. The case to add an erroneous check for options > is stronger than for supported annotations because supported > annotations have some additional processing if modules are not > present. In more detail, with modules to fully specify an annotation > type, the module name needs to be used: "mod1/foo.bar" vs > "mod2/foo.bar". If such a processor is run when modules are not used, > then the names are stripped to "foo.bar" in both cases and that should > not be treated as an error. >> Revised webrev: >> http://cr.openjdk.java.net/~darcy/8146726.3/ >> Will possibly update based on guidance from Stuart on the collections > usage question. >> Thanks, >> -Joe >
With kind regards, Ivan Gerasimov
- Previous message: JDK 12 RFR of JDK-8146726 : Refactor AbstractProcessor to use Set.of and related methods
- Next message: JDK 12 RFR of JDK-8146726 : Refactor AbstractProcessor to use Set.of and related methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]