The Former Weblog of Peter Ahé

We are planning to make -target 6 the default target of javac in Mustang Beta and intend to keep this default for the final version (subject to feedback). See RFE number 6283313. Obviously, this only affects what version is generated by javac if you don't use the -target option at all. Similarly, it should be obvious that the best-practice is to use the -target option explicitly when developing on newer JDK than the target platform.

This means that javac will generate class file version 50. This version is being defined as part of JSR 202. Most importantly, the class file format will contain a new attribute called StackMapTable which is used by the new verifier. A Java™ compiler, such as javac, uses the StackMapTable to record type information that was previously inferred by the old verifier. This greatly simplifies the verifier and improves performance of byte code verification.

This should have no impact on most Java developers, however, tool vendors using byte code instrumentation for purposes like profiling and logging, should pay attention to this new attribute. When byte codes are injected into existing methods, the StackMapTable attribute becomes invalid and should be updated. However, in order to allow such tools to operate unmodified on class file version 50, the VM can (optionally) fall-back to the old verifier. However, in the long run this will not be feasible.

Also, running a faster verifier (the new one) before falling back to the slower (the old one) doesn't yield optimal performance.

I have already touched on the reasons for this change in verification but let me summarize the motivation for the new verification scheme:

• Simplicity of the scheme leads to improved reliability and robustness
• Performance improvements in byte code verification and thus class loading and start up time
• More verifier technology sharing between Java SE and Java ME benefiting both platforms

A note on terminology: this scheme is often referred to as split-verification or pre-verification. However, this terminology is confusing as the compiler doesn't verify anything, it just records the information it has (which might be corrupt). Similarly, "pre-verifier" is not a good name for a tool which can infer StackMapTable attributes for old class files. This is because the name implies that some verification have been performed. However, inferring types does not imply that they are valid or that the byte codes can be verified. Better names for a tool which infers types for StackMapTable attributes include: "stack map table inferencer", "stack map table generator", etc. Better names for the new verifier includes: "new verifier", "type checking verifier", etc. The old verifier can be called "old verifier", "type inferencing verifier", etc.

UPDATE: My colleague, Wei Tao, has written an execellent article about the new verifer