In part two of this series, I demonstrated the effect of erasure on type parameters within the body of a class. I used examples to show how type parameters were limited to accessing methods of the root
Object class irrespective of the actual type with which it was replaced at a later time.
Java's generics is implemented using erasure which is a mechanism that removes specific type information within the body of a generic class or method. Essentially, when you instantiate a generic class with an actual type, the syntax within the generic class would suggest that every occurrence of the type parameter
In computer programming, generalisation is understood to be a noble pursuit and a fundamental tool for achieving reusability, the idea being that a programmer can be more expressive when he has tools that work with many types.
Runtime type information (RTTI) refers to the correct identification of the type of your objects at run time. When you write code, it is generally desirable to do so in a way that takes advantage of OOP features like encapsulation and inheritance to make your program easily extensible, by for instance, as much as possible manipulating references to base classes and letting polymorphism work for you. Essentially, when you create a new object with a base class reference, the process necessarily involves an upcast to the base class from a more specialised type.
The manipulation of strings is a quite common activity for which the programmer undertakes responsibility fairly frequently. In Java, strings are of a distinct data type, that are implemented as literal constants.
In this post, I try to give a reasonable account of Java's error handling system being as it is that the handling of errors is a concern that any reasonable programming language must find some way to contend with. Java's error handling methodology is based on an idea of exceptions.
If you have followed previous posts, you might begin to perceive a pattern in the semantics of the Java programming language. If not, it might help to go over previous posts as I tend to return to expand on previous topics or add clearer examples as time permits. Inner classes might at first seem like a whole new language to the uninitiated but they are a nice feature in Java that allow you to logically group related classes and control the visibility of one class from outside of the other.
In the normal course of solving a general programming problem, it is almost certain that you will become compelled to create, and identify useful ways by which to hold any number of objects within your program. In Java, you are normally inclined toward the array as the natural choice for holding a group of primitives, but this has the obvious limitation of being of a fixed size, whereas, under normal circumstances, you are unlikely to know before hand, the number of objects, or indeed anything about their type before run-time.
Interfaces are completely abstract classes in Java that provide you with a uniform way to properly delineate the structure or inner workings of your program from its publicly available interface, with the consequence being a greater amount of flexibility and reusable code as well as more control over how you create and interact with other classes.
In object oriented programming, polymorphism is a feature that allows you to provide a single interface to varying entities of the same type. This is analogous to the interpretation of the same concept in the field of Biology.
To understand how this works in Java, we must consider inheritance and the ways by which the Java programming language makes method calls.