Java class file verification

John Bergin john.bergin at
Thu Jan 15 13:12:19 UTC 2015

Hi Andrew. I'm glad to hear you also have a similar
interpretation of the spec. And it does make sense
like you said that the JVM should not punish Java
class files that have invalid start_pc values potentially
due to instrumentation which is commonly done.

Thanks again for you response.

Kind regards,

On 15/01/15 12:29, Andrew Dinn wrote:
> On 14/01/15 23:01, John Bergin wrote:
>> To me this means the start_pc value must be the index of an opcode --
>> the opcode's starting code-array offset only, and not an interval for
>> the size of the opcode.
>> But maybe I am interpreting the specification incorrectly.
> That's how I read it i.e. a start pc index into the middle of a
> multibyte bytecode instruction sequence (i.e. which address a bytecode
> operand rather than the bytecode operator itself) is not valid according
> to the spec.
> Your summary above omits the extra requirement that the end pc index is
> likewise constrained modulo the one special case that it can be the
> first index beyond the end of the array.
> However, I'll note that my experience over the last 6 years with Byteman
> is that quite a few classfile transformer programs (both offline and
> online) fail to update these indexes when they rewrite bytecode,
> frequently leaving indices addressing instructuon operands ... and,
> clearly, these programs were not punished for it by the JVM class file
> checking routines or else they would have had to correct the omission.
> That's been my experience on JDK5/6/7. I have not seen examples when
> running on 8 but I don't believe it is any different.
> regards,
> Andrew Dinn
> -----------

More information about the discuss mailing list