Now making the rounds in Slashdot, blogs and email the internal memo from Sun regarding problems with the Java language.

Being a Java developer I have a bias towards Java. The memo however, is justified in a lot of its comments. Don't run for the hills just yet though. This is constructive criticism that should be looked upon as a way to make some serious improvements and think about the next evolution of Java. Slashdot readers love to dump on Microsoft whenever internal critique comes about, but I'd be more scared of a company that thinks their product is perfect and makes no serious examinations of its flaws.

The idea of Java is fantastic but the implementation falls short first in the area of performance and second in implementation. It's time to stop making excuses and put up or shut up. That said I'm still sticking with Java. The ability to rapidly develop applications with easier debugging and a fantastic library and documentation at my disposal is enough to sell me.

In response to the major points:

"The JRE is very large"

This is a bit misleading in my opinion. I think what they mean is that the JVM can take a significant amount of memory during runtime and is slow with several applications noted. I assume this since a compiled "Hello World" class file would not be anywhere near 9MB as indicated. The size of the JVM is an issue that is separate from the language itself but quite effectively points out that the model for bytecode execution needs some serious examination. The scope of this is quite beyond my level of understanding of the JVM at this point in time. Comparing to Python may be significant although I'm not familiar with Python to determine if it is appropriate.

"Extensions do not support modularity".

Convenience dictates that extensions (javax.*, etc) be put into the main JRE distributions. I think this unnecessary inclusion of optional classes is wasteful. The various Java packages are separate enough that developers can include the .jar files along with their application. This also creates dependency problems as packages such as XML parsers that were once in an application's library are now in the JRE and conflicts arise. I don't know how to back out of this scenario other than to stop adding unnecessary extensions and give precedence over application libraries.

"It is not backward-compatible across minor releases"

The JRE release number has always confused me. JRE 1.2 is Java 2 1.0. Huh? Shouldn't this be Java 2.0? Well yes and no depending on where you draw the lines. In a lot of cases there is backwards compatibility but not in all as the memo points out. Regression tests would be nice. Upgrade to a 2.0 or better yet 3.0 to avoid confusion with Java 2 and start over from there. Make sure that all methods and classes are backwards compatible and that point releases are either an addition of functionality or major bug fixes.