Non-exported vs restricted packages

[Volker Berlin]

Am 04.12.2015 um 10:10 schrieb Remi Forax:
> Hi All,
> I think there is an issue with the current design of jigsaw that we should tackle.
>
> The problem have been raised several times of the jigsaw-dev mailing list by different people and I think it's a valid point, currently the way encapsulation is specified doesn't match with the way people use/want to use modules in an application server. Don't get me wrong, I don't not want to have stronger encapsulation that we currently have, i just think we should recognize that the way people currently use modules is a valid use case.
>
> So the problem is that most application servers use reflection to create instances of implementation of an interface and people want the implementation on that interface to be in a non-exported package. With Jigsaw only option if you want this configuration is to use a ServiceLoader to load the implementation.
This make no sense for me. When external code should create an instance 
of it then it must be exported. There is no requirement that an 
application server use reflection to instantiate the classes. There can 
be used byte code generation or dynamic languages. This should also work.

In our private module system we use an annotation @PublicApi on class 
and all other classes are obfuscated. There is no external access.
> So I propose that the spec should specify three kind of packages "availability",
> exported packages that make classes available by module that require the module containing the packages, non-exported packages that make classes non available but that can be used by reflection using setAccessible as an escape hatch and restricted packages that make the classes non-available even by using setAccessible.
The option of no reflection support is not practicable because 
deserialize must be possible. In the other case many framework for 
serializing will not work anymore.
Also an debugger must have access to the classes to inspect its state.

Volker