Skip to main content

Package permission

Simple Story

This part of the checklist is about what equipment a pupil may bring into the room at all.

It is settled by reading the compiled answer, not by watching them work.

For the fields an exercise author writes, see Package permission in the instructor guide. This page is about how the domain is enforced.

Model​

PackagePermission, one record per permitted package prefix.

Validation and normalisation​

Prefix matching is boundary aware, so permitting java.util does not silently permit java.utilities.

What it generates​

Architecture test cases only.

Static enforcement​

This is the whole of its enforcement. The rule inspects the imports of the supervised bytecode; there is no runtime counterpart, because by the time a class runs its imports have already been resolved.

Runtime enforcement​

None. A package restriction that a static analyser misses is not caught later.

Where the code lives​

  • policy/policySubComponents/PackagePermission.java, which is one of the classes copied into a Precompile-generated exercise (ArchunitJavaCopyFiles.csv)
  • architecture/java/archunit/JavaArchunitTestCaseCollection.java

Known gaps​

Being architecture-only makes this the domain most sensitive to the ArchUnit-versus-WALA choice, since the two build their view of the code differently.