Well, mostly anyway.

The wonderful world of Java applets is a funny old world. One of pitfalls and woe on one side and unparalleled power on the other.

Java has been around for a while and has a very substantial support base, which comes in handy when trying to get around some of the more annoying problems associated with Java development, well Applet development anyway. It runs on pretty much anything, part of it’s charm is that you don’t need to run on a Microsoft platform unlike .net

One of the best things is that as a language, it’s free and there are many free IDEs out there to help you to develop. One of the best I’ve seen so far is NetBeans v6.5 – An IDE originally written by Sun Micro systems, made open source whilst being heavily sponsored by Sun. It’s completely free, Cross platform and downloadable from the their site www.netbeans.org
Without wanting to spend too much time singing the praises of NetBeans, I have to mention that it’s PHP editing tools are pretty fine too and when coupled with the correct version of xdebug for your PHP runtime, make for a very powerful PHP development platform indeed.

We found a couple of minor issues which were noteworthy when developing Java Applets.

One of them being that the HTML standard has kind-of left Applets behind, deprecating the Applet tag for the more generic Object tag. Not a big problem, but slightly annoying and important if your web site is to be XHTML compliant.

We had a simple task to solve for our client:

Print PDF documents on a cross browser web page, without user intervention.

The task in itself doesn’t sound too bad. PDFs are a well known standard for documents and there are numerous browser plug-ins we can use. The tricky part is the “Without user intervention” bit.

That suddenly throws all of the spanners into the machine, leaving a poor engineer with the task of putting it all back together again.. only this time making it spanner proof.
Browsers are very protective of the printer. You can’t access it directly. Sure, you can print a web page, but you can’t bypass the all-seeing eye of the Printer Dialog.

Because of this, numerous ActiveX components have been developed and are sold to get around this issue for web applications. The thing is, ActiveX is a Microsoft Only technology, for Windows and Internet Explorer. That goes against the Cross Platform, Cross Browser requirement.

Java to the Rescue… mostly

So we had to set about printing from the browser. Thankfully, Java does have the capability to talk to the printer directly. The only downside being that it keeps asking for permission to do so, rather like an over-polite child constantly asking to use the bathroom.. The temptation to lose all patience and say “Yes, for the 1000th time, just use the bathroom if you need it OK?” – which would be bad.

There is a way to instruct the Java runtime that it’s OK for it to use the bathroom.. I mean, Printer. You can modify the java.policy file in your runtime directory/lib/security folder to grant permissions to use the printer. A cheap and nasty solution in more than one way.

First of all, it meant having to modify the file on the machines of each user using the web application to grant access to the printer and secondly (and possibly more importantly) Every time you upgrade your Java runtime, it keeps a copy of the old one and installs the new one in a fresh directory.
This means that you have to re-apply your cheap hack to the new runtime, whenever your users upgrade their Java.. Support Nightmare!

Thankfully, there was a solution.
First of all.. Sign the Applet. You can self sign your applets but we chose to buy a certificate and sign it that way. It looks much better with a certificate from a trusted Certificate Authority, and they’re not expensive.

A signed applet is a trusted applet (assuming the user says ‘Yes’, they trust your applet) and has access to things like Printing and Files etc. Things a normal applet just doesn’t have (without above hack).

But we were still running into problems. The over-polite child.. I mean, Java.. was still asking to use the printer, each and every time we initialized the applet and tried to print. Even though we’d checked the little box which was supposed to remember our selection. I’m not sure if this is a bug in the runtime or not, but that’s another thing entirely.

Odd permissions issue – The day Logic took the day off
It turns out that the reason it kept asking, even with a signed applet was that the code being called to talk to the printer was being accessed from Javascript on the web page, and was therefore un-trusted. I’m unsure of the logic here, what was going through the minds of the Java Runtime developers.. a trusted applet should be a trusted applet irrespective of what is calling it, but it is what it is.

The way around that was to make sure that the Javascript was not directly accessing the printing method.

This was done using a separate thread, sitting waiting for a variable to be set.
The public method accessed by the Javascript then only set a variable along with the printing details.
The printing thread then picks this information up and prints the document. No problems.

Are we nearly there yet?
Another issue was telling when the applet was loaded so that we could call it’s methods from the site. This turned out to be more problematic than we originally thought. The isActive method didn’t always work and we had to resort to getting the Applet to call a Javascript method on the page (if it existed) to inform the page that it was ready.

..and Finally

Now, figuring that all out took more time than writing the entire applet and if this was a few years ago, If google didn’t have access to forum threads where other people had solved these same problems, it would have taken a lot longer. In some ways, I can see why the .net framework has overtaken Java as the development platform of choice for business. It’s certainly easier to get up and running faster with .net but .net can’t do everything and Java shouldn’t be dismissed as old hat.

It’s very powerful, fast, cross-platform, cross-browser and free. These factors alone make it a language worth using.