What are the policies for internal modules?

[Alan Bateman]

On 21/11/2022 01:02, Ethan McCue wrote:
> There are some modules like jdk.internal.le which contain no 
> publicly exported packages. In some of the experimentation we are 
> doing, We want to use the 
> jdk.internal.org.jline.utils.Levenshtien class from jdk.compiler.
>
> Mechanically, we can do this without creating any new modules by 
> adding a qualified export of the utils package to jdk.compiler. We 
> could also make a brand new, tiny pointless module called 
> jdk.internal.levenshtien. That would be the "cleanest" approach, but 
> only if we didn't consider the existence of the internal modules to be 
> public API.
>
> So that's my general question - what is the bar for making a new 
> internal module, and is the set of internal modules subject to 
> backwards compatibility concerns?

There aren't many compatibility constraints on jdk.internal modules. 
Assume they can change or be removed in any release. It's important they 
don't export any packages to all modules, otherwise they cease to be 
"internal".  Also if they provide services then the name of the module 
may be something that users of jlink may become dependent on, so we have 
to be careful there.

A general point is that we don't want the JDK to backslide to a big ball 
of mud. We put a lot of effort several years ago to de-tangle the 
libraries so it would be disappointing see jdk.compiler, with no 
interest in line editing, add a dependency on jdk.internal.le so that it 
can make use of one of utility classes. So I don't think we should do that.

Can you say a bit more about what you are doing? Is this just a method 
to compute the Levenshtein distance between two strings? I assume you 
can just implement that in jdk.compiler without touching the module 
graph. It might be useful to get some sense on how common fuzzy matching 
is in the eco system to see if there is any merit to exposing APIs for this.

-Alan