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

Reply via email to