Questions About Kacheck/J and Confined Types
Answers
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