[
https://issues.apache.org/jira/browse/SOLR-16167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527564#comment-17527564
]
Michael Gibney commented on SOLR-16167:
---------------------------------------
In addition to the [palantir gradle
plugin|https://blog.palantir.com/using-static-analysis-to-prevent-java-class-initialization-deadlocks-c2f31ca967d6]
(which seems to suffer false negatives so is probably not suitable in its
current form), the [IDEA
implementation|https://github.com/JetBrains/intellij-community/blob/0e2aa4030ee763c9b0c828f0b5119f4cdcc66f35/plugins/InspectionGadgets/InspectionGadgetsAnalysis/src/com/siyeh/ig/threading/StaticInitializerReferencesSubClassInspection.java]
seems to do a better job. I wonder whether it would be possible to do
something analogous as a gradle plugin. cc [~dweiss], [~donnerpeter] -- any
solution should apply equally to Lucene build -- or do you think that this
check would be more trouble than it's worth, and we should just manually remove
existing cases and be vigilant?
[~jsweene2] if you want to tackle the existing cases, go for it -- unless
perhaps it makes sense to first figure out whether an automated check can be
added to the build?
> Review static initializers that reference subclasses
> ----------------------------------------------------
>
> Key: SOLR-16167
> URL: https://issues.apache.org/jira/browse/SOLR-16167
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: main (10.0)
> Reporter: Michael Gibney
> Priority: Major
> Attachments: StaticInitializerReferencesSubClass.xml
>
>
> More general follow-up to SOLR-16165.
> There is the potential for classloading deadlock in the case where static
> initializers reference a subclass.
> This issue could cover 1 or 2 things:
> # Fix existing issues
> # Add a build check to prevent such issues from being introduced in the future
> Fixing existing issues should be relatively straightforward, once we're
> specifically looking for them. "in the wild" these are problematic enough
> that it's probably worth just fixing all such issues whether or not they
> manifest as deadlock in practice.
> It would be great if we could port/modify/leverage an existing implementation
> that already checks for this and have it apply automatically in the build,
> unless this approach proves impractical.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
