F**$#&% Java Policy Files

If you have ever had to modify a policy file, let me warn you of a wrinkle that you may run into IF your applet/java code needs to perform an operation that is authorized by the policy file BUT IS CALLED VIA JavaScript.

Guess what folks?  Java doesn't trust JavaScript any more (and hasn't intermittently over the past 5 years or so - sometimes trusting, sometimes not) so just because you gave your code a valid policy file grant, any code triggered via JavaScript will run as if being run outside the Java codebase (which in a way it is.)  This means that you have two options, one of which is not palatable, and the other can break backwards compatibility in your codebase.

(1)Grant permissions without using the codebase attribute (this is very very bad as your permission change will therefore grant the same permissions to ANY applet that the user runs into.)

(2)Surround the code that needs permissions privileges (and can be called via JavaScript) with a doPrivileged block.  The downside to this is that early versions of Java don't support this functionality; ergo you are (probably) forced to go the trusted/signed applet route (not good for many reasons.)

Luckily for me, I only need this functionality inside of a tool that is hosting my Java code, so I can put the non 1.1.8 jdk compliant code in my dynamically loaded adapter class that only ships with the offline tool.

Anyhow, I hope someone else trying to figure this out learns from this.

If your applet needs policy file permissions and your applet will be called from javascript, you must not only grant the applet the permissions in the appropriate fashion but also surround the code that can be triggered via JavaScript with a doPriveleged block.  This is because Java's runtime no longer executes javascript with the permissions levels of the applet.

Java JRE, IE8, and 64-bit systems...

I just put Windows 7 Ultimate on my HP QuadCore laptop, and after downloading and installing the latest 64-bit JRE from SUN, I found that it didn't appear to actually install properly. Applets wouldn't load, but java showed up through the command line. So, I went to 'manage add-ons' in IE8, and saw only 1 of the usual 2 SUN plug-ins. I figured I'd just had a screwy install, so I removed, re-downloaded (you never know) and re-installed. Bang, same problem.

At this point, I usually slow down and ensure I'm not being a complete idiot about something and I carefully evaluate my actions. Yes, this is Windows 7 Ultimate x64, yes I downloaded the x64 JRE 6, update 17. Ok, time to google. People having problems with this? After sifting through the inevitable mountains of detritus trying to find a nugget of useful information (should I have used Bing? ;)) I ran across a tiny little comment in forum about 17 posts down saying "Make sure it's IE8 x64 you're using..." Click. No way, I thought. I could understand and appreciate why Microsoft would install two versions of IE8 on an x64 system, but I figured there's no freakin' way the default IE to be used would be the 32-bit version, right? Wrong.

Turns out that that the default IE8 that shows up 'pinned' to the taskbar is the 32-bit version. Jerkoffs... So, 30 seconds later I had both added a quick launch toolbar to the tastbar (some idiot decided to remove this from Windows 7) and replaced 'IE8' with 'IE8 (x64).' Bingo applets showed up.

If you need to see the MSJVM console in IE7...

...then there are two things you need to do (or you may be able to skip step #1 and proceed directly to step #2 depending upon your current settings.)

(1)Go to the menu bar (enable it if you've hidden it) and choose Tools|Internet Options|Advanced, scroll down to "Microsoft VM" and enable "Java console enabled". You need to close and re-open your browser after this.

(2)When running an applet, go to the menu bar and choose View|Java Console (it should be the item right after 'Full Screen' on the menu.)

Hope this helps people testing applets on the MSJVM like I am currently.

Update to services in Android...

...it turns out that what you really should do, if your code is in separate projects, is to declare a global (I presume) service moniker like this (in your service's manifest):

<action android:name="com.android.TestService.TEST_SERVICE" />

Then, change the method by which you call startService to call like this:

startService( new Intent( "com.android.TestService.TEST_SERVICE" ) );

NOTE: The argument is a string, which is the key. (Don't forget to change your invocation to stopService if you call that as well.)

Google might want to think about software less for tinkerers and more for real software engineers who will need to organize their code and look for opportunities to re-use, especially regarding services, and mention in their documentation that they recommend you add this naming schema to your service manifests for good reason. I'm just glad I noticed it in the remote services sample code.

If you're having a hard time with services under Android...

...I can feel your pain. The SDK documentation is good from a referential point of view, but focuses primarily (as you would expect) on the more superficial aspects of the system. Personally, I'm interested in services, IPC mechanisms, and networking so that means I get to read a bunch of API docs and peruse some of the samples.

Now the Android SDK samples aren't bad; however, they are limited. Let's say you're going to write a GUI application (termed for some reason by Google as an 'Activity') and you're going to write a service (as in daemon/service.) Google gives you an example of doing so, but for some reason decided to include all the manifest data for ALL THE SAMPLES into the same manifest file and as one big project (which has implications under Eclipse - which is presumably the development environment you're working in unless you're a sadist and you probably enjoy the pain I'm describing anyhow...)

Well, real projects for useful applications do NOT clump everything together in a single manifest, and they do NOT clump all the source code into the same project. Separating the two is not difficult; HOWEVER, Google's documentation and everything I could find on the 'net regarding service declarations in application manifests neglects to mention what you need to do when yo uhave one project that will be a client of the service and the other project being the service in question. Now, maybe I'm an idiot, but I spent several hours trying to understand why my client application could not successfully call 'startService' on a perfectly named, installed, and runnable service that was on the emulator. The log kept reporting that the component could not be found (while explicitly listing the component correctly which means it had exactly the right package name.) After beating my head for hours, I finally wised up to the fact that I was making an enormous assumption.

I was ASSuming that Google wasn't doing something funny with the service binding mechanism and that because it used a standard Java packaging nomenclature, surely that meant that my client application could call 'startService' and have the OS identify the package correctly. Boy was I wrong.

Apparently, the 'multi-project' trick with a service is that you must declare the service in the manifest of every client application that you will have use the service - even though the declaration is just supposed to be in the service project's manifest according to the documentation (and you cannot tell from the samples because they're all glommed together.)

So, before I forget this, and so I can google my own frustration when I do forget this:

In your client manifest XML you need to add this inside :

<service name="com.MyPackages.MyService.MyServiceClass">

Please note the full package name usage, which is HIGHLY recommended in case you move projects around or rename things. BTW, if your service is to run in its own process, add
android:process=":remote" to your service tag, otherwise it runs locally which I don't understand the purpose of really.

So, to sum up. If you create a service, you'll have a manifest for that project with a service entry in it, as one would expect. If you create a client that will make use of this service, you'll have to add, oddly, a service entry in the client's manifest as well.

I don't know if this is a bug or not, but it was certainly unclear to me. Hope this helps somebody.