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."
No cold hard cash or equivalent for "cracking the verifier?"
I guess it could lead to more pay in some cases.
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 follow for days, months and years afterwards.
I'm not pretending that this would cure the world of buggy ms software, but it can't hurt, can it? They should be doing it with vista right now.
Craig
I am a bit tired of the aproach "Let's just see if it works!". That aproach works well on an old car, but it does not work well on the linch-pin of one of the most important technologies today!
Why not do what it takes: Prove that it will work, and prove that it cannot be broken!
Could Java/SUN afford a major flaw in the Java sandbox/class loader...? I think not!
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
Also, the language is easily picked up, simple to write and the API's are quite sane compared to a lot of other languages.
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.
It depends on what you mean by "slow." If you're talking about long running processes, then no, it isn't slow at all; in fact, it is quite fast. If you're talking about short-running processes, then the JVM startup time overshadows any commendable performance.
Ruby is much, much slower than Java when it comes to raw computational power, but I still use it when I'm writing non-server process apps, simply because it starts up so much more quickly.
My main complaint about Java, though, is that it is a memory hog. If I recall correctly, MacOS's answer to Java's startup lag is to pre-load a VM, which makes executing Java apps quite quick. However, the last thing I want is Java running in the background when I'm not using it, hogging my system resources.
The memory and startup issue is why I think you don't see a whole lot of Java apps, and when you do see them, they're far less popular (on average) than native apps -- even native apps that are less capable than the Java version. The obvious exception to this (that proves the rule) is Eclipse, which has won enormous mindshare even among non-Java developers.
--- SER
What I don't understand is exactly what advantage is Java providing on the server-side. Do you really need cross-platform bytecode at that level?
Certainly. Being cross-platform is always a big plus, didn't you read the Slashdot article about the large British retail chain that switched over all their POS terminals to Linux? They could do that thanks to Java. Of course, it is not COMPLETE platform independence, you are of course tied to the Java platform. You gain hardware and OS independence though, good enough for most.
As a language Java is certainly not easier to use than the higher-level languages like PHP, Perl, Ruby, etc. It's very verbose and complicated (relatively speaking). I can understand using scripting languages, it's Java that doesn't make any sense.
I mean really, is it just because Java provides a lot of easy to use API's?
Speaking from my own experience, the number one advantage Java has is that it is maintainable. The strict typing and verbose exception handling is annoying if you just want to get something done quick. However, if you have a large team of programmers (of varying skill levels) and a large code base, you start to appreciate that the language tries to force good programming practice, and that a lot of bugs are caught not at runtime but at compile time (or even as you are typing if you use a tool like Eclipse). This is a lot more important than raw performance, since a lot more time is spent on maintaining a product than building it in the first place (90% is number often cited).
Someone on Slashdot in a post way back said it drove him mad in Java to always have to declare "what he was going to do" in advance, and what he wanted to do if something went wrong -
"Now I am going to open a connection"
"Now I'm opening a connection"
"If error type one happens then..."
"If error type two happens then..."
and claimed that we don't do that in real life. Someone else pointed out a counter example - in the military and other large teams that does critical work they DO work like that. If a large ship is approaching a harbour, they don't just run in and hope nothing is in the way,
they ask
"Harbour, permission to dock?"
"Deck team, all clear?"
"Engine team, all clear?"
"Ok, commencing docking..."
Of course, there is still a lot of garbage written in java, I just think it is somewhat simpler to spot in advance. I.e. someone is catching general Exceptions and ignoring them all over the place, is using a lot of static methods, etc...
Being bitter is drinking poison and hoping someone else will die
On a server-side environment, the "massive overhead involved with installing the runtime everywhere" is pretty much a non-issue. It's like complaining that you can't write Ruby or Perl apps because Ruby and Perl aren't installed on every client machine. In the end, when you are doing these kind of applications, the only thing the client needs is a browsers and an internet connection.
If you're doing stand-along applications that need to be installed locally on a client then perhaps you have a point. On the other hand, it is easy enough to package the correct version of the JRE on your install CD and have you application use that.
The company I works for uses Java for basically one reason: J2EE. Fast enterprise applications that are developed very, very quickly and are delivered as HTML pages to the client's browser. JVM startup times are a non-issue since the application server is pretty much running all of the time. Memory is a non-issue since we know how much memory is available on the server and plan accordingly. It's not like someone is going to startup MS Office on the the back-up Sun server and start complaining about lack of resources. I'm guess we could do the same thing with C or Perl or some other CGI system, but Java has proven itself to be a stable development environment that is fairly safe (in terms of memory, security, and tolerance towards "newbie" programmers) so why change?
Personally, I want to experiment with Ruby on Rails to try and get a hands-on comparison since I've heard nothing but good things about both the language and the enterprise evironment. But, there is a bit of inertia with any development. Right now, at least, it is much easier to hire J2EE developers than Ruby on Rails developers.
Waltz, nymph, for quick jigs vex Bud.
What happens when your hardware changes and that nice Java Runtime Environment isn't available for your new hardware?
while true; do eject; eject -t; done
I will try and summarize your main point. You don't like Java because the JVM for each platform can be upwards of 100MB and you don't like garbage collection over handling the cleanup of objects yourself in code.
To the first point. Do you develop software? I do and it sucks big time if you code for Windows. You currently have to worry about DLL issues and what service packs are installed and what the heck Microsoft is going to throw at you in the next "hotfix". You say that you want to code for Linux? Well do you want to make an RPM, shell script, YAST, Yum or Apt get? What version of libraries are they running? Do you want to include "everything" just in case they don't have the correct libraries you think they will need? Or do you just want to make the user go through something like "RPM Hell". Do you want to target a Macintosh? Well good luck there! What platform are you going for? OSX on X86 or OSX on PPC or are you going to produce "fat" binaries? I find it a bit easier to just have the user install a 1.4 JVM for their platform.
Now Java is by no means the silver bullet of programming, you still have some small library issues, however getting an application to run on multiple versions of Windows, Linux, Solaris, OSX, and just about everything else is very easy compared to what else is out there. I will actually say that there is no reason for Java in one core situation. That is if the whole world runs the latest patched version of Windows. Then, and only then does Java loose one of it's major strengths. However, as you mentioned in your post that place doesn't exist, or if a company tries to inforce those strick standards they are "broken" within a couple of years.
Now as far as garbage collection. I somewhat agree with your point, but I would say that I have created close to a million objects in a few seconds and distroyed them (let garbage collection run) and the program has run fine. I will say that it uses up a rather large amount of memory, but that wasn't your complaint and in my case it didn't matter.
I do wish that Java would do a couple of things better. One is to provide a good tool for JSF development (WYSIWYG) Studio Creator beta does not cut it! It needs some serious work. MyEclipse also doesn't quite cut it. I would also like to see AJAX support in JSF. I also wish that they would simplify developing web services a bit and perhaps their security layout as well. Much later down my list would be to address any performance/memory issues. I guess I would also wish for one more thing, and that would be to make EJB 3 very similar to hibernate (I believe that this is the case).
The more I learn about science, the more my faith in God increases.
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."
I'd like to add "type safety" in there, but then I'm a programming language geek at the best of times.
AC misunderstands the issue. The class verifier checks that that a program is unable to break out of the "sandbox" infect the system. This is not related to DRM. Hate DRM all you want, but at least RTFA before you post.
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.
While this is theoretically true for byte code, in Java isn't not something you can depend on. I write Java code for a living, and our test team still has to test our product on every platform and OS we claim support for. Even the same version of the same vendor's JVM will have little OS-specific quirks which can add up to big problems if ignored.
More importantly, "write once, run anywhere" really should be qualified as "write once, run anywhere the exact same JVM is installed and a decent script/command/launcher exists to properly start your application with all the flags, classpaths, memory management, and other configuration needed for this platform"
This may seem sorta nit-picky but I spend a great deal of my time figuring out why a certain behavior only occurs on a certain platform. Usually it's because to do anything useful, you can only abstract the underlying operating system so far. For example, the way that Windows creates and manages a file is very different than the why most Unix systems do. An application which downloads a file from the network and overwrites an existing file often needs special handling on Windows because Windows sometimes will deny access to a file (if it thinks it is in use), or not synch the descriptors when you expect it to. This isn't either Java or Window's "fault" it's just the way things work.
However, I do agree that Java is a good language and makes a lot more "sense" from an API perspective than most other languages. Writing programs in C/C++ now seems very tedious to me. All the stuff I used to worry about without thinking about (buffer sizes, memory allocation, finding functions/libraries) in C/C++ which aren't issues in Java amazes me.
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.
You sound like you are a decent programmer. However, the type of problem you describe is not exactly a standard thing: multithreaded, lots of disk IO, lots of memory used. Doing this right in Java (or any other environment) requires some knowledge about how things work. In your post you make it clear you do not have more than a rough understanding of how garbage collecting is implemented in Java or indeed the ins and outs of optimizing Java's behaviour in this respect. That's pretty essential stuff for this kind of thing.
I think the key problem with your Java implementation is not that it is written in Java but that it's design is based on some wrong assumptions about how things work in Java. For example IO quickly becomes a bottleneck, did you use the nio classes? Did you run a profiler to find out where the bottlenecks were? Maybe there's some synchronization issues? There could be a whole lot of things wrong. Optimization in Java is possible, just like in C. And just like in C it requires that you understand the technology.
I'm not suggesting you should do things in Java but merely that you should be a bit more careful to blame technology for things that may also be attributed to your lack of knowledge. It isn't Java that failed here, but you and indeed the end result is the same.
Jilles
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.