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
1. speed
2. speed
3. speed
4. speed
5. speed
6. speed
7. speed
8. speed
9. speed
10. profit
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 find it frustrating that I can't wring out every last bit of performance from whatever CPU I'm coding for.
Um, isn't one of the key selling points of Java portability?, allowing programmers to write code for a specific (family of) cpus would utterly break that..
I always wondered why Sun didn't make compilers for the most common OS'es. So we'd have something like this:
.. or .. .. etc.
Java Source -> Bytecode -> Windows
Java Source -> Bytecode -> Solaris
Not only the source would be portable, but also the bytecode, as always. No changes, just a damn bytecode compiler. Of course, the java interpreter should still be included if you for some reason didn't want to run optimized code for your CPU or had a CPU that wasn't supported with specialized native code compilers.
The only thing that would mess things up would of course be if someone just distributed the native compiled code, but wouldn't that be just a brainless thing to do since if you included the bytecode everyone would be able to use it?
???
Beware: In C++, your friends can see your privates!
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.
So I say the Smalltalk way is easier to use, there is only one integer type when doing computation, yet I can do I/O with integers in all formats I want (8-, 16-, 32-, or 64-bit, signed or unsigned, big-endian or little-endian). If high performance is required, maybe C-like types can be added too, used only in speed-critical things.
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
java allowed you to increase productivity, substantially?
according to this whitepaper, when developers are given their preferance of language to use to implement a solution, they're most productive. ie, someone who knows c++ and enjoys working in c++ will be just as productive as someone who knows java and enjoys working in java.
i'd be extremely interested to see some concrete independant studies showing otherwise.
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).
Well, tell them to get fucked and go and read the Java tutorial then!
Hey, it's hard to figure out the classpath! You need to take the dots and change them into slashes, for crying out loud! And never forget the classpath is relative to the base directory! my head hurts... *sob*
Beware: In C++, your friends can see your privates!
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
Multiple inheritance has major problems (if both superclasses have the same function, which one do you use?). A much better answer is often to use "Composition", where the class you are writing contains both of the superclasses that you want to extend, and have your class manually delegate to which ever one of the classes you want to perform the operation. See the "Inheritance versus Composition" section of "Design Pattern" for more details.
Operator overloading
I agree that it is a shame that this was not included. The usual arguement against them, that it's very easy to change the semantic meaning of an operator and this can confuse developers, is just as applicable to an "add" method, but I don't think it's a devastating loss to the language.
Pointers and direct memory access:
Ye gods. No. The moment you start doing this is the moment Java stops being cross platform, and this is a far more important feature than the extra performance that you could squeeze out of it with direct access. Since they sorted most of the performance issues out, I've rarely seen an app where there was any noticable issue in the speed of the actual java code at all (speed of DB link/RMI from overuse of EJBs are much more likely to be problems and unlikely to be sorted out with direct memory access. If you really need to do it, then write that bit in C or assembler on your native platform and call it using JNI. It's messy, but it makes sure that you really think about whether you need it or not.
You seem to have missed the biggest C++ related ommission from Java - templates. The ability to create typed arrays using a single line is something that Java would really benefit from.
So much for proof reading. :)
This is a refreshing view on changes to Java, because it doesn't make the traditional calls for templates, a preprocessor, and operator overloading. Most of the article is well considered and logical, and should be implemented in a move to Java 3.
There are however some issues with which I must disagree:
While the overhead of promoting all primitive types to objects may be insignificant, the overhead of checking all arithmetic for overflow does have the possibility of causing significant overhead.
Not only that, but you will still end up with a RuntimeException, because you cannot expect ALL arithmetic to be in a try
Overflow errors are a well known problem - well-written software should not suffer from them.
Many Java developers are caught by using code like b = (byte)i; rather than b = (byte)(i & 0xff);. It is generally true that when dealing with bytes, you want to keep data as bytes until you explicitly make it into another type.
Finally, byte arithmetic should always overflow, as is expected in CPUs.
While J2ME is not fully Java-compliant (no floating point support, for example), it still largely conforms to the write-once test-everywhere rule, and this is part of Java's attractiveness.
More memory is not always a good solution. Java's garbage collection architecture is very wasteful of memory at the best of times; at the worst of times you are using immutable objects like Strings, so you can't pool or reuse the objects. As increasingly more applications handle text because of our new XML obsession, this situation becomes worse.
Java implementations typically do not emulate threads on their most common platforms - they make use of the native threading model of the operating system. This means that making a 64-bit operation atomic must involve the use of a lock; so instead of a 64-bit operation taking up 4 times the time of a 32-bit operation, it could take that plus two calls into kernel space.
As mentioned before, the same is true of using arbitrary-size numbers. Only a number that the CPU can treat atomically will result in an atomic operation without additional synchronisation.
Thus, to have different types of operations (all implemenented in one object) synchronised on different locks, simply use each in an explicit synchronisation block and have private or protected lock objects specifically for that purpose.
Decoupling monitors from objects would kill a lot of the ease-of-use that makes Java threading such a pleasure by comparison to many other models.
Furthermore it ONLY has monitors as locking primitives, which rules out the use of overlapping locks, which are one of the few effective synchronisation primitives which can overcome weakly-defined scheduling.
Java would do well to add an additional synchronisation primitive - either mutexes (as error-prone as they are), or interlocked increment-and-compare (which can solve a number of synchronisation problems far more effectively than mutexes).
For a better critique of XML take a look at http://www.eastcoast.co.za/twylite/pml/pml.html" >my anti-XML page (incomplete, but the anti-XML rationale is presented).
In particular, XML is a very poor choice for the encoding of Java objects, because of its lack of terseness, and the relatively slower speed of parsing XML - both of which impose significant penalties in a distributed environment.
Some hard facts to back up these claims: in an application I have worked on, we experimented with SOAP instead of our original binary protocol. The result was a 80% decrease in call rate.
In a few years, the XML phenomenon will wear off, and world+dog will wonder why we are wasting our precious bandwidth on all the overhead. Already WS developers are starting to wonder how it will affect their resources, and we have proposals for a binary encoded XML for the mobile world.
This "simple" specification is too complex and too overkill for most tasks, so every "lightweight" XML parser on the market conveniently leaves out certain parts of the specification - be it DTD, PI, CDATA, whatever. We already have XML documents that aren't compatible between two parsers, the situation will only worsen.
And in the end we will realise that it isn't necessary to make computer data human-readable, because really, everything is just a bucket of bytes and a rule on how to view it, and XML is a very, very poor rule.
Java is not perfect. It is not a silver bullet, and it is certainly not everything to everyone. Instead, it offers an environment that, to a lot of people, is a damn sight better than C++ because it avoids the error-prone complexities and power of the latter. But you must accepts its weaknesses as a trade-off.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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. Java 2 isn't big enough.
9. Cool 3D-glasses marketing gimick potential
8. We can all complain more when MS doesn't support it.
7. Library need another complete overhaul of the GUI classes.
6. Add in all of the C/C++ features that we're left out.
5. O'Rielly can sell another series of books (how about a fungus?).
4. Since all of the people who know Java 2 are unemployed, this project will keep them off the streets and out of trouble.
3. Java doesn't have enough incompatibility issues as it is. We need to level the playing field.
2. 'Cause the alternative is caving in to C#.
1. Emacs is better than vi.
Someone you trust is one of us.
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.
Coming in J2SE 1.5, by all accounts. A "preview" compiler implementation is available from developer.java.sun.com.
> Multiple inheritance has major problems (if both superclasses have the same function, which one do you use?).
Well, in well-defined language (Eiffel), this isn't a major problem: the developer have to solve by hand the conflict and that's all.
> >Pointers and direct memory access:
> Ye gods. No. The moment you start doing this is the moment Java stops being cross platform.
Pointers and direct memory access are two different thing.
Pointers in themselves can be used without preventing cross platform portability.
As for direct memory access, it's true that it is against portability, so what?
JNI are also non-portable but it doesn't mean that we should totally get rid of JNI.
As for the end, I agree: the lack of template in Java is quite annoying.
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.
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.
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?
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.