If you stick to the assumption that the Java virtual machine is
equivalent to the Java language, I can certainly see why it .class
might seem like a hack. Initially, that was true, but with every post
1.1 Java release, the JVM and the Java language drift further apart.
The JVM isn't moving. A few optional class/field/method attributes
are added here or there, but the bytecode and operation of the JVM
aren't changing. That leaves it up to the compiler writers to find ways to implement
new Java features on the existing JVM structure.
There's no Java bytecode to load a Class object directly, so the
compiler has to find a way to implement it. There's no concept of
inner classes, dynamic proxies, or assertions, leaving it up to the
compiler to fend for itself. (the JVM does play some minor role in
configuring assertion enable/disable, but that's really outside of the
JVM specification)
Looking forward to 1.5, metadata, generics and autoboxing and
enums are all a combination of the compiler and the Java libraries.
There's really nothing new for the JVM. I don't
One person's hack is another person's implmentation detail.
Since there is very good reason to not keep the JVM view of the world
in sync with the Java language view of the world, Java language
implementation in the JVM is going to get more and more interesting
implementation details.
I think a strong understanding how the Java language maps onto the
Java virtual machine is critical for senior level programmer
types. You want to live in the Java abstraction, but to truly
understand it you really have to get to the level below it. That is
really the motivation for the Java Internals talk I'm giving at the
Dallas Lonestar
Software Symposium next week. I'm more than a bit biased, but if
you are going to conference then take a look at that session. If you
have never looked beneath the hood, I promise you'll find the session
invaluable.