Top Most The Death of Java - Generics

Java has been dying a slow death for some years now. Competition from higher productivity languages has forced Java to market "Java as a platform", rather than Java as a language. Businesses can take advantage of the benefits of the JVM while having the freedom to choose from a variety of programming languages.


The classic challenge of any software is to add new features and paradigms while maintaining compatibility with existing solutions. Over time this challenge results in either the death of the software or a new release that forces users to "freeze" their upgrades until they complete a "conversion".

Neither of these options are appreciated by users.



Generics are a good example of how Java is dying. What seemed like a good idea has, in my opinion, backfired. To understand this, we need to understand how we got here.

Type-safety
Many years ago IBM introduced a programming language designed to replace all others with a single language, and called it PL-1 (Programming Language One). PL-1 was designed to be powerful, yet it failed for a simple reason: it was very easy to code bugs.

Languages evolved to improve this situation, and one of the most successful features was type safety. Simply put, type safety meant variables could be declared as having a type (string, integer, etc.) and the compiler would produce errors if the programmer tried to use that variable as a different type. Strongly typed languages forced programmers to specify the type of all variables.

Interestingly, bugs were reduced by restricting what a programmer could do.

Java's type safety
The term strongly typed became muddled over the years, and zealous programmers engaged in lengthy debates arguing over semantics. Java is, by design, strongly typed. However it is also Object Orientated, using the classic "everything descends from a single object" paradigm. So there is nothing preventing programmers from declaring variables to be of type Object, which neatly defeats type safety.

Collections
Java 3 provided the Collections framework, an implementations of common data structures (lists, sets, maps and bags). Designed for maximum usability, collections store references to many types by declaring much of it's api to be of type Object.

What was the problem with Collections?
Collections were not type-safe. Let's say a developer creates a collection of strings. Later on she (or someone else) starts storing numbers in the same collection. This usually results in bugs since the existing code assumes that the collection contains strings.

Generics come to the rescue!
With the release of Java 5, the generics feature fixed this hole for collections (and in general). Programmers could write API's that support any type, yet enforced type safety at compile time. Awesome, right?

Pragmatism gets in the way
There are two serious flaws and one minor issue with generics.


Minor issue: Generics only work at "compiler time". It is possible to break generics at runtime. This may sound like it is more than a "minor" issue, but see below.

Flaw #1: Adding generics to code makes it more verbose, more difficult to read, and reduces productivity.

Flaw #2: In over 12 years I've performed many hundreds of Java code reviews and observed thousands of bugs reports. In all this time, I have never seen a bug that generics would have prevented.  I'm sure there have been some, but I haven't seen any.

Trade-off
The trade-off is reduced productivity, less readable code and more verbose code, to prevent an issue that never happens. Yet every Java shop I know of requires generics!

What sounded like a good idea, in my view, has only hurt the language.