I've been tweaking it to include SpamAssassin with Bayesian spam filtering and directories for users to drop in spam for it to learn + customizing Squirrelmail for a couple of weeks, but it's been functioning out of the box after an hour.
You've just said in took you a couple of weeks to get everything set up? So what was functioning out of the box? Did not look like the software you've used satisfied your requirements out of the box, so its working in a hour is not a fair statement.
I've got James setup in less than an hour satisfactory to my requirements and have it working just fine. No compiling of the code on an appropriate platform and etc. THat is what's good about it - cross-platform, given the existence of an appropriate JVM, whithout mundane compilation. Unzip, configure and run.
Can James or any Java App hope to do this? There's a time and a place for Java, and low level system services like this ain't it.
Memory is the only concern, although you can get a Java service down to a 10-20 MB allocated memory if you try very hard. James is at around 32MB, not much of a difference given the amounts of memory world works with now days.
Otherwise Java is just fine for any low-level services and more it allows much greater extensibility and flexibility without much hassle (reflection, bindings and etc.). Look at James and its plugin capability. Very cleanly defined XML metadata too. APIs for that are widely available and supported and are standard in many cases, so Java can do the work no worse than any other language implementation.
So I think you are being a bit too judgemental about capabilities of Java and apps written in it.
so why re-invent the wheel?
To come up with something better, more secure and easier to use. And in addition reinventing the wheel would be coming up with an SMTP or POP3 or etc. protocol again, not by developing a product, maybe similar to others, which function is to manage the communication and data across such protocols. Otherwise we would not have any competing products and would not have any choice.
Artem D. Yegorov