`internal` is `public` in Java, so our libs leak i...

# announcements

[dagguh]

internal is public in Java, so our libs leak internal API
is there a way to post-process Kotlin-generated bytecode to translate the internal to package-private?

[diesieben07]

That would potentially break your code, since internal can be accessed across packages in Kotlin.

[dagguh]

yikes, good catch

[diesieben07]

If you really do want to hide them from Java, you can use the @JvmSynthetic annotation

[dagguh]

I cannot apply it on constructors though 😕
so I can make the constructors private and then add factory method and make it synthetic
it leaks a Companion class to Java, but it’s pretty benign 🤔

[diesieben07]

Seems like an oversight that it can't be put on constructors... but yes, you can work around it like that if you absolutely must hide it from Java.

[dagguh]

well, we have to hide them
otherwise, our Java callers are not informed to avoid this specific constructor
and we want to be able to change it in the future without breaking our callers

[dagguh]

https://discuss.kotlinlang.org/t/another-call-for-package-private-visibility/9577/6
it seems @JvmSynthetic has negative side-effects

[diesieben07]

Huh, I was not aware of that.

[diesieben07]

Not much you can do here then, I think. At least IntelliJ will warn people trying to use those internal members.

[dagguh]

That’s unfortunate. The main appeal of Kotlin was that it’s a better Java. Which for me meant that it has the advantages of Java, while fixing many of its flaws. Now it seems that my control of JVM API is limited and my API consumers would have to switch to IntelliJ rather than being happy with a Java IDE of their choice. I don’t want to go back to vanilla Java 😢

[ribesg]

Everybody but the language designers want package in Kotlin

[tddmonkey]

If you want to control access to the constructors, why not make them all private and use a JvmStatic creator method in a companion object?

[hho]

We need more votes for https://youtrack.jetbrains.com/issue/KT-29227

[dagguh]

@tddmonkey, then the creator method is public. I wanted to keep all creation within the lib and not in the API.

[tddmonkey]

ok - that was in response to you saying you wanted to control access to certain constructors so you could change them

[dagguh]

My current “solution” is to stop wanting to hide the constructors (or builders/factory methods). I still want the ability to incompatibly change their signatures. To do that, I’ll move their public members to an interface and expose its implementation in the API too. When I’ll want to provide a different signature for internal reasons, I’ll add a new implementation, leaving the old one intact.

[dagguh]

Also, package-private wouldn’t work too well either, because it’d mean that internal API consumers would all have to reside in the same package - making it huge.

[diesieben07]

So you want something on the JVM that the JVM has no support for. Go talk to the JVM people 😛 Sorry for the snark, but how do you expect this to work?

[dagguh]

you are right, what I wanted is internal, that works in Java, but Java doesn’t have it and package-private is not it either

[dagguh]

my bad

[hho]

Is that what Javas module system should provide?

[dagguh]

Java modules don’t allow a single class to have both public (exported) and internal members
unless you use package-private, but it still causes the uber-package problem

[louiscad]

If you want to expose an API without exposing constructors or coupling the API with the implementation, using an interface is almost always the best solution.