This search engine applet works fine in Netscape Navigator 4.5 and Hotjava 3.0 browsers. Microsoft Internet Explorer 5.0 also runs it, but with an annoying side-effect.
IE5 seems to destroy the applet every time you leave its host HTML page. This means that when you search on a keyword and then view one of the listed documents, then when you return, the results of your search have disappeared. You have to enter the keyword again. The other two browsers preserve the applet and its class instances so that when you return to the applet's host HTML document, your search results are as you left them - which is much more convenient.
If you have Navigator's Java Console running when you go to the search applet's page, you will notice that it issues a warning message saying that Navigator may lock up because the applet called Thread.suspend(). The applet uses a separate thread for Indernet downloading operations. It creates and then suspends this thread during initialisation. It then resumes the thread upon starting proper. It suspends the thread whenver the browser leaves the applet's host page and resumes it again upon return. It stops and discards the thread before the applet can be destroyed. This is a perfectly valid way of handling threads, so I don't see why Navigator should lock up. Nevertheless it does on occasions when the applet is first started. It shouldn't. The only remedy I have found is to re-boot Navigator. The other browsers don't suffer from this drawback.
I originally wrote this search engine according to the client-server model. It had a server-side index searcher called index.class. This contained search and retrieval methods which were invoked by the enquiring client-side applet via RMI [Remote Method Invocation]. It searched for keywords and retrieved the relevant URLs from a highly-tuned dataset comprising 6 data files. The applet simply handled the user input and the presentation of the results.
But there was a big problem with this. It required Java executables running server-side. This is all very well for corporates. However, there is no way a lowly unemployed programmer like me would be allowed to run an executable on his ISP's mighty server. Certainly not on any web site service tariff that can be afforded by anybody existing on this miserly pittance called 'benefit'. I therefore had no choice but to take the whole thing client-side, leaving nothing but passive files sitting on the server. When technology provides a way, politics and the commercial prerogative seem to take it away again.
Unfortunately, as far as I can see, Java makes no provision for the random access of files across the Internet. In other words, there is no class: RandomAccessConnection. So you cannot write things like:
RandomAccessConnection rac = url.openRandomAccessConnection();
Nor should such provision be made. With RMI there is no point. And it is most unlikely that the political and commercial restrictions imposed upon the likes of me would even occur to the inhabitants of Sun Microsystems.
So take the whole thing client-side I did. Index and all. This restricted the size of the index. Nevertheless, it is possible to contain the index of a fair sized web site client-side without any trouble. I'm not going to explain how the applet works at the moment, but here's the source code. Work it out for yourself and be happy.