(always so hard to remember to reply all)
On Thu, Nov 24, 2022 at 8:26 PM Ethan McCue 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
> 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
>>
>>
