Bug 226410

InstalledFileLocator says:
     * @param codeNameBase name of the supplying module, e.g. <samp>org.netbeans.modules.foo</samp>;
     *                     may be <code>null</code> if unknown

The module is unknown to the calling code in this case. So a bug in the platform, from my point of view. I filled a bug for that long time ago, and it was turned down (bug #189298).

How can it be unknown! Can you please show me description of the API the spellchecker uses to talk to "unknown" module?

So it is OK for the module system to behave not according to its own API documentation?

There are already community provided modules defining spellchecker dictionaries. So the best I can do is to document that API.

Anyway, whether the API in the spellchecker is or is not documented does not really matter, IMO: the platform specifies something and behaved according to its own specification in (far) past. Now it does not behave according to its own specification. Is that OK? Is that incompatible change documented as such (please link)? I can do a new API in the spellchecker to workaround the incompatible change if necessary, documenting it as such a workaround, and documenting the module system's incompatible change unless it is already documented as such. Please reassign back to me if I should do this.

(In reply to comment #3)
> There are already community provided modules defining spellchecker
> dictionaries. So the best I can do is to document that API.

Can you please tell me what the API is (better in a documentation, not in a plain text inside a bugzilla)? Only after seeing it I can decide whether your usage of platform API is desirable or not. Thanks.

(In reply to comment #4)
> (In reply to comment #3)
> > There are already community provided modules defining spellchecker
> > dictionaries. So the best I can do is to document that API.
> 
> Can you please tell me what the API is (better in a documentation, not in a
> plain text inside a bugzilla)? Only after seeing it I can decide whether your

http://hg.netbeans.org/jet-main/rev/3dcffaab9a57

> usage of platform API is desirable or not. Thanks.

As the way the dictionaries are being looked-up is now officially documented, we cannot change it anymore. I was peeking at possible solutions in spellchecker, and found basically nothing. The only compatible solution in spellchecker is to disable the logger while spellchecker is doing the lookups.

(In reply to comment #6)
> As the way the dictionaries are being looked-up is now officially documented,
> we cannot change it anymore.

I have nothing against strong API commitment, but checking in an arch.xml and the next day claiming the API is stable (while it was not stable so far) seems a bit hectic. 

You probably want to start an API review to find an optimal way (from the point of usability as well as performance and QA) to define such API.

As far as I can tell, you are attempting to propose standardization of 

    1.99 +     <api category="stable" group="java.io.File" name="dict-lookup" type="export">
   1.100 +         A dictionary for a language can be provided by any module by:
   1.101 +         <ul>
   1.102 +             <li>specifying file <code>modules/dict/dictionary_&lt;language-code&gt;.txt</code> file in the module's cluster, in which case each line of this file will be considered to be one word of the dictionary</li>
   1.103 +             <li>specifying file <code>modules/dict/dictionary_&lt;language-code&gt;.description</code> file in the module's cluster, in which case each line of this file will be considered to be an URL pointing to a dictionary file as described above</li>
   1.104 +         </ul>
   1.105 +         In both cases, all files are expected to the in the UTF-8 encoding. &lt;language-code&gt; is the dictionary language's Locale code.
   1.106 +     </api>

In such case, I'd like to know:

Y01 Why these files are not located on system file system? In fact, having well known folder, would constitute even simpler API (as one can use relative URL as well as nbinst: protocol to define the content of file on system file system).

Y02 If Y01 is found acceptable/better alternative to currently used system, I propose to update Javadoc of InstalledFileLocator to discourage usage of null.

(In reply to comment #7)
> (In reply to comment #6)
> > As the way the dictionaries are being looked-up is now officially documented,
> > we cannot change it anymore.
> 
> I have nothing against strong API commitment, but checking in an arch.xml and
> the next day claiming the API is stable (while it was not stable so far) seems
> a bit hectic. 

Given the API is there for many years, if we want to change it, there should be a compelling reason. The fact that it is documented did not change anything in principle, but it means the reason for breaking it needs to be even more compelling. Is there such a reason?

> In such case, I'd like to know:
> 
> Y01 Why these files are not located on system file system? In fact, having well
> known folder, would constitute even simpler API (as one can use relative URL as
> well as nbinst: protocol to define the content of file on system file system).

a) in the case that I would consider to be most typical, e.g. place one file at the correct place, using the layer is less convenient: place a file somewhere and then create an XML file with delicate structure pointing to it.
b) performance: is system filesystem prepared to read multi-megabyte files (last time I tested Czech dictionary the file was about 6MB)? Is it prepared to read content of multi-hundred kilobytes zip without copying the content somewhere (related to bug #219474)? The importance of using ispell.zip is that we provide two (technically three) different dictionaries with only a little bit more consumed space than required for one (zipped), and, as importantly, that we use unmodified zip from upstream.
c) the current system allows future enhancement in bundling directly optimized representation of the dictionaries. That is currently mmaped, to conserve heap space. In case of system filesystem, this would be more problematic.