Open kylepl opened 1 month ago
Ki Kyle, happy to hear you're continuing to give it a try!
The Java bindings are an implementation detail. Our goal down the line is to implement this part natively in the Kotlin library, but we have limited resources right now, so it's not a huge priority.
Can you tell me what your scenarios are for using Java objects directly? It's generally not something we recommend (with maybe one or two exceptions).
https://github.com/VirtuslabRnD/pulumi-kotlin/issues/706 is a good example of needing to fallback to the Java bindings, and wanting to re-use my existing Kotlin logic.
https://github.com/VirtuslabRnD/pulumi-kotlin/issues/706 is a good example of needing to fallback to the Java bindings, and wanting to re-use my existing Kotlin logic.
Yes, but in this case there's no corresponding Kotlin classes, so exposing the Java objects wouldn't really be of much help 😅 Do any other examples come to mind?
Definitely possible that I am missing something better, but in the other example I have:
Ah, I understand, good point. I'll try to figure out how to handle these overlay resources when I get the chance, thank you for your patience 🙏
Sounds good, no rush though, I'm unblocked.
And I empathize with the desire to both hide implementation details and also the occasional need for escape hatches. 😅
Sometime I fallback to using just the Java bindings, but have specified say the provider in the Kotlin side. I tried to extract a JavaProviderResource from a KotlinProviderResource - but it is protected (so I had to patch locally, and start generating more things locally).
My local path is just modifying https://github.com/VirtuslabRnD/pulumi-kotlin/blob/c2839f709f610fa55d0327637230e3bc2d2d91b0/sdk/src/main/kotlin/com/pulumi/kotlin/Common.kt#L52 to be
public
instead ofinternal
.So two questions: