Forbidden classes semantics consistency with dependOnClassesThat() and accessClassesThat()

[Perdjesk]

The use case represents the following need:

A project wants to forbid the usage of certain classes from its code, however if a dependent library uses those classes (i.e in library's API, as returns or parameters) it doesn't prevent from using that library.

Example

• java.util.Date must not be used.
• The project is using a library which contains DateUtility class which provides API methods that are using java.util.Date as returns or parameters.

This example poorly represents it, but the project must use that API for some legitimate cases, it goes beyond the simplicity of the example's DateUtility.

Method signatures of DateUtiliy.java:

public static java.util.Date getUtilDate();
public static void consume(java.util.Date date);

Rule

ArchRuleDefinition.noClasses().should().dependOnClassesThat().belongToAnyOf(java.util.Date.class);

Allowed case

java.util.Date nowutil = DateUtility.getUtilDate();
DateUtility.consume(nowutil);

Note: for simplicity the example show a case where the instance of the forbidden class originates and is consumed by methods from the same class, however this is not mandatory.

Forbidden cases

DateUtility.consume(new java.util.Date());

DateUtility.consume(Date.from(java.time.Instant.now());

Discussion

In that example as long as it possible to get an instance of the forbidden class from a foreign method of the project, the rule allows to "pass around" this instance. However whenever there isn't such foreign method to get an instance of the forbidden class, the library becomes unusable.
A possible workaround would require to scope out to a dedicated package the code requiring to use constructors or static factory of forbidden class, and exclude the package from the rule enforcement.

Is there a way to express an ArchUnit rule that remain consistent between the above cases, while still prevents most of the others cases (e.g. fields, inheritance, method signature)?
Is the proposed workaround a good enough practice, is there a better way to do it?