Welcome FAQ Download Papers Links

Questions About Kacheck/J and Confined Types


What is a confined type?

A confined type is a type that meets the criteria for confined types given in the papers. These criteria then provide the following guarantee:

"Code outside of the package a confined type T is defined in cannot get a reference to objects of type T, except for the this reference in inherited methods."

Or less strictly, objects of confined type do not escape their enclosing package. This is desirable for many objects from a software engineering or security perspective. See also Why should I care about confined types?

What is an anonymous method?

While the exact definition of an anonymous method has evolved over time, the key idea of an anonymous method has stayed the same. A method is called anonymous if invoking it on a confined type does not breach encapsulation. Method invocations are difficult to handle because due to dynamic dispatch they may invoke inherited code where the static type of this is not the confined type.
If these inherited methods, that may also be defined outside of the confining package, leak the this reference, they are called non-anonymous.
A method will always be anonymous if it does not use this as an argument, store this in a field or return this. Native methods are never anonymous.

Why should I care about confined types?

Confined types allow you to increase the modularization of your code. As objects of confined type to not escape their defining package, you can be sure that no code outside of the package will depend on the interface or implementation of the confined type.
Thus it is generally desirable to have a high number of confined types in your code. Kacheck/J allows you to analyze your code for confinement and can print violations. Using the option -violations you can get for each type that is not confined a list of constraints that tell why the type is not confined. This gives you the information you need to re-engineer your software.
Confined types are also interesting from a security perspective. If you are dealing with untrusted code in your application, you may want to make sure that the untrusted code can never access certain parts of the running application, especially the control mechanisms for the untrusted code. But even if you don't have to worry about this, encapsulating critical parts of your code is always a good thing -- this way you can limit the influence of programming errors --- they must be in the same package to affect the confined type.
Should you be worried about aliasing control --- well, objects of confined type can only be aliased from within their defining package. This limits the amount of code that may have side-effects.

Are there any known bugs?

The current version has no known bugs.

How can I torture students with confined types?

If you happen to teach an advanced programming languages course, we suggest giving the students the XTC framework short some of the core functionality of Kacheck/J. Contact Jens Palsberg for experiences with teaching such a course.

Confined types may also be useful in software engineering courses as an example of how to re-engineer software to ensure encapsulation.

Christian Grothoff