Curious what other peoples opinions are for this. ...

# announcements

[Dan Newton]

Curious what other peoples opinions are for this.

My team and I are considering using Java interfaces instead of Kotlin interfaces for our public APIs while working on a library that can be heavily used by both.

The main reason for using Java interfaces is to ensure that Java is a first class citizen and to make it harder for us to rely on Kotlin’s syntactic sugar that can lead to APIs that are annoying to use from Java. Yes, there are rules we can put in place to make sure our API is easy to use from Java but I would argue its harder to follow these instead of 1 rule of “all public api interfaces in Java!“. This could also make it easier to onboard new developers as the one rule is easier to follow.

Interested to hear what others think.

[christophsturm]

if you want to make sure that its great to use it from java you could add an additional test suite thats written in java.

[Dan Newton]

yes, thats an option we’ve considered. But then the downside is having to write extra tests per api.

[Casey Brooks]

☝️While I understand the sentiment, I think you’d lose a lot of null-safety, and that will cascade throughout the entire Kotlin implementation. By declaring interfaces in Java, you’ll run into a problem where there is no nullability info on the Kotlin side, and so you’ll naturally tend to treat parameters as non-null, but there’s no way to enforce that from the Java side.

Rather than writing extra tests in Java, you may want to just write all tests in Java. Still just 1 thing to remember, and helps enforce the code style you’re looking for

[christophsturm]

i would write the normal test suite in kotlin and just very simple tests in java. tests in kotlin are just so much easier to read

[Rob Elliot]

The java “tests” don’t really need to be tests as such, after all - you just need the expressions to compile, nothing has to happen at runtime.

[andylamax]

I agree with @Casey Brooks on this one. Write all your tests in Java

[Big Chungus]

I like your approach. Although I'd make sure to use nullability annotations on such java interfaces to ensure that it can be used with null safety on kotlin side

[Big Chungus]

With those in place, you'll get the same null safety in kotlin as with regular kotlin interfaces

[Rob Elliot]

Test legibility & refactorability is at least as, if not more, important than production legibility, in my view. Personally I would be very reluctant to sacrifice kotlin’s expressiveness in my test code.

[Dan Newton]

@Casey Brooks one consideration we’ve had around nullability is to use annotations like @NotNull to prevent exactly what you’re talking about

[Dan Newton]

unfortunately not part of the language per say but with IDE integration should a solution to handling nullability

[Dan Newton]

ah just aw @Big Chungus mentioned this (was afk for a bit)

[Dan Newton]

and yes, I agree with writing all test code in java would be much more annoying to us than writing java interfaces

[Hanno]

We have been in such a Situation and we switched from initially Java interfaces to kotlin ones, because it's too annoying what you lose... Nullability, extension functions in interfaces, companions...

We are happy with having a single test suite that is written in java, using much of the api surface, disabled so that they only compile.

I can just give the advice to not write apis in java, it's Not Worth it

[Zach Klippenstein (he/him) [MOD]]

I would also recommend using Jetbrains’ binary compatibility validator to keep an eye on what your API actually looks like in bytecode (roughly): https://github.com/Kotlin/binary-compatibility-validator

[Dan Newton]

@Hanno I think some of those downsides can be managed (e.g. @NotNull and we can always have a file containing extension functions for an interface where appropriate). The tests is interesting, as a few of you have mentioned now were we only care about it compiling. Disabling the tests to just check compilation takes it a step further 🤔

[Dan Newton]

@Zach Klippenstein (he/him) [MOD] I’ll check if we are using that or not already 👍

[Arkadii Ivanov]

Another thing is generics variance/covariance. This information will be lost with Java interfaces/classes.

[Dan Newton]

yes, that is a downside that doesn’t have an answer

[Hanno]

Of course you can Model some things with java, but as i said we tried that and it resulted in being a burden that really is not necessary. I mean you can try for yourself, but since you are interested in others experience... I wouldnt recommend doing it in Java :)

[Hanno]

The only thing we though was not nice enough for java users in our code was companion object usage and non-jvm default methods. We found out by writing some tests, all other things were fine :)

[Hanno]

Oh and of course some annotations fixed those

[Dan Newton]

Yeah, I found while trying to write a doc justifying the java based approach was that what we really want, is to get people to write code in a certain way

[Dan Newton]

That is considerate of java users

[Dan Newton]

Rather than there actually being issues with using kotlin code from java

[Hanno]

Oh and i forgot one thing, it's super easy and nice to have data classes, also in the api. But immutable data classes are a problem for java users because they can't really use copy, so we added some wither functions to our data classes, although i hate that, it was necessary

[Dan Newton]

Ye we would still use kotlin data classes were appropriate.

[Dan Newton]

Thanks for your thoughts everyone 😄