TEERA 2.0: Vancouver Sun

During my last presentation, someone raised a question about Java performance comparing to other languages like C#.NET and C++. Java's reputation of slowness seemed to precede itself for the last decade. I've met many who complain about Java being slow, when they have never actually written any Java code! This misunderstanding has also been amplified by many Java non-believers in the industry. I think it would be a good idea to do a little roundup on Java performance benchmarking and overview of HotSpot VM as it contribute to faster Java for future reference.

Java vs C/C++

David Agastine's classic works on Java Benchmarking

• http://blogs.sun.com/dagastine/entry/java_is_faster_than_c
• http://blogs.sun.com/dagastine/entry/sun_java_is_faster_than

Performance of Java versus C++ by J.P.Lewis and Ulrich Neumann

Java vs C#

Another of David's blog entry

• http://blogs.sun.com/dagastine/entry/sun_java_is_faster_than1

Java vs Python and Ruby

C++ vs Java vs Python vs Ruby : a first impression

Hard Fight : Java vs. Python vs. Ruby

• This blog post is originally written in Thai, but the testing code and result are in English. So to see the code and performance summary, scroll down to the bottom of the page. A couple points to note about this test:
  
  • The performance is subject to the code running. The author
    does not claim to be an expert in Java, Python, Ruby.
  • As you can see along this post, the testing code has been revised many times. After each revision, the result changes. So, this benchmarking result subjects heavily to the quality of the testing code.
    

There are many other benchmarking done and published on the web. Yet some of them are old and the information they provide is based on older version of JDK, so I will not include them here. Let me know if there are other good benchmarks out there. Several key factors contributing to Java's outstanding performance:

HotSpot VM

Default Sun JVM since Java 1.3. Apart from providing shared Java Runtime library and executing bytecode, HotSpot implements several optimization techniques that yield higher performance.

Just-in-Time(JIT) compilation:
The basic idea is that bytecode compilation is done selectively by JIT compiler when it's about to be executed. JIT compiler is also smart enough to cache heavily used code
(the hot spots!) in memory at runtime to reduce number of recompilation and reinterpretation. Another beautiful thing about JIT compiler is that the longer the application is running, it collects and analyzes more data. JIT runtime can then use this information optimize compilation for better
performance.

 Adaptive optimization:
HotSpot adaptive optimizer can base compilation on current execution profile, making tradeoff between JIT compiling and interpreting instructions. The optimizer can collect data and schedule compilation accordingly to improve performance for current use case. So, in
theory, Java application running in optimized run-time environment can, if it is not already, be faster than C/C++.

Dynamic recompilation:
At a lower level, VM can recompile
some part of a program during execution time. Once the VM spots a repeating code pattern or redundancy in code that is running, it can tailor generated code to optimize current run-time environment. Adaptive optimization usually employs Dynamic recompilation as a part of its strategy.

JDK improvement
Java language compiler, along with HotSpot VM, is improving on every release. Every releases include bug fixed, code review, and additional optimization techniques. I think the JDK improvement on future releases will even be more significant after Sun open sourced JDK.

I think it is worth to think about reasons why many people still stuck with the idea that Java is slow, after all, HotSpot run-time optimization isn’t a new thing

1. They had bad experience with earlier version of Java - 1.2 and earlier ones that didn't have JIT compiler in it.
2. HotSpot optimization units improve performance over time as it collects more information from run-time environment. So the application can be sluggish on the first run.

During Steve Jobs' recent interview with Time Magazine, when asked if IPhone will be running Java, Jobs' response was

"Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

So he's saying that Java is history? An article I found on JDJ magazine extends the discussion to how Java handles AJAX and RIA. At the end, the author's suggesting that Flex and Flash would be better alternatives than Java.

I do like Flash very much for its wonderful graphic and smooth interactivity, but only when these conditions are met:

1. When it’s nicely done. For flash, it's better not having one than a lousy one

2. When I have enough patience to wait until it finishes loading

3. When the machine I'm using have (right version) Flash browser plug-in installed

4. When it has nice music with volume properly adjusted

5. When I'm not in a rush to the content and have time to appreciate it

If these conditions are met, yes..I love Flash.

I bought a copy of Adobe Flex 2 some while ago. I think it's a good tool to build web application front end.
FlexBuilder lets you create a flash-driven web very fast. You can also extend its use to developing Rich Internet Application with
database backend. Nevertheless, as it is Adobe's product, it seems to target Web designer, not developer or programmer. In the end, you will still need J2EE or other application servers to handle the server side complexity. Note that I'm saying this not as a Sun employee but as a developer who works with the web on daily basis to pay for his tuition. Rafael, a fellow Sun employee, brought up a point that adding heavy Flash or Flex layer instead of using simple AJAX call or Applet would also increase integration complexity and not to mention security threats for developers have to worry about.

Regarding Mr.Jobs' comment, I think he's off on this one (probably it's his RDF in the work as usual). Don't get me wrong, Steve Jobs has always been my iconic figure and I admire him greatly. Sure, his IPhone doesn't need Java if he says so (he's running Apple!), but he probably forgot that his Apple has chosen Blu-ray as its next gen DVD and Blu-ray is running Java...

The latest release of Java SE has been recently shipped along with bundled JAX-WS 2.0. For those who've done some web services development with Java EE 5 would probably be familiar with how JAX-WS 2.0 and WS annotations can make your life a whole lot easier. Well, it's about to get even better with Mustang!

Mustang allows you to create and test your web services with ease. With integrated lightweight HTTP Server API, now you can create POJOs for your business logic, add WS annotations, establish endpoints, and test your WS components right away without having to deploy to application server. The following code example will show you how easy it is to develop web services, attach to endpoint, build, deploy, and redeploy when new service is created. For complete code of this example, click here.

The scenario on this example is that I am trying to create two web services to perform mathematical operations. One of them will be performing simple operations: add, subtract, multiply, divide. Another will perform exponential and modulus operations.

First, I create a java class name SimpleArithmetic.java to perform simple operations and AdvancedArithmetic.java for the other operation set. I also mark these classes and their methods with @WebService and @WebMethod annotations so that I can deploy them as web services.

View Listing 1

To control services deployment, I create an XML file to serve as database of available services (ServiceConfig.xml). Each of the web service will be represented by <Service> element with the following attributes:

• publish: true/false indicate if this service should be published
• endpoint: endpoint URL of this service
•  class: class name of POJO that implement this service

Let’s suppose that at this moment, I only want to publish SimpleArithmetic service.

<root> 

<Services>

        <Service publish="true" class="ws.SimpleArithmetic" endpoint="http://localhost:9001/ArithmeticService/SimpleArithmeticService" />

        <Service publish="false" class="ws.AdvancedArithmetic" endpoint="http://localhost:9001/ArithmeticService/AdvancedArithmeticService" />

    </Services>

</root>

Now, I create another class that reads this xml file and create endpoints for service with ‘publish’ attribute set to true. I name this class ServiceHub.java with the following implementation. This class contains three public methods:

• Start(): read the xml file and establish service endpoints

• Stop(): stop all services

• Restart() 

View listing 2

Note that I use sTAX to read the xml file. Click here for more information on Stax.

To run the service, in my Main method of this application, I create a while loop that can take use keyboard input and invoke Start(), Stop(), and Restart() methods on ServiceHub instance accordingly.

View Listing 3

Compile all classes and run Main method, after typing in ‘start’ and hit enter, I will see only SimpleArithmetic service running on its specified endpoint URL in the ServiceConfig.xml file. I can view the WSDL file of this service on http://localhost:9001/ArithmeticService/SimpleArithmeticService?wsdl

Now, suppose that I just finish creating AdvancedArithmetic service class and want to simply test it. If I’m running this with Java EE and application server, I will have to deploy this new service on a separate test application server and configure whole new environment just for testing. Instead, I will just change the ServiceConfig xml file to publish this new service.

…<Service publish="true" class="ws.AdvancedArithmetic" endpoint="http://localhost:9001/ArithmeticService/AdvancedArithmeticService" />…

In my running Main method, I will just enter ‘restart’ to republish service endpoints. Now if I go to ‘http://localhost:9001/ArithmeticService/AdvancedArithmeticService?wsdl’ url on my web browser, I will be able to see that my new AdvancedArithmetic web service is up and running too!

Now you probably think, ‘Hey, I can do all this with JAX-WS on Java EE 5 too!’ Yes, that’s right. JAX-WS on Mustang does not eliminate the need of Java EE and application server. We still need other advanced features such as security and application management from Java EE. I think the true gem of JAX-WS bundle on Mustang is how it can accelerate web service development. It enables developers to build POJO-based web service components very rapidly.

There are some arguments against JAX-WS bundle on Java standard edition. Among the most interesting ones are an entry on Arun’s blog and Dim’s ‘Why bundling JAX-WS with Java SE 6 is a bad idea’. Another article on SearchWebServices also provides an interesting point by pairing up Java SE 6 and Java EE 5 ability to support SOA.