Skip to content

Add a getImplementationName method to VectorizationProvider that returns the name of the selected implementation #15294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Add a getImplementationName method to VectorizationProvider that returns the name of the selected implementation #15294

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions lucene/core/src/java/org/apache/lucene/internal/vectorization/VectorizationProvider.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,11 @@ public static VectorizationProvider getInstance() {
Holder.INSTANCE, "call to getInstance() from subclass of VectorizationProvider");
}

/** Returns the name of the {@code VectorizationProvider}'s implementation that's being used. */
public static String getImplementationName() {
return Objects.requireNonNull(Holder.INSTANCE).getName();
}

VectorizationProvider() {
// no instance/subclass except from this package
}
Expand Down Expand Up @@ -224,6 +229,10 @@ private static void ensureCaller() {
}
}

public String getName() {
return this.getClass().getSimpleName();
}

/** This static holder class prevents classloading deadlock. */
private static final class Holder {
private Holder() {}
Expand Down
4 changes: 4 additions & 0 deletions lucene/core/src/test/org/apache/lucene/internal/vectorization/TestVectorizationProvider.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,10 @@ public void testCallerOfGetter() {
expectThrows(UnsupportedOperationException.class, TestVectorizationProvider::illegalCaller);
}

public void testGetProviderName() {
assertEquals("DefaultVectorizationProvider", VectorizationProvider.getImplementationName());
Copy link
Contributor

@msokolov msokolov Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is all makes sense to me, but I'm wondering under what circumstances we would have an alternate provider and whether we can test that. Is that something that only happens in the MRJAR code? If that's right, do we have MRJAR-specific tests where we could test that this also works when we have a non-default provider?

Copy link
Member Author

@tflobbe tflobbe Oct 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean, under what circumstances we could get VectorizationProvider.getImplementationName() return something other than DefaultVectorizationProvider (and thus, make the test fail?). If so, I was thinking something along those lines too, like, if someone runs the tests with the right conditions, this could return the Panama implementation and make the test fail.
I guess an option to handle this case is to relax the test and make the return name be any of the existing implementations. Still, not ideal because it would break in the future if a new implementation is added but not included in this list. We could make the test more complex by looking for all implementations dynamically, but at that point we aren't testing anything that valuable and the test becomes way more complex than the code itself.
Is that what you were thinking? or did I misunderstood your comment?

Copy link
Contributor

@msokolov msokolov Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the value that gets used will currently either be DefaultVectorizationProvider or PanamaVectorizationProvider - The Panama one gets used when the JDK is new enough and the CPU preferred vector size can handle it ... the logic is in VectorizationProvider. So this test will pass or fail depending on the host and JDK used to run it. Although since we require JDK version in the build I think that will be guaranteed to support. But we probably would need to add some kind of assumeTrue so the test doesn't fail on architectures that do or don't support the level of Panama we require.

I'm actually surprised this test passed for you and on github - I would have expected the result to be PanamaVectorizationProvider for most setups?

Copy link
Member Author

@tflobbe tflobbe Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we probably would need to add some kind of assumeTrue

ah, yes, that's a good idea

I'm actually surprised this test passed for you and on github - I would have expected the result to be PanamaVectorizationProvider for most setups?

I guess the build system isn't adding the incubator vectorization module?

Copy link
Contributor

@msokolov msokolov Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'm not clear how we are testing the Panama support -- we must be! I also get confused about whether the incubating flag is required - some Paname stuff finally came out of incubator? But I guess the Vector API is still in it and will be forever. But anyway we must somewhere be running tests with incubus unleashed

}

private static void illegalCaller() {
VectorizationProvider.getInstance();
}
Expand Down
Loading