Policy enforcement: system wide contracts in Java

Encoder QR Code in Java Policy enforcement: system wide contracts

violation may not always be an immediate issue. It may be perfectly fine to violate them as long as you understand what you are doing. Policy enforcement for best practices, therefore, simply warns developers of potential traps instead of issuing hard errors. For example, even though one of the basic object-oriented principles is to not expose the implementation, such exposure will not cause any observable problems immediately. However, over time you will start to see that such exposure will lead to brittle systems; flagging such violations will help you make an informed choice. Minimally, the rule against exposing internal implementation translates to assigning a nonpublic access to any (nonfinal) members. Although this principle is commonly accepted, its enforcement still relies on education and code reviews. Reviews usually involve searching through the code base either manually or with a tool. Maybe, with effort, you can initially fix all such violations, but after a time some developer forgets this principle and adds a public field. Such a violation of your policy will go undetected until another review or, worse, another bug. The reason for the lack of better enforcement of this policy is that it is a crosscutting concern every part of the code has to adhere to it. In listing 6.4, the aspect warns the developer about using public access to any nonfinal field.

aspect DetectPublicAccessMembers { declare warning : get(public !final * *) || set(public * *) : "Please consider using nonpublic access"; }

The aspect, per se, does not detect the presence of public fields in a class. However, it detects read or write access to any such field. The pointcut get(public !final * *) captures read access to any nonfinal public field of any class. The use of !final prevents the code from issuing warnings for access to final fields, which usually isn t considered bad practice. Similarly, the pointcut set(public * *) captures all write access to any public field of any class. In case of write access, we have omitted !final, because Java s access check will take care of issuing an error for writing to a final field. Now when the developer compiles this aspect along with the rest of classes, he will get warnings similar to the following:

The developer can then assign appropriate nonpublic access control to the field and may introduce getter and/or setter methods. The next time someone writes code that uses access to a public field, this aspect will catch the violation immediately. Try this aspect in your own system; you might get some surprises.

The EJB specification imposes several programming restrictions on a bean. For example, it does not allow you to make AWT operations, directly work with networking resources, or use thread-synchronization primitives from a bean. These restrictions ensure that application servers can utilize nodes in a server cluster without any behavioral change in the system. Since most of these situations occur during user-heavy loads, you may not run into these situations during the development phase, and failure may occur only in real deployment situations and stress testing. Please refer to section 24.1.2 of the EJB 2.0 specification for more details.1 Our way to detect EJB violations, like most of the solutions presented in this book, works in a plug-and-play style and is reusable. Simply compiling your code with the aspect in listing 6.5 gets you the benefit. You can use AspectJ to catch violations at compile time and runtime in a nonintrusive manner, as we discussed in section 6.3.1. So now let s dive straight into an aspect. Listing 6.5 shows an EJB policy-enforcement aspect that enforces two rules: no AWT code from EJBs and no nonfinal static field access.