D1: It suggests the replacement of the unauthorized type B with one of its supertypes B′, since such B′ is outside M_B and it can be type checked. This recommendation is particularly useful to handle violations due to the use of a concrete implementation of a service, instead of its general interface.

D2: This recommendation is similar to D1; the only difference is that it suggests the replacement of the unauthorized type B with one of its subtypes B′, instead of one of its supertypes. As a practical example, developers when specifying GWT (Google Web Toolkit) interfaces should avoid the use of generic types due to the overhead in the size of the generated JavaScript code, which has important consequences both in CPU performance and network bandwidth consumption. Therefore, they should rely on more specialized types as possible.

D3: It suggests the removal of the unauthorized declaration followed by the propagation of the initialization expression exp to all uses of the declared identifier. This recommendation can be triggered when A cannot declare B but is allowed to access it. For instance,

D4: It suggests the removal of a parameter declaration whenever it is not being used, i.e., the removal does not cause any compiler error.

D5: It suggests the replacement of the unauthorized exception of type B with one of its supertypes B′ whenever such B′ is outside M_B.

D6: It suggests the replacement of an unauthorized call to a method f with a call to a delegate method g—i.e., a method that just encapsulates a call to f. This recommendation can only be triggered if the type that contains such delegate method is outside M_B.

D7: Similarly to D6, this recommendation suggests the replacement of an unauthorized call to a method f with a method g that has an equal signature.

D8: It suggests the extraction of a new method g that encapsulates the call to f and then the movement of g to a class inside the most suitable module M. Moreover, the current module (M_A) must not be the most suitable one (M).

D9: It suggests the removal of the call whether no class in the system is allowed to access B. This recommendation is particularly useful when developers access methods or fields whose usage should be restricted. For instance, developers tend to establish dependencies with the Java API System class (mainly calls to System.out.println) as a practice of rudimentary debugging. Nevertheless, these calls must be removed, specially in web-based system.

D10: It suggests the promotion of variable v—whose initialization expression exp_b contains the unauthorized access—to a formal parameter of the enclosing method g. In this case, the initialization expression exp_b must be used as the argument in g calls. This recommendation is particularly useful when accessing B is allowed from all g call sites.

D11: It suggests the replacement of the new operator with a call to the get method of a Factory class FB, since A is allowed to access the factory. This recommendation addresses the fact that developers may—due to unawareness or forgetfulness—create a objects of classes that have a factory.

D12: It suggests the removal of the instantiation whether no class in the system is allowed to create B. For example, this recommendation is useful when objects of some classes are supposed to be provided by dependency injection techniques.

D13: It suggests the replacement of the new operator with a call to the get method of a new Factory class, which will be created by the auxiliary function gen_factory.

D14: It suggests the replacement of an instantiation of B using exp in a return statement with only exp, delegating the responsibility for the creation of B to the call sites. Moreover, this recommendation involves modifying the signature of method g (as performed by the function replace_return) and it can only be triggered if all call sites are able to create B.

D15: It suggests the removal of the throws clause, in the cases it is not need. This recommendation addresses the tendency of developers to over-declare the exceptions that can be raised in a method.

D16: It suggests, when the throws is in fact need, the removal of the throws clause and the insertion of a try-catch block around the body of the method to handle the exception internally. In this particular case, the developers must provide the code that handles the exception, as required by function user_code.

D17: It suggests the replacement of the unauthorized exception type B with one of its supertypes B′, assuming that B′ is outside M_B.

D18: It suggests the movement of method g to a class in the most suitable module M, assuming that M is different than the current module. For instance, suppose that a method g throwing DAOException—which possibility should be implemented by a DAO class—was mistakenly implemented by a class outside the DAO module. In such case, this recommendation suggests to move g to a DAO class.

D19: It suggests that the class A should derive from B′, which is one of the supertypes of B. This recommendation can only be triggered if such replacement type checks, if B does not override methods of B′ (in order to avoid any possible changes in semantics), and if B′ is outside M_B.

D20: It suggests the movement of class A to the most suitable module M, assuming that M is different than M_A, i.e., the current module of A is not the most suitable one. This recommendation is particularly useful when developers mistakenly place a class in the wrong module, e.g., a DAO class in the Controller layer.

D21: It suggests the movement of class A to the most suitable module M, assuming that M is different than M_A, i.e., the current module of A is not the most suitable one. This recommendation is particularly useful when developers implement a class in the wrong module, e.g., a class using annotations related to persistent concerns in the Controller layer.

D22: It suggests the removal of the class-type annotation B from class A whenever M_A is already the suitable module for A and it is not able to receive B.

D23: Similarly to D21, it suggests the movement of method g to a class located in the most suitable module M whenever the current module of g is not the most suitable one.

D24: Similarly to D22, it suggests the removal of the method-type annotation B from method g whenever M_A is already the suitable module for g and it is not able to receive B.

A1: It suggests the adding of the exception B in the throws clause of method g when such exception is being handled by a certain catch in the method’s body. This recommendation is particularly useful to guide developers in throwing exceptions that should not be handled internally by a method.

A2: It suggests the movement of method g to a class in the most suitable module M whenever the current module of g is not the most suitable one.

A3: It suggests that class A must extend or implement B whenever the class is already in the most suitable module and it type checks. For instance, suppose an Entity class that must implement Serializable. Because Entity classes rely extensively on the same types, the suitable_module function will probably be able to determine that indeed the class is in its most suitable module and therefore should also implement Serializable.

A4: It suggests the movement of class A to a most suitable module M, because the current module of A is not the most suitable one. For instance, suppose a class that must derive V iew but establishes dependencies only with Controller types. In such case, this recommendation will suggest the movement of this class to a module in the Controller layer.

A5: It suggests the movement of class A to the most suitable module M, assuming that M is different than M_A, i.e., the current module of A is not the most suitable one.

A6: It suggests the adding of the class-type annotation B to class A whenever M_A is already the suitable module for A and hence A has to receive annotation B.

A7: It suggests the movement of method g to a class in the most suitable module M whenever the current module of g is not the most suitable one.

A8: It suggests the adding of the method-type annotation B to method g, assuming that M_A is already the suitable module for g and hence g has to receive annotation B.