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."Ads_xl=0;Ads_yl=0;Ads_xp='';Ads_yp='';Ads_xp1='';Ads_yp1='';Ads_par='';Ads_cnturl='';Ads_prf='page=article';Ads_channels='RON_P6_IMU';Ads_wrd='java,sun,programming,it';Ads_kid=0;Ads_bid=0;Ads_sec=0; Help crack the Java 1.6 Classfile Verifier Log in/Create an Account | Top | 231 comments | Search Discussion Display Options Threshold: -1: 231 comments 0: 223 comments 1: 195 comments 2: 148 comments 3: 41 comments 4: 14 comments 5: 8 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. Great Editing, Hemos! (Score:1, Funny) by repruhsent (672799) on Monday October 31, @08:43AM (#13914450) (http://nyud.info/ | Last Journal: Sunday October 23, @11:11AM) and join the new Crack the Verifier initiative to if you can break it.I'm going to if I can break it right now! [ Reply to This Only an Attaboy? (Score:2, Insightful) by elgee (308600) on Monday October 31, @08:48AM (#13914474) No cold hard cash or equivalent for "cracking the verifier?"I guess it could lead to more pay in some cases. [ Reply to ThisRe:Only an Attaboy? by shiznatix (Score:3) Monday October 31, @08:55AMRe:Only an Attaboy? by elgee (Score:1) Monday October 31, @09:36AM1 reply beneath your current threshold.Re:Only an Attaboy? by nadadogg (Score:2) Monday October 31, @02:01PM1 reply beneath your current threshold. Take Java seriously (Score:4, Interesting) by rexguo (555504) on Monday October 31, @08:49AM (#13914482) (http://www.waterlogic.com.sg/) 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 [javalobby.org]. Among them are AdWords and GMail. [ Reply to ThisRe:Take Java seriously by Cthefuture (Score:1) Monday October 31, @09:05AM Re:Take Java seriously (Score:4, Insightful) by Naikrovek (667) <jjohnson AT psg DOT com> on Monday October 31, @09:17AM (#13914650) (http://naikrovek.org/) 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. [ Reply to This | ParentRe:Take Java seriously by Anonymous Coward (Score:3) Monday October 31, @09:29AMRe:Take Java seriously by bbn (Score:3) Monday October 31, @09:48AMRe:Take Java seriously by jaywee (Score:3) Monday October 31, @09:55AMRe:Take Java seriously by egeorge (Score:1) Monday October 31, @01:50PMRe:Take Java seriously by (startx) (Score:2) Monday October 31, @02:12PM Re:Take Java seriously (Score:4, Insightful) by bbn (172659) on Monday October 31, @12:44PM (#13916396) 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. [ Reply to This | Parent2 replies beneath your current threshold.Re:Take Java seriously by Politburo (Score:2) Monday October 31, @11:20AMRe:Take Java seriously by MemoryDragon (Score:2) Monday October 31, @11:53AM Re:Take Java seriously (Score:5, Informative) by swillden (191260) <shawn-sd@willden.org> on Monday October 31, @12:00PM (#13915999) Java will ALWAYS keep the 64MB heap. It will NEVER shrink it. Who cares? This is completely irrelevant, as long as the JVM marks the pages it's not using as discardable, which modern JVMs on modern OSes do. You have to remember that all memory is virtual. I can allocate a 1GB array, but as long as I never actually touch the pages (making them "dirty"), no storage, whether RAM or disk, is ever used. When the JVM allocates its 64MB, that virtual memory is initially all "clean" and therefore consumes no RAM. As it's used, it gets dirtied and physical RAM gets mapped to it... but when a garbage allocation occurs, both the Sun and IBM JVMs mark the now-unused pages as clean, allowing the OS to reuse them at will. Effectively, they no longer consume any space. Even if the JVMs didn't mark the pages as clean, the impact of the JVM holding onto the 64MB wouldn't be that significant. The allocated, dirtied but now-unused memory will simply get swapped out to disk, allowing those pages of RAM to be used by other applications. With a decent OS, it really doesn't matter if an app holds onto some memory that it's not using, especially if it has the decency to tell the OS that it's not actually using it. That said, there is a "problem" here, it's just not the one you're pointing out. The problem, if you want to call it that, arises from the generational, copying, compacting garbage collector used by modern VMs. Now, don't get me wrong, this GC is very cool. It's significantly more efficient than typical malloc/free memory management, *and* it eliminates some major classes of memory leaks (programmers can still leak memory with GC, but it's harder). Without getting into the details, although GC is safer and more efficient in terms of CPU cycles, and although on average it doesn't use a great deal more memory than manual allocation would use (particularly since many performance-sensitive manual allocation apps end up managing their own memory pools in order to avoid the run-time cost of malloc() and free()), GC does tend to increase the number of memory pages that get touched over time. Why? Two reasons. First, suppose the application allocates a small chunk of memory, uses it, frees it, allocates another small chunk (about the same size), and then uses and frees it. Most malloc()/free() implementations will tend to return the same chunk of memory for both allocations. Repeating the process a thousand times (which isn't all that uncommon) will probably only dirty a single page of memory. With the sort of garbage collector used by current JVMs, every one of those allocations will return a different chunk of memory, and many pages will therefore be dirtied. In terms of CPU cycles, GC wins big, because, rather than a thousand small frees, there is one big one. And allocation is up to two orders of magnitude faster. It may sound like the GC approach is going to use a lot more memory, on average, but it's not that bad because of the tendency of malloc/free-managed heaps to become fragmented. On average, GC implementations don't have many more pages in use than malloc/free implementations, and may actually have less, but the GC allocators tend to "roam" across the pages. Second, the "copying" nature of the GC. The main thing that makes generational, copying GC-based memory management so fast it that it never has to deal with fragmentation. To describe it in an oversimplified way: Every now and then, the GC relocates all of the in-use objects into a nice, compact block. That makes allocation fast, and tends to reduce the number of pages in active use, but it increases the number of pages that get dirtied and therefore require actual RAM to be provided by the OS. The copying also has a cost in CPU cycles, but it's small relative to the cost of managing and searching free lists, which is what malloc/free implementations have to do. Theoretically, as the GC copies objects and marks the pages where they used to live as discardable, the OS coulRead the rest of this comment... [ Reply to This | ParentRe:Take Java seriously by Hard_Code (Score:3) Monday October 31, @01:21PMRe:Take Java seriously by hr raattgift (Score:1) Monday October 31, @02:36PMRe:Take Java seriously (nope) by maraist (Score:2) Monday October 31, @07:53PM1 reply beneath your current threshold.MaxHeapFreeRatio by rossjudson (Score:2) Monday October 31, @12:06PMRe:Take Java seriously by DarkTempes (Score:1) Monday October 31, @09:41AMRe:Take Java seriously by srussell (Score:2) Monday October 31, @09:47AM Re:Take Java seriously (Score:5, Funny) by jiushao (898575) on Monday October 31, @10:21AM (#13915112) 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. Yeah, it is a shame, if only Sun would do something like writing a new faster classfile verifier. [ Reply to This | ParentRe:Take Java seriously by 21mhz (Score:3) Monday October 31, @11:16AMRe:Take Java seriously by Jesus_666 (Score:3) Monday October 31, @04:10PMRe:Take Java seriously by ultranova (Score:2) Monday October 31, @12:00PMRe:Take Java seriously by MenTaLguY (Score:2) Monday October 31, @12:13PMRe:Take Java seriously by Kent Recal (Score:2) Monday October 31, @12:39PMRe:Take Java seriously by kaffiene (Score:2) Monday October 31, @03:26PMRe:Take Java seriously by tigeba (Score:1) Monday October 31, @05:13PMRe:Take Java seriously by Cthefuture (Score:1) Monday October 31, @09:55AMRe:Take Java seriously by felix_lucian (Score:1) Monday October 31, @10:06AM1 reply beneath your current threshold.Re:Take Java seriously by SnapShot (Score:2) Monday October 31, @10:22AMRe:Take Java seriously by FatherOfONe (Score:3) Monday October 31, @10:37AMRe:Take Java seriously by MemoryDragon (Score:2) Monday October 31, @11:58AM1 reply beneath your current threshold.Re:Take Java seriously by ultranova (Score:2) Monday October 31, @12:27PM1 reply beneath your current threshold. Re:Take Java seriously (Score:4, Interesting) by justsomebody (525308) on Monday October 31, @10:03AM (#13914985) (Last Journal: Thursday January 15, @06:55PM) While I agree with you on all accounts I can't help but comment you.Both Java and .Net have the same problem. Sloppy memory. As long as you don't use a lot of atomic memory blocks with higher load on machine where it runs, everything is ok and just as you said it. I tested both on the same tests and always fallen in the same problem. No direct memory control, GC waited until it was too late, and everything started to crawl. GC somehow avoids doing work if software is taking most of the CPU, it is also the same reason why Java beats C or C++ on speed tests (Every speed test where they try to proove that Java or .Net is faster than C or C++) uses allocation and freeing of memory in some loop. And while both C and C++ actualy do free memory, Java and .Net just mark that as garbage and wait for GC to clean up the mess which doesn't happen if load is too high. Just take any test where Java was faster and test loop to make 2^32 instead of 1000 or 10000 calls. This way you will actualy use more memory than you actualy have with allocations.p.s. Not bashing, just saying results of my testing. If you can suggest some approach, do that, but so far not even one person suggested something I haven't tried yet. Both Java or .Net would be a real gift for me if only I could use them for my needs. [ Reply to This | ParentSpecify max memory by CustomDesigned (Score:2) Monday October 31, @10:52AM Re:Take Java seriously (Score:5, Informative) by icebattle (638355) on Monday October 31, @11:03AM (#13915460) Have you tried running your app with -XX:+UseParNewGC -XX:+UseConcMarkSweepGC?This will allow the vm to do small amounts of gc whenever it has a chance, as opposed to wating until an allocation request will fail and then running through the entire heap.Our app runs 24/7 and while the markets are open and 10meg+ of raw data is coming down the line every second, we can't allow the app to take a timeout for a gc run. The app runs in 256meg, too. [ Reply to This | ParentRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @12:48PMRe:Take Java seriously by Hard_Code (Score:2) Monday October 31, @11:14AMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @12:45PMRe:Take Java seriously by jilles (Score:2) Monday October 31, @11:31AMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @12:36PMRe:Take Java seriously by jilles (Score:3) Monday October 31, @01:24PMRe:Take Java seriously by greg_barton (Score:2) Monday October 31, @02:00PMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @02:46PMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @03:18PMRe:Take Java seriously by jilles (Score:2) Monday October 31, @04:03PMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @05:41PMRe:Take Java seriously by MSBob (Score:2) Monday October 31, @09:04PMRe:Take Java seriously by 0xABADC0DA (Score:2) Monday October 31, @12:19PMRe:Take Java seriously by NoOneInParticular (Score:2) Monday October 31, @05:01PMRe:Take Java seriously by vingilot (Score:1) Monday October 31, @12:41PMRe:Take Java seriously by justsomebody (Score:2) Monday October 31, @01:09PM1 reply beneath your current threshold.Re:Take Java seriously by tyldis (Score:1) Monday October 31, @10:14AMRe:Take Java seriously by VisualStim (Score:1) Monday October 31, @10:29AMRe:Take Java seriously by cluening (Score:2) Monday October 31, @10:34AMRe:Take Java seriously by Elm Tree (Score:1) Monday October 31, @11:52AMRe:Take Java seriously by cluening (Score:1) Monday October 31, @12:30PMRe:Take Java seriously by msuzio (Score:3) Monday October 31, @02:13PMRe:Take Java seriously by 0kComputer (Score:1) Monday October 31, @10:37AMRe:Take Java seriously by MSBob (Score:2) Monday October 31, @11:33AM Re:Take Java seriously (Score:5, Interesting) by TheRaven64 (641858) on Monday October 31, @12:21PM (#13916200) (http://theravensnest.org/ | Last Journal: Tuesday September 20, @10:24AM) 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. [ Reply to This | ParentRe:Take Java seriously by Mithrandir (Score:1) Monday October 31, @01:26PM1 reply beneath your current threshold.Re:Take Java seriously by felix_lucian (Score:1) Monday October 31, @03:35PMRe:Take Java seriously by kaffiene (Score:2) Monday October 31, @03:19PMRe:Take Java seriously by shutdown -p now (Score:2) Monday October 31, @09:50PM1 reply beneath your current threshold.Re:Take Java seriously by bzzzt (Score:3) Monday October 31, @09:22AMRe:Take Java seriously by Cthefuture (Score:1) Monday October 31, @09:47AMRe:Take Java seriously by (A)*(B)!0_- (Score:1) Monday October 31, @10:10AMRe:Take Java seriously by Anonymous Coward (Score:1) Monday October 31, @10:23AMRe:Take Java seriously by dastrike (Score:2) Monday October 31, @10:27AMRe:Take Java seriously by Halo- (Score:3) Monday October 31, @11:59AMRe:Take Java seriously by LizardKing (Score:2) Monday October 31, @01:42PMRe:Take Java seriously by LarsWestergren (Score:3) Monday October 31, @10:01AMRe:Take Java seriously by xtracto (Score:2) Monday October 31, @11:00AMRe:Take Java seriously by Coryoth (Score:2) Monday October 31, @12:35PMRe:Take Java seriously by shutdown -p now (Score:2) Monday October 31, @10:00PMRe:Take Java seriously by Myolp (Score:1) Monday October 31, @10:22AMRe:Take Java seriously by 955301 (Score:2) Monday October 31, @10:26AM Re:Take Java seriously (Score:5, Interesting) by AKAImBatman (238306) * on Monday October 31, @10:36AM (#13915243) (http://akaimbatman.blogspot.com/ | Last Journal: Friday September 30, @07:23AM) 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 thanRead the rest of this comment... [ Reply to This | ParentRe:Take Java seriously by zootm (Score:3) Monday October 31, @10:46AMRe:Take Java seriously by NoOneInParticular (Score:2) Monday October 31, @04:38PMRe:Take Java seriously by zootm (Score:2) Monday October 31, @07:57PMRe:Take Java seriously by Felonious Ham (Score:3) Monday October 31, @01:28PMRe:Take Java seriously by Anonymous Coward (Score:1) Monday October 31, @11:15AMRe:Take Java seriously by MemoryDragon (Score:2) Monday October 31, @11:51AMyou have no clue by RelliK (Score:3) Monday October 31, @12:12PMRe:you have no clue by shutdown -p now (Score:2) Monday October 31, @10:07PMRe:Take Java seriously by slapout (Score:2) Monday October 31, @12:25PMRe:Take Java seriously by Billly Gates (Score:2) Monday October 31, @12:41PMCross-platform really is a big deal by JavaRob (Score:2) Monday October 31, @12:42PMRe:Take Java seriously by Decaff (Score:2) Monday October 31, @01:59PMHere are some reasons: by DimGeo (Score:2) Monday October 31, @02:01PMRe:Take Java seriously by cameronpurdy (Score:1) Monday October 31, @03:11PMRe:Take Java seriously by kaffiene (Score:2) Monday October 31, @03:16PM2 replies beneath your current threshold."Extreme Scales" ? by DavidNWelton (Score:2) Monday October 31, @09:06AMRe:"Extreme Scales" ? by tcampb01 (Score:1) Monday October 31, @09:49AMRe:"Extreme Scales" ? by Taladar (Score:2) Monday October 31, @11:15AMRe:"Extreme Scales" ? by Decaff (Score:2) Monday October 31, @04:15PMScripting languages can scale just fine by DavidNWelton (Score:2) Monday October 31, @11:28AMRe:"Extreme Scales" ? by rexguo (Score:2) Monday October 31, @10:48AMRe:"Extreme Scales" ? by DavidNWelton (Score:2) Monday October 31, @11:33AM Microsoft should take this approach (Score:2, Insightful) by craigmarshall (679127) on Monday October 31, @08:53AM (#13914508) 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 [ Reply to ThisMS Anti spyware beta by Anonymous Coward (Score:2) Monday October 31, @09:12AMRe:MS Anti spyware beta by craigmarshall (Score:3) Monday October 31, @09:20AM More on Gilad Bracha (Score:5, Informative) by tcopeland (32225) * <{moc.rehteofni} {ta} {mot}> on Monday October 31, @09:02AM (#13914571) (http://tomcopeland.home.mindspring.com/) 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 [bracha.org].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 [blogs.com]. [ Reply to ThisRe:More on Gilad Bracha by Naikrovek (Score:3) Monday October 31, @09:10AMRe:More on Gilad Bracha by tcopeland (Score:2) Monday October 31, @09:14AMRe:More on Gilad Bracha by owlstead (Score:2) Monday October 31, @10:52AMRe:More on Gilad Bracha by Surt (Score:2) Monday October 31, @11:04AMJava 1.5 by Craig Ringer (Score:3) Monday October 31, @09:55AMRe:Java 1.5 by wzzzzrd (Score:1) Monday October 31, @10:20AMRe:Java 1.5 by Craig Ringer (Score:2) Monday October 31, @10:34AMRe:Java 1.5 by Piquan (Score:2) Monday October 31, @06:27PMRe:Java 1.5 by slashdotnickname (Score:2) Monday October 31, @12:01PMRe:Java 1.5 by LizardKing (Score:2) Monday October 31, @01:49PMRe:Java 1.5 by maraist (Score:2) Monday October 31, @08:28PM Why not prove it? (Score:1, Insightful) by jivo (889268) on Monday October 31, @09:17AM (#13914648) 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! [ Reply to ThisRe:Why not prove it? by scarlac (Score:1) Monday October 31, @09:27AMRe:Why not prove it? by masklinn (Score:2) Monday October 31, @09:38AMRe:Why not prove it? by jrockway (Score:2) Monday October 31, @09:52AMRe:Why not prove it? by bdcrazy (Score:1) Monday October 31, @09:55AMRe:Why not prove it? by TrappedByMyself (Score:2) Monday October 31, @10:00AMRe:Why not prove it? by arkanes (Score:2) Monday October 31, @12:30PMRe:Why not prove it? by zootm (Score:2) Monday October 31, @10:52AMRe:Should have payed more attention in CS class by masklinn (Score:2) Monday October 31, @01:42PM1 reply beneath your current threshold.Re:Why not prove it? by GileadGreene (Score:2) Monday October 31, @02:39PM1 reply beneath your current threshold. Re:Why not prove it? (Score:5, Insightful) by TrappedByMyself (861094) on Monday October 31, @09:43AM (#13914837) 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. [ Reply to This | ParentRe:Why not prove it? by jivo (Score:1) Monday October 31, @09:52AMRe:Why not prove it? by TrappedByMyself (Score:2) Monday October 31, @11:11AMRe:Why not prove it? by TrappedByMyself (Score:2) Monday October 31, @11:52AMRe:Why not prove it? by arkanes (Score:2) Monday October 31, @12:48PM1 reply beneath your current threshold.Re:Why not prove it? by retinaburn (Score:2) Monday October 31, @09:51AM Re:Why not prove it? (Score:4, Interesting) by fuzzy12345 (745891) on Monday October 31, @09:53AM (#13914921) Here's a flame to all the respondents to the parent post. They say (if I may paraphrase) "Code verification is hard. I want my MOOMMMMMY!" Well, it's certainly more difficult, in the short run, than the "throw it against the wall and see if it sticks" approach. But it has been done, it isn't as hard as the naysayers are making out, and it's one of those things that you don't improve at unless you try. Google VLISP for an example of a provably correct compiler.One thing's for sure: Improvements in software quality will be harder to come by if everybody's attitude continues to be "Bugs are inevitable. Formal proofs are beyond us. Let's keep doing it the old way." [ Reply to This | ParentRe:Why not prove it? by Coryoth (Score:2) Monday October 31, @12:59PMI'm pretty sure it's been done by lokedhs (Score:2) Monday October 31, @12:05PMRe:Why not prove it? by jivo (Score:1) Monday October 31, @10:25AM1 reply beneath your current threshold. Optimization and late binding (Score:5, Insightful) by jfengel (409917) on Monday October 31, @09:40AM (#13914809) (http://slashdot.org/ | Last Journal: Monday November 03, @03:59PM) 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. [ Reply to ThisRe:Optimization and late binding by Curt Cox (Score:1) Monday October 31, @10:11AMRe:Optimization and late binding by pdbaby (Score:1) Monday October 31, @11:44AMRe:Optimization and late binding by zootm (Score:2) Monday October 31, @12:34PMRe:Optimization and late binding by Hard_Code (Score:3) Monday October 31, @10:52AMRe:Optimization and late binding by Hugo Graffiti (Score:1) Monday October 31, @11:44AMRe:Optimization and late binding by Decaff (Score:2) Monday October 31, @04:46PM Not execution speed, but predictability (Score:3, Interesting) by awol (98751) on Monday October 31, @10:37AM (#13915254) 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. [ Reply to ThisGarbage Collection by CaptainPinko (Score:3) Monday October 31, @11:01AMRe:Not execution speed, but predictability by Phil John (Score:2) Monday October 31, @11:36AMRe:Not execution speed, but predictability by The Mayor (Score:2) Monday October 31, @03:42PM1 reply beneath your current threshold.1 reply beneath your current threshold.Re:Not execution speed, but predictability by rossjudson (Score:2) Monday October 31, @12:34PMRe:Not execution speed, but predictability by awol (Score:2) Monday October 31, @03:09PM Violation of DCMA? (Score:2, Funny) by XNuke (5231) on Monday October 31, @11:11AM (#13915522) Pardon my ignorance, but isn't this a violation of the anti cracking clauses of the DCMA? [ Reply to This2 replies beneath your current threshold. Someone Remind Me... (Score:1, Troll) by h4ck7h3p14n37 (926070) on Monday October 31, @12:07PM (#13916079) ...why we'd want to test Sun's code for free? Oh, that's right, we get props at either the JavaOne Conference, or on a webpage!If you find a flaw in the specification itself - the design of the Type Checking Verifier as embodied in JSR 202 - that compromises the security of the JDK, Sun will specially recognize and thank you for your contribution to the Java platform at the JavaOneSM 2006 conference, during one of the Day 1 keynote sessions on May 15, 2006, in front of all JavaOne 2006 conference attendees.If you find an ambiguity in the wording of the specification that could allow an alternative, unsafe implementation to be created, or if you find an implementation flaw or coding error in the source code for the Type Checking Verifier in the Java SE 6 JDK, you'll be recognized on a special "Verifier Verified" web page on the JDK Community site, as well as a roll call of contributors that will be included for posterity in the source code itself.To make the contest even more attractive, we have to sign a legal agreement to review the source code:Anyone may participate, but if you would like to review the source code, you'll need to agree to the Java Research License first.Thanks Sun, but no thanks. If you want me to do your work for you, I'd better be getting paid in a cash equivalent. [ Reply to ThisRe:Someone Remind Me... by codemachine (Score:2) Monday October 31, @12:23PMRe:Someone Remind Me... by Phil John (Score:2) Monday October 31, @12:27PMRe:Someone Remind Me... by fantastic (Score:1) Monday October 31, @02:36PM1 reply beneath your current threshold. Gibson required (Score:2) by millennial (830897) on Monday October 31, @02:02PM (#13917017) (Last Journal: Tuesday July 19, @07:33PM) If only I could hack the Gibson, I'd have the power I needed to crack the verifier. /hack the planet! [ Reply to This The old trick (Score:1) by Piroca (900659) on Monday October 31, @03:24PM (#13917647) Simply set -Xverify:none and you'll have no class verifier running in your vm. This is a known, old trick to speed up applications. [ Reply to This Re:Condition (Score:2, Informative) by Anonymous Coward