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."

Comments

Take Java seriously

[rexguo]

Before those who go on to dismiss Java for various reasons (no matter how ignorant they are), take a look at the presentation given by Google at this year's JavaZone conference on how Google is using Java internally at extreme scales. Among them are AdWords and GMail.

Re:Take Java seriously

[AKAImBatman]

The reasons to use Java on the server are quite simple. The combination of factors that attracted developers to Java in the first place make them want to use it on the server. Those factors are:

1. Cross-platform capability - Many companies still prefer to deploy applications on large Sun, IBM, or Linux (name your brand) servers. However, these companies would also like to give their developers Windows desktops so they can interact with the rest of the company. (Who most likely uses MS Office/Outlook.) As long as you avoid explicit path names, it is quite easy (and common!) to develop on a Windows machines but deploy on a Unix or Unix-like machine.

2. Automatic Memory Management - So your server is running along, and suddenly someone generates an unexpected error. In Java you can sleep soundly because even the worst programmer would have a hard time doing anything to completely take down the application. If you use a language that allows direct memory management, you have a good chance of that new guy coding a General Protection Fault/Segfault. The result is that your entire system coredumps when you least expect it.

3. Security - While Java is able to control the Security of the ENTIRE JVM through its security framework, most companies are happy with the lack of buffer overruns, code injection techniques, and other common attacks. That's not to say that a poor programmer can't put a security hole in the application wide enough to drive a Mack truck through, but at least you can rely on the underlying system not to betray you.

4. Flexibility - The Java server side frameworks are exceedingly flexible in their designs. For example, the servlet framework allows you to plug in your own custom server page technology. I have seen many a programmer (including myself) implement something like Reports by simply linking the ".rpt" extension to a custom servlet. The servlet then loads the requested configuration file and executes it. Very nice.

Another example is servlet filters. Need a security framework added in a hurry? Just add a filter servlet! It will execute before the rest of the code, allowing you to check the variables and security permissions to ensure that the client isn't trying any funny business.

5. API - When Java was first introduced, it absolutely creamed all the competing languages in the richness of its bundled API. As time has worn on, this has changed. However, Java still enjoys a sizable lead over even C/C++ with features such as Type IV (tested cross-platform, pure Java) JDBC database drivers. Unlike ODBC, many of these drivers have been tuned for excellent performance. Similarly, there are free APIs for handling Office Documents, PDF Creation/Editing, SOAP/XML-RPC communications, Object-Relational mapping, Image Management/Creation/Editing, CORBA, XML Databases, XSL-T, etc. While these APIs are all available for C/C++, there are significant cross-platform issues with many of them, as well as a lack of common "pluggable" APIs that allow for one API to many implementations.

Other languages have a hit/miss score with these sorts of features, often not providing these features, providing only a small subset, or only being available in an expensive commercial package.

6. Dynamic Loading - While C/C++ can manage dynamic loading of shared objects, it's a very difficult thing to implement. Java does it out of the box, with a full reflection API and interface support, thus allowing such wonderful code as Beans, Servlets, Pluggable Drivers, self-organizing code, and a host of other features that other systems can't compete with.

(If you don't believe me, try adding support for a feature in PHP sometime. "It's so simple! Just install the SO and recompile PHP!" Meh.)

7. Performance - This may sound like an odd thing to say, but the performance of Java is a key selling feature. Java server applications may execute more slowly than one written in C/C++ (just as C/C++ may execute more slowly than

Re:Take Java seriously

[TheRaven64]

I would refer you to some research done around a decade ago, which involved running a MIPS emulator on a MIPS machine. The emulator was doing dynamic optimisation, and got around a 10% speed increase over the same code running directly on the hardware.

A Java VM does some things that are simply not possible with C. To inline a C function, you need the source for both - this leads to some really ugly things like putting simple functions in headers, which should be reserved for interface definitions, not implementation details. The Java VM will inline functions on the fly. This can potentially give a huge performance boost - I got almost a 50% speed increase on some C code I was recently writing by shuffling things around to allow the compiler to inline some common functions.

The other advantage of higher-level languages is that they provide more semantic information to the optimiser. Consider the trivial example of autovectorisation. In C, if you want to do an operation on a vector, you will usually iterate over every element and perform the operation. The compiler then needs to check that there are no dependencies between loop iterations, which can be non-trivial. In a language like FORTRAN or Smalltalk, you can simply perform an operation on a vector type. The compiler then just needs to check if the operation you are trying to perform corresponds to one or more vector unit instructions, and substitute these in to your code. This is much easier to do.

C is a fairly easy language to write optimised code in for any CPU up to and including a 386. For anything more modern, you will find yourself fighting a language which is simply not designed to deal with parallelism - and compiler writers find themselves fighting even harder.