Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Help crack the Java 1.6 Classfile Verifier 276

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."
This discussion has been archived. No new comments can be posted.

Help crack the Java 1.6 Classfile Verifier

Comments Filter:
  • Only an Attaboy? (Score:2, Insightful)

    by elgee ( 308600 )
    No cold hard cash or equivalent for "cracking the verifier?"

    I guess it could lead to more pay in some cases.

  • Take Java seriously (Score:4, Interesting)

    by rexguo ( 555504 ) on Monday October 31, 2005 @09:49AM (#13914482) Homepage

    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.

    • That link doesn't work.

      In any case, the tools that impress me most are those that scale up, but scale down as well too. Google has the money and the brains to make anything work, more or less. What's more impressive to me is technology that lets Joe Schmoe get things up and running easily, and then still scale up reasonably well. I wrote a bit about it here: tml []. Java scores just a bit better on this front than C and C++, because of the big standard li
      • 300+ million J2ME-capable phones out there shows that Java is indeed downward-scalable. Just today nVidia announced a tight-integration of OpenGL ES API with its GPUs for mobile phones.
        • Hi,

          A few comments:

          "300+ million J2ME capable phones" shows that Sun has some savvy marketing people more than anything:-)

          I do have some experience with j2me - I wrote Hecl [] for it, and found that it's a fun environment to work with, modulo the inconsistencies between phone models. It's really different from 'normal' Java though - you have to do a lot of things differently, and you have a very limited version of the standard library.

          But in any case, my point was not really with regards to the embedded system
  • I'm not sure how the MS beta process works, but I get the impression that it's not just a straightforward download but you need to sign up or something (passport?).

    I wonder what would happen if they junked the whole exclusive beta thing (which might get some of the more privacy-concerned, tech-savvy people on board? dunno - just a guess), and then actively encourage people to try and break the security? Surely that would produce better results than product x coming out, and then massive security problems fo
    • MS Anti spyware beta (Score:2, Informative)

      by Anonymous Coward
      • 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 I
  • More on Gilad Bracha (Score:5, Informative)

    by tcopeland ( 32225 ) * <> on Monday October 31, 2005 @10:02AM (#13914571) Homepage
    If his name doesn't ring a bell, he's a Java guru who works for Sun and wrote the 2nd and 3rd editions of the Java Language Spec. A bunch of his papers are listed here [].

    It's a relief that JDK 1.6 won't include any language changes (as far as I know?). Updating various parsers and whatnot to work with all the JDK 1.5 language changes was a big job, although some of the new features certainly are quite handy [].
    • by Naikrovek ( 667 )
      I believe Java 6 introduces, which provides several convenience methods when using the console, but other than that I don't know of any language changes.
      • Cool, yup, right on, I should have said "syntax changes", like new keywords or whatever. At least, I don't think any have been introduced.

        On the other hand, most folks I know are still on JDK 1.4, so I wonder how many people will move to 1.6? I even still get PMD [] parsing bug reports and whatnot for JDK 1.3...
      • That's an API change, not a language change. Language changes would be concerned with the syntax or semantics of Java constructs, not with something inside a package.
      • is just a package. It doesn't require the compiler to handle anything differently, hence not a language change.
    • Java 1.5 (Score:3, Interesting)

      Java 1.5 introduced the two things that make me willing to consider Java as a practical language for real work (as opposed to a "safe to let untrained programmers run rampant, too bad about the 10000k LoC required to do anything" language). Those two things are collections and generics.

      I was forced to use Java 1.2 some time ago, and found it a horrific experience with my background in dynamic languages. Since then, I've learned C++ and got used to the pluses and minuses of static languages (both in the sens
  • by jfengel ( 409917 ) on Monday October 31, 2005 @10:40AM (#13914809) Homepage Journal
    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.
  • by awol ( 98751 ) on Monday October 31, 2005 @11:37AM (#13915254) Journal
    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.
    • I believe that there is a concurrent garbage collector in Sun's JVM that while not as effecient over-all but runs continously preventing pauses and bubbles associated with traditional garbage collectors.

      I'm my Java in a Nutshell 4th Edition (p. 246) one of the java(the interpreter) arguments is:

      Uses incremental garbage collection. In this mode the garbage collector eun continuously in the background, and a running program is rarely if ever, subject to noticeable pauses while gharbage collectio
    • The only thing that gives you "Raw control over the execution path" is assembly language.

      Your c/c++ compiler is going to be making optimisations and tweaks to your code such that you can't exactly predict the way it will be working unless you know the inner workings of it as intimately as the people who work on it..

      Garbage collectors have advanced in leaps and bounds since they were first introduced, gone are the days of the painfully naive mark-and-sweep algorithms. In some cases generational GC can be

  • Pardon my ignorance, but isn't this a violation of the anti cracking clauses of the DCMA?

To write good code is a worthy challenge, and a source of civilized delight. -- stolen and paraphrased from William Safire