Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Essentially type safety and convenience.</p> <p>Java implements its generics by a mechanism known as type erasure which effectively replaces the generic definition with a non-generic definition at compile time. The reason this was done was to maintain API compatability between 1.4 and 1.5 - the collections API may well have been updated but if you accessed it in a non-generic way in 1.5 it would work the same.</p> <p>The difference was that if you intended a collection to only contain particular types of objects you could explictly encode that requirement in your APIs and avoid issues such as receiving a list with the wrong type of objects in it - and also the need to have to explictly cast those objects making your code simpler to read and less error prone.</p> <p>You would use the generics for essentially the same reasons as when they are used with collections - when you need to say that an object is a composite of other objects, but that there may be a range of types possible for that composition and that once bound the addition of these new objects implies a new composite type disimilar to other similar composites. That is to say a list of strings is similar in type to a list of integers but they are no longer compatible with each other.</p> <p>One example of this is in the <code>Future</code> where you are waiting for an asynchronous result. The <code>Future</code> class encapsulates the concept of the asynchronous result, but the specific type of <code>Future</code> such as <code>Future&lt;String&gt;</code> futher specifies what type of result you can expect - and makes it distinct from <code>Future&lt;Integer&gt;</code>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload