You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
@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.
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 ?
The text was updated successfully, but these errors were encountered: