Skip to main content

Migration to the Type Checking Verifier

4 replies [Last post]
Joined: 2003-06-10

Wei Tao wrote a nice introduction to the Type Checking Verifier enabled since Mustang build 45.

I believe that there is lot of "legacy" libraries that unlikely will be recompiled and as a result woun't be able to benefit from this feature. So, it would be a good idea to have some kind of utility that will add StackMapTable attribute to the old bytecode. That will be similar to the preverifier tool used for CLDC 1.1 where this idea had been introduced in the first place.

Perhaps this utility could part of JSR 199, so other tools, such as profilers, aop and orm engines could use this API.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-10-07

ASM is a bytecode manipulation lib that will permit
in a very near future to write such tool.

PS: in my opinion in 20 lines max.

Rémi Forax

Joined: 2003-06-10

Remi, actually it is not that easy, because you'll need to inline JSR/RET opcodes. However, Craig Setera already implemented this algorithm in his ASM-based CDLC preverifier and probably we can include it into the ASM commons package.

Anyway, my point was to have such tool in a JDK toolset to help developers with migration to the new JVM.

BTW, I'm one of the ASM developers. :-)

Joined: 2005-11-20


Sun has said that it will "help" tool vendors to get their products to comply with the new bytecode verifier spec, as outlined in JRS202 and appearing soon in Mustang. But as far as I know, it hasn't yet said what form this help will take.

My own view is that if Sun could provide a tool to generate (or regenerate) the StackMapTable attributes from a classfile's bytecode, it would be extraordinarily useful. A really good use would be to "supercharge" third-party libraries (ie, acquired in binary form only) so that they too could enjoy the performance improvements of the new bytecode verifier, for minimal effort. Though I guess that there would be a minor issue with the classfiles' existing version numbers, which would also have to be "upgraded".

Which brings up this whole wretched issue of version numbers. Personally, I'm not a great fan of writing version-dependent code. Instead of triggering the new verifier behaviour based on the classfile version numbers, why didn't Sun simply decide to trigger it purely on the presence of the StackMapTable attributes?

Anyway, back to our (as yet hypothetical) StackMapTable generator tool. Not only would it make life really easy for all the vendors of code profilers, debuggers and the like, but it would be really useful for vendors of code obfuscators too. After all, it would be a great shame if their craftily reordered bytecode were to also unavoidably slow down your application under Java 1.6! So there's another incentive for Sun, if they needed it.

I do hope someone in Sun-land is listening...

Chris Clark

Joined: 2003-06-10

Chris, even if Sun isn't listening there will be alternatives...