Menneisyys
07-03-2005, 07:35 PM
Now that I played with the JavaScript-compliance of the three major Pocket PC browsers (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=41265) and DeBary_FL has posted some good reports on the Java compliance of the new (2.1) Thunderhawk (TH) version (http://discussion.brighthand.com/showthread.php?s=&threadid=118021), I decided to continue scrutinizing the Java support in Thunderhawk. My first impressions weren’t that all great back when version 2.1 was announced (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=40983). Now that I’ve done some additional tests, I’ve changed my opinions to a certain degree (at least “serious” business applet-wise).
First and foremost, the Java support does exist, even in the trial version.
The well-known Tumbling Duke (http://java.sun.com/applets/other/TumblingDuke/index.html) applet has shown that there is Java support, but this is indeed a client-server based one. That is, the client (which is almost no different from non-Java-enabled older TH clients, code-wise) just receives the current page as an image file, and if a user clicks it, it sends back the click positions, just like an imagemap.
This means some applets will indeed work, but not all of them: see for example the above-linked ones or the ones that need, for example, local sound generation. The JVM in NetFront 3.2 can play these applets great with sound. Compare for example the BouncingHeads applet (http://java.sun.com/applets/other/BouncingHeads/index.html) in NetFront 3.2 and in Thunderhawk.
That is, you’ll have a hard time with anything graphics-intensive (not to mention sound). The reaction time of applets like these will also be very high and the screen refresh rate very low. The same stands for the bandwidth consumption: as all new screens must be explicitly downloaded as an image file, your bandwidth consumption will be really high. This kind of Java support is definitely not for gamers.
“Serious”, non-graphics-intensive applets that are, for example, needed in banking environments, are an entirely different matter. The fact that it’s on the server that applets are run, with full Java 1.5 (including full support for security, code signing, etc), support, makes Thunderhawk’s Java support really great – actually, much better than any of its competitors (NetFront 3.1/3.2; Jeode/Jbed and CrEme PIE plug-ins), as far as non-strictly CDC/J2ME applications are concerned. Online banking systems (still?) don’t use strictly CDC/J2ME-compliant applets AFAIK.
Also, some practical advice:
Cleaning up Thunderhawk
You may also want to clean the Thunderhawk home directory a bit cleaner. Some 250k there can be freely deleted – they will never be needed unless you want to browse the pre-stored examples.
thunderhawk.txt: the splash screen of TH. Can be freely removed
amazon.txt: just an Amazon demo
nytimes.txt: just a NYT demo
You can also delete bitstream.txt, looksmart.txt and priceline.txt.
Security-wise, it’s also worth knowing that TH doesn’t encrypt the username/password; it’s available in thconfig.txt as plain text.
First and foremost, the Java support does exist, even in the trial version.
The well-known Tumbling Duke (http://java.sun.com/applets/other/TumblingDuke/index.html) applet has shown that there is Java support, but this is indeed a client-server based one. That is, the client (which is almost no different from non-Java-enabled older TH clients, code-wise) just receives the current page as an image file, and if a user clicks it, it sends back the click positions, just like an imagemap.
This means some applets will indeed work, but not all of them: see for example the above-linked ones or the ones that need, for example, local sound generation. The JVM in NetFront 3.2 can play these applets great with sound. Compare for example the BouncingHeads applet (http://java.sun.com/applets/other/BouncingHeads/index.html) in NetFront 3.2 and in Thunderhawk.
That is, you’ll have a hard time with anything graphics-intensive (not to mention sound). The reaction time of applets like these will also be very high and the screen refresh rate very low. The same stands for the bandwidth consumption: as all new screens must be explicitly downloaded as an image file, your bandwidth consumption will be really high. This kind of Java support is definitely not for gamers.
“Serious”, non-graphics-intensive applets that are, for example, needed in banking environments, are an entirely different matter. The fact that it’s on the server that applets are run, with full Java 1.5 (including full support for security, code signing, etc), support, makes Thunderhawk’s Java support really great – actually, much better than any of its competitors (NetFront 3.1/3.2; Jeode/Jbed and CrEme PIE plug-ins), as far as non-strictly CDC/J2ME applications are concerned. Online banking systems (still?) don’t use strictly CDC/J2ME-compliant applets AFAIK.
Also, some practical advice:
Cleaning up Thunderhawk
You may also want to clean the Thunderhawk home directory a bit cleaner. Some 250k there can be freely deleted – they will never be needed unless you want to browse the pre-stored examples.
thunderhawk.txt: the splash screen of TH. Can be freely removed
amazon.txt: just an Amazon demo
nytimes.txt: just a NYT demo
You can also delete bitstream.txt, looksmart.txt and priceline.txt.
Security-wise, it’s also worth knowing that TH doesn’t encrypt the username/password; it’s available in thconfig.txt as plain text.