Both SIP-22 tickets are now filed: - SOLR-18603 (step 4): seal NamedList. PR https://www.google.com/url?q=https://github.com/apache/solr/pull/5267&source=gmail&ust=1793435655885000&sa=E - SimpleOrderedMap is final, so the hierarchy is exactly the two classes. The audit found one other subclass, CloudSolrClient.RouteResponse, which can't be permitted from another package without a module-info, so the PR removes it and carries the per-route replication factor in the merged responseHeader instead; getShardReplicationFactor() keeps working. Details are on the Jira. - SOLR-18612 (step 5): NamedList instantiations -> SimpleOrderedMap, to follow once step 4 lands. It calls out the JSON-visible effect (a SimpleOrderedMap is always written as an object, while a NamedList follows https://www.google.com/url?q=http://json.nl&source=gmail&ust=1793435655885000&sa=E) as the compatibility cost of that step.
On 10.x: happy to prepare a branch_10x backport of SOLR-18603 once it's merged, if you want to enforce it there. The one thing to weigh is that the RouteResponse removal goes along with it, which is an API removal in a minor release; your call. Could you (or any committer) add SOLR-18603 and SOLR-18612 to the JIRA field on the SIP-22 page? Regards, Ivan Šarić Owner and developer Path Variable d.o.o. Vinjerac, Croatia VAT No. HR76935894745 Phone: +385 99 254 9702 E-mail: [email protected] Web: https://www.path-variable.com On Wed, Oct 28, 2026 03:28 PM, David Smiley <[email protected]> wrote: > Thanks. > FWIW I'm totally onboard with enforcing this restriction at the next 10.x > release. Users can adapt if they are subclassing them, which should be > *very* unusual. Additionally, SimpleOrderedMap should be final. Bottom > line: these 2 classes should be locked down with exactly 2 implementations. > > On Wed, Oct 28, 2026 at 6:57 AM Ivan Šarić <[email protected]> wrote: > > > Hi David, > > > > I've filed the first SIP-22 ticket: > > > > SOLR-18603: Seal the NamedList class hierarchy (SIP-22 step 4) > > https://issues.apache.org/jira/browse/SOLR-18603 > > < > > > https://www.google.com/url?q=https://issues.apache.org/jira/browse/SOLR-18603&source=gmail&ust=1793270606387000&sa=E > > > > > > > Scoped as discussed: seal NamedList with an explicit permits list after > > auditing every subclass across all modules (tests and solr/modules > > included), no behaviour or signature changes, main / 11.0 only, with an > > upgrade note since sealing a public SolrJ class is a plugin-compatibility > > change. One PR against main. > > > > I'll file the step 5 ticket (NamedList instantiations -> > SimpleOrderedMap) > > once the audit from step 4 is done, since what it turns up may affect > that > > scope. Thanks for sharing SOLR-18398 - I'll keep step 5 clear of > > SolrQueryResponse and the response header, and I'm happy to help with > that > > one when the time comes. > > > > Regards, > > Ivan Šarić > > Owner and developer > > Path Variable d.o.o. > > Vinjerac, Croatia > > VAT No. HR76935894745 > > Phone: +385 99 254 9702 <+385%2099%20254%209702> > > E-mail: [email protected] > > Web: https://www.path-variable.com > > > > On Thu, Oct 22, 2026 11:09 PM, David Smiley <[email protected]> wrote: > > > > > Thanks for looking to contribute to the effort, Ivan! > > > The NamedList migration SIP is here: > > > > > > > > > https://cwiki.apache.org/confluence/spaces/SOLR/pages/340036504/SIP-22+NamedList+Reduction > > > Some progress was made, but it has stalled. The "Proposed Changes" > > > list is useful and ordered. The last completed step was > > > "NamedList.findRecursive: deprecate and stop using". So you could > > > look to the next one or two. Note that the SIP suggests 10.0 is the > > > bigger release to land incompatible changes on but that version is now > > > Solr 11.0, since 10.0 shipped. > > > > > > Next: > > > > > > Minor: Use Java 17 "sealed classes" to insist the NamedList type > > > hierarchy is exactly what we want; no surprises. > > > > > > Change NamedList *instantiations* to SimpleOrderedMap as appropriate; > > > probably many places. This is Solr 11 only; it can affect backwards > > > compatibility. > > > You might ignore tests for the scope of this. > > > The intended scope of that is where "new" is used -- creating a new > > > NamedList -- using SOM instead. The intended scope is *not* updating > > > common Solr APIs (public methods) to change signature types away from > > > NamedList (to either SOM or Map). Of course we want that too... but > > > perhaps that's too much in one go. > > > > > > On Thu, Oct 22, 2026 at 2:06 PM Houston Putman <[email protected]> > > wrote: > > > > > > > > I think a lot of the next stage will be changing the actual users of > > > > NamedList to change their usage so that a different data structure > can > > be > > > > used. > > > > Or at least identify the easy-win usages and migrate them away. > > > > But maybe I am misunderstanding the goal here. > > > > > > > > - Houston > > > > > > > > On Thu, Oct 22, 2026 at 9:35 AM Ivan Šarić <[email protected]> > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > Earlier this year I contributed the SOLR-17600 series (PRs > > #4463–#4466) > > > > > migrating the codebase from MapSerializable to MapWriter and > removing > > > the > > > > > interface. I'd like to keep contributing in the same area. > > > > > > > > > > Is there a natural next step in the NamedList → Map / MapWriter > > cleanup > > > > > that nobody has picked up yet? I saw SOLR-18373 recently removed > > > > > asShallowMap and the related NamedList helpers, so I assume there > is > > > more > > > > > of that deprecation track planned. If there is an open or > > > soon-to-be-filed > > > > > issue in that direction, I'm happy to take it. > > > > > > > > > > Failing that, I'd appreciate a pointer to any newdev-style ticket > > that > > > fits > > > > > a contributor already familiar with the SolrJ/common.util side. > > > > > > > > > > > > > > > Regards, > > > > > Ivan Šarić > > > > > Owner and developer > > > > > Path Variable d.o.o. > > > > > Vinjerac, Croatia > > > > > VAT No. HR76935894745 > > > > > Phone: +385 99 254 9702 <+385%2099%20254%209702> > > <+385%2099%20254%209702> > > > > > E-mail: [email protected] > > > > > Web: https://www.path-variable.com > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
