(always so hard to remember to reply all) On Thu, Nov 24, 2022 at 8:26 PM Ethan McCue <et...@mccue.dev> wrote:
> The use here is giving help to the user on > misspelled classes/methods/fields like "new ArayList". > > For now we've just copy pasted the class since that seems the least > architecturally painful. (And it's not clear that text distance is the full > story with regards to this sort of analysis, so tbd if that stays in its > current form) > > On Mon, Nov 21, 2022 at 3:19 AM Alan Bateman <alan.bate...@oracle.com> > wrote: > >> 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 >> >>
