Hello. Is there any way to achieve same behavior in Kotlin like package-private in Java? Maybe you c...

# getting-started

[Rafał Kuźmiński]

Hello. Is there any way to achieve same behavior in Kotlin like package-private in Java? Maybe you can recommend some plugins for Intelij? Currently I'm trying to do it with Arch Test, but it works only for JVM part and doesn't work in real time, it can only show errors after running tests. Of course I'm aware of internal modifier, but it is not the same

[Daniel Pitts]

You can use internal which sort of means module-private .

[Daniel Pitts]

lol, just saw your edit.

[Rafał Kuźmiński]

Sure but we cannot have hundreds of modules just to keep some interface implementation from being visible. Internal is great for libraries, but in big project it is not enough

[Daniel Pitts]

In reality you'd be more likely to organize it with a module-per-layer (if you have a layered architecture), in which case using internal makes sense.

[Daniel Pitts]

Having hundreds of packages seems nearly as bad as having hundreds of modules.

[Rafał Kuźmiński]

Could you elaborate? Hundreds of packages does not make me to create and maintain hundreds of build.gradle files. I could not think of any issue related to packages amount

[Daniel Pitts]

I'm not talking about build overhead, but design wise that indicates extreme complexity.

[Daniel Pitts]

If you have a monolithic project with 100 packages, it is definitely type to decompose it into separate modules. Separate projects even.

[Rafał Kuźmiński]

Anyway I don't want to discuss package-private vs internal, there is huge discussion on kotlinlang.org
I only wanted to ask if anyone knows some plugin for Intelij or other way to simulate this behavior.
Complexity is subjective and related to specific project

[Daniel Pitts]

Probably the best way is to create an InternalApi annotation, and mark it as RequiresOptIn

[Daniel Pitts]

Here is an example in the coroutines library:

/**
 * Marks declarations that are **internal** in coroutines API, which means that should not be used outside of
 * `kotlinx.coroutines`, because their signatures and semantics will change between future releases without any
 * warnings and without providing any migration aids.
 */
@Retention(value = AnnotationRetention.BINARY)
@Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION, AnnotationTarget.TYPEALIAS, AnnotationTarget.PROPERTY)
@RequiresOptIn(
    level = RequiresOptIn.Level.ERROR, message = "This is an internal kotlinx.coroutines API that " +
            "should not be used from outside of kotlinx.coroutines. No compatibility guarantees are provided. " +
            "It is recommended to report your use-case of internal API to kotlinx.coroutines issue tracker, " +
            "so stable API could be provided instead"
)
public annotation class InternalCoroutinesApi

[Daniel Pitts]

It doesn't prevent usage, but it strongly discourages.

[Daniel Pitts]

Not that package-private (or even private) prevents usage if you use reflection.

[Rafał Kuźmiński]

Sure but I don't care about how someone would use it, like I said I don't need this for library, just for a project. Most important thing is to hide classes from autocomplete and show compilation error if anyone would try to use them.

There is a private class option, but it can be used only in single file, which is tragic for readability

[Daniel Pitts]

I don't know if the RequiresOptIn hides from autocomplete, but it does show a compiler error.

[Daniel Pitts]

Anyway, that's the best I know of.

[Rafał Kuźmiński]

Sure, thank you!