Please report any bugs or features discovered to JIndexer@exnet.com, and also check the ExNet JIndexer noticeboard.
Netscape Communications Corporation -- Java 1.1.2 Type '?' for options. # Verifier error ISearch.reallySearch(LInvertedIndexURL;[LWordText;II)[LISearchMatchItem;: Cannot find class InvertedIndexURL # Applet exception: class ISearch got a security violation: method verification error java.lang.VerifyError: ISearch at java.lang.ClassLoader.resolveClass(ClassLoader.java) at netscape.applet.AppletClassLoader.loadClass1(AppletClassLoader.java) * at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java) at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java) at netscape.applet.DerivedAppletFrame.run(DerivedAppletFrame.java) at java.lang.Thread.run(Thread.java)
There seems to be a problem with use of the GridBagLayout layout manager, causing inconsistent and poor layout of the applet. It is not yet clear if this is misuse of the class, a bug in the class, or some combination of the two. It may even have something to do with code generation by the JDK1.0.2 compiler.
In order to prevent Netscape 3 crashing (with a Bus Error on Solaris systems), some of the text, eg in the results area, has to be made smaller than is ideal. This will be fixed when possible, and the results area might be popped up a separate window to improve usability.
It would sometimes be very useful to give the ROOT input parameter to the applet as a relative path to facilitate use via more than one view of the document tree, eg via filesystem and HTTP access, with different implied absolute URLs for each. However, a relative URL for ROOT is ignored. Should probably be fixed to be relative to CODEBASE.
This is a known feature of the `Quick' indexing method, which keeps everything in memory for speed and simplicity. You are limited to something like the same about of input text as you have swap space (ie virtual memory) depending on the content of the text you are indexing. Future versions of JIndexer will tackle this with an additional disc-based indexing method that will be a little slower but of arbitrary capacity (and that need not re-index unchanged input files).