-- wait for laughter to die down --
I am serious.
-- wait for laughter to die down - again --
let me explain (to anyone who hasn't discounted me as a complete nutter yet, and is still reading)
5.0 has a new tool "apt" which is a better javac. It allows us (mere mortals) to run our own code inside the compiler which can ...
* examine the source being compiled (via mirror API - similar to reflection or javadoc API)
* generate other code (sourcecode which will then be compiled, as well as bytecode if you have the inclination),
* and generate compiler errors if we detect something out of spec.
Do you want a compiler error when you implement an interface and the javadocs say that implementations must have a public default constructor, and yours doesn't?
Well "apt" could do that - (in fact I've coded it already - and it works - I'll probably put the stuff up as a java.net project when its a bit more stable and I have a few more useful things included, and a bit of time and ... ).
Now for sure, apt does need a little more work (check the bug parade keyword "apt"), but as far as teenagers go, its pretty damn useful.
It could also do with a bit more work under the hood in terms of reusing information from the apt processing phase in the compilation phase, but thats just a performance thing (and might have already been done because I can't find the bug anymore that suggested this).
Apt's one weakness is that you can't force people to use it, so whatever useful stuff you do with it, others can just bypass it and use javac instead, and all those runtime errors you would have caught at compile time, slip through again. Argh.
Hence - deprecate javac, but also rename apt to be javac (or just put the apt processing functionality in javac - but that doesn't make such a controversial subject heading does it :) ).