1. Let’s start with basics. John Rose posted a good starting guide for those who’d like to micro-benchmark things on JVM: So You Want to Write a Micro-Benchmark.
2. Performance techniques used in the Hotspot JVM wiki entry with the list of optimizations JVM does, sweet and to the point.
3. Fundamental work by Ulrich Drepper: What Every Programmer Should Know About Memory, a MUST read, but painful
4. Deep dive into assembly code from Java blog post by Kohsuke Kawaguchi, on how to print out the assembly code that JIT is producing.
5. Examining generated code with OpenJDK 7, exciting stuff!
6. Polymorphism Performance Mysteries Explained, the Issue #158 of The Java Specialists’ Newsletter.
7. How fast is Java Volatile? or Atomic? or Synchronized?, with nice charts and comparisons.
8. Escape analysis can help optimize synchronization by Brian Goetz.

Enjoy!

So, open up your Firefox bookmarks and create a new one, with the following info:

• Name: Quick Javadoc Search
• Location: Copy This Link
• Keyword: jd

This is it. If you look at the link closer, you’ll notice that we just use Google search for “(Java Platform 5.0)” on java.sun.com site in “I’m feeling lucky” mode.

Now, any time you enter in the Firefox, for example,

jd String

it will get you to the javadocs for java.lang.String. In most cases you don’t even need to fully qualify the class name!

Please note that this comparison is focused mostly on the API.

Popular Unit testing framework for Java ME:

1. J2MEUnit
2. JMUnit
3. Sony Ericsson Mobile JUnit 1.0

All three frameworks are close to the original JUnit, with adjustments needed to support the Java ME Platform. In all 3 cases, a test class should extend a base class from the appropriate framework. And all typical JUnit helper methods are provided to the subclasses, e.g.: assertTrue, assertFalse, assertEquals, etc. (J2MEUnit provides the bare minimum of such methods, leaving quite some of them out).

JUnit standard hook methods are also present: setUp() and tearDown(), to setup test environment and to tear it down after the test is done.

So, in all 3 cases, developers who are familiar with JUnit, can start writing new unit tests for Java ME with fewer problems, since they basically know the core API.

The differences can be seen in areas where support for Java ME was added (one of the major problems is the lack of reflection in Java ME, while the original JUnit relies heavily on it). While the tests themselves look pretty similar for all three frameworks, the way the test suites are constructed differs.

1. J2MEUnit

With absence of reflection, J2MEUnit authors decided that test suites should be created manually, explicitly adding new tests to the test suite, like this:

  aSuite.addTest(
      new TestOne("testOne", new TestMethod() {
          public void run(TestCase tc) {
              ((TestOne) tc).testOne();
          }
      })
   );

The name of the test provided in the constructor, and the functionality of the test is enclosed in the anonymous inner class that implements the TestMethod.

Pretty heavyweight and not that simple, if you ask me.

2. JMUnit

JMUnit test class must call a two-parameters constructor of the base class, specifying the number of the “sub”-tests, and the name of the test.

public TemperatureConversionTest() {
    super(4,"TemperatureConversionTest");
}

The test selection and execution is done via method test(int), that should be implemented by every test:

public void test(int testNumber) throws Throwable {
    switch(testNumber) {
        case 0:testfahrenheitToCelsius();break;
        case 1:testcelsiusToFahrenheit();break;
        case 2:testisHotter();break;
        case 3:testisCooler();break;
        default: break;
    }
}

The base class will call this method with all int values, from 0 to number-of-tests.

In my opinion, this approach is less convoluted and more straightforward then J2MEUnit. JMUnit also provides better GUI on a device that shows the results.

JMUnit provides two versions, one is suitable for CLDC 1.0, and the another one is for CLDC 1.1.

Overall, JMUnit provides more extensive set of helper methods (asserts), with better GUI, and with more straightforward configuration.

Netbeans’ Mobility Pack has switched from J2MEUnit to JMUnit recently.

3. Sony Ericsson Mobile JUnit 1.0

The folks from Sony Ericsson did an excellent job on this, providing good extension to JUnit for Java ME, and with great documentation

Sony Ericsson approach, it seems, was to provide experience as close to original JUnit as possible. In most cases, to port JUnit tests to Sony Ericsson unit tests is just a matter of replacing the base test class all the tests extend (from JUnit one to Sony Ericsson one.)

Couple of innovative things were done in this library. The absence of reflection is handled on Java SE side, where the tests are being analyzed and proper extra classes are created, so that developers are freed from manual work of specifying all their test names. Sony Ericsson’s version is clearly better here then the two alternatives (J2MEUnit and JMUnit).

The library also provides nice additions on top of typical JUnit API. For example, it not only provides setUp() method, but also setUp(MIDlet midlet), for those tests that would like to access the midlet that runs the tests.

The GUI on the device looks nice too, with tabbed interface for passed/failed tests. Sample project for WTK is also provided. And the basic code coverage can be calculated, which is an unexpected plus.

Integration with Ant, NetBeans and Eclipse is provided.

Overall, Sony Ericsson Mobile JUnit 1.0 is very well done and easily beats other alternatives, discussed above. They provide the best JUnit “emulation”, and resolve absence of reflection in innovative way simplifying developers life.

For additional information, take a look at the following article: “JUnit Testing Using Java ME JUnit Frameworks“.

I’ve noticed that we use StringTokenizers here and there, mostly to parse quite big text files, while the javadoc for the StringTokenizer states:

StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead.

OK, I thought, let’s switch to regular expressions and see, they are indeed more powerful and convenient to use. Well, yes, except for the fact that the new code runs typically 4-5 times slower than the original one. Come to think of it, the regexp-based version indeed should have been much slower when compared to very simple and straightforward Tokenizer.

So, the lesson for me here is to use String.split() for non-performance sensitive operations and to keep using good old StringTokenizer when the performance is critical. Oh, and not to trust everything I read in javadocs.

I’ve been using the Profiler for months now, and can honestly say that the strong desire to buy a commercial profiler is no more. The latest NetBeans Profiler does all or almost all that I need, including performance analysis, memory analysis, heap dumps, compatibility with jhat, partial class instrumentation (no need to instrument the whole application).

The two missing in Profiler 5.5 features are now implemented, and work:

1. Heap Walker
2. Compare Memory Snapshots

I’ve been also quite surprised by performance of instrumented code. Yes, it’s slower than non-instrumented code, but the difference is not that big, so I can execute my apps under profiler and they run without major performance degradation.

Overall, the memory and performance analysis in Java has become much more easy and fun.

• Tracking Down Memory Leaks by Greg Sporar
• Plugging memory leaks with weak references by Brian Goetz
• Using Mustang’s jmap/jhat to profile GlassFish by Jean-Francois Arcand
• Heap Dump Snapshots by Kelly O’Hair
• What’s in my Java heap? by A. Sundararajan
• Heap dumps are back with a vengeance! by Alan Bateman

I’ve written it while trying to find memory leaks in our testing tools: JTHarness and ME Framework, and then wanted to share the HOWTO with the world, but I didn’t have my blog at that time, so I posted this info as a comment to a relevant entry in the excellent Adam Bien’s blog.

Note: Use the latest JDK 6, because it has the latest tools, with lots of bug fixes and improvements. All the later examples assume that JDK6′s bin directory is in the PATH.

Step 1. Start the application.

Start the application as you usually do:

java -jar java_app.jar

Alternatively, you could start java with hprof agent. Java will run slower, but the huge benefit of this approach is that the stack traces for created objects will be available which improves memory leak analysis greatly:

 java
  -Dcom.sun.management.jmxremote
  -Dcom.sun.management.jmxremote.port=9000
  -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false
  -agentlib:hprof=heap=dump,file=/tmp/hprof.bin,
   format=b,depth=10
  -jar java_app.jar

When the application is up, perform various actions that you think might lead to memory leaks.

For example, if you open some documents in your app, the memory graph could rapidly go up. If closing the docs and invocation of full garbage collection did not bring the memory back to normal level, there is probably a leak somewhere.You might use jconsole from JDK 6 to see the memory consumption graph to have a clue whether memory leak is present or not:

jconsole

It will pop up a dialog with a list of Java applications to connect to. Find the one with java_app.jar and connect. Also, jconsole allows to invoke full GC providing nice button just for that.

Step 2. Find the application pid.

Find out the application’s process id via:

jps

It will print something like:

15976 java_app.jar
7586 startup.jar
22476 Jps
12248 Main
5437 Bootstrap

In our case the pid is 15976.

Step 3. Dump the heap into file.

Dump heap into the file:

jmap -dump:format=b,file=/tmp/java_app-heap.bin 15976

We just told jmap to dump the heap into /tmp/java_app-heap.bin file, in binary from (which is optimized to work with large heaps). The third parameter is the pid we found in Step 2.

Alternatively, if you started java with hprof agent, you could just use Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows to dump heap into the file, specified in hprof agent arguments.

Step 4. Visualize the heap.

Use jhat tool to visualize the heap:

jhat -J-Xmx326m /tmp/java_app-heap.bin

Jhat will parse the heap dump and start a web server at port 7000. Connect to Jhat server by pointing your browser to:

http://localhost:7000

And start investigating.

Jhat allows you to see what objects are present in the heap, who has references to those objects, etc.

Here are some tips:

• Investigate _instances_, not _classes_.
• Use the following URL to see the instances: http://localhost:7000/showInstanceCounts/
• Use “Reference Chains from Rootset” (Exclude weak refs!!!) to see who’s holding the instance.