While trying to find the block coverage from Emma, I came across this curious observation. See the method below

public double getBalance()
     return this.balance;

The coverage summary from Emma says that it has 3 blocks


          name         class, %     method, %      block, %        line, %
   BankAccount.java   100% (1/1)  82%  (14/17)  61%  (152/250)  71%  (45/63)


                name              class, % method, %    block, %    line, %

   class [4]BankAccount           100%     82%        61%          71%
                                  (1/1)    (14/17)    (152/250)    (45/63)
   [13]getBalance (): double               100% (1/1) 100% (3/3)   100% (1/1)

I was wondering how this method has three blocks unless it was counting the jvm byte codes, and outputting the total number of byte codes as the number of blocks. Given below is the dis-assembly for comparison

public double getBalance();
   Stack=2, Locals=1, Args_size=1
   0: aload_0
   1: getfield  #8; //Field balance:D
   4: dreturn
   line 99: 0

This seems to hold true for other methods too. Is my finding correct?

public void addTransaction(double amount)

[10]addTransaction (double):            100% (1/1) 100% (7/7)   100% (2/2)

public void addTransaction(double);
   Stack=3, Locals=3, Args_size=2
   0:   aload_0
   1:   getfield        #6; //Field transactions:Ljava/util/ArrayList;
   4:   dload_1
   5:   invokestatic    #24; //Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
   8:   invokevirtual   #25; //Method java/util/ArrayList.add:(Ljava/lang/Object;)Z
   11:  pop
   12:  return
   line 186: 0
   line 187: 12

This does not seem to match with the description of block coverage in the Emma Faq, which suggests that a block is a sequence of instructions without a jump. Am I going wrong some where?

  • Try coding multiple conditions in a single line. I don't think Emma handles that case right, because using only line numbers, it can't distinguish the conditions. This is one of the many problems of using a byte code instrumenter.
    – Ira Baxter
    Jan 27, 2014 at 10:11

1 Answer 1


Your observation is correct. According to Emma, a block is defined as a "sequence of byte code instructions without a jump".

This jump, however, can be caused by a byte code instruction throwing an exception. As most byte code instructions may throw exceptions, the number of blocks is very close to the number of byte code instructions.

This definition does make sense on a very low level, but it runs counter intuitive to developers expectations. As developer I associate the term "block" with { and }.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.