{"id":260,"date":"2011-02-08T16:00:41","date_gmt":"2011-02-08T14:00:41","guid":{"rendered":"http:\/\/blog.ansuz.nl\/?p=260"},"modified":"2011-02-08T16:00:41","modified_gmt":"2011-02-08T14:00:41","slug":"flex-java-frankenstein","status":"publish","type":"post","link":"http:\/\/blog.ansuz.nl\/index.php\/2011\/02\/08\/flex-java-frankenstein\/","title":{"rendered":"Flex + Java = Frankenstein?"},"content":{"rendered":"

Lately I’ve been working on a small upload tool in Flex\/AIR.
\nTo verify that an upload has succeeded, I created a hash (md5) of the entire file and sent that to the backend for verification. The AS3CoreLib<\/a> contains a nice MD5 class, MD5Stream, but it’s much too slow for creating a checksum of files.<\/p>\n

Actually, it’s so slow that when I was uploading a 5+ MB file the application would slow down so much that the upload speed dropped to a third of the speed without feeding the MD5Stream data during uploading.
\nLuckily, with AIR 2.0 NativeProcess<\/a> has been introduced, it made it much easier to “outsource” complicated calculation to a process that can deal with that much better, i.e. Java.<\/p>\n

The nice thing about Java is that it’s cross-platform just as AIR, and these days many people will have the JRE installed.\u00c2\u00a0 So first of all, I wrote a small Java class that would print out an MD5 hash of a file based on the path that I passed. I jarred the class and added it to my AIR project.
\nThe second step was to call my Java class instead of the AS3 MD5Stream class. This is surprisingly easy. The NativeProcess documentation comes with a pretty clear example and Piotr Walczyszyn<\/a> has created a small framework, Flerry<\/a>, to let Flex talk to Java and vice versa.<\/p>\n

Looking at how Flerry is built will give you some more insight on how to deal with NativeProcess.
\nFor my application, I only use the BaseStartupInfoProvider<\/a> class from Flerry to find where Java is installed on the user’s machine. After that I set up all event listeners as per the NativeProcess documentation and call NativeProcess.start() with a NativeProcessStartupInfo as passed in parameter.
\nNow my uploads are fast again and I can generate a checksum in a fraction of the time I could before.<\/p>\n

There are unfortunately some downsides to this approach. You have to deploy your AIR application as native installer<\/a> to be able to use the NativeProcess class. So instead of having one AIR file, you’ll end up with four native installers (.exe, .dmg, .deb, .rpm). On the plus side, you can create the native installers from an AIR file without needing to resign the application.
\nAnother downside is that now I’m relying on two runtimes being installed on the end user’s machine, AIR and Java.
\nMy final thought is that now that I am outsourcing some calculations to Java, why not built the whole thing in Java? Then again, building a decent UI can take ages using Java. To me, my application feels like I’m creating a bit of a Frankenstein.<\/p>\n

All in all I’m glad I now have a fast way to generate a checksum and my uploads aren’t slowed down by it any more.<\/p>\n

Links:<\/p>\n