uschindler commented on PR #2881: URL: https://github.com/apache/solr/pull/2881#issuecomment-2646355888
> Thanks for your feedback @uschindler 😄 > > > Please be still careful to not use the plural s classes during initialization on the original class. This would reintroduce the problems. > > I believe this is not the case, and I hope error-prone would identify such cases. OK. > > If you have accessor methods, you can use the holder pattern used in Lucene. > > I haven't used this pattern before. Would [`TimeSources.get(type)`](https://github.com/apache/solr/blob/b34abd5a5016f125174cd036cd7b3273efe6345a/solr/solrj/src/java/org/apache/solr/common/util/TimeSources.java#L49) (previously `TimeSource.get(type)`) be such a scenario where this pattern could be used? The pattern can be seen here when codec initialization is done. Lucene has a default Codec, which is a subclass of the Codec class. The Codec class has a method `Codec#getDefault()` which returns the static default. The initialization is delayed by a Holder pattern: https://github.com/apache/lucene/blob/30d18dfbe1e67bed2d4550b2bc20b9b86ce9781c/lucene/core/src/java/org/apache/lucene/codecs/Codec.java#L40-L59 Here it is called: https://github.com/apache/lucene/blob/30d18dfbe1e67bed2d4550b2bc20b9b86ce9781c/lucene/core/src/java/org/apache/lucene/codecs/Codec.java#L139-L147 Basically the trick is similar to your's but has more checks to really prevent codec subclasses to get the default during initialization phase (that's why the null checks are there). > I guess in cases where the instances are public and directly accessed or added to a list with `static { ... }` the holder pattern cannot be used? No, that's the problem of most classes seen in this PR. It is impossible to use that where the superclass has a static final field to one of the subclasses. You need to break backwards compatibility. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org