Does Emma provide true block coverage?

Question

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

COVERAGE SUMMARY FOR SOURCE FILE [BankAccount.java]

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

  COVERAGE BREAKDOWN BY CLASS AND METHOD

                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();
  Code:
   Stack=2, Locals=1, Args_size=1
   0: aload_0
   1: getfield  #8; //Field balance:D
   4: dreturn
  LineNumberTable: 
   line 99: 0

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

public void addTransaction(double amount)
{
     this.transactions.add(amount);
}

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

public void addTransaction(double);
  Code:
   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
  LineNumberTable:
   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?

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 }.