STABILITY.md carries a Java interoperability section. It says the public API is suspend functions and
Flows, that they are callable from Java but not idiomatic there, and it names the two bridges a Java
caller should use: future { } from kotlinx-coroutines-jdk8, and runBlocking. There is not one
.java file in this repository.
So a documented promise is an argument, and it is the argument that settled a declined milestone: the
bundled CompletableFuture facade was turned down partly because the bridges are enough. That may well
be right. It is not currently checked, and the ways it goes wrong are specific rather than vague. A
suspend function's Java signature carries a Continuation parameter. Default arguments do not exist
on that side, so every DSL overload with defaults is a different call. An inline function with reified
type parameters is not callable from Java at all, which is how PayloadAccess decodes a payload. A
value class changes a method name in a way nobody sees until they try.
The work is a test source set rather than a document: a Java class that opens a client, creates a
collection, upserts, searches, scrolls and closes, through both bridges, compiled and run by the build
against a real Qdrant.
What it produces is a list of the operations that are awkward or unreachable from Java, and that list is
what belongs in STABILITY.md in place of the present paragraph. "Callable from Java" is a claim a Java
team evaluates a library on, and the honest form of it names the exceptions.
Exit criterion: a Java source set in the build calls the client through both bridges STABILITY.md
documents and runs against a real Qdrant in CI, and the Java interoperability section names what turned
out not to work rather than describing the bridges in the abstract.
STABILITY.mdcarries a Java interoperability section. It says the public API issuspendfunctions andFlows, that they are callable from Java but not idiomatic there, and it names the two bridges a Javacaller should use:
future { }fromkotlinx-coroutines-jdk8, andrunBlocking. There is not one.javafile in this repository.So a documented promise is an argument, and it is the argument that settled a declined milestone: the
bundled
CompletableFuturefacade was turned down partly because the bridges are enough. That may wellbe right. It is not currently checked, and the ways it goes wrong are specific rather than vague. A
suspendfunction's Java signature carries aContinuationparameter. Default arguments do not existon that side, so every DSL overload with defaults is a different call. An inline function with reified
type parameters is not callable from Java at all, which is how
PayloadAccessdecodes a payload. Avalue class changes a method name in a way nobody sees until they try.
The work is a test source set rather than a document: a Java class that opens a client, creates a
collection, upserts, searches, scrolls and closes, through both bridges, compiled and run by the build
against a real Qdrant.
What it produces is a list of the operations that are awkward or unreachable from Java, and that list is
what belongs in
STABILITY.mdin place of the present paragraph. "Callable from Java" is a claim a Javateam evaluates a library on, and the honest form of it names the exceptions.
Exit criterion: a Java source set in the build calls the client through both bridges
STABILITY.mddocuments and runs against a real Qdrant in CI, and the Java interoperability section names what turned
out not to work rather than describing the bridges in the abstract.