Slashdot Mirror
Help crack the Java 1.6 Classfile Verifier
pdoubleya writes "As part of the development of Mustang (Java 1.6), Sun is developing a new, smaller and faster classfile verifier which they want your help in trying to break. As Sun VP Graham Hamilton puts it in his blog entry, "As part of Mustang we will be delivering a whole new classfile verifier implementation based on an entirely new verification approach. The classfile verifier is the very heart of the whole Java sandbox model, so replacing both the implementation and the basic verification model is a Really Big Deal.... The new verifier is faster and smaller than the classic verifier, but at the same time it doesn't have the ten years of reassuring shakedown history that we have with the classic verifier." You can read about the new verifier on Gilad Bracha's blog, and join the new Crack the Verifier initiative to if you can break it. Read all about the Crack the Verifier - Challenge."
I'm sorry... but what??? I guess there is no sense arguing this because I'm already getting bizarre answers.
Cross-platform byte code enables you to deploy the same application on your PC or Mac workstation and have it function exactly the same as on a 64-processor Ultra server. It also means your application is "future-proof". Deploy it now on a 32-bits machine, later on a 64-bits machine without recompiling AND run it at speeds comparable to native code.
My question is specifically about server-side Java. We all know Java failed on the desktop. "Future-proof"? That doesn't make any sense, most likely at some point that code will need to be updated or changed or something requiring a recompile. New API's come and go. Because it's on a static server that's no big deal. No big deal for a compiled language either. Do you expect to just compile your application once and never touch it again? No bugs? No updates for future technology? "Future-proof"? There is no such thing.
Believe it or not I can write 64-bit native applications as well.
Also, the language is easily picked up, simple to write and the API's are quite sane compared to a lot of other languages.
Now this was what my question was about. However, like I said, there is no reason you couldn't have a nice API in a native language.
The ratio of people to cake is too big
Java 1.5 introduced the two things that make me willing to consider Java as a practical language for real work. Those two things are collections and generics.
Hah! Java generics are laughable, especially if you ever used C++ templates. Java generics are nothing more than syntactic sugar for type-casts, except type-casts are performed at runtime whereas generics are a compile time thing. The consequence of this is that, at runtime, an ArrrayList of integers is indistinguishable from an ArrayList of strings (they'd both show up as an ArrayList of objects).