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."
Begin able to show proof that you cracked, or helped crack, the Java verifier would be a excellent addon to your resume.
I don't think Java is as slow as you think it is. It is very fast lately, and it is actually giving C a run for its money in some respects. It is *definitely* not the slug everyone thinks it is.
They're probably using Java because its not as slow as its reputation, and its becoming a commodity language in the enterprise lately. My corporate overlords have dictated the use of Java (IBMs WebSphere) for all current and future enterprise development, and most of us developers couldn't be happier. Everywhere I do contracting work for lately also uses Java. Java Is A Great Language(TM), especially since 5.0.
There used to be a time when I believed that all techies had agreed that Java was slow and bloated, but once I stopped reading Slashdot comments so religiously I began to see some truth. It isn't slow, it isn't bloated, and it isn't something I expect the Slashdot crowd (that I'm a founding member of) to understand anytime soon.
That's almost what I mean except everyone I know uses ad-aware and spybot S&D, so bugs in MS anti-spyware don't really have the same impact. Also - I can't see anywhere on that page inviting people to break the software, and I can't what security systems the software has that can be "broken into". I don't have lots of time at the moment, so I might have missed something.
The most damaging problems I see and hear about are related to Windows and Internet Explorer. An open beta of those (I know about the IE7 beta) with encouraged breakage and bug-reporting could do some good. I wouldn't be surprised if you're breaking some license agreement or other (nope haven't read it - just guessing) by trying to trick IE7 or Vista into buffer overflows or whatever.
Craig
the onus isn't on the community, the onus is on the developers and their QA team. This is just an attempt to get a few more eyeballs on the verifier in case something falls through. There's nothing wrong with that.
Also it is an opportunity for someone to get recognition for breaking a new peice of software.
It is important to get extra scrutiny on newly designed peices of software, for it is the new designs that usually break in the least expected ways.
Another nice thing about the new classfile specification is that it's going to make certain new kinds of optimization possible. The more you can prove about what's on the stack at any given point, the more you can inline.
Not only does inlining eliminate method call overhead, but it allows you to re-run the peephole optimizer, which can eliminate range checks, reduce redudant type checks, etc.
The ultimate performance promise of Java is that it can do optimization very, very late in the process. Native libraries are basically black boxes in C/C++, and it's very hard to do that sort of inlining because most of the type information has been lost. Java may, someday, with sufficient ingenuity, rival or even beat C++ in performance, and it already does in certain limited areas.
Of course C# has all of the same advantages, and even though it's more recent there are some areas where its performance beats Java. I'd love to see all the Microsoft reasearchers vs. all the Sun researchers coming up with increasingly brilliant ways to take advantage of the late binding to turn a performance hindrance into a benefit.
Why not do what it takes: Prove that it will work, and prove that it cannot be broken!
;)
Did you just walk out of an undergrad Computer Science class?
Popping in pre/postconditions and doing line-by-line proofs doesn't cut it for an application of this complexity. While that is an important part of a real process, it doesn't guarentee coverage. You still have to make assumptions about the environment, which is the gotcha. Testing and QA is all about the assumptions you make and the boundaries you set. With a complex application the number of factors grows so large, that you cannot have the resources to cover every possible test. You can grab the most common stuff, but really need to dump it to the community to get the real 'out of the box' thinking hitting it.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
Look, I wish people who keep banging on about how Java is nearly as fast as C would get their heads out of their asses and realise that the biggest defect in Java is not raw execution speed but the "business processing" holiday that the system takes every "completely unpredictible once in a while". If I have a throughput capacity system, I can control the rate of throughput in a number of ways (eg selling less than my total capacity and then throttling at times of peak use) but when the system goes and does something like a garbage collection and the whole pipe goes "fnark" for a some seconds I am quite pissed since my users who want the service level in their SLA aren't getting it.
Predictability and execution control are why I use C (and to a lesser extent c++) not Java. That cannot change for languages that give me no control over the raw execution path.
"The first thing to do when you find yourself in a hole is stop digging."
You can say the same thing about the parent comment about java memory management. The J2ME for mobilephones does indead free the memory. Funny how java for embedded systems uses the same strategy eh? J2ME works with very little memory. A Nokia 3410 only has 64 KB memory for the java games.
The parent post was obviously talking about ordinary client applications running on PC under either Windows, Linux, Mac or something simelar.
On such a system, malloc cannot map directly to the OS API, because the OS will only allocate full pages at a time. So if you want 40 bytes of memory, the OS would give you 1 KB (or whatever the page size is).
This also means that if you allocate 2x40 bytes, then free the first 40 bytes block, malloc can not free the page. It is simply not possible, since it would have to free the whole page.
Some J2ME implementations can defragment the memory in this situation, to be able to release memory back to the OS. That is impossible with a C program, where direct pointers to memory is allowed.
For large blocks you can of course go directly to the OS.
I'd also add that the pool of Java developers is pretty substantial, making it easier to staff a project than say PHP or Ruby.