Skip to content
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.

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

Make it possible for JVector users to consume MemorySegmentReader #322

Open
jkni opened this issue May 17, 2024 · 2 comments
Open

Make it possible for JVector users to consume MemorySegmentReader #322

jkni opened this issue May 17, 2024 · 2 comments

Comments

@jkni
Copy link
Collaborator

jkni commented May 17, 2024

The JVector jar available through Maven Central packages JVector 11 on the regular class path, with jvector-twenty and jvector-native adding additional classes through multi-release JAR support. This means that users depending on JVector cannot import/use MemorySegmentReader directly. In jvector-examples, we use ReaderSupplierFactory to provide the best reader implementation based on what is available at runtime.

What would be the best way to make MemorySegmentReader available to users building on JVector? Should we provide ReaderSupplierFactory in jvector-base (or something similar, that would provide MemorySegmentReader for nothing, if we think the other implementations aren't production-worthy).

Any thoughts here @mdogan ?

@mdogan
Copy link
Collaborator

mdogan commented May 20, 2024

I think a public ReaderSupplierFactory is the simplest solution (or maybe something using Java service provider facility, but personally I dislike them :)

An alternative would be not to package with multi-release jar but instead having separate packages for Java versions. Then people would depend on the specific artifacts for their jdk version. But this would be a significant change.

Btw, is there a specific reason for you want jvector to be Java 11 compatible? I don't think anyone serious with building a vector index will stay on 11.

@jkni
Copy link
Collaborator Author

jkni commented May 20, 2024

@mdogan Thanks for the feedback! We do have cases where it's being used with Java 11 at this time, but I'm very sympathetic to the push to modern JDKs as the best option here. I think it makes sense to revisit this decision periodically and way the cost/benefit of supporting older versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants