Bug 226410 - no code name base warning in spellchecker
no code name base warning in spellchecker
Status: NEW
Product: platform
Classification: Unclassified
Component: Module System
7.4
PC Windows 7
: P3 (vote)
: TBD
Assigned To: Jaroslav Tulach
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-20 15:07 UTC by Jiri Skrivanek
Modified: 2013-03-26 12:11 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2013-02-20 15:07:43 UTC
Please, fix your code to dismiss the following warning:

WARNING [org.netbeans.core.startup.InstalledFileLocatorImpl]: no code name base
passed when looking up modules/dict/ispell-enwl-3.1.20.zip at org.netbeans.core.
startup.layers.NbinstURLMapper.decodeURL(NbinstURLMapper.java:121)
Comment 1 Jan Lahoda 2013-02-20 15:45:59 UTC
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).
Comment 2 Jaroslav Tulach 2013-03-21 08:53:26 UTC
How can it be unknown! Can you please show me description of the API the spellchecker uses to talk to "unknown" module?
Comment 3 Jan Lahoda 2013-03-21 09:12:53 UTC
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.
Comment 4 Jaroslav Tulach 2013-03-25 10:49:25 UTC
(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.
Comment 5 Jan Lahoda 2013-03-25 11:36:09 UTC
(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.
Comment 6 Jan Lahoda 2013-03-25 15:52:38 UTC
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.
Comment 7 Jaroslav Tulach 2013-03-26 10:59:27 UTC
(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.
Comment 8 Jan Lahoda 2013-03-26 12:11:19 UTC
(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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo