Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Java interop #1046

Open
1 task done
Petroniuss opened this issue Feb 29, 2024 · 2 comments
Open
1 task done

Support for Java interop #1046

Petroniuss opened this issue Feb 29, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@Petroniuss
Copy link

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.

  • 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
@Petroniuss Petroniuss added the enhancement New feature or request label Feb 29, 2024
@aajtodd
Copy link
Contributor

aajtodd commented Feb 29, 2024

Hey thanks for the feedback.

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.

@Petroniuss
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants