I opened https://issues.apache.org/jira/browse/LUCENE-10283.
On Fri, Nov 5, 2021 at 3:46 AM Robert Muir wrote:
>
> On Thu, Nov 4, 2021 at 10:42 AM Dawid Weiss wrote:
> >
> > > we don't have to "support" users on our main trunk branch. That's why
> > > we make releases.
> >
> > Nah. I don't
On Thu, Nov 4, 2021 at 10:42 AM Dawid Weiss wrote:
>
> > we don't have to "support" users on our main trunk branch. That's why
> > we make releases.
>
> Nah. I don't agree with this one - you have to be aware about who is
> using your project (especially a library) and in what context. Maybe
> we
variable in each case is then finally
> > obsolete.
> > You have then “variable = switch(….)”. And finally we will get a switch for
> > instanceofs a bit later (hopefully at same time when Panama comes out)
> > > >>
> > > >>
> > > >
> > >>
> > >> Records are bullshit, sorry. It’s only useful for the
> Hibernate/Spring/Foobar-like Entities-For-Everything business logic. It may be
> useful at some point when they are no instances on heap anymore and just
> data wrappers, but based on classes I see n
: Bump minimum Java version to 17 on main (10.0)
I prefer that we require JDK 17 for build/test but allow our artifacts (except
lucene-test-framework maybe) to be run on JDK 11 (or 14?) via setting the
"target". This allows us some time to appreciate some of the benefits of
Java/JDK
> we don't have to "support" users on our main trunk branch. That's why
> we make releases.
Nah. I don't agree with this one - you have to be aware about who is
using your project (especially a library) and in what context. Maybe
we differ in our opinion here. Your previous argument is much more
will get a switch for instanceofs a bit later (hopefully
> > >> at same time when Panama comes out)
> > >>
> > >>
> > >>
> > >> Records are bullshit, sorry. It’s only useful for the
> > >>
l for the
> >> Hibernate/Spring/Foobar-like Entities-For-Everything business logic. It
> >> may be useful at some point when they are no instances on heap anymore and
> >> just data wrappers, but based on classes I see no reason to use them for
> >> Lucene.
> >&
ords are bullshit, sorry. It’s only useful for the
>> Hibernate/Spring/Foobar-like Entities-For-Everything business logic. It may
>> be useful at some point when they are no instances on heap anymore and just
>> data wrappers, but based on classes I see no reason to use them for
oint when they are no instances on heap anymore and just
> data wrappers, but based on classes I see no reason to use them for Lucene.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@t
://www.thetaphi.de
eMail: u...@thetaphi.de
From: Dawid Weiss
Sent: Thursday, November 4, 2021 8:27 AM
To: Lucene Dev
Subject: Re: Bump minimum Java version to 17 on main (10.0)
Now you're talking.
+1.
On Thu, Nov 4, 2021 at 1:49 AM Robert Muir mailto:rcm...@gmail.com> >
Now you're talking.
+1.
On Thu, Nov 4, 2021 at 1:49 AM Robert Muir wrote:
> 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
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
>
> 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
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
+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
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
> >
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
> 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
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
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
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
22 matches
Mail list logo
