I have a weird scenario and I was wondering if Kot...

# announcements

[Dave Jensen]

I have a weird scenario and I was wondering if Kotlin has any language features that would make the solution more straightforward?
I have a poorly designed 3rd party Java API that we must use. That library has the exact same class, let’s call it Headers, in a dozen or more packages but they do not implement an interface and all extend Object. I’ve struggling to come up with a solution that keeps the code DRY.

[Dave Jensen]

It’s literally something like 🙄

package1.Headers
package2.Headers
...
package20.Headers

And they all have the exact same properties.

[Dragan Stanojević - Nevidljivi]

You can use import alias like
import package1.Headers as <whatever name you like>

[Dave Jensen]

I think that helps. 🤔

[Amirul Zin]

Hmm. Doesn’t that practically make you have to copy paste everything again in the end?

Maybe an intermediary reflection class is needed here to act as a proper double.

[Dave Jensen]

Oof, the R-word.

[Dave Jensen]

I guess the only way to avoid reflection is annotations or a mapper library like MapStruct, which uses annotations.

[Dave Jensen]

I can’t really use a delegate in this situation either, right? The delegate still must implement the interface.

[Dragan Stanojević - Nevidljivi]

I think you can look into Kotlin delegate features for that adapter/intermediary class. Kotlin might just help you avoid a lot of boilerplate code...

[ianrumac]

maybe make a wrapper object that you pass the Header into and have that object obey an interface. you pass in the header as Any, have a setOf(Header1::class.java, Header2::class.java,etc…) which you check against if the object is it then cast into whatever class it is in the set and call the method.

[Dave Jensen]

Well, the other half of the problem is that need to pass that header in like package2.Client.send(package2.Headers, body, etc)

[bbaldino]

Maybe you could define a common type in your lib, write extension functions to convert all the lib types into that type, and extension functions to convert from your type back into the specific types? Then you can bridge the gap by doing MyCommonType.from(Package1.HeadersInstance) and <http://MyCommonType.to|MyCommonType.to><Package2.Headers>() and write some code with reflection to create the right one?

[Dave Jensen]

Yeah, that is similar the approach I'm experimenting with using MapStruct.

[Dave Jensen]

The idea is to have the mapper have mappings like fun convertToHeaders2(headers: MyHeaders): package2.Headers

[bbaldino]

If the params are all exactly the same, I think you could write a single convert function and pass the lib type you wanted via a generic and create it/fill it out using reflection

[Dave Jensen]

Isn't there a performance hit with reflection?
Now I'm wondering if I could generate some code to fill out the covert function without using reflection.

[bbaldino]

You'd have to test if any performance hit was a deal breaker I guess. Are you talking about using kotlinpoet or something? Could also be a good way to do the original generation of all the methods without using reflection.

[Daniel]

Personal opinion: Don't make an already complicated situation more complicated with reflection / code generation ect.

Create a common class in your code and at the very end (where the api calls of the bad java lib are executed) map tthe class to headerXY. Basically wrap the whole lib. This way you can easily swap it out should you be able to some day

[Dave Jensen]

We’d have to do that about 1 dozen times. 😕

[bbaldino]

He's saying write a single wrapper around the "poorly designed 3rd party java API" that defines a custom type and does the translation, couldn't you just re-use that?

[bbaldino]

Or, do what 1 dozen times?

[Dave Jensen]

There are about a dozen APIs we need to call. Each is in it’s own package, each has it’s own version of Headers.

[Daniel]

I see no problem doing this a fixed amount of times. Then we have 12 map yourheader to libheaderX methods. Still less complicated than using reflection, code generation. Its different though when you expect the number of bad java headers to grow but still stay the same structure wise

[bbaldino]

Ah gotcha. I feel like it'd be better to define a new common type and implement all of the to/from stuff then. Don't need to use reflection or code generation for it (or could do the code generation one time and commit the result, not re-generate it every time as part of the build or whatever)

[Dave Jensen]

package1.Api1.send(headers: package1.Headers)
package2.Api2.send(headers: package2.Headers)
package3.Api3.send(headers: package3.Headers)
package4.Api4.send(headers: package4.Headers)
package12.Api12.send(headers: package12.Headers)

[Dave Jensen]

I see no problem doing this a fixed amount of times.

It’s human error prone and IMO doesn’t buy much. Just pushing the problem into the wrapper. At least your code errors are all in one place.

[Daniel]

Is the header implementation (bad java) unstable?

[Dave Jensen]

Basically, I’m trying to avoid the same 12 lines of code over and over again.

[Dave Jensen]

Possibly, it’s generated from WSDL. 🤯

[Dave Jensen]

I really didn’t want to mention that piece because it might derail to conversation. So let’s not talk about WSDL. 😉

[Daniel]

As always: personal opinion: The duplication here is "accidental" duplication. They may look the same now, but when you even say its unstable they may not look the same a few month out.

Personally I see that its nicely dividable in api calls. Lets say you have a MakeApi1Request class which does something and then you have a MakeApi2Request class which does something different. That the mappers inside the classes which map from your business code to theirs are the same at the moment is not a big concern. This might change any moment. For example tomorrow they change api2.header and only this one. Then you only have to update one mapper

[Daniel]

But of couse you can make a better asumption here, its only as I would do it given the current information 🙂