The case for run-time types in generic Java

  • Authors:

  • Eric Allen;Robert Cartwright

  • Affiliations:

  • Rice University;Rice University

  • Venue:
  • PPPJ '02/IRE '02 Proceedings of the inaugural conference on the Principles and Practice of programming, 2002 and Proceedings of the second workshop on Intermediate representation engineering for virtual machines, 2002
  • Year:
  • 2002

Quantified Score

Hi-index 0.00

Visualization

Abstract

Since the advent of the Java Programming Language in 1995, many thoughtful proposals have been made for adding generic types to the Java programming language. Generic types are a glaring omission from the existing language, forcing programmers to use permissive, non-parametric type signatures for fields and methods of "naturally generic" classes (such as java.util.Vector) and repeatedly cast the results of operations on these classes to the more specific types. The JSR14 extension of Java proposed by Sun Microsystems (based on GJ) addresses this problem by adding generic types to the language, but prohibits operations that depend on run-time generic type information. This prohibition relegates generic types to "second-class" status where they are invisible at run-time, which is inconsistent with the status of types including parametric arrray types in the existing language. We have implemented a generalization of JSR14 called NextGen that supports the same syntactic extensions of Java of JSR14 yet eliminates the prohibition on operations that depend on run-time generic type information. In NextGen. generic types are "first-class": they can be used in excactly the same contexts as conventional types. The implementation of NextGen compiler is derived from the same prototype GJ compiler as the JSR14 compiler and shares most of its desirable properties including a high degree of compatibility with legacy code. In this paper, we show through of a series of programming examples that first-class generic types play an important role in writing clean generic code.