Hulles

Recently I decided I had better bite the bullet and share with you some of the results of my experimentation with the Lookup functionality in NetBeans. I have always found the Lookup documentation confusing, and since the Lookup implementation itself seems to have evolved over the years it is difficult to separate out the currently-preferred Lookup syntax and usage from that of previous incarnations. So here are a couple tips that I discovered that might help you if you're in the same boat.

First, just a bit about what Lookup is and what it does: Lookup is designed to decouple providers and consumers of functionality within a NetBeans application. To borrow (I believe) Tim Boudreau's example, if you have a module SpellCheck that needs to look up words in a set of dictionaries and determine if a given word is spelled correctly, you can use the Lookup function to determine at run time what dictionary modules are available to use. SpellCheck does not need to know at compile time what providers will be available; it just defines an interface that can be implemented by anybody who cares to and at run time looks around to see who showed up.

If you've done a lot of development, you understand the beauty of this: I develop a module SpellCheck, I provide a dictionary specification in the form of a public interface, and you can write a module BritishEnglishDict that implements the interface. I then go on to create a module suite called FancyEditor that includes my spiffy little SpellCheck module and your module in it as well if I think Brits might be using it and if they sent me a cheque. When FancyEditor is run, within SpellCheck there is a Lookup statement that grabs all available implementing modules of the dictionary interface, including yours, and gives them to SpellCheck to use in looking up the spelling of a given word. Neither you nor I need to know anything about the other's module other than the contract provided by the interface. Both compile independently in NetBeans just fine without the presence of the other, thanks to Lookup.

So how do you implement Lookup? That's a harder question because there are a lot of ways to do it. I found at least three in my research: cookies, META-INF/Services, and layer file. Of the three, you should use the layer file approach unless you need a) backwards compatibility with previous NetBeans versions (cookies) or b) compatibility with JDK ServiceProvider syntax (META-INF/Services). Assuming that neither of these conditions is the case, use the layer file as it seems to be the preferred way to do things these days in NetBeans country. (And if I'm wrong, please tell me, it's difficult to stay current if you're a rugged lone-wolf renegade like me.)

By the way, you might notice that I'm trying to speak of "providers" and "consumers" without talking about services here. That's because it's easy to confuse JDK ServiceProvider services, NetBeans Lookup "services", and the myriad of other services available out there. So forget about the word "services" and let us never mention it again. Tough to find a good synonym though, but we'll get through this.

In this article (which is already a lot longer than I intended!) I will only discuss the layer file approach. The layer file is the means by which you tell NetBeans Lookup that your module BritishEnglishDict can provide dictionary functionality as specified in my interface. All you need to do is this:

1. Create a public interface in the consumer module (SpellCheck in my example) that defines what is needed.
2. Add a lookup statement to the consumer to call for modules that implement the interface.
3. Create a provider module (BritishEnglishDict) that implements the interface.
4. Create a layer file in the provider that announces to NetBeans (and Lookup) that our provider module implements the interface.

If all goes well, your brand new module suite will function perfectly and you can write ten more dictionary provider modules for various dialects of English without changing a thing in the consumer module.

How To Make All Go Well

To illustrate with some concrete code, first let's specify the interface in a hypothetical SpellCheck module that will be checking the spelling of some imaginary documents :

package org.hulles.spellcheck;

public interface SpellDictionary {

    public boolean isCorrect(String word);

}

Not much to it, for our example purposes. We just want to query a set of dictionaries and find if our word is spelled correctly. Next, let's add our Lookup to a class in SpellCheck:

...
public List<SpellDictionary> getDictionaries() {
    Collection<? extends SpellDictionary> dicts;

    StatusDisplayer.getDefault().setStatusText("Loading dictionaries....");
    dicts = Lookup.getDefault().lookupAll(SpellDictionary.class);
    return new ArrayList<SpellDictionary>(dicts);
}
...

In my example we're using the "lookupAll" method to get all implementations of our interface but there are variations that you can use as well to get, for example, either zero or one implementation. And also notice there is no "Lookup.Result" in there either. We'll stick with "lookupAll" to keep it simple. You might also note the status message; while not strictly relevant to what we're discussing it's such a damn good use of the NetBeans platform that I left it in anyway.

Now we're done with the consumer module. Let's move to the provider module, BritishEnglishDict. It's pretty simple as well -- it contains one class that implements the SpellDictionary interface, called "MyOED":

package org.hulles.dictionaryprovider;

import org.hulles.spellcheck.SpellDictionary;

public class MyOED implements SpellDictionary {

    public boolean isCorrect(String word) {
        return ("cheque".equals(word));
    }

}

Great! Now we have a provider that, in spite of its Oxonian title, just fulfills its contract with the interface by returning true if the word passed to it is 'cheque'. That's good enough for our purposes. The only step remaining is to announce our new spelling dictionary to the world by adapting the layer file for the "org.hulles.dictionaryprovider" package.

The layer file that I'm talking about is a file generally called "layer.xml" in NetBeans and is an XML file that informs the NetBeans platform of, well, stuff pertaining to its owning module. See other documentation wherever you can find it for more information on this; further discussion here is beyond our scope. The layer.xml file can be created automatically when you create the module in NetBeans, and if you think you're going to use one you should check the appropriate box at creation time to let NetBeans do this for you. If you didn't you can create your own, but be sure to add it to the module's manifest by adding a line to the manifest similar to:

OpenIDE-Module-Layer: org/hulles/dictionaryprovider/layer.xml

If you don't do this, NetBeans won't find your layer file and none of these great Lookup gizmos will work correctly. If you generate it when you create the module, this is added to the manifest automatically.

To add the necessary declaration for Lookup to find your provider, in the layer.xml file you should add lines similar to the following to whatever may already be in there:

<folder name="Services">
<folder name="Hidden">
<file name="org-hulles-dictionaryprovider-MyOED.instance">
<attr name="instanceClass"
    stringvalue="org.hulles.dictionaryprovider.MyOED"/>
<attr name="instanceOf"
    stringvalue="org.hulles.spellcheck.SpellDictionary"/>
<attr name="position" intvalue="400"/>
</file>
</folder>
</folder>

I didn't format the XML very nicely here because I don't want the lines to run too long (!), but you can automatically format the XML in your own file by right-clicking in the editor and selecting "Format". Formatting aside, you can see that we're just informing the NetBeans platform that our class MyOED exists as an implementation of SpellDictionary. This is all Lookup needs to find it within our module suite. Simple, no? By using a layer file, you don't need to use cookies nor do you need to use a "META-INF/Services" folder. It works just fine as it is.

I should also mention that you can include more than one provider class in your module. If you should write another class called, say, "MyWebsters" in the same module, you just need to add another definition to the "Services/Hidden" structure in your layer file. This was not crystal clear to me from the documentation until I tried it, but it works just fine. Your new layer file would then contain:

<folder name="Services">
<folder name="Hidden">
<file name="org-hulles-dictionaryprovider-MyOED.instance">
<attr name="instanceClass"
    stringvalue="org.hulles.dictionaryprovider.MyOED"/>
<attr name="instanceOf"
    stringvalue="org.hulles.spellcheck.SpellDictionary"/>
<attr name="position" intvalue="400"/>
</file>
<file name="org-hulles-dictionaryprovider-MyWebsters.instance">
<attr name="instanceClass"
    stringvalue="org.hulles.dictionaryprovider.MyWebsters"/>
<attr name="instanceOf"
    stringvalue="org.hulles.spellcheck.SpellDictionary"/>
<attr name="position" intvalue="300"/>
</file>
</folder>
</folder>

Of course you could also put your "MyWebsters" class into a different module, and probably should if your module is called "BritishEnglishDict" to avoid confusion. If you were to do this, I might then include both of your modules in my suite to check my word against both of your dictionaries. In this case, the position attribute in the layer.xml file comes into play. Lookup will return its results in the order specified by the position attribute in the layer file if it is present. Thus, my spell checker would first check to see if its word was in "MyWebsters", then it would check "MyOED" (via the List implementation in the example). There. We're done!

Too Bad It Doesn't Work

If you followed the above steps exactly, your Lookup should work just fine. But if it doesn't, it's harder than hell to debug it because the compiler doesn't know about the relationship between the provider and the consumer! Of course this is the trade-off for the decoupling we sought, but it can certainly make our life difficult until we get it right. And that's the real reason I'm writing this.

I actually modified a spell checker recently (Jazzy) to work with an application, and I could not get my Lookup to find my providers no matter what I tried. This is how I learned the things I did about Lookup that I've been discussing in this article, but it's all to no avail if the sucker don't work! Finally, after much agony and shouting of "Ogg Vorbis!" and "Bogofilter!", I realized that my provider modules were declared as type "Autoload" in the "API Versioning" section of the module properties. This meant that the modules weren't being loaded because there was no direct invocation of the provider modules anywhere, and modules of type "Autoload" are only loaded when they are invoked. I did away with direct references to the code in the providers when I used Lookup, so when the consumer called for providers it was whistling in the dark -- none were loaded. (The layer file for a module is only added to the application's layers when the module is loaded.) I switched the modules' types to "Regular", cleaned and rebuilt the modules, and it worked wonderfully at last. But to find this I really had to understand how it all worked, so I thought I would once again try to pass the hard-won knowledge along to you. Hope it helps someone!

If you're using or have tried to use the Twitter SaaS service in NetBeans 6.5, you may have encountered a bug in NetBeans that gives you an error that looks something like this:

javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"nilclasses").
            Expected elements are <{}authenticated>,<{}authorized>,<
            {}direct-messages>,<{}direct_message>,<{}friends>,<
            {}hash>,<{}nil-classes>,<{}ok>,
            <{}status>,<{}statuses>,<{}user>
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext...
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportError(Lo...
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportError(Lo...
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportUnexpe...
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContex...
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContex...
...

I reported the bug via the official NetBeans channel but it's my first occasion to do that. Hopefully I did it correctly and will not be harshly reprimanded by the NetBeans Ministry of Love and put on a diet of blutwurst, refried beans and watery beer. Although come to think of it I'm on that diet anyway; I must have done something else bad recently to warrant it.

The error results from a small bug in the updated Twitter SaaS service code in NetBeans 6.5. It occurs when you (for example) try to get direct messages and there are no new ones. Under these circumstances Twitter now replies with a 200 (everything went swell) code but returns NilClasses, whereas it used to give a 310 error code. I can only imagine that someone somewhere is trying to migrate away from returning error codes when things happen normally so that consumer code doesn't throw exceptions.

Speaking of which, if you mask out the exception handling in the caller function you won't see the above message, you'll just get anomalous results in your direct messages (e.g.). This drove me crazy for a couple of days until I tracked down the result. "Bogofilter!" I muttered. "Ogg Vorbis!" (I swear when I'm frustrated.) Hence this short article to pass along the hard-won information.

I am also including a modified TwitterResponse.jar that you can plug into your code as a workaround until the bug is fixed by the NetBeans folks. Please note that you use it at your own risk. It was a simple change and I've used it without a hitch many many times since I created it, but it hasn't gone through the (presumably) rigorous QA process that happens at NetBeans HQ, wherever the hell that is. So my recommendation is that you should only download and install the jar if you work in a production environment and need the fix to stay productive; otherwise I strongly urge you to wait for the official fix. Also, if you don't already know what to do with the attached jar file you should probably wait as well. This patch is just to keep the fires burning for American industry until the real fix. You non-Americans can use the patch as well of course but you should delay installing it for a bit so that we in the United States can get a much-needed head start toward regaining our technical edge.

I hope this helps any others out there (American or not) who are currently muttering "Bogofilter!" to themselves. Let me know how it goes. Namaste.

In my last two articles (NetBeans Tip: Prism Break and More About Prism And NetBeans) I discussed using the Mozilla Labs Prism application to create dedicated "mini-browser" windows to reduce the overhead involved in (e.g.) looking up JavaDocs within the NetBeans IDE. My primary stated reason for using Prism from within NetBeans was to improve the performance of Lucille II, my aging laptop, bless her little 1.6GHz CPU.

However, one mustn't lose sight of one's overall goals as one mucks about in the fascinating but stinky cesspool of software development, and if results matter the number one rule for improving the performance of any piece of software should be: throw hardware at it. This is because since the 70's hardware costs have trended dramatically downward and software (i.e. people) costs have done the reverse until recently. It is nearly always a better idea economically to upgrade hardware before even thinking about software solutions, let alone discussing such solutions, let alone actually implementing them.

To reinforce this point, I'd like to point out that a certain unnamed consumer electronics retail chain is currently offering what seems to be a Best Buy for laptop owners like myself: 1GB memory modules for US$19.99. To max out Lucille's memory at 2GB (currently she packs 512MB under her skirt) costs under US$40! That is substantially less than it cost me to write this blog entry in terms of person costs, assuming that I had something better to do.

The moral of the story is that if you're a guerrilla software developer or otherwise work in the real world you should keep the big picture in mind and Do The Right Thing, no matter how attractive it might otherwise be to f*** around with the latest and greatest SSB or any of my other blog posts for that matter (except this one). If on the other hand you work for Sun you probably couldn't care less. I understand they actually pay you guys to write blogs! (Hire me and I'll quit giving you shit and go back to making fun of Microsoft Windows operating systems.)

Namaste and Happy New Year!

P.S. Of course the purpose for my writing these articles is to entertain and elucidate, as opposed to trying to stroke and bore your Sony VAIO so that it kicks the ass of all the other laptops in your coffee shop. But still... US$40! I'm off to buy memory, which at my age is an unexpected luxury.

As I mentioned in my last post, NetBeans Tip: Prism Break, the Prism application from Mozilla Labs has changed my (NetBeans) life. I can now use Lucille II, my laptop, to actually do NetBeans development work in a productive and efficient manner. I have been using the Prism SSB a lot from within the IDE for a couple of weeks now and I love it, particularly since finding out how to navigate back and forth between pages [see "special bonus tip" at the bottom of the Prism Break article]. So, since I'm still pretty excited about how well it works for me, I thought I'd discuss it a little bit more in this follow-up post.

Prism As A Self-Contained Browser

In the closing paragraph of the last post I said, "One thing I didn't mention earlier is that I think Prism will work as well with Internet Explorer as it does with Firefox." What I should have said was that "Prism will work as well on a machine that uses Internet Explorer as its default (or only) browser as well as one that uses Firefox." Prism seems to be a self-contained browser and does not appear to rely on the presence or absence of Firefox. I have been reluctant to de-install Firefox on any of my boxes to test this out but the more I have worked with it and researched it the more this seems to be the case. So I hope that clarifies what I stated in the previous article. And as I said there, please let me know of your experiences in this regard.

Prism On Windows

Since I published the Prism Break entry I decided to install Prism on Aspen, a custom-built desktop PC that I have in my home office to provide extra heat in the winter. Aspen is a little less underpowered than Lucille II; as opposed to her it has Delrin® gears and discrete transistors and doesn't require a bevy, underdressed or otherwise. It boots both Windows 2000 and Ubuntu, so I fired up W2K and downloaded and installed Prism on it. It installed flawlessly. (You can't imagine how elated I am every time I get to say that.) When I started Prism up in W2K it gave me a slightly different dialog than the Ubuntu Linux one, viz:

One gets a few more options than in Linux, but it is fundamentally the same. I created a miniapp to open up Mozilla Labs and it worked just fine.

Is that great or what? Now I use Prism on Aspen all the time as well as on good old Lucille II. Incidentally, I don't seem to get nav buttons in W2K either but I'm happy to say that the special bonus tip from last time works as well there as it does in Linux.

Other Software Development Uses For Prism

I've found that, in addition to the intra-IDE JavaDoc usage I mentioned in the previous post, Prism is quite useful in other ways as I carefully craft clean custom code (and concatenate consonants) on my computer. For example with Sancho, my Big NetBeans Platform Rich Client Application (BNPRCA), I need to be able to document changes that I make on a web site to be able to better communicate with my non-paying clients. To do this now I just leave a Prism window open to the web site and switch over to it whenever I need to. Because of Prism's dainty footprint I can afford to do this resource-wise, where once I couldn't and instead had to keep copious illegible paper notes laying around in my workspace for my cat to play in.

Still other uses I've found for Prism vis-à-vis software development include: keeping the old social networking applications open while I work (as I mentioned last time), having an on-line dictionary readily available to look up "vis-à-vis", tuning in to Last.fm (can't code without tunes!), and leaving a feed window open to catch the latest scoops in Planet NetBeans. And at this point I will somewhat shamefacedly admit that every time Hulles pops up in Planet NetBeans I whoop with delight and scare the shit out of my cat who then knocks more papers off my desk in retaliation. No one said the life of a renegade NetBeans Java programmer was going to be easy, I suppose. If they had I would have gotten it in writing then sued the pants off 'em.

The Prism Firefox Add-In

I didn't mention it before but there also exists a plug-in for Firefox called (I believe) Refractor that can generate a Prism desktop miniapp for whatever web page you happen to be on at the time. I used this for a short while but I found that, as seldom as I used it, it didn't add much value compared to simply starting Prism from the desktop and filling in the dialog fields. Ironically, adding the Prism plug-in into Firefox makes Firefox just that much more bloated, which is why I started using Prism in the first place! So I 86'ed the plug-in out of Firefox. You may like it however so give it a try if you want. It can be found in the normal Firefox add-in arena under Prism.

Heh Heh. The Cat's Asleep On The Scanner.

So that's it for this Prism follow-up. I'm going to post it now and wait for it to show up in Planet NetBeans. Namaste and Happy New Year!

Let's Gain Ourselves An Extra Hour or Two of Productivity Per Day!

Hoo boy and way doggies, are you going to thank me for this one, especially if you are like me and do most of your work on an underpowered laptop. I'm not necessarily saying my laptop's old, but it has big clanky iron gears and uses vacuum tubes and requires a bevy of underdressed 20-something brunettes to continually fan it with ostrich feathers to keep it cool. While there are some advantages to the last requirement, it is a non-trivial exercise for me to actually go anywhere with my laptop because I have to wait forever while the bevy primps and gets ready to go out. Underdressing is an art, not a science, they tell me.

So what does that have to do with this NetBeans tip? Well, because my laptop is creaky and slow I find myself constantly avoiding looking up JavaDocs from within the NetBeans IDE Java Editor no matter how much I might need the information. This is because it takes as long for my laptop to start up Firefox and display the JavaDocs as it does for the aforementioned bevy to get ready to go out. Mind you, I would never call NetBeans fat, but it is certainly big-boned, and Firefox is no anorexic supermodel either. Between them they suck resources like -- well, never mind, just take my word for it that they suck a lot of resources.

Enter Prism. Alarums And Excursions.

Because of all this you can imagine my elation when I accidentally stumbled across a simple, lightweight, dedicated browser application called Prism the other day. Prism is a XULRunner-based project of Mozilla Labs, the people who bring you the Firefox browser among other things, and the goal of the project is to provide an application for your desktop that starts a small no-frills browser for a single purpose -- like displaying JavaDocs, just to pick an example at random. This concept is called a "Site Specific Browser" (SSB). Perfect! I downloaded some Prism-started apps like Google Reader, Google Mail (GMail), Facebook and Twitter(!) to try out and they all have their own desktop menu shortcuts and they all bring up a lightweight dedicated browser window with just their own specific application web site in it. See this Twitter screenshot for an example:

Notice the lack of nearly all normal browser accoutrements like menus, tabs, etc. Excellent! For our purposes all we typically need to do is look at a damn JavaDoc, not shop for ostrich feathers on eBay (at least while we're working). Note also the picture of the distinguished-looking rogue in the corner. Looks hungry and thirsty, doesn't he? See "Donate" button. His children run naked and his cat needs scotch.

So here's what we're going to do: we're going to create ourselves a little mini-application to display JavaDocs (and any other web application started from NetBeans) in a Prism window instead of in our bloated browser. The steps that we will perform are these:

1. Obtain the Prism application and install it on our computer.
2. Create a dummy Prism instance that we can use for displaying JavaDocs.
3. Add our new NetBeans Prism instance to the list of browsers in the NetBeans IDE.
4. Test the new NetBeans Prism browser by looking up JavaDocs in the IDE.
5. Sit back and feel smug.

Acquiring And Installing Prism

The Prism application is free and available for download from Mozilla Labs at this URL: http://labs.mozilla.com/projects/prism/. It is available for Windows, Mac OS X, and Linux. I personally use Ubuntu 8.10 Linux and I installed Prism from the Ubuntu Debian repository without any problems via the Applications menu "Add/Remove..." command, but your experience may vary. If you have trouble installing Prism look around on the Mozilla Labs site or in the Mozilla Wiki for help. As a last resort you can ask me, but I'm not sure how much help I can offer in this.

At the same time you download and install Prism itself you may want to download other Prism-driven apps like the ones I mentioned earlier just to try them out. I particularly find the Twitter and FaceBook Prism applications useful so I can maintain contact with my vast extended social network (both people) while slaving away inside the big-boned NetBeans IDE.

Incidentally, you can also try out your new Prism gizmo to create your very own Prism launcher, simply by starting Prism. It will give you a window that looks like this:

You can then fill in the URL and name of whatever web site you choose and Prism will place an icon on your desktop that opens the site in an SSB window like this:

Pretty nifty, isn't it? I can think of about a gazillion uses for this, but right now let's get back to our project at hand.

Creating A NetBeans Prism Launcher

This step is easy, and it's the same process as the one described in the previous section for creating your own Prism Launcher. First you need to start Prism:

In the spare and terse Prism window that comes up you need to enter a URL and a name for the NetBeans JavaDoc launcher:

I used a real JavaDoc local file URI in my example but you can actually use any URL; we're going to override it in the launcher later on. And by the way, while I called my launcher "NetBeans JavaDoc", it should more precisely be called "NetBeans Prism" or something of that nature because NetBeans will use it to open all web sites from within the IDE, not just JavaDocs.

Once you hit the "OK" button in the dialog, it will create a shortcut on your desktop to open the URL you specified inside a cute little Prism window. Next we're going to get the shortcut off the desktop and into an application start menu so we don't clutter up our desktop. This step is optional of course but I recommend it. In most operating systems you can accomplish this by dragging the icon from the desktop into your "Start Menu" or equivalent:

If you don't or can't do this last step however, don't worry about it. Everything should be fine if you just leave it on your desktop. You can even try deleting it altogether and seeing if the following steps work without any shortcut at all (in spite of what the Prism dialog says) but I haven't done this myself. I suspect it will work just fine anyway because I've seen artifacts of deleted launchers lurking around in the Prism internal directory. Let me know if you try this and it works (or doesn't work, for that matter).

Once you're done, start the launcher from wherever you put it and you should get your chosen web site, a JavaDoc in my case, displayed in a Prism window like this:

Adding The Prism Launcher To The IDE

Now we're going to do the most difficult part: adding a browser definition to the NetBeans IDE. It really isn't all that difficult, especially for you since I'm going to tell you how to do it. Of course I had to hunt for a Prism command line syntax reference document that apparently doesn't exist so I once again had to dig into the source code to find it, but hey, that's why I have this blog, so I can share the hard-won information. [Pats self on back, clears throat deprecatingly.]

To add our new browser definition to the IDE, you should first open the properties window of the shortcut that you created in the previous step:

This will give you the correct Prism command line for your operating system. Copy the command line to the clipboard and paste it into a new text document. It should look something like this (all on one line), though it will vary with different operating systems and versions:

Now start the NetBeans IDE, go into "Tools / Options" from the main menu, and click on the "General" icon.

Click the "Edit..." button next to the "Web Browser" combo box. In the next window, click the "Add..." button.

You should now be at a screen that looks similar to this:

Replace the default name with the same name that you used when you created your shortcut. From the text document containing your system's command line, copy the program portion of the command line into the "Process" field (xulrunner-1.9 in my case) and paste the rest of the command line into the "Arguments" field. In the "Arguments" field, add the following text to the end of the line:

This tells Prism to override the URL in its application definition with the one that NetBeans provides via the "{URL}" template, as it helpfully mentions in the forms "Arguments Hint" box.

Hit "OK" to save your new browser definition. Make sure that the new definition is selected in the "Web Browser" combo box. Close the Options window. You should be all set!

Testing The New Browserito (Browserita?)

To test your new Prism launcher, open any Java file in the editor, right-click on a class or method name, and choose "Show JavaDoc". If the element has an associated JavaDoc, it should open in a Prism window like this:

"Viola!", as we used to say in Iowa. You now have a lightweight JavaDoc browser at your beck and call within the IDE, ready to spring forth with speedy goodness to show you the errors of your coding ways. No more waiting for chubby old FireFox (or obese old Internet Explorer) to huff and puff into the foreground.

But Now We Have A New Problem

If your working machine is anything like my laptop Lucille II, this tip should cut out at least an hour a day of nonproductive time when all is said and done, maybe more. See "Donate" button. Show "Donate" button to boss and explain new productivity gains. (Seriously.) But as foreshadowed by the title to this section, this leaves us with a whole new problem: our bevy of ostrich feather wavers now have an extra hour or two of free time and nothing to do. How to occupy them? This I leave to you.

SPECIAL BONUS TIP!

One Prism anomaly that I ran across in my experimentation, at least on my Linux system, is that even if you check the "navigation buttons" box on the Prism application creation dialog box you don't get navigation buttons (i.e. back arrow and forward arrow) in your resulting Prism browser window. After trying everything I could think of I finally discovered that you can navigate backwards and forwards through visited web pages by holding down the "Alt" key and using the mouse scroll button. This works regardless of whether you checked the "navigation buttons" box at app creation time. And it's FAST! Try it. And that solves the one problem I was having with the Prism SSB, so now I'm happy and I hope you are too.

In Conclusion

I hope you found this article useful and possibly even entertaining. I also hope it helps your productivity as much as it helped mine. One thing I didn't mention earlier is that I think Prism will work as well with Internet Explorer as it does with FireFox. I think this because of the Mozilla documentation, but I haven't tested it. Let me and others know of your experiences by commenting here. Good luck and good coding. Namaste.