Interop story

[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.

[JasonSteving99]

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 that is actually just a java.util.ArrayDeque underneath. The reason this isn't exposed to Claro programs outside the stdlib (yet) is because:

• 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]

I am excited to see what progress can be made here as interop with current Java libraries will be helpful filling in some "gaps" for now. :) 👍

[lorefnon]

OK, this is great to know. Thanks for sharing your thoughts on this.