• Choose a category
• All
• Classic-Fiction

By Root 638 0

You could call the array element anything you want. To fix this, Java introduces an ugly implementation of a feature called generics . Here's what the usage looks like:

ArrayList animals = new ArrayList();

animals.add("elephant");

String elephant=animals.get(0);

Comparing the preceding code with its nongeneric equivalent, you may think that you avoided casting, but you really did not. Java introduced an ugly implementation of generics, called type erasure. Under the hood, in the modified version, the ArrayList still maintains a collection of Objects and not a collection of Strings. Of course, any library that you need to strongly type with user-defined types must enable the code for generics. Enabling generics gets a little ugly. Here's the List declaration from within the Java collections package:

public interface List { void add(E x);

Iterator iterator();

}public interface Iterator {

E next();

boolean hasNext();

}

If you're not a fan of statically typed languages, you don't like the extra type checks that place yet an additional burden on you. Even if you like the idea of generics, you probably don't like the implementation. Generics offer only syntactic sugar and not real runtime protection, because the JVM has no concept of generics. In an article series on agiledeveloper.com,[*] Venkat Subramaniam lays out the problems in gory detail:

You lose type safety when you mix nongenerics with generics. For example, List notGeneric = genericList; type safety would not flow into notGeneric, even though it's bound to the same list as genericList in memory.

You can't use primitive types as parametric type or static fields of generic type.

Instances of different parameterized types (like ArrayList and ArrayList) belong to the same type ArrayList.

Since the JVM has no notion of generics, other classes won't be able to take advantage of generics via reflection.

So, if you're protected at only a superficial level, and if new languages can't participate in the solution, the syntax only serves to further burden users with details and inconsistencies, prompting the question, are generics a solution begging for a problem? When I ask my students how many class cast exceptions they get from collections, very few say this is a significant problem.

Ted Neward: Generics

Author of Effective Enterprise Java

Ted Neward is an independent consultant specializing in high-scale enterprise systems. He is an author, teacher, and consultant, focusing on Java .NET interoperability. He has written several widely recognized books in both the Java and .NET space, including the recently released Effective Enterprise Java (Addison Wesley). He lives in the Seattle area with his wife, two sons, two cats, and eight PCs.

What's wrong with Java, in general?

TN: Hordes of developers are writing code that doesn't fit well with the tools and technologies they're using to build applications, pronouncing the tools and technologies "ugly and unusable" and going off to reinvent the wheel.

What's wrong with Java 1.5 ?

TN: Java 1.5 demonstrates a general attitude against progress, and Sun adamantly refuses to advance the JVM whatsoever, preferring instead to maintain the fiction that the Java language and the JVM are one tightly coupled entity.

Do you like the implementation of generics?

TN: No. The fact that they're implemented at a language level, rather than at the JVM level, means that under the hood, it's all still just Object references, so:

Other languages have no concept of generics.

We get no performance boost from generics.

We have to have some sneaky backward compatibility that still permits use as Object references (which you might argue would be necessary anyway, and I'll suggest that the Object-reference versions should be deprecated in 1.5 and removed in 1.6).

Overloading

In some ways, Java's typing problems are exacerbated by another limitation described as a feature: method overloading . Taken alone, overloading is not a huge problem,