Name: ddT132432 Date: 12/17/2001


java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

The JLS 2.0 states that debug information supporting local variables can end
either on an instruction or on the first index beyond the end of the code array.

For convenience here is the corresponding extract from the specs
---------------
start_pc, length
The given local variable must have a value at indices into the code array in
the interval [start_pc, start_pc+length], that is, between start_pc and
start_pc+length inclusive. The value of start_pc must be a valid index into the
code array of this Code attribute and must be the index of the opcode of an
instruction. Either the value of start_pc+length must be a valid index into the
code array of this Code attribute and be the index of the opcode of an
instruction, or it must be the first index beyond the end of that code array.
---------------

As a result, for local variables whose scope end at the last instruction of the
method's code, the specs are ambiguous: both a start_pc+length ending at the
last instruction and start_pc+length ending at first index beyond the end of
the code are valid.

The JDK compiler generates valid bytecode with respect to local variables but
is inconsistent in the adopted policy for local variables which end at the last
intruction of the code array. Sometimes they end on the last valid index of the
code array, sometimes they end on the first index beyond the end of the code
array. Whereas this behavior seems consistent, it's rationale is difficult to
understand.

It becomes a useability problem for programs that perform dynamic bytecode
generation (such as the dynamic proxy), or dynamic bytecode edition, which can
not depend on a particular policy for scope of variables ending at the code
array end: there is no single canonical bytecode form of same exact java code
(not taking into account optimizations.

In my case, I was trying to write an automated test for a dynamic bytecode
generator tool that was taking the output of the JDK compiler as the expected
outcome. I had to drop this idea with code incorporating debugging information
because of the inconsistent scope of local variables ending at the code array
end.

If there is no good reason for accepting both variable scopes, I would suggest
to consistently choose one for all local variables. Always choosing the first
index beyond the end of the code array.

I hope this feedback can help the increasing number of people taking advantage
of the powers of Java dynamic code loading and dynamic code edition/generation
(Review ID: 137196)
======================================================================