Results 1 -
2 of
2
Compound Types for Java
, 1998
"... Type compatibility can be defined based on name equivalence, that is, explicit declarations, or on structural matching. We argue that component software has demands for both. For types expressing individual contracts, name equivalence should be used so that references are made to external semantical ..."
Abstract
-
Cited by 24 (3 self)
- Add to MetaCart
Type compatibility can be defined based on name equivalence, that is, explicit declarations, or on structural matching. We argue that component software has demands for both. For types expressing individual contracts, name equivalence should be used so that references are made to external semantical specifications. For types that are composed of several such contracts, the structure of this composition should decide about compatibility. We introduce
Java needs compound types
, 1998
"... We propose to extend the Java type system with a new construction: compound types, compositions of a class and any number of interfaces. Java users will benefit from the type system’s increased expressiveness, resulting in more kinds of errors being statically excludable. Compound types are particul ..."
Abstract
-
Cited by 6 (2 self)
- Add to MetaCart
We propose to extend the Java type system with a new construction: compound types, compositions of a class and any number of interfaces. Java users will benefit from the type system’s increased expressiveness, resulting in more kinds of errors being statically excludable. Compound types are particularly beneficial when several independently predefined standards need to be considered, as typically required by component software. Compound types are a strict extension of Java, i.e., existing programs need not to be modified. Our proposal can be implemented using the existing Java Virtual Machine. Our scientific contribution is a new combination of name and structural type equivcalence, which our Java extension exemplifies. Type matching is decided by structural comparison of compositions of named types; the latter being only compatible if explicitly declared so. This concept is applicable to several other languages than Java, as well. We support the feasibility of our proposal by a formal and mechanically verified proof of the extended type system’s soundness.

