Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Robert Muir
On Wed, Nov 3, 2021 at 1:36 PM Dawid Weiss wrote: > > I principally agree with you - we should leverage new Java features and I'm > all for it. I just don't see much difference between > Java 11 and 17 in the context of Lucene... Upgrading for the sake of > upgrading doesn't justify the move to

Re: 8.11 release candidate

2021-11-03 Thread Adrien Grand
Jason's above issue isn't fixed yet but it looks like we should be able to have a fix in the very near future. However we seem to still have these two other open Solr blockers for 8.11: - SOLR-14438 : Mention decodeAES in LICENSE.txt - SOLR-15762

Re: [JENKINS] Lucene » Lucene-Solr-Tests-8.11 - Build # 7 - Unstable!

2021-11-03 Thread Adrien Grand
Thanks for the pointer Dawid. On Wed, Nov 3, 2021 at 4:15 PM Dawid Weiss wrote: > > It's this one, Adrien - > https://issues.apache.org/jira/browse/LUCENE-10190 > > On Wed, Nov 3, 2021 at 4:01 PM Adrien Grand wrote: > >> I ran 100 iterations with ant beast but could not reproduce this failure.

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Dawid Weiss
> > six months to a year? I think it has been 2.5 years since the last > major release! > I was hoping for an improvement here! :) > we should try to be free to use the latest JDK and Java language improvements. I principally agree with you - we should leverage new Java features and I'm all for

Re: Taxonomy backward compatibility tests

2021-11-03 Thread Patrick Zhai
Got it, thanks Adrien. I'll try to make it ready these days. Adrien Grand 于2021年11月2日周二 上午11:23写道: > Hi Patrick, > > Lucene 9.0 is supposed to be feature frozen, so in theory this change > shouldn't make it to 9.0. That said, having it merged before 9.0 would help > not have to carry over the ba

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Mike Drob
We'll be going to Java 18 or 19 as a minimum for MMapDirectory using the new Panama APIs once those stabilize, right? We could probably benefit today some from record classes, but I'm not sure how much of a hint those are to the runtime VM for optimizations or if it is entirely a source code synta

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Michael McCandless
+1 for JDK 17 or maybe 18. In main (to eventually be Lucene 10.0, a couple years from now?) we should try to be free to use the latest JDK and Java language improvements. Mike McCandless http://blog.mikemccandless.com On Wed, Nov 3, 2021 at 12:57 PM Robert Muir wrote: > On Wed, Nov 3, 2021 a

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Robert Muir
On Wed, Nov 3, 2021 at 12:51 PM Robert Muir wrote: > > > > It will be released, eventually, right? In six months, a year maybe? Then > > it's people like me who would be affected: we use Lucene internally and > > this one dependency would push the entire stack to Java 17. I wouldn't mind > > th

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Robert Muir
On Wed, Nov 3, 2021 at 12:32 PM Dawid Weiss wrote: > > >> Who would we be forcing to upgrade? It is the 'main' branch: unreleased. > > > It will be released, eventually, right? In six months, a year maybe? Then > it's people like me who would be affected: we use Lucene internally and this > one

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Dawid Weiss
> Who would we be forcing to upgrade? It is the 'main' branch: unreleased. > It will be released, eventually, right? In six months, a year maybe? Then it's people like me who would be affected: we use Lucene internally and this one dependency would push the entire stack to Java 17. I wouldn't mind

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Robert Muir
Who would we be forcing to upgrade? It is the 'main' branch: unreleased. +1 to bump to 17 On Wed, Nov 3, 2021 at 11:19 AM Dawid Weiss wrote: > > > Do we gain much from such a requirement? Are there APIs that make things run > faster or perform better? > > The downside for me is that if Lucene r

Re: Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Dawid Weiss
Do we gain much from such a requirement? Are there APIs that make things run faster or perform better? The downside for me is that if Lucene requires Java 17 then all downstream projects will be forced to require Java 17. And Java 11 LTS is still perfectly fine and supported. So unless there is a

Re: [JENKINS] Lucene » Lucene-Solr-Tests-8.11 - Build # 7 - Unstable!

2021-11-03 Thread Dawid Weiss
It's this one, Adrien - https://issues.apache.org/jira/browse/LUCENE-10190 On Wed, Nov 3, 2021 at 4:01 PM Adrien Grand wrote: > I ran 100 iterations with ant beast but could not reproduce this failure. > > I won't treat this test failure as a blocker for the release, but I > suspect there's stil

Re: [JENKINS] Lucene » Lucene-Solr-Tests-8.11 - Build # 7 - Unstable!

2021-11-03 Thread Adrien Grand
I ran 100 iterations with ant beast but could not reproduce this failure. I won't treat this test failure as a blocker for the release, but I suspect there's still something wrong with it. On Wed, Nov 3, 2021 at 12:36 PM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > Build: > https:

Bump minimum Java version to 17 on main (10.0)

2021-11-03 Thread Adrien Grand
Hello, Now that the main branch is the future 10.0 version, would there be any concern if we bumped the minimum Java version to 17 instead of 11? -- Adrien

Re: [JENKINS] Lucene » Lucene-NightlyTests-9.x - Build # 1 - Unstable!

2021-11-03 Thread Dawid Weiss
Ok, I see the discussion here. https://issues.apache.org/jira/browse/LUCENE-10088 On Wed, Nov 3, 2021 at 10:22 AM Dawid Weiss wrote: > > This thing does reproduce (with the seed and multiplier/ nightly). When it > hits the breakpoint, the temporary folder has over 6k files in it (not all > of t

Re: [JENKINS] Lucene » Lucene-NightlyTests-9.x - Build # 1 - Unstable!

2021-11-03 Thread Dawid Weiss
This thing does reproduce (with the seed and multiplier/ nightly). When it hits the breakpoint, the temporary folder has over 6k files in it (not all of them are open file handles, I guess, but still!). I corrected an unclosed reader in the test but it still seems like too many open files (shouldn'