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
