Hi all, At ECLM the other week, Alessio and I agreed to start working on a requirements analysis regarding the output required for the type-checking bytecode verifier. We know Mark wants to create an intermediate level code representation to address any issues that may arise. However, we want to assess requirements first and come up with a solution after that. That solution may or may not depend on such an intermediate representation. For now, we'd like to leave that undecided. So, what I learned that the type-checking bytecode verifier wants is that it can verify the state of the stack and of the locals for all bytecode instructions. In order to do so, it needs: 1. The "initial state" of stack and locals at the external entry points of a function (ie notably the start and any exception handlers) 2. Optional "state modifications" when locals start being used or when the flow from one instruction to another is broken (such as in case of (conditional) jumps) Apart from a different class file version number and an attribute to store this information in, that's it. More doesn't the verifier want to know. Is it your understanding as well that this is all that is required? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.