I find it interesting that James Waldo has written a book (nicely promoted here on the 'ranch) about the good parts of Java. I've been writing Java since '98. I started with the O'Reilly Java Nutshell book, which was tiny for version 1. Since then, Java the language has been expanded in each release. More importantly, ever six months or so, a new library or framework is released with claims to add all the features that Java is missing.
The result is a huge complex language environment, so full of stuff that folks like Mr Waldo had to write a book on what parts are good.
I think we need a book on which parts suck. Which are bloated bad ideas left over from what may have been a good idea at the time, but have been shown in real world usage to not work. The original NIO (new IO) is a classic example of a big feature set that never delivered. Another hideous legacy is the "java.util.Date" class, that does nearly none of the functions you expect a good Date object to do. I won't even mention J2EE, an idea so bad that even the Java community changed the name to protect the guilty.
Something tells me that you have been hurt in the past...
I'll be the first to admit that there has been a lot of crud that has accumulated in Java over the years. The libraries have expanded in a fairly random way, and lots of people have argued (many successfully) for the inclusion of something that came from their previous favorite language so Java could look more like something else. All bad things.
But I think the core of the language is still decent, and one of the reasons for my book was to remind some folks of that. You can always ignore a library, but bad changes to the core language (some of which have happened) impact everyone. I still find Java an enjoyable language in which to program (and I've been using it since '94, when it was called Oak, so maybe it is just habit), but there is a lot of the overall environment that I don't use.
What is important is to write code that is correct, concise, and that other people can read. That can still be done in Java. But it requires taste, restraint, and practice. Much like any other craft.
Jim Waldo wrote:lots of people have argued (many successfully) for the inclusion of something that came from their previous favorite language so Java could look more like something else. All bad things.
I'll even argue that raw data types, int, long, float, etc. were a bad thing brought in from C so that people would think that going from C to Java was easy. A very bad thing, IMHO.
Its really sad that with all the language design experience that the world had, that early Java got so many things wrong, which drove later designers to "fix" them. I consider generics to be a key feature, yet it really suffers from being added in late to keep "backward compatibility" and as a result, some of the syntax to describe bounds on arguments is simply bizarre. Type-erasure does no one any favors.
Its not that its impossible to write clear, correct, readable Java, its that it is so hard to do.
I just ran into another of the bad parts. Compare the format strings/encodings in java.util.Formatter to java.text.DateFormat. Why are the meanings of the same character different? Formatter uses capital Y for a four digit year, and a lower case y for a two digit year. DateFormat uses lower case y for both. There is no way to memorize which is which. Sigh.
Joined: Jun 22, 2011
Pat Farrell wrote:I just ran into another of the bad parts. Compare the format strings/encodings in java.util.Formatter to java.text.DateFormat. Why are the meanings of the same character different? Formatter uses capital Y for a four digit year, and a lower case y for a two digit year. DateFormat uses lower case y for both. There is no way to memorize which is which. Sigh.
If this were the worst thing in Java, I would be pretty content. Compared to, say, the security model(s), this is pretty minor.
This is really more an indication that a lot of people (and a lot of companies) have worked on Java and the associated libraries. While the JCP is pretty good at reviewing the big stuff, inconsistencies like this will creak in. Once in, they are hard to fix without breaking some/lots of code (and making a lot of users unhappy). It is worthy of note, and perhaps a sigh and a curse, but it isn't really a biggie...
Jim Waldo wrote:It is worthy of note, and perhaps a sigh and a curse, but it isn't really a biggie...
I agree that its not the worst of the bad parts.
But one of the hallmarks of something that is well designed is that you can learn to use it by analogy and composition. And as Java has grown, its more like a frankenstein language. Things that are very similar just don't work the same. A clean slate replacement could trivially fix things like this.
This stuff is a death by a thousand paper cuts. It crushes programmer productivity. It just does it a tiny bit at a time for every programmer every day.
On the Devoxx conference last year in December, there were some boards with questions with multiple choice answers that you could add marks to, to indicate which answer would be yours.
One of the questions there was: Should there be incompatible changes in a future Java release?
Sun and Oracle have always been extremely cautious about backward compatibility whenever a new Java version was released. Some things in the standard API are deprecated, but nothing has ever been removed from the standard library in a new release, because of fear of breaking backward compatibility. Over the years a lot of bad stuff has accumulated in the standard library that would better be removed or rewritten. Examples are the Date and Calendar API which is not very good, and stuff that was written before generics were added. (For example, Map.get() takes an Object, which is horrible, because it is totally not type-safe, even if you've specify the type of the keys that you're using for the Map).
On the Devoxx question, the answer "Yes, there should be incompatible changes" got by far the most votes. So there are a lot of people who would love to see deprecated and other bad stuff be removed.
I hope that when the module system is added in Java 8, it will become easier to make breaking changes in the standard library. The module system will include version numbering. So I can imagine there would be a version 7 module of the standard lib, and a version 8 version which has incompatible changes. If you'd need your code to work with older Java versions, you would use the v7 module (on the Java 8 JRE), and if you'd want a newer, cleaner version you'd use the v8 module. I don't know if it's going to work like that, but that would be a possibility.