[
https://issues.apache.org/jira/browse/SOLR-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025607#comment-15025607
]
Hoss Man commented on SOLR-8333:
--------------------------------
bq. ... Making CacheEntry public is the simple fix, but since the class should
only be used internally and never by users, I wonder if this is better: ...
Shawn: I think any API improvements/refacotring/class-moving should be tracked
in a dedicated issue, where the questions of backcompat and code structure can
be considered appropriately, and decisions can be made about wehter those
changes are trunk only or 5x, etc...
For this issue i really think we should focus on the minimum viable changes
that can be made to the existing APIs in terms of class level visibility in
order for the APIs to not be broken in 5.x - ideally in such a way that we
don't break any existing user plugins that might be using these classes...
* erik already fixed hte issue with SimplePostTool -> GlobFileFilter by making
the public API refer to an appropriate public abstraction/interface rather then
the concrete impl.
* for HLL -> ISchemaVersion we should make ISchemaVersion public
** it was public in the original java-hll project, i'm not sure why dawid
removed that when importing
* for ConcurrentLRUCache & ConcurrentLFUCache I think we should go ahead and
make the respective static inner CacheEntry classes public for now.
any concerns with these solutions to address the immediate problems?
(I have yet to find any automated tools that might make it easy to fail the
build if any other such API problems exist)
> fix public methods that take/return private/package-private arguments/results
> -----------------------------------------------------------------------------
>
> Key: SOLR-8333
> URL: https://issues.apache.org/jira/browse/SOLR-8333
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: SOLR-8333-ConcurrentLFUCache-protected.patch,
> SOLR-8333.patch
>
>
> background info:
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201511.mbox/%3Calpine.DEB.2.11.1511231128450.24330@tray%3E
> A commit that added a package to solrj which already existed in solr-core
> caused the javadoc link checker to uncover at least 4 instances of private or
> package-private classes being neccessary to use public APIs.
> we should fix these instances and any other instances of APIs with similar
> problems that we can find.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
