The Blog that Noone Reads

I posted recently about the idea of using a headless Java applet or Flash movie to encapsulate complex business logic. The JavaScript runtime is painfully slow compared to other runtimes. Here, I compare the performance of a Java version versus a JavaScript version of the same code.

Here’s the JavaScript version:

function countPrimes(size){
    var i, c, prime_count;

    prime_count = 2;

    for(i =2 ; i < size; ++i){
        for(c = 2; c < i; ++c){
            if(i % c == 0){
                prime_count++;
                break;
            }
        }
    }

    return prime_count;
}

And the Java version:

import java.applet.*;
import java.awt.*;
import java.util.*;

public class JavaInteractionTest extends Applet {

    public void init() {
    }

    public int countPrimes(int size){
        int i, c, prime_count;

        prime_count = 2;

        for(i =2 ; i < size; ++i){
            for(c = 2; c < i; ++c){
                if(i % c == 0){
                    prime_count++;
                    break;
                }
            }
        }

        return prime_count;
    }
}

Calling them:

The JavaScript method is pretty simple:

    var prime_count = countPrimes(search_amount);

The Java method is not much more complicated:

    var engine = document.getElementById('sample_applet');
    var prime_count = engine.countPrimes(search_amount);

The Results:

I ran my test in FireFox with search_amount equalling 10000.
The JavaScript version took 927ms.
The Java version took only 281ms.

The amount of code is basically the same. There’s a little bit more involved wrapping the Java so it’s a valid applet and including the applet in the page, but the functions themselves are nearly identical. There are many benefits to using Java: Runtime execution is much faster. Developers don’t have to spend as much time dealing with the incompatibilities of different JavaScript runtimes. Java is more well known by many engineers. It has strong unit testing support. There is a much stronger separation of application logic from presentation. The application logic can be re-used more easily in many types of applications. You can perform most of your testing completely separate from the browser, which leads to better automated testing, which leads to better code. There is a vast library of Java components available open source on the web.

The few downsides, I’m afraid, may be deal breakers: File sizes are substantially bigger. The JavaScript version of this code was only a few bytes. The Java version is 2KB. That number will grow substantially as more libraries are included in the application. This is offset however by the fact that Java applets are cached by the browser for a long, long time. The other problem with this method is market penetration. Far more web users have JavaScript capable browsers than Java capable ones. This is definitely an issue for many sites, but I’ll bet it’s not a deal breaker for everyone.

I’d like to see more people play with this technique. I’m sure it will find usefulness in many places. I’d also like to see a similar test done comparing JavaScript versus the sexy new ActionScript runtime in Flash 9. If anyone out there has any experience with this, or some decent data on the current state of Java availability in modern browsers, please drop me a line or leave a comment.

This entry was posted on Thursday, May 10th, 2007 at 12:02 am and is filed under Geek. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.