We love the performance improvements, but most of our upgrades are because of
CVEs that aren’t backported. We need to upgrade Thing X to the next major
version and that version requires a more recent Java.
Java versions for Solr are managed separately from the massive Java codebase,
but we’d
> It's not just you - we have an internal JDK11 fork at BIG COMPANY for some
> folks that can't get off the stick.
>
The truth is - most large companies will be reluctant to upgrade unless
they see a benefit in doing so. Here, we can offer this benefit (call it a
carrot, if you mentioned the
Yes, LexisNexis is running Java 11 and will probably move to Java 17 soon
because of Spring Boot 3 requirements. We are running a few hundred Solr nodes,
mostly 9.1. Probably a few 8.10 clusters out there.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
+1 to a 10.0 on JDK17.
There is no "agreement" anywhere to follow a 2-year cadence for major versions,
even if that's been a pattern.
Adopting a new JDK with clear benefits or getting off an EOL JDK should be
valid arguments for considering a new major.
If downstream wants to keep supporting
It's not just you - we have an internal JDK11 fork at BIG COMPANY for some
folks that can't get off the stick. To be fair it's challenging because
they have to shift all their dependencies. I think Spark was the one
mentioned by one group, but there is a JDK17-based release of Spark, so
clearly
For perspective, I'm still seeing java 11 as the norm for clients... 17 is
uncommon. Anything requiring 21 is likely to be difficult to sell. I am
however a small shop, and "migrating off of solr 6" and "trying out solr
cloud" is still a thing for some clients.
Just a datapoint/anecdote, possibly
Hi Robert,
> On 6 Nov 2023, at 12:24, Robert Muir wrote:
>
>> …
>> The only concern I have with no.2 is that it could be considered an
>> “aggressive” adoption of Java 21 - adoption sooner than the ecosystem can
>> handle, e.g. are environments in which Lucene is deployed, and their
>>
> > The only concern I have with no.2 is that it could be considered an
> > “aggressive” adoption of Java 21 - adoption sooner than the ecosystem can
> > handle, e.g. are environments in which Lucene is deployed, and their
> > transitive dependencies, ready to run on Java 21? By the time we’re
On Mon, Nov 6, 2023 at 4:22 AM Chris Hegarty
wrote:
>
> Hi,
>
> Great discussion, I agree with all that you have said. And that we will have
> to deal with the intricacies of the MR-JAR regardless of the outcome here,
> which is doable.
>
> I would very much like to avoid supporting Java 17
Hi,
Great discussion, I agree with all that you have said. And that we will have to
deal with the intricacies of the MR-JAR regardless of the outcome here, which
is doable.
I would very much like to avoid supporting Java 17 (released in Sep 2021) in
2025. So far we have two possible
Hi,
thanks Chris. This is why I suggested the idea, to have the discussion
here. We are already close to Lucene 9.9. Do we want 9.10? We had that
long series of minor releases only int the 4.x branch (which ended in 4.10).
I have some comments inline:
On 3 Nov 2023, at 13:11, Uwe Schindler
Hi Uwe,
Thanks for your reply, comments inline.
> On 3 Nov 2023, at 13:11, Uwe Schindler wrote:
>
> Hi,
>
> I had another idea: Why not release main as 10.0.0 *NOW* and create
> branch_10x (with Java 17) minimum, stop working on 9.x, and move main branch
> to 21?
I see now that 9.x has a
Hi,
I had another idea: Why not release main as 10.0.0 *NOW* and create
branch_10x (with Java 17) minimum, stop working on 9.x, and move main
branch to 21?
I would be happy to remove the MmapByteBuffer directory in Java 18.
Unfortunately in Java 21 we still need a hack top compile the
Hi,
I would like to start the discussion and gather feedback on bumping the
minimum Java version requirement to 21.
I have no particular timeline in mind, but these kinda bumps often
require dependency updates [*], small code refactorings, etc, and can
take some time to plan and execute. It's
14 matches
Mail list logo
