Let's not bother disturbing 10x. On Wed, Nov 4, 2026 at 6:49 AM Ivan Šarić <[email protected]> wrote:
> SOLR-18603 is merged (ad26fdf2c), thanks David for the review and Nick for > the extra tests. Thanks also for the JIRA search link on the SIP-22 page; > it picks up both tickets. > > One open question from this thread, on 10.x: you mentioned enforcing the > sealing at the next 10.x release. If you still want that, I can open a > branch_10x backport PR this week; the one thing to weigh is the > RouteResponse removal, which is an API removal in a minor. Say the word > either way. > > Next I'll start on SOLR-18612 (step 5), beginning with the solrj module as > its own PR. > > 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 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> > <+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> > > > <+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] > > > > > > > > > > > > > >
