Slashdot Mirror
10 Reasons We Need Java 3
An anonymous reader writes "This article on O'Reilly Network (written by one of the most active Java book writers ever, Elliotte Rusty Harold) has some interesting points about the need for a new 'cleaned up' Java version, made to incorporate the advances in the last 7 years of its life and without the requirement to keep compatibility with old versions."
"without the requirement to keep compatibility with old versions"
The only way this will work is if it is compatable with older versions. Would anyone upgrade to Borland Builder 6 if they were told they couldn't compile there previous programs.
If it was compatable , then people could upgrade and start using in the morning.
Cruise TT
Microsoft Visual Studio .NET is not compatible with old versions. Visual Basic.NET only has a shallow likeness to it's predecessors.
Sometimes it is possible and necessary to break compability.
One big thing Java needs is a multi-process VM. Think about it, how many processes does your machine run? Probably lots. How many does a Java virtual machine run? One. Each process has its own VM. While this might have some advantages when it comes to controlling crashes and security, it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while. jEdit, a popular Java text editor had to overcome this by attaching to an existing server process. Kludges like this shouldn't be necessary.
I have spent the majority of my time over the past 4 years programming Java professionally for a number of large corporate clients, mostly in the banking and telecoms sectors. While Java has certainly allowed me to increase my productivity substantially over more 'traditional' languages like C and C++, there are still a number of important features that should be included in Java 3 in order for it to fully cement it's supremacy over C/C++:
- Multiple inheritance: some problem domains just don't map cleanly onto a single-inheritance model, and need the power that only multiple inheritance can bring. Multiple inheritance often leads to clearer code representations in the developer's head, avoiding the abstract mess present in languages like C++ and Eiffel which only kludge this feature with 'interfaces'.
- Operator overloading: this can be a natural and productive extension for the experienced coder, and aid the junior programmer to get up to speed quickly. Again, an important omission in other languages which should be fixed
- Pointers and direct memory access: Java currently makes it very difficult to write specific machine-targeted instructions. I find it frustrating that I can't wring out every last bit of performance from whatever CPU I'm coding for. The designers of Java really blew that one. Direct memory access with pointers like in Visual Basic and Delphi would be a godsend.
If people start writing for new java, then people with old java shall get cut out -- the Windows users, more than likely. They are going to have to get new java on there own, and i'm not sure how many people want to. However, they will likely have .NET forced on them anyway. New Java will just encourage use of C# unless it remains backwards compatible.
Not the users. IN GENERAL the cost the rework would be greater than the cost of the benefits of additional clarity.
I think the only real beneficiaries would be the Book authors, who would make a killing from killing trees to feed the poor confused users.
Now I wonder which camp ERH comes into...
DWR is Ajax for Java
Number 8 -
:)
> Eliminate primitive data types.
> This will undoubtedly be my most controversial
> proposal, but bear with me.
I can agree with almost every other proposal in this article, but he's right - this one will cause a fracas.
> I am not talking about removing int, float,
> double, char, and other types completely. I
> simply want to make them full objects with
> classes, methods, inheritance, and so forth.
One word - ew!
> This would make Java's type system much
> cleaner. We'd no longer need to use type-
> wrapper classes to add primitives to lists and
> hash tables. We could write methods that
> operated on all variables and data.
What you really need is generics (as in C++ templates). Java collections are vile, since they suffer from type loss even when used with "real" objects. I'm surprised that didn't come into this top ten; it's a major language deficiency.
> All types would be classes and all
> classes would be types. Every variable, field,
> and argument would be an instance of Object.
> Java would finally become a pure object-
> oriented language.
However, that wouldn't make all Java programs "object-oriented programs", nor would it make all Java developers "object-oriented programmers". I have a suspicion that it might impact things like the JNI too.
> Programmers in each environment need a language
> tailored for them. One size does not fit all.
<ahem> Quite. That's why you don't start an exercise in OOD by deriving everything from "TObject".
These sigs are more interesting tha
it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
Apple's JVM implementation for OS X already supports some of the features which you are requesting... For instance, Apple's JVM uses a shared memory space between JVM instances. This significantly reduces the memory footprint of each JVM instance and allows classes to be loaded only once. Example: I launch 2 Swing apps, they can share the same JFC classes, requiring class loading only once. I can stop and start the one of the appilcations without having to wait for Swing to be reloaded into memory.Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while.
Additionally, startup time is really not an issue on OS X. I am writing a fairly complex Java Swing application right now. On start up, it parses 3 (one of which is very large) configuration files, it creates a few Swing components, and finally displays a complex JFrame to the user. Total time for a cold start (no other JVM loaded) is approximately 2 seconds. That's certainly not slow. Not Sun needs to take a look at what Apple did and implement it back across their JVM implementations.
One big thing Java needs is a multi-process VM.
I don't really see what the advantage of this is. Again, the JVMs from Sun and Apple both use native threads. On most platforms, thread creation is less expensive than process creating. This is why Apache 2.0 is a hybird muli-threaded/multi-process application. Apache used to run a multi-process only model and it bogged down on Solaris b/c of process creation overhead. The new model overcomes this by using threads more heavily. As long as the threads take advantage of native thread features, like _____, thread use is most likely more efficient than process use.
BTW, on Linux, there is no real difference between a process and a thread, so Sun's JVM is already "multi-process" on Linux. And it's not any faster than their other implementations. As a matter of fact, Apple's JVM blows away Suns implementation on Linux and Windows (I haven't been able to test against Solaris).
Its wonderful seeing well thought out postings on this topic - my respect for this guy has just gone up a LOT, and I'm going to take a look at his books.
Talking about "what should be Java" and "what should not be Java" is a volatile topic no matter how you slice it. One thing I think the Java community has going for it is that they're not nearly as fragmented or hyper-screaming knee-jerk as a lot of the C or C++ community is.
I could see Sun and/or the JCP taking these proposals and starting the J3 development cycle. The trick is that much of what he's talking about is more than just a couple weeks hacking by a few dozen coders. Theres some serious internal redesigns here. However, he has worked them all through, with well-thought out arguments for and against each of his points.
I don't profess to be a Java guru. I've only been working in the language for about a year, but I've found it strong, the community intelligent and professional, and the environment a pleasure to work with.
Java ain't just applets and painfully slow JVM's anymore.
Event Management Solutions : http://www.stonekeep.com/
10. Delete all deprecated methods, fields, classes, and interfaces
They don't get in my way much, so removing them wouldnt help me at all. It would only force me to re-write old but working code. I disagree with this one.
9. Fix incorrect naming conventions
Is InetAddress really that confusing that I need to re-write everything? And where is the benefit to me in moving java.sql to javax.sql. None that I can see, and it will create more errors until I learn the new way. I disagree with this one too.
8. Eliminate primitive data types
I can see the benefit to this. I like C#'s compromise where it automatically casts from native type to Object. BUT I don't think it is a good idea to slow Java down. It already has a bad reputation for speed, lets not make things worse. And as for "The int/char/double/float/boolean objects would be immutable, so these objects would be thread-safe and could be interned to save memory" I don't think you've really though this through Eliotte. What about "i++"? So I disagree with this one too.
7. Extend chars to four bytes
May I dont spend enough time writing XML parsers, but I've never been bitten by this one. So to me it doesn't seem worth the cost of re-writing everything. So I disagree with this one too.
6. Fix threads
Yes Thread have had problems, but they are still very useful. I'm prepared to make use of Thread and wait for the JSR to come up with improvements. I am more in agreement here, but not to the point of shoulding applause
5. Convert file formats to XML
I can see the benefits, but not enough to re-write all my servlets etc. And I don't think this change requires Java 3, just some updates to the servlet spec etc. Reason for Java 3? Not from where I stand.
4. Ditch the AWT
I can hear people (IBM) wanting to drop Swing because it is too slow, but not so much wanting to drop AWT. The key thing is where does anyone benefit from removing AWT? Surely have a class call JButton is not that complex that we need to break all that code? I'm not agreeing with this one much either.
3. Rationalize the collections
Well there aren't that many problems. I suggest we just *gradually* deprecate Vector and Hashtable and carry on with the alternatives.
2. Redesign I/O
No not again! Please! I've taken 2 re-writes already. Perhaps File could be updated as some of Eliotte's suggestions, but that hardly requires Java3.
1. Redesign class loading from scratch, this time with human interface factors in mind
Accepted this is a problem. But while neither I nor Eliotte has a solution, perhaps we should make do with learning the idiosyncracies, or finding solutions rather than calling for Java 3.
DWR is Ajax for Java
So in my not-so-humble opinion what Java needs greatly is a completely redesigned & revamped architecture (bytecode & JVM) with compatibility modes, of course.
Most points discussed in the article are just library-related. Those simply do not justify a new major release.
The Raven
The Raven
As another noted, the JVM is already capable of running multiple processes on Mac OS X. Fix the JVMs for GNU/Linux, FreeBSD, Solaris, and those obscure, mutually incompatible operating systems from Redmond :-), and let others fix (or replace) the language.
Concentrate on the JVM.
Already Python can be compiled into java bytecode, and if the capability doesn't already exist for Ruby, it will soon. Similar compilers could be created for any number of other languages (scheme, smalltalk, whatever).
Java isn't what is important, it is the write (bytecode) once, run (bytecode) anywhere that is important. Whether that bytecode is generated from Java, Python, Scheme, Ruby, or Joes New Language For His CS210 course, doesn't really matter.
The Future of Human Evolution: Autonomy
10 ) Ok, but what about moving to a better system where you can compile against a specific version. Try to compile agains 1.3 with methods that were depreciated and it will fail.
9 ) Ok, within the java API the naming convention should be consistant. Outside of the API it's the programmers decesion. To dictate a style of writing would place an undue burden on programmers
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
As for your comment about 2b + 2b != 4b... No shit you add two SIGNED 32bit values and expect it to work properly despite the buffer overflow! BigInteger is part of java.math and is a perfedt counterpart to Integer, but can be as big as you want.
7) Um, mabye. Chars are already expected to represent string and I doubt there would be much resistance to having a JVM decide how big those should be. It's not like he's trying to suggest that short should be changed ( oh... yea ).
6) I can see some cleanup here. Threadgroups could go away and 99.9% of people would not care. As for the non-atomic nature of 64bit+ primatives that has alwyas been clearly documented in the spec. It does not guarentee atomic operations on anything longer than 32bits. Although this could be changed it was always a trade off between the smaller systems and the larger systems that java would be running on.
5) No, please, no more bloat. XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
4) Smoking the BAD crack. AWT has it's warts and problems, but just look at mozilla on the MAC for all the reasons that native widgets should continue to be supported at all costs. I would not mind an alternate WM/WT as long as it had true native peers so that java can participate as a first class application on all platforms. AWT currently is poorly designed to handle the diffrences between OS's and take advantage of the niceties on some platforms, but that's no reason to abandon native widgets.
3) Java has two sets of collecations. Ove that was based on 1.1 ( Vector, Hashtable ) and one for Java2 ( List, HashMap ). Anybody that's bothered to read a performace tuning book would realize that the Java2 collection system ( although without generics ) is by far the better system. The Java2 system allows either synchronized or non-synchronized operation. This is because the vast majority of java collection use is internal to a class or method where syncronization just adds a burden to the system. Why use a beartrap for holding your desk pens when a cup would work just as well.
2) Yes, count me in. The I/O subsystem uner java it totally inoperative for many tasks. A RFE currently pending ( for several years ) is to adda simple way of finding out how much free space is availible on the filesystem. Metadata information is a casulatly of war. It just needs to be tossed out.
One thing that he doesn't hit on, but it a REQUIREMENT for interoperability is some standardized way of doing fixed block decoding/encoding ( think struct ). It's just amess trying to get complex binary structures into and out of java without going quite mad.
I don't agree that Streams should be buffered by default as that can CAUSE problems. Buffering should alwyas be under the control of the programer.
1) Yes, it's already known that the current class loader has some issues, but they are working on a better one. There is no reason to throw the baby out with the bathwater. Many advanced programs are running into problems expecially when they are using custom class loaders.
But.... he didn't even mention quite a few issues I have personally with my big pet peve being....
The GC. Many programs need some feedback and some wat to hint or force the GC of specific objects ( since they peer with NATIVE blocks of ( memeory/code) ). It's very important that the programmer be able to programmaticly control SOME operations of the GC subsystem. I'm not asking for malloc/free, but there are some objects that can be a pain to work with and some programming requirements that cannot be achived under the current GC system. It's a black box without any feedback. I would like to be able to tell the GC when I have 10ms where I know the system's time would be better spent cleaning up after itself to go ahead nad do it. I need to be able to force the cleanup of specific classes/instances when they are holding on to native resources.
Anyways..... I think I've rated enough. I can see where this guy is comming from, but most of his points are whining or ignorace of the system.
10. Get rid of deprecated methods - don't be an arse, ruins past compatability with no benefits.
people shouldn't be using deprecated methods anyway...that's why they're deprecated, becuase they may not be supported in future releases...this makes perfect sense...
Eliminate primitive data types - oh yeah, please let me do x = new Int(1) + new Int(3);
did you even read his explanation??? from the article: "The new byte, int, long, double, float, and char classes would still have the literal forms they have today. Just as the statement String s ="Hello" creates a new String object, so too would int i = 23 create a new int object."...the way you use them wouldn't change at all...in fact this would totally eliminate the need to create new Integers, Doubles, Booleans, etc, when you wanted to put primitive things in lists, hashmaps, etc...that's a big pain now...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
Java 2 (or 'The Java 2 Platform') is used to refer to all versions of Java since 1.2 - the idea being that the Java platform came of age at that point, having managed to absorb the major new features added in 1.1 and being ready for enterprise use. So JDK 1.2, 1.3 and 1.4 are all still Java 2.
;)
Given how interesting that sort of numbering approach is already, I see no additional confusion springing from the idea that Sun could declare 'Java 3' starting from JDK 1.6 - anyone who's going to get confused by these things already is.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
ERH makes some excellent points in the article, which happens to touch on a couple of issues I've felt is mediocre in Java, but moderately cool in the .NET Common Language Runtime - things that could do well in being transplanted into the Java language and runtime.
The .NET CLR, being a relatively recent creation has naturally gotten the benefit of 20-20 hindsight. Two area that it seems to do better than Java is of course, class versioning/loading and the issue of primitive types in Java.
For those of you who aren't familiar with C#, it implements it's primitive types as "value types" (as opposed to the familiar reference types we know and love from both Java and C#). Value types are passed by value (but can be boxed if you need to take a reference to an instance of a value type). The .NET CLR type system imposes some restrictions on what you can do with value types (I can't remember what they are offhand, sorry), but they enable value type instances to take up a very little space, making them virtually as efficient (time and space wise) as the "atomic" primitive types currently in Java. Would the introduction of primitive types as classes be so inefficient as other posters are claiming. I think not.
In the .NET CLR, you don't have no bloody CLASSPATH, but you do have two types of assemblies (private and shared), assembly probing (standard "protocol" for searching for dependancies of a given module), a powerful way of tweaking module loading through user-written configuration files, and a neat versioning model.
I highly recommend all haters of Java's class loading mechanism take a look at how the Microsoft people have done it. This is seriously good work.
MSDN: How the Runtime Locates Assemblies
>>Really there's no overwhelming reason the primitives can't remain as built-ins. They just need to behave in the same way as objects.
What do you mean in they have to behave like objects? So do they become garbage collected like regular objects? Can I serialize them? How about extend them? How does the equals() work?
it is true that there has been a horrible lack of discipline. Many times not just with IT or technology in general, adversity and difficulty beget innovative solutions. However, when it becomes 'easy' then people get lazy. Complacense is rarely if ever good.
There are many out there that enjoy the 'career' of IT because they genuinely like it. If they have bad habits it is not correct to judge that they have them because of lack of trying. perhaps if instead of hacking, people would then PLAN systems? What follows is; instead of just throwing languages out, perhaps people could teach proper methods, provide standards and actually have the discipline to interoperate and provide modular extensions to apps and services instead of creating thousands of little craplets that don't mesh.
offtopic now, but if the next time you see a gap in features or 'look' then please consider adding to existing projects. At the very least, please consider the very real (as in real life USE) situation that many will eventually want to use said app WITH others.
Microsoft would like nothing better than for Sun to release a version of Java that isn't backwards compatible. That would give them two options:
1) Stick with the old Java 2 VM for a really really really long time, claiming backwards compatibility, and watch Sun fall on its face, or
2) Upgrade to Java 3 immediately and watch everything break.
Either way they obey the letter of the law, and it gives MS an opportunity to really push C# as developers get frustrated with the transition.
May I suggest to include SWT into next release, this GUI implementation is far more superior than Swing, much cleaner and faster. For more information please go to: www.eclipse.org
http://dtum.livejournal.com
In several decades of programming (assembler, fortran, algol, PL/1, C, C++, ...) I've never had code written in one year fail in the next.
You must not have done much work in C++ or C. The K&R C to ANSI C transition broke many of my programs, and C++, well, all I can say is that I remember having to make changes to my C++ code almost every time a new compiler version was introduced in the early 90's.
removing confusing and unnecessary classes like StringTokenizer and StreamTokenizer
wtf? obviously this guy has never parsed anything in java. StringTokenizer is infinitely useful (though I must grudgingly confess to liking c#'s String.split(char[]) method). StreamTokenizer is much harder to use, but very helpful for parsing CSV files.
geez, don't throw the baby out with the bathwater. that includes leaving my primitives in place too.
reech bee-yond ur clip-0n
1. Emacs is better than vi.
You almost had me until that...
I love Java's simplicity, and wouldn't mind to keep it as it is (although I WOULD adopt the proposed changes for Java 3), but the following is what drives me nuts: Three COMPLETELLY different ways to get the length/size of things:
myArray.length
myVector.size()
myString.length()
It also drives me nuts having to convert all the time between the primitive data types and the Object data types (int/Integer, long/Long, etc).
Other than that, even with its current flaws I simply have to love Java (I guess is like being married to someone who is not perfect, but that you wouldn't change for anything in the world...)
10. Delete all deprecated methods, fields, classes, and interfaces.
While I would also like to see these die, to tell the truth, Java has done an above average job here. In most other (should I qualify that as "practical") languages, there isn't even a concept of deprecated. Deprecated is your client calling you up and telling you something is breaking in a weird way and you say "oh yeah, don't use that". In Java when you deprecate something it means something. The compiler compiles in a flag, and anything that is built against deprecated methods, the compiler will spit out a big fat "THIS IS DEPRECATED" warning. You can't do much better than that. So while I'd like to see these things gone, the reality is that there is a lot of code that is using them, and they really aren't doing much harm. The most "harmful" are the deprecated thread operations. Everything else has mostly been for name changes or additional functionality. Take the most out of your own eye first and all...
This is just a library issue, not a language issue.
9. Fix incorrect naming conventions.
Amen. Given that we adhere to whatever we resolve to do with deprecations, fine. But again, Sun has done a terrific job, and if you look through the libraries, I'd say 90% or greater (including deprecated stuff) adheres pretty well to the standard. Again, this is just a library issue, not a language issue.
8. Eliminate primitive data types.
What you want is "boxing" (like C#/.NET/CLR does), and they're already working on it: RFE 4609038 Request auto boxing of primitives in Java.
7. Extend chars to four bytes.
Meh. I don't use Unicode that much, so it's not as relevant to me, I'll trust you on this one. Just don't bloat up good ole US-ASCII character strings.
6. Fix threads.
I generally agree. The first 5 bullets are pretty trivial. I have never ever run into a problem when using threads, even with complicated synchronization implementations. The last bullet is already possible: write your own damn monitor! Nobody is stopping you as long as the sychronization primitives work. Here I'll give you a clue: custom monitor implementations. Easy as cake. I'm not sure what the author is really asking for here. Sun cannot possibly make every single implementation of a monitor somebody would like (ok, well, it *could* but why?). It gives you the primitives and you go from there. That is why you are a programmer.
5. Convert file formats to XML.
No no no no no no NO. XML is not a panacea. Please DON'T turn everything into XML. The formats that exist (properties format, manifest format) are simple and designed for their purpose. XML has its uses, and simple, flat, non-hierarchical, terse data, which has absolutely no expectation of being rendered visually or translated into another form, is not one of them. I don't see any REASON being proposed other than "everybody is using it". Well, if everybody jumped off a bridge...
4. Ditch the AWT.
Meh. I have a better one. Replace AWT with a natively back-ended Swing or Swing-like API, akin to IBM's SWT. Swing is a lovely API, but it is cumbersome to lug all the libraries around, and it is slow. SWT is a nice compromise (nice high-level abstract, generic, Java API - to the metal native implementation).
3. Rationalize the collections.
This is basically an argument against the deprecated classes, for which there are already replacements. I don't see much wrong with the Collections API (i.e. java.util 1.2+), and when generics arrive, it will be much more useful (no tedious subclassing or casting to contained type). The author is making some fuzzy argument that the Collections APIis not cuddly enough or something. It's a starting point - it has the most used structures (hashtable, linked list, growable array, etc.). If you don't like them, feel free to subclass or write your own. They are fine for me, and certainly don't rank up at 3 as far as complaints to Sun go.
2. Redesigned I/O
A bunch of non-arguments here. Again, for something like 90% of the time, this is going to do you just fine. Please DON'T sneak buffering into classes which do not announce this fact. This is the charm of composition, and I think it works nicely. Want a stream buffered? Wrap it with a buffering stream. Want a stream GZipped? Wrap it with a GZip*Stream. Anyway, there IS a new IO API, which promises much better performance (introduces asynchronous I/O), java.nio.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Agreed. This is getting to be a headache. Especially when deploying in application servers/servlet engines that have their own custom classloaders. There probably isn't a good solution other than good documentation, and reduction of unnecessary conflicts when security is obviously not an issue (the whole reason of seperate classloaders to begin with).
Summing Up
Well, this article is largely gripes about the library not the language, and where it gripes about the language, those gripes are already being addressed. I would complain about things like, methods not being first-class objects (callback classes are really annoying), unspecified symbol resolution in the language spec, inner classes not being allowed to have static declarations, lack of enumeration type in the language itself, interfaces unable to declare overridable fields, array types being pseudo objects when they could instead be easily made to be real objects which could be subclassed, etc.
It's 10 PM. Do you know if you're un-American?
If it was open source we would already have multiple versions of Java and they would all be incompatible with one another. You would have the neat freaks going with a version of java that has the articles fixes, and would completely ignore backward compatibility (Because after all were going to do RIGHT this time!), you would also have the hacker crowd who would make Java++# that would include pointers and remove garbage collection and also make it incompatible with existing code. (Because they are making it RIGHT as well).
In a few years the language would be forked just as bad as C.
Thank God Sun hasn't Open Sourced it.
Sounds like most of the author's complaints have been addressed 20 years ago, in Smalltalk. Now maybe if Gosling had done his reading.....
Talk Small and Carry a Big Class Library
Multiple inheritance of implementation has absolutely no major problems. If you have a conflict in a derived class, you can simply rename one or both functions in its interface. When your object is used as a base class object, it advertises the base class interface, and when it's used as a derived object, it advertises the derived interface, with the renamed features. If your derived version wants to provide an override of either or both base classes' implementation, you can always do so. None of this violates the Liskov Substitution Principle, or any other OO design rules. The only reason languages don't support MI is because it would break their object model or something that depends on it, not because of any theoretical flaw with MI itself.
I agree, often MI is not the right answer to a design problem. But when it is, it is. If your type genuinely can be interpreted as more than one base type and behave as such, multiple inheritance is the correct relationship to model that.
Indeed. The arguments against operator overloading are bizarre to say the least. "We don't like artificial operators!" they say, as they concatenate their strings using the + operator, while writing z1.addTo(z2) to add two complex numbers.
Added to which, as I've argued here before, operator overloading is a very important complement to writing generic algorithms. If I want to write a generic summation algorithm that can add the elements of an array of any type, is it more sensible for me to write it using the natural + notation and provide the ability for complex numbers, rational numbers, fixed point numbers and such to implement that operator, or is it smarter for me to hope that everyone gives their classes a method called add, and not addTo, sum, increase, or bananaMilkShake?
I agree entirely about the low-level features (hide them, don't make them part of a language like Java) and templates. Templates is a particularly glaring omission, and even the proposed generics aren't really up to the job of basic generic programming AFAICS. C++ IOStreams may suck because they gave every method a stupidly obscure name and no-one understands them, but compared to Java's "five lines of bizarre OO to read a string from the keyboard" approach, it's a godsend. A little generality would probably go a long way here, aside from improving things like the container class situation.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If the price of not pissing off the current user-base is to support some deprecated functionality, then I really think that the good outweighs the lack of asthetic simplicity of not having deprecated methods.