JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Alan Bateman]

On 12/10/2017 05:01, cowwoc wrote:
> Hi Jan,
>
> I've got a specific use-case I'd like your feedback on:
>
> * My library exports an enum.
> * Users must be able to pass enum values into exported API methods.
> * The enum contains a method to ensure that each possible value defines a
> different implementation.
> * The method is only meant to be invoked by non-exported implementation
> classes; however, seeing as those classes reside in other packages the
> method is public.
>
> So I'm left with a public method that I don't want users to be able to
> invoke. Ideally I don't want them to see the method either, but I don't
> think there is much I can do about that.
>
> Does this represent a legitimate case for public, non-exported methods? Or
> is there a better design that would meet the requirements?
Your library is a module that exports a package with a public enum. The 
enum defines a method that is not intended to be directly used outside 
of the module and so needs to be non-public.

One approach is to put a helper class in a non-exported package that 
calls the non-public method on the enum reflectively (code in a module 
can do deep reflection on any member of any class in its own module). 
Using reflection, even on oneself, is brittle of course.

A type safe approach would be to define a helper interface in a 
non-exported package and have the enum register an implementation. 
Static methods on the interface, or a separate helper, would provide 
consumers in the module a way to obtain the implementation. We uses this 
approach in the java.base module where it known as the "shared secrets 
mechanism".

As regards "seeing the method" then there is nothing to prevent nosy 
parkers from reflecting on the enum class and discovering all its 
declared methods, including non-public methods. They can't invoke the 
methods but they will know they exist.

-Alan