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
Smithy seems to support several programming languages (awesome-smithy) but it seems to lack direct support for Java.
The main complication here is that Kotlin code uses coroutines which are not easily callable from Java (or at least not in an idiomatic way).
Since JVM-based languages are interoperable the easiest way to provide idiomatic support for Java would be to codegen code that would be a bridge between Java and Kotlin.
I noticed that there exists a design spec for java interop here. Are there plans to implement it in the nearest future? Or is smithy-kotlin simply not targeting Java? 🙂
Proposed Solution
Implement Java interop behind a feature gate (plugin configuration property for example).
Describe alternatives you've considered
I was thinking about implementing it myself.
Additional Context
My applications using generated code by smithy are mostly Java-based apps and it'd be preferable for them to use something idiomatic to the language and not hand-write the bridge code.
I may be able to implement this feature request
Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue, please leave a comment
The text was updated successfully, but these errors were encountered:
It would help to understand your use case a bit better. Are you asking for support from the AWS SDK for Kotlin for this or are you using (or planning to) generate code using smithy-kotlin for your own models?
Smithy will eventually support Java as a first class code generator. The recommendation right now for people in Kotlin that need to bridge the two would be to wrap or write extension functions around the coroutines code the same way you would for any other coroutine code to make it callable from Java.
I think we could certainly explore this as a plugin setting for people that want to generate the extra code but we don't currently have plans to implement this. Gathering use cases and how people would want this to look and why they want it would be a good first step.
Hi there,
I was experimenting with Smithy as a tool for codegen similar to thrift or grpc but targeting existing HTTP services communicating over JSON. The main advantage that smithy has is I'd say ease of customizability - for example to extend codegen for Kotlin to adjust it for my use-case I could simply implement KotlinIntegration interface and that would be it.
In my specific case, I'd like to generate clients with some customizations (for example: attaching headers for tracing) but I'd like those clients to be usable from both Kotlin and Java.
Kotlin clients look great (thanks for your work!) but I wouldn't want to write bridge code by hand in a java application to consume a kotlin client - hence my request to generate that code.
I'd be okay with generating different clients for Java and for Kotlin but as you mentioned smithy project doesn't yet support Java.
Describe the Feature
Smithy seems to support several programming languages (awesome-smithy) but it seems to lack direct support for Java.
The main complication here is that Kotlin code uses coroutines which are not easily callable from Java (or at least not in an idiomatic way).
Since JVM-based languages are interoperable the easiest way to provide idiomatic support for Java would be to codegen code that would be a bridge between Java and Kotlin.
I noticed that there exists a design spec for java interop here. Are there plans to implement it in the nearest future? Or is smithy-kotlin simply not targeting Java? 🙂
Proposed Solution
Implement Java interop behind a feature gate (plugin configuration property for example).
Describe alternatives you've considered
I was thinking about implementing it myself.
Additional Context
My applications using generated code by smithy are mostly Java-based apps and it'd be preferable for them to use something idiomatic to the language and not hand-write the bridge code.
Community Note
The text was updated successfully, but these errors were encountered: