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

Only an Attaboy?

[elgee]

No cold hard cash or equivalent for "cracking the verifier?"

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

Re:Only an Attaboy?

[shiznatix]

Begin able to show proof that you cracked, or helped crack, the Java verifier would be a excellent addon to your resume.

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 [javalobby.org]. Among them are AdWords and GMail.

"Extreme Scales" ?

[DavidNWelton]

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: http://www.dedasys.com/articles/scalable_systems.h tml [dedasys.com]. Java scores just a bit better on this front than C and C++, because of the big standard li

Re:"Extreme Scales" ?

[rexguo]

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.

Re:"Extreme Scales" ?

[DavidNWelton]

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 [hecl.org] 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

Re:"Extreme Scales" ?

[Taladar]

You may argue about the Java platform being better than scripting languages but in terms of developer-time-saving language features (not only the quick-and-dirty ones, the scaling ones too) scripting languages beat Java hands down. Perhaps Sun should try to add more languages to the Java Platform (more official ones, AFAIK there are a few unofficial compilers).

Scripting languages can scale just fine

[DavidNWelton]

There is a large ISP in the US called AOL, which runs on a web server called AOLserver [aolserver.com], which is now open source software. The web server makes extensive use of Tcl [www.tcl.tk]. Many other large sites use PHP. So, you can make it scale if you want to (although this may involve mixing in some C code).

Does it scale as well as Java? Perhaps not. The point is that it's easier to get started with the scripting language, though. Your customers probably had an easier time of it getting started with scripting rather than

Re:Take Java seriously

[Naikrovek]

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.

Re:Take Java seriously

[Anonymous Coward]

Java may not be "slow" any more, but it's an INSANE memory hog. Part of this is because the heap NEVER shrinks - as you allocate more memory, the heap just grows and grows until it reaches the heap limit (which can be user-set). The other part is because you need to load in large numbers of "support" classes, along with the virtual machine itself, just to get to something as simple as "Hello World".

Now, I need to explain that "heap NEVER shrinks" bit, because people are going to hop in and start talking a

Re:Take Java seriously

[bbn]

You realise that the C malloc/free calls are just the same right? It never releases memory back to the OS.

The only difference in this regard, is that java might alloc extra memory from the OS, when it could have run the garbage collector and reused some memory instead.

Very few programs actually ever release memory back to the OS.

Re:Take Java seriously

[jaywee]

That depends on libc implementation. glibc for example uses mmap() for bigger allocations - therefore is able to return the freed memory to the OS.

Re:Take Java seriously

[bbn]

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.

Re:Take Java seriously

[Politburo]

It doesn't really matter that Java never releases the memory, assuming the amounts aren't obscene. In your example, when the heap grows to 64 MB, we can assume that some pages are swapped from RAM to HD to make room for the larger heap as it is being used. After the memory is used and re-allocated to the VM's free memory, the OS will swap other application's pages back into memory as needed. The VM free memory, allocated by the OS, will swap to HD. It will then sit on the HD until it is needed again. In you

Re:Take Java seriously

[MemoryDragon]

You forgot to mention one thing, there is a maximum heap size, every java program has to adhere to, it is depending on the VM between 32 and 64MB, and you can adjust it with the -Xmx param. It is true, the heap never shrinks but in reality it also does not grow!

Re:Take Java seriously

[swillden]

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 coul

Re:Take Java seriously

[Hard_Code]

And given the escape analysis that is apparently going to be implemented in the next version of Java, it looks like a large chunk of the class of problem you propose (many small allocations/deallocations causing "roaming") may be able to be eliminated. The VM will know when some references never "escape" a certain context/scope, and adjust memory management accordingly. One common scenario, and source of many "temporary" objects, will be automatic/local variables in methods, which can be stack-allocated, eliminating this problem.

MaxHeapFreeRatio

[rossjudson]

Cripes. You might want to do a tiny bit of fact checking before posting such nonsense. The JVM can and does return memory to the operating system, subject to parameters that you can easily set on the command line. There's a pair of thresholds (low and high) on the ratio of free space to total heap size. When free space drops below the low threshold, the VM will get more memory from the operating system (up to the MX limit). Conversely, when free memory rises _above_ the high threshold, the overall heap

Re:Take Java seriously

[srussell]

I don't think Java is as slow as you think it is.

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 m

Re:Take Java seriously

[jiushao]

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.

Re:Take Java seriously

[21mhz]

if only Sun would do something like writing a new faster classfile verifier.

They do: since (1.)5.0, JRE classes come preloaded in a shareable file.

Re:Take Java seriously

[Jesus_666]

Yeah, the day that happens is the day Microsoft puts symlinks into NTFS.

Re:Take Java seriously

[ultranova]

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.

My quick, very scientific experiment with a wristwatch and an animation library test application I've written had java start, from pressing enter into the sprites begin bouncing in the window, in 5 seconds. This was with a 1GHz Duron, lots of free

Re:Take Java seriously

[MenTaLguY]

I hate to break it to you, but five seconds for an application that small on hardware like that is a long time...

Re:Take Java seriously

[justsomebody]

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.

Specify max memory

[CustomDesigned]

While this negates much of the benefit of "automatic" memory management, I avoid the problem you describe by specifying max memory. For instance, a multi-user VM with our accounting applications (no graphics) runs in 1M. The solution to the problem is to use some form of continuous GC (a must for real time Java) - but that increases the GC overhead to where it is comparable to malloc/free. Another solution (though I last used it in JDK1.1) is to call System.gc() at a convenient point. This is supposed t

Re:Take Java seriously

[icebattle]

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.

Re:Take Java seriously

[Hard_Code]

Sure this is a problem, but isn't it also a problem with traditional 'malloc'? From what I've seen, malloc gets pretty pathological under high load also, does it not? Eagerly reclaiming memory may not actually be as good as it sounds. Even with traditional explicit memory reclamation, you aren't ever *really* reclaiming the memory yourself. It has to first jump through whatever the malloc strategy is, and then the operating systems virtual memory and cache subsystems, all of which may choose to do arbit

Re:Take Java seriously

[jilles]

Your argument is effectively countered by this excellent article on why java memory management is actually faster than the way it is handled in C/C++: http://www-128.ibm.com/developerworks/java/librar y /j-jtp09275.html?ca=dgr-lnxw07JavaUrbanLegends [ibm.com]

In short, memory allocation in Java is faster (measured in cpu cycles used) and it can use both stack and heap based memory allocation (unlike the urban myth that Java can't do that). Additionally, for short lived objects, garbage collection is essentially free (u

Re:Take Java seriously

[jilles]

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

Re:Take Java seriously

[0xABADC0DA]

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. Just take any test where Java was faster and test loop to make 2^32 instead of 1000 or 10000 calls.

Wrong. Java typically wins the FFT microbenchmarks where there is *zero* memory allocation. Making the test run over and over actually improves Java's performance. Typically in microbenchmarks that involve memory, Java recognizes that the objects are short-lived and delete

Re:Take Java seriously

[cluening]

I suspect that the wannabe nature of a huge number of slashdot readers is part of the problem with this "myth". _Most_ people only experience Java in their web browser or in stand-alone GUI apps. In many cases, these things really are slow, as could probably be expected: your application has to pass through several layers of virtual machine and windowing libraries before it can draw to the screen. Doing real work with Java, requiring writing your own app in an efficient way, isn't really bad. This invol

Re:Take Java seriously

[msuzio]

Thank you. "Wannabe" is just the right term. It really burns my ass when someone who is ignorant (and I mean that in the truest sense of the word -- they might not be stupid, but they obviously do not actually know what they are talking about) just spits out the standard "Java is teh suX0r!!!! It is sl0w!!!!" stuff.

*rolls eyes*

LISP weenies and C++ gurus can knock Java. They've earned the right to do so. Anyone who has written code for one of the "scripting languages" people position as competitors to J

Re:Take Java seriously

[SnapShot]

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 th

Re:Take Java seriously

[FatherOfONe]

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?

Re:Take Java seriously

[MemoryDragon]

Check outExade [exadel.com] for jsf development much better in this regard than MyEclipse. As for ejb3, it is very close to Hibernate but more cleaned up and really good. There already is a good tool which covers the ORM part of EJB3 (the BO part is equally stunningly good) it is called jsr200 an you can download it from the Eclipse site.

Re:Take Java seriously

[ultranova]

Also being forced to use the garbage collector has a ton of overhead. If you have to create and destroy millions of objects quickly the Java VM will bloat out and kill the machine (an exageration but you get my point).

Hmm.

public class Dummy {
public static void main(String[] args) {
int i;
int x;
Object o;

x = 0;
for (i = 0; i < 100000000; i++) {
o = new Object();
x += o.hashCode();
}
System.out.println(Integer.toStr ing(x));
}
}

The hashcodes are summed up and printed to make sure that the object allocation

Re:Take Java seriously

[MSBob]

I think you're a bit behind the curve. Managed languages can analyze runtime profile and perform optimizations that can't be performed on native code. High level concepts like escape analysis and lock elision come to mind.

But hey, never let the facts get in the way of your argument.

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.

Re:Take Java seriously

[bzzzt]

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.

Also, the language is easily picked up, simple to write and the API's are quite sane compared to a lot of other languages.

Re:Take Java seriously

[Halo-]

I'm not bashing Java, but I don't completely agree with your statement that:

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

Re:Take Java seriously

[dastrike]

"What happens when your hardware changes and that nice API isn't available for your new hardware?"

What happens when your hardware changes and that nice Java Runtime Environment isn't available for your new hardware?

Re:Take Java seriously

[LarsWestergren]

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 en

Re:Take Java seriously

[xtracto]

...The strict typing and verbose exception handling is annoying if you just want to get something done quick. [...] 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).

Just a smal

Re:Take Java seriously

[Myolp]

Perhaps it's because there are a ton of good Java developers available, compared to the amount of C/C++ developers. But it could also be because Java is acutally faster at things like memory allocation [sun.com]. I also believe that the large amount of ready-to-use and stable software components available makes a difference when choosing Java for your server application. Then there are the large number of standards built on Java, like J2EE or J2ME, that allows you to focus on the application-specifics in your project

Re:Take Java seriously

[955301]

Yes you do. The advantages of being able to develop on my local linux notebook and deploy to a Solaris cluster should not be overlooked simploy because it's important at dev time, not production time. Recompiling on another platform means retesting on that other platform. I'd rather run my unit and integration tests off the production & staging environments, load test in staging and no testing in production. This way unit and integration can be part of my build process (http://maven.apache.org/ [apache.org] and not

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

[zootm]

I'd like to add "type safety" in there, but then I'm a programming language geek at the best of times.

Re:Take Java seriously

[Felonious Ham]

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.

Re:Take Java seriously

[MemoryDragon]

Actually natively compiled languages in the server sides case are not really that much faster, but you are around 10 times as fast in development times as you would be in C++, besides that you get stuff like clustering scaling up to mainfraime level, clustered caches, excellent orm mappers etc... out of the box. There is a reason why Java is used heavily on the server side nowadays, it is scalability, fast development times, stability, and huge excellent libraries for everything under the sun.

you have no clue

[RelliK]

You obviously have never worked on large server-side applications. Other posters have already listed some reasons for java's popularity. I'll add some more:

* java is nearly as fast as C++ according to all the benchmarks I've seen. Yes, really. The perception of java as being "slow" is simply the legacy of the old awt apps. Yes, the awt gui was (and is) slow. Server-side java applications are not. The "much better performance" is simply not there, particularly for typical enterprise apps.

* *All* the enterprise apps (which is the area where java is particularly successful) store stuff in a database and/or talk to remote apps. Newsflash: a database query or a remote procedure call is *orders of magnitude slower* than an in-process procedure call. Once you include DB/RPC into the equation, whatever little speed advantage C++ has is wiped out completely.

* This is CS 101: performance of a program is largely determined by the algorithm used. You can write a linear search in assembly, and it will be very fast for small lists. But for large lists, a binary search written in shell script will beat it.

* In an enterprise application scalability is much more important than raw speed. So what if I can write a C++ app that's 20% faster than an equivalent java app? Java has frameworks that make it easy to write an app that you can scale horizontally (i.e. by adding more boxes). Easy being the keyword.

* Developer's time is much more expensive than runtime. It is *much faster* to write an app in java than in C++. And for all but the smallest/simplest apps it is faster to write the app in java than in PHP/perl/whatever.

If it's a safety/security issue then again you could build the same thing in a native compiled language, sandbox and all.

Uhhhm, yes. Safety and security are *big* issues in enterprise apps. Show me *one* native language and platform that does it. You are saying it like one can just wave a magic wand and have it built in no time. "You could build the same thing" is not "it's already built".

I mean really, is it just because Java provides a lot of easy to use API's?

Yes. among all the other things I've mentioned.

These are just a few reasons why java is so popular in enterprise apps. Sure, I wouldn't write a game in java, but for enterprise apps, it's perfect. Why java and not PHP/perl/? Simply because java is better. It has all the advantages of compiled laguages (type safety, variable declaration checking, syntax checking, etc.) without some of the disadvantages (manual memory management). Think of java compiler as a sanity checker for your code. It will catch common mistakes like typos, missing return statements, invalid function parameters, etc. A scripting language will not complain about that, but force you to spend hours tracking down the bug. That's why java is faster to develop in than any scripting language for large apps.

Re:Take Java seriously

[slapout]

Maybe it's so that it doesn't matter what the server is. They could be running Linux. Then the could decided to run Sun instead. Or maybe try Windows (just kidding :-)
The point is if a server goes down, just throw another one up (that can run Java) and you don't have to worry about it.

Cross-platform really is a big deal

[JavaRob]

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?

Actually, yes -- the cross-platform ability is extremely useful. Speaking personally: the two biggest projects I have worked on, both for one client, are deployed (production) on a IBM iSeries server (these used to be called AS/400s -- using the OS/400 operating system), and a Solaris server respectively. Both web apps are built on the same code base, and we deve

Microsoft should take this approach

[craigmarshall]

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

[Anonymous Coward]

You mean like this; http://www.microsoft.com/athome/security/spyware/s oftware/default.mspx [microsoft.com] ?

Re:MS Anti spyware beta

[craigmarshall]

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

[tcopeland]

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

Re:More on Gilad Bracha

[Naikrovek]

I believe Java 6 introduces java.io.Console, which provides several convenience methods when using the console, but other than that I don't know of any language changes.

Re:More on Gilad Bracha

[tcopeland]

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 [sf.net] parsing bug reports and whatnot for JDK 1.3...

Re:More on Gilad Bracha

[owlstead]

java.io.Console? 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.

Re:More on Gilad Bracha

[Surt]

java.io.Console is just a package. It doesn't require the compiler to handle anything differently, hence not a language change.

Java 1.5

[Craig Ringer]

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

Re:Java 1.5

[Craig Ringer]

Whoops, you're quite right.

I guess a third thing changed in the interim - a good five years of programming experience that I didn't have when forced to use 1.2 . I may be a crap programmer now, but man I was awful then. I should also note that I was forced to use 1.2 /for applets/ which might be no small part of my remembered loathing.

It's a bit sad, actually, given that the languages I'd been using prior to that had sort comparitors, lambda functions, etc so I should really have found the related features

Optimization and late binding

[jfengel]

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.

Re:Optimization and late binding

[Hard_Code]

"Java may, someday, with sufficient ingenuity, rival or even beat C++ in performance"

For long-running throughput-bound server processes, doesn't it already?

Not execution speed, but predictability

[awol]

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.

Garbage Collection

[CaptainPinko]

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:

-Xincgc

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

Re:Not execution speed, but predictability

[Phil John]

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

Violation of DCMA?

[XNuke]

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

Re:Condition

[Anonymous Coward]

Here you go:
https://mustang.dev.java.net/ [java.net]

Re:Java is overrated

[zootm]

I can safely say that Java doesn't suck, but on the other hand, .NET is an extremely nice technology. Java is certainly lagging behind (and has been for some time) in terms of suitability to desktop applications, but it's a solid base and is extremely useful for just about everything else.

dotNET is overrated

[dascandy]

It allows you to work faster and create more in a short while. It allows you to create abnormally slow programs that you can't even speed up with the willpower to do so, because of Windows internals. Those exact internals that Java won't touch with a stick.

Java doesn't look like win32 because it isn't even trying to. It's trying to look platform-independant and the same on all platforms, with the option to skin it to any GUI you want. dotNET IS windows. There's no wonder that it looks a lot more like window

Re:dotNET is overrated

[masklinn]

I must strongly disagree on the OO implementation however, aside from it not supporting multiple inheritance, it's just good.

Given the fact that C# does not support multiple inheritance either, you must really know quite a lot about it...

Oh, and as far as implicit goes, you don't want C# nor Java, you want a dynamically strong typed language such as Python or Ruby, which both - on top of that - consider functions, classes and modules as perfectly regular first-class objects.

Re:dotNET is overrated

[$RANDOMLUSER]

I never got the joy of multiple inheritance, anyways.
I mean:

"It's a floor wax!"
"It's a desert topping!"
"No, it's both! New Schimmel is a floor wax and a desert topping!"
(This is from early Saturday Night Live for the humor impaired)

Re:dotNET is overrated

[Courageous]

Well, I guess you're trying to be funny. But seriously, it's not about what's being abstracted. Rather, it's about borrowing implementation. Dynamic languages don't usually have 'multiple inheritance' in the classic sense, anyway. They use an approach called 'mixins', which varies in subtle and useful ways from the way that the static languages community is accustomed to thinking about it (has to do with dynamic dispatch...).

Although, to be fair, you don't see much MI in Python in practice...

C//

Re:dotNET is overrated

[$RANDOMLUSER]

Actually, I was reasonably serious, I just said it silly-like. While I can see an object having multiple begaviors (in Java-speak implementing an interface or two); I cannot see an object having multiple states, which is what's really implied by MI. To me, an (non-trivial) object is about the data it contains, and/or the state it preserves. To say that a thing is both one thing and another (from a data standpoint) in the same breath, to me just smacks of bad design. Again, nothing wrong with having unre

Re:dotNET is overrated

[Courageous]

...To say that a thing is both one thing and another...

But who says that one is saying that? This seems like an abstraction issue, with you personally being unwilling to look at the problem from a different abstraction point of view.

Perhaps you just want an object to have multiple behaviors, and get those behaviors for free? The recommendation here, from the typical representative of the Java crowd, is to say to just hand roll the dispatch. ...which is what's really implied by MI...

Certainly dynamic languag

Re:dotNET is overrated

[smallguy78]

I believe the place that Java users discuss their religion (and the evils of that new satanic cult C#/.NET that is taking our jobs and women) is comp.lang.java.advocacy [google.com]

Re:dotNET is overrated

[zootm]

C# makes a distinction between virtual and non-virtual methods (which is largely used for optimisation which is not available otherwise, as I understand it). The distinction between override (which seems a little unnecessary, but it's arguably better than ambiguity) and new stems from this.

I wouldn't say there's a huge difference between C# and Java, certainly not of the kind you're trying to imply there is. C#'s syntax is a little closer to C++, not so much the Windows API.

Re:dotNET is overrated

[21mhz]

Oh, sorry, I didn't see the reversed parameters.
Well, there may be cases when the developer meant this, however bad style it is.
I guess it wasn't worth making it a special case in the inheritance/override rules, they are complicated enough already.

Re:Aren't QA people supposed to get paid?

[Naikrovek]

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.

Also for 3rd party bytecode generators!

[JavaRob]

Right, it's Sun's "responsibility", and of course if the verifier falls down they will get all the bad press -- but they are giving the rest of us the *chance*, if we want it, to contribute to the security of an essential part of the JVM (because we're the ones who'll be vulnerable if there's a flaw!), PLUS to find out if their new verifier is going to play nicely with the myriad 3rd party tools that manipulate and generate Java bytecode.

There are tons of alternative compilers out there that turn various la

Re:Aren't QA people supposed to get paid?

[$RANDOMLUSER]

Because Microsoft's testing procedure works so well, Sun should emulate it?

Re:Google

[masklinn]

Toplevel ISPs have issues, not google. It would probably require the whole intarweb to break down to down all of google's various servers.

Re:Don't believe the hype!

[craigmarshall]

> C is portable, fast, very complex and since 35+ years the leading standard for professional OS and APP development.

I agree that C is portable and fast, however I don't it can be called very complex.

The smallest programming language manual I have ever owned (and I've owned quite a number), has to be "The C Programming Language", often hailed as the One True Reference to the language. How can it be that complex if the manual is less than half the size of most of my other manuals? I think languages (in ge

Missing option...

[DrYak]

I think C is actually one of the simpler languages. The closer to assembly you get, the simpler the language has to be.

Do not underestimate Brainfuck [wikipedia.org] !

Re:Don't believe the hype!

[dave1g]

And the Algol manual/language definition is what, 15 pages long?

Sit down.

Re:Why not prove it?

[TrappedByMyself]

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.

Re:Why not prove it?

[TrappedByMyself]

No - I have a colleague, that used to work for ESA. Proving that software really works as it's supposed to do, is something you do, when you cannot afford the consequence of failure (eg. loss of human life, or perhaps even worse: bad PR...).

Now, my question for you folks: Could Java afford a failure in this area, or should SUN do what it takes?

I think you're really just trying to play the evil and incompetent big bisuness FUD card. How do you know Sun isn't doing this already? Also, you're still making

Re:Why not prove it?

[TrappedByMyself]

From your post it is obvious that you are at best vaguely familar with the topics you speak of.

Well, to be honest, I really have no clue about the sort of systems that the ESA builds, so I was really stretching there. However, I'm not backing down on the argument that you cannot do a mathematical proof which guarantees that a complex piece of software is bug free. You can define a set of conditions and prove that the code works against those conditions, but you can never slap on the 100% bug free label.

Re:Why not prove it?

[retinaburn]

I don't see why you have a problem with this, it is exactly what they are doing. They are saying 'help us test it out so we know it doesnt have any major flaws.' They are in fact proving that it works, many hands make light work.

Re:Why not prove it?

[fuzzy12345]

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

I'm pretty sure it's been done

[lokedhs]

I'm quite certain that the new code verification algorithm has been theoretically proven.

What is going to be tested is the implementation, not the theory behind the algorithm, however. It doesn't really matter how well proven the algorithm is if the implementation has a bug (which could caused by a typo for example).

Code proving is a nice theoretical excersise, but don't for a second believe that just because some code has been put through a formal proof that it cannot contain bugs.

Re:Why not prove it?

[masklinn]

You hit a classic problem with all software. Software cannot be proven to work 100%. You should not try to prove it.

Yes they can, it's the mathematical proof of a software.

It's tough, time consuming, very expensive and requires *the horror* the actual usage of mathematicians, but it is possible to prove a software.

Re:Why not prove it?

[jrockway]

Here's an article about proving software:

http://www.spectrum.ieee.org/sep05/1454 [ieee.org]

If you read that whole issue (Sep2005 IEEE Spectrum), you'll see that the industry realizes they can't afford shitty software anymore. Finally.

Re:Why not prove it?

[TrappedByMyself]

Yes they can, it's the mathematical proof of a software. It's tough, time consuming, very expensive and requires *the horror* the actual usage of mathematicians, but it is possible to prove a software.

No you can't. You can get really close though.
Mathematics is not a description of how things work, it is only a model of how things work. When you toss it at your code, you still need to make assumptions about the environment which you are proving in. Again, to do these proofs, you need to make a model of

Re:Why not prove it?

[arkanes]

Some CompSci guru (Dijkstra?) once posted some code with the disclaimer that it may not work, as he had only proven it correct, not tested it.

A proof is in no way protection against bugs - it simply is a proof of the algorithmic integrity of the software. It, of neccesity, doesn't account for any errors outside of the software algorithms (in libraries, the OS, the hardware) and any issues that may arise from those, and more importantly it doesn't actually show that your software actually makes any sense -

Re:Why not prove it?

[zootm]

To the best of my knowledge, there's still not a exhaustive proof that Java is typesafe, let alone more complex proofs. The proofs are possible, yes, but they are incredibly time-consuming, and much of the time may not even catch the problems for which you look.

Re:Someone Remind Me...

[codemachine]

Or they could put it under a more permissive license like the BSD license. That way they can include it in their commercial JVM, but it would also let the community that is doing their testing work for them to use it in the open source alternatives.

Of course that will never happen, because one serious advantage Sun's JVM has is its security sandbox. The open source ones often have something that is nowhere near as secure, if there is any security checks at all (take a look at how much security you'd get i

Re:Someone Remind Me...

[Phil John]

Don't forget you can mention it on your CV and in Job interviews, that's sure to impress people in-the-know when you're up for that Java programming job.