Questions
Answers
Which modifiers can JAMIT infer?
JAMIT currently supports the modifiers
- public - protected - default (package-scoped) - private
- non-final - final (for methods and classes)
- dead (not used, for fields, methods and classes)
Are the modifiers that JAMIT infers always optimal?
JAMIT infers always more restrictive modifiers than the programmer
chose initially. Thus, from an encapsulation point of view, the
modifiers are always better than (or equal to) the
initial modifiers. They are not always optimal, in the
sense that the optimal modifier must also keep all
possible uses of the code in the future in mind. JAMIT
will, for example, infer methods and classes as final
because the current code does not override or extend
them. In those cases, where the programmer explicitly had future
extentions in mind, the less restrictive modifiers may have been
better than the tighter modifiers that were inferred by JAMIT.
There are also certain cases where a method could be made
protected but JAMIT cannot determine this for certain and
conservatively selects public.
Can I analyze libraries with JAMIT?
JAMIT can analyze libraries, but as JAMIT cannot the interface of
the library in those cases, the inferred modifiers must be treated
with extreme caution; otherwise noone will be able to use the
library because public interfaces may be restricted. The
best way to avoid too restrictive modifiers is to have extensive
testcases that cover the entire API of the library and to run
JAMIT on the main method of the testsuite.
Using JAMIT on libraries is recommended, because for libraries the
correct level of restriction can be crucial for security and
future development. Finding needlessly exposed internals of a
library was one of the primary motivations for the implementation
of JAMIT.
Sometimes it is desireable not to modify certain libraries at all,
such as the JDK. Nevertheless JAMIT needs to see the code of
these libraries for the analysis. Specify the path to JDK with
the -library option.