Update TermInSetQuery Example?
Hi
I recently found TermInSetQuery example at
https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/TermInSetQuery.html
but if I understand correctly one should use now BooleanQuery.Builder
instead BooleanQuery itself, right?
BooleanQuery.Builder bqb = new BooleanQuery.Builder();
bqb.add(new TermQuery(new Term("field", "foo")),
BooleanClause.Occcur.SHOULD);
bqb.add(new TermQuery(new Term("field", "bar")),
BooleanClause.Occcur.SHOULD);
Query q2 = new ConstantScoreQuery(bqb.build());
If so, I would be happy to do a minor pull request or feel free to
update it directly.
Thanks
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause
FWIW: The choice to ignore the original exception goes back to here...
https://issues.apache.org/jira/browse/LUCENE-3588
...circa 2011, where it was focused on catching NPE and throwing
AlreadyClosedException instead, w/o any particular discussion as to why to
throw away the original NPE.
If i had to guess it's simply because at that time AlreadyClosedException
didn't support wrapping any other Throwable. That wasn't added until
LUCENE-5958 (circa 2014) which was focused on making sure "tragic" errors
kept a record of what caused the tragedy, and then include that as the
'cause' of the AlreadyClosedExceptions throw by 'ensureOpen()'
There didn't seem to be any discussion at that time about reviewing other
code that might be throwing AlreadyClosedException from a 'catch' block
that could also be updated to include the cause.
I'd say open a PR to review & update all code that results in
AlreadyClosedException originating from a catch block?
: Date: Tue, 17 Oct 2023 11:24:03 -0400
: From: Michael Sokolov
: Reply-To: dev@lucene.apache.org
: To: Lucene Dev
: Subject: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't
: track its cause
:
: I was messing around with something that was resulting in
: AlreadyClosedException being thrown and I noticed that we weren't
: tracking the exception that caused it. I found this in
: ByteBufferIndexInput:
:
:// the unused parameter is just to silence javac about unused variables
:AlreadyClosedException alreadyClosed(RuntimeException unused) {
: -return new AlreadyClosedException("Already closed: " + this);
: +return new AlreadyClosedException("Already closed: " + this, unused);
:}
:
: and added the cause there, which helped me find and fix my wicked
: ways. Is there a reason we decided not to wrap the "unused"
: RuntimeException there?
:
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
:
:
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Greetings!
JDK 21 has been released (General Availability) on September 19th as planned.
You can find "The Arrival of Java 21" announcement here [1], and some
additional Java 21 materials in the "Topics of Interest" section below. On
behalf of the entire Java team, let me send our thanks to all of you. Through
your active participation in this program, you are helping shape the Java
platform!
Needless to say, that Java 21 is an important release, so may I ask you to send
me a brief email with the Java 21 support status of your project(s): Already
supported - Plan to support short-term - Don't plan to support short-term ?
And now that JDK 21 is out, let's shift our attention to JDK 22 which will
enter the Rampdown Phase in less than 50 days on December 7 [2].
I want to conclude this update by briefly mentioning three different
initiatives to are relevant to this group as they are, in their own way and at
various levels, contributing to adopt newer Java releases more rapidly: the
Class-File API, Oracle's Java Platform extension for VS Code, and the Java
Playground.
### The Class-File API
The Class-File API is a new standard API for parsing, generating, and
transforming Java class files. One of its unique aspects is that it will
co-evolve with the class-file format, which overtime will greatly reduce the
friction of implementing new class-file features. With the fast-paced evolution
of the Java platform, this was much-needed. This API should soon be previewed
and as it matures, we expect the JDK to switch from using various custom
class-file libraries to this standard API. We also expect that overtime
frameworks relying on bytecode manipulation will also benefit from using this
new JDK class-file library. For more information, please check this recent
Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details
and design considerations, and JEP 457: Class-File API (Preview) [5] for the
technical details.
### Oracle's Java Platform extension for Visual Studio Code
Oracle has just announced [6] a new Visual Studio Code extension for Java
developers. Unlike other VS Code extensions, this new extension is using under
the hood the `javac` compiler for code editing and compilation, and OpenJDK's
debugger interface for debugging. This enables us to offer VS Code IDE support
for new JDK features as soon as they are introduced, even during JDK Early
Access phases. To this effect, this VS Code Extension will support the current
JDK releases as well as the next upcoming JDK version. For more information,
please check the announcement [6].
### The Java Playground
The Java Playground [7] is an online sandbox that helps testing and exploring
new Java language features. No setup required, just type your Java snippet in
your browser and run it! Right now, the Playground is using Java 21 with
Preview Features enabled, and it will switch to a new Java version as soon as
there is a new Java language features integrated in OpenJDK Early-Access
builds. The Playground is focusing mostly on Project Amber and is certainly not
mean to be some sort of a lightweight online-IDE, it is instead a learning tool
to play with new Java language feature shortly after they have been integrated
into the platform.
[1] https://inside.java/2023/09/19/the-arrival-of-java-21/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html
[3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks
[4] https://www.youtube.com/watch?v=pcg-E_qyMOI
[5] https://openjdk.org/jeps/457
[6] https://inside.java/2023/10/18/announcing-vscode-extension/
[7] https://dev.java/playground
## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21
javac emits a note if _implicit_ annotation processing is being used, that is,
if one or more annotation processors are found and run from the class path when
no explicit annotation processing configuration options are used.
The note is reported since, quoting from the note text: "A future release of
javac may disable annotation processing unless at least one processor is
specified by name (-processor), or a search path is specified
(--processor-path, --processor-module-path), or annotation processing is
enabled explicitly (-proc:only, -proc:full)."
That future version of javac has arrived in JDK 22 b19+ with JDK-8306819
("Consider disabling the compiler's default active annotation processing"). In
the situation where a note was emitted in JDK 21, in JDK 22 no note is emitted,
and annotation processors are *not* run. To restore the previous behavior with
respect to running annotation processors, add the '-proc:full' javac option.
Feedback on the annotation processing policy change can be sent to compiler-dev
[9].
[8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
[9] https://mail.openjdk.org/mailman/listinfo/compiler-dev
## JDK
Re: Welcome Luca Cavanna to the Lucene PMC
Welcome, congratulations! Le ven. 20 oct. 2023 à 10:02, Dawid Weiss a écrit : > > Congratulations, Luca! > > On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand wrote: > >> I'm pleased to announce that Luca Cavanna has accepted an invitation to >> join the Lucene PMC! >> >> Congratulations Luca, and welcome aboard! >> >> -- >> Adrien >> >
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations, Luca! On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand wrote: > I'm pleased to announce that Luca Cavanna has accepted an invitation to > join the Lucene PMC! > > Congratulations Luca, and welcome aboard! > > -- > Adrien >
Where do we send users who want to request changes to the Lucene application API or design?
Hello, We on the Lucene.NET project are setting up issue templates for GitHub to put some guardrails in place about submitting design changes that are not specific to the .NET platform, but more general about Lucene. We are thinking of dropping a link to you, but not sure whether to suggest using the Lucene dev mailing list, the "Enhancement Request/Suggestion" category on GitHub Issues, or somewhere else. Please advise. This is a work in progress, but here is what it looks like so far: https://github.com/NightOwl888/lucenenet-issue-template-demo/issues/new/choose Thank you, Shad Storhaug Project Chairperson - Lucene.NET
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations Luca, well deserved! On Thu, Oct 19, 2023 at 11:02 PM Lu Xugang wrote: > Congratulations Luca ! > > > Xugang > https://www.amazingkoala.com.cn > > > Adrien Grand 于2023年10月20日 周五13:51写道： > >> I'm pleased to announce that Luca Cavanna has accepted an invitation to >> join the Lucene PMC! >> >> Congratulations Luca, and welcome aboard! >> >> >> -- >> Adrien >> > -- Marcus Eagan
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations Luca ! Xugang https://www.amazingkoala.com.cn Adrien Grand 于2023年10月20日 周五13:51写道： > I'm pleased to announce that Luca Cavanna has accepted an invitation to > join the Lucene PMC! > > Congratulations Luca, and welcome aboard! > > > -- > Adrien >
