# Kotlin to support package protected visibility **URL:** \ **Category:** Language Design\ **Created:** [March 18, 2016, 11:05am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544 "2016-03-18T11:05:14Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![sam.zhou](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/sam.zhou/32/4922_2.png) [@sam.zhou](https://discuss.kotlinlang.org/u/sam.zhou)\ **Post date:** [July 12, 2018, 4:32pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/42 "2018-07-12T16:32:08Z")
The “lightweight” module I prefer is the ability to mark a package as a module. This restriction is only enforced at compile time. Those members marked with internal will then be compiled to package-private members post-fixed with ugly module name to tell Kotlin it’s internal. ---
**Author:** ![hqzxzwb](https://avatars.discourse-cdn.com/v4/letter/h/43a26b/32.png) [@hqzxzwb](https://discuss.kotlinlang.org/u/hqzxzwb)\ **Post date:** [August 20, 2018, 6:53am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/43 "2018-08-20T06:53:10Z")
How about defining a scope which is not visible either from outside the package or from outside the module? ---
**Author:** ![HughG](https://avatars.discourse-cdn.com/v4/letter/h/35a633/32.png) [@HughG](https://discuss.kotlinlang.org/u/HughG)\ **Post date:** [September 20, 2018, 5:36pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/44 "2018-09-20T17:36:52Z")
The Dylan language allows you to expose multiple different “modules” (named lists of types, functions, etc.) from each “library” (compilation unit), so you could have things exposed for general use from one module, and things for testing from another. Modules would also import things from other modules. There are no doubt other languages which do similar things. It works well in terms of encapsulation options, but it forces you to explicitly list everything you want to export in a module file, separate from the definition of the thing, which is a pain to maintain. I could imagine Kotlin having a default module for exporting public things, and @ExportFrom annotations on other things to export them from one or more other modules. But how you would represent that cross-platform behind the scenes, I don’t know. ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [September 20, 2018, 7:18pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/45 "2018-09-20T19:18:35Z")
You have [jigsaw](http://openjdk.java.net/projects/jigsaw/) for that. Kotlin does not fully support it yet, but it will. ---
**Author:** ![HughG](https://avatars.discourse-cdn.com/v4/letter/h/35a633/32.png) [@HughG](https://discuss.kotlinlang.org/u/HughG)\ **Post date:** [September 21, 2018, 8:27am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/46 "2018-09-21T08:27:05Z")
I’d heard about jigsaw but not looked into it yet. It seems like a great thing but only operates at the class level. I don’t see an obvious way to export different fields or methods of a class via different modules, which some might want for testing. Perhaps one could make a class method package-scope, have it implement a package-scope interface from a sub-package, then export the sub-package from a separate module and/or export it only to test modules? Not sure that works, though. Of course, you can usually refactor to avoid having to call some otherwise private/protected methods for testing. ---
**Author:** ![ilogico](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/ilogico/32/3725_2.png) [@ilogico](https://discuss.kotlinlang.org/u/ilogico)\ **Post date:** [September 21, 2018, 2:07pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/47 "2018-09-21T14:07:23Z")
Actually, java modules work at the package level, not the class level. ---
**Author:** ![HughG](https://avatars.discourse-cdn.com/v4/letter/h/35a633/32.png) [@HughG](https://discuss.kotlinlang.org/u/HughG)\ **Post date:** [September 21, 2018, 5:17pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/48 "2018-09-21T17:17:26Z")
Sorry, I wasn’t clear. I meant that the finest possible level of granularity I could see as being possible would be the class level, if you had one class in a package. But I didn’t see a way to expose a class and only some of its methods from a package. ---
**Author:** ![pdvrieze](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/pdvrieze/32/1882_2.png) [@pdvrieze](https://discuss.kotlinlang.org/u/pdvrieze)\ **Post date:** [September 23, 2018, 12:32pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/49 "2018-09-23T12:32:44Z")
Custom scopes might be interesting. Like having an extension scope for plugins and a user scope for regular users. Perhaps they don’t need to be public either (internal, but explicit). One limitation would be the need to state the actual scope on the use side per file (or at build/gradle level) ---
**Author:** ![Synch](https://avatars.discourse-cdn.com/v4/letter/s/8dc957/32.png) [@Synch](https://discuss.kotlinlang.org/u/Synch)\ **Post date:** [November 15, 2018, 12:07pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/50 "2018-11-15T12:07:20Z")
So what’s the current stance on this from the Jetbrains team? ---
**Author:** ![laomengzhu](https://avatars.discourse-cdn.com/v4/letter/l/f07891/32.png) [@laomengzhu](https://discuss.kotlinlang.org/u/laomengzhu)\ **Post date:** [November 28, 2018, 9:26am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/51 "2018-11-28T09:26:34Z")
Companion object can access private constructor ---
**Author:** ![ghedeon](https://avatars.discourse-cdn.com/v4/letter/g/ea666f/32.png) [@ghedeon](https://discuss.kotlinlang.org/u/ghedeon)\ **Post date:** [January 4, 2019, 12:31pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/52 "2019-01-04T12:31:45Z")
Any roadmap or progress in this direction? I’d love to not have my project namespace polluted with dozens of classes that could be easily package isolated. ---
**Author:** ![ghedeon](https://avatars.discourse-cdn.com/v4/letter/g/ea666f/32.png) [@ghedeon](https://discuss.kotlinlang.org/u/ghedeon)\ **Post date:** [January 11, 2019, 1:34pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/53 "2019-01-11T13:34:17Z")
Feature request: [https://youtrack.jetbrains.net/issue/KT-29227](https://youtrack.jetbrains.net/issue/KT-29227) ---
**Author:** ![hqzxzwb](https://avatars.discourse-cdn.com/v4/letter/h/43a26b/32.png) [@hqzxzwb](https://discuss.kotlinlang.org/u/hqzxzwb)\ **Post date:** [March 13, 2019, 6:29am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/54 "2019-03-13T06:29:13Z")
`private` does not provide any real encapsulation. Any other module in the system can use reflection and get full access to its internals. Can this mean `private` can also be omitted? ---
**Author:** ![pdvrieze](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/pdvrieze/32/1882_2.png) [@pdvrieze](https://discuss.kotlinlang.org/u/pdvrieze)\ **Post date:** [March 18, 2019, 3:01pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/55 "2019-03-18T15:01:59Z")
No longer true for Java 9+ where it can be actually restricted. But you don’t write access specifiers to protect against people who want access at any cost, you do it to protect it against unintended access. Modifiers are not a security measure. ---
**Author:** ![fatjoe79](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fatjoe79/32/4221_2.png) [@fatjoe79](https://discuss.kotlinlang.org/u/fatjoe79)\ **Post date:** [March 18, 2019, 6:22pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/56 "2019-03-18T18:22:55Z")
> [@pdvrieze](#): > > you do it to protect it against unintended access. Modifiers are not a security measure That’s actually also his point. He argues that the same can be replied to @yole, hidden in a somewhat sarcastic tone. ---
**Author:** ![eugene](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/eugene/32/6454_2.png) [@eugene](https://discuss.kotlinlang.org/u/eugene)\ **Post date:** [June 15, 2019, 9:19am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/57 "2019-06-15T09:19:34Z")
I have just recently switched from Java to Kotlin for microsevice implementation. I like the language but the absence of _package private_ visibility is what discourages me the most so far. I’m surprised no one yet mentioned anything about two major practices for structuring your code: _package by layer_ vs _package by feature_. This article describes the subject really well: [http://www.javapractices.com/topic/TopicAction.do?Id=205](http://www.javapractices.com/topic/TopicAction.do?Id=205) So what you _Kotlin team_ did is made all the people who use _package by feature_ to structure the code **quite unhappy**. Basically i want my **package** to become my second most primitive **module** unit after the class itself. Package scope (visibility) is an essential unit for code modularization and you have thrown it away making package a mere unit for structuring physical files. The thing is, these _modifiers_ are _visibility_ modifiers. Not _access_ modifiers. They don’t provide _encapsulation_ - there’s no real encapsulation in OOP. They let you constraint the code visibility. And we are using that to **express** ourselves. Not to _protect_ our code from being accessed. Yes you can access my code and i’m ok with that because you can only do that in an unnatural way implying that you shouldn’t be doing that in the first place. - This is not about _encapsulation_ - this is about _modularization_ by means of _visibility_ constraints - This is about the design, about being able to _draw the line_ while structuring your program - This is the second most simple and one of the most important methods for _modularization_ in Java, enforced by the language designers by default - No _package_ scoping in the language forces us to make all of the _package private_ classes private staffed inside the single file which is just bad - No _package_ scoping in the language provokes the pollution of the classpath rendering code autocompletion useless - _internal_ visibility modifier is useless when you work on the same codebase and has no actual value in this context thus can’t be considered as _package private_ replacement - The larger the codebase the more of the problem absence of the package scoping really is I don’t need to protect my code. I want to express myself. I want to hide implementation details in my package to make my design and intentions clear to others and to myself when i revisit the codebase. With package scoping i can design the module around the package exposing only it’s public API and leverage DI framework to actually wire the “package modules”. If my package grows i separate it into the actual module or even microservice of it’s own. When i use DDD with “package by feature” i can naturally implement everything related to one aggregate root within single package and later make that a separate microservice without much effort. Please, _Kotlin team_, reconsider this and incorporate the _package_ visibility scope into the language. > [@crownclown67](#): > > Guys who developed JAVA language has great Idea to make package scope as a default scope (without keyword). Some devs has hard time to understand of true potential of Package scope I couldn’t agree more. _package private_ was very cleverly chosen to be the default scope. And Kotlin throws it away making everything wide-open by default. And _internal_ is the same “wide-open” in the context of a single code base. Most of the classes we write are an implementation details related to the package we are in so _public_ isn’t suitable as the default scope, is it? ---
**Author:** ![nickallendev](https://avatars.discourse-cdn.com/v4/letter/n/cdc98d/32.png) [@nickallendev](https://discuss.kotlinlang.org/u/nickallendev)\ **Post date:** [June 15, 2019, 6:21pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/58 "2019-06-15T18:21:14Z")
@eugene, What you describe is easily achieved by creating a nested “internal” package within each feature package. It allows _package by feature_ and expresses the intended access of the class within the app or library. One feature accessing another feature’s internal details is “unnatural” since it has to reach into the other feature’s internal package. Note: I use _package by feature_ in this way and I am quite happy. ---
**Author:** ![eugene](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/eugene/32/6454_2.png) [@eugene](https://discuss.kotlinlang.org/u/eugene)\ **Post date:** [June 15, 2019, 9:05pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/59 "2019-06-15T21:05:53Z")
@nickallendev, you invented your own convention with the dedicated nested package, correct? While i see how it helps to address part of the problem in question, i still can’t see it as a replacement for proper visibility scope control: granted a medium to large codebase one could easily use your internal classes without the second thought on a couple of successful autocompletion attempts. And validating the class packages against the convention on every autocompletion would be so inconvenient, one could consider that a waste of time. In the end, i don’t want to ask everyone to follow my convention and not use classes from the “internal” package, i want to have a way to enforce that by means of the language. Furthermore, i want to reduce the set of wide-openly visible types and the corresponding mental overhead. Constraints liberate. ---
**Author:** ![nickallendev](https://avatars.discourse-cdn.com/v4/letter/n/cdc98d/32.png) [@nickallendev](https://discuss.kotlinlang.org/u/nickallendev)\ **Post date:** [June 16, 2019, 4:17am UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/60 "2019-06-16T04:17:30Z")
@eugene > you invented your own convention with the dedicated nested package Not exactly, my team shamelessly stole this particular convention from other libraries: [https://github.com/ReactiveX/RxJava/tree/2.x/src/main/java/io/reactivex/internal](https://github.com/ReactiveX/RxJava/tree/2.x/src/main/java/io/reactivex/internal) [https://github.com/Kotlin/kotlinx.coroutines/tree/master/kotlinx-coroutines-core/common/src/internal](https://github.com/Kotlin/kotlinx.coroutines/tree/master/kotlinx-coroutines-core/common/src/internal) [https://github.com/square/moshi/tree/master/moshi/src/main/java/com/squareup/moshi/internal](https://github.com/square/moshi/tree/master/moshi/src/main/java/com/squareup/moshi/internal) > one could easily use your internal classes without the second thought on a couple of successful autocompletion attempts It’s quite easy for auto-complete to expose classes of an external library not even within the same project in Java. > i don’t want to ask everyone to follow my convention I don’t advise anybody to randomly start using their own conventions within a team and demand others to adhere. Do what works for your team. Using a package naming pattern is a simple way to express intentions. It can be especially helpful when using a tool (like an annotation processor) that requires public classes. It is not the only way to express such intentions and it is definitely not a replacement for modularization. If a project is too large then you also have to deal with other problems like long build times and commit histories that are cluttered. While _package private_ can de-clutter your autocomplete, it is not a solution that fully replaces modularizing your project. If you do modularize your project, then Kotlin’s internal visibility will work quite well. ---
**Author:** ![vbezhenar](https://avatars.discourse-cdn.com/v4/letter/v/35a633/32.png) [@vbezhenar](https://discuss.kotlinlang.org/u/vbezhenar)\ **Post date:** [June 17, 2019, 4:13pm UTC](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/61 "2019-06-17T16:13:19Z")
> [@nickallendev](#): > > It’s quite easy for auto-complete to expose classes of an external library not even within the same project in Java. Not if they properly used visibility modifiers. [Previous page](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544.md?page=2) [Next page](https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544.md?page=4)