JasonSteving99
commented
4 months ago Great question! This is actually something that will take more work to pull off "right" - but it's definitely planned.
For now, Java code can call into Claro code in a fairly straightforward way. The main hurdles are:
- the namespacing/naming of the Claro code you're calling into is funky because Claro doesn't use Java's "package" namespacing system
- manually constructing non-primitive data to pass to Claro procedures is currently very annoying and technically unsafe (you could break Claro's type system rules)
In the other direction, Claro's only (current) mechanism for calling into Java directly is restricted to the stdlib's implementation. For example the deque Module exports an opaque newtype mut Deque
- the type systems are very dissimilar and would need mapping
- Claro doesn't use Exceptions, so you'd have to ensure that any calls into Java code that can throw manually catches and models an error return value
All this said, it's very possible that in the future these limitations can be addressed!
swork1
lorefnon
Hello, thanks for open sourcing claro - this looks quite interesting.
Coming from kotlin, I am curious what is your perspective on interop with other jvm libraries, which I couldn't glean from the docs. Is this something that will be possible and if so, will it require claro wrappers to be authored for individual libraries ? I guess the latter is needed to retain the guarantees claro provides but still curious where this lies in your roadmap.