DekGenius.com
[ Team LiB ] Previous Section Next Section

6.3 Enhancement Effects on Your Code

It is important for you to understand how enhancement affects your persistent classes. Enhancement does not alter the logic or functional behavior that you have defined. It adds code to mediate all access to a field to ensure that its value has been read from the datastore and that any modifications are tracked. You will not see any behavioral differences between transient instances of enhanced classes and transient instances of the same nonenhanced classes.

The PersistenceCapable interface is designed to avoid name conflicts with fields and methods that you define. All of its declared method names are prefixed with "jdo". To avoid selecting a name the enhancer uses, you should not declare a persistent class with fields or methods that start with "jdo". The reference-enhancement contract adds additional methods and fields that begin with "jdo" to your classes.

The enhancer does not change the behavior of introspection. All of the fields and methods added to an enhanced class are exposed when you use the Java reflection APIs.

Your enhanced classes will have dependencies on the JDO JDOImplHelper, StateManager, and PersistenceCapable interfaces, defined in the javax.jdo.spi package. Therefore, your enhanced classes need to have the jdo.jar file that contains their definitions available in your classpath at runtime.

Class enhancement will not impact source-line-level debugging. You can debug your enhanced classes using the line numbers of your original source code. You will be able to work at the source level as if the class had not been enhanced. If the enhancer makes any code modifications that change the offset of any byte codes within a method, it updates the line number references to reflect the change.

However, as you will learn in this chapter and Chapter 12, a JDO implementation has some flexibility as to when it initializes an instance's persistent fields. The enhancer places field-mediation code in your application classes to ensure the field is loaded before your application classes access a field. But this field mediation is not applied to debuggers or software that uses introspection. These will access the field directly, even when it has not been loaded by the JDO implementation. This may confuse you, because the field's value will change when it is loaded from the datastore. This can even occur if the specific field you are examining in the debugger has not been accessed by the application; it could get loaded as a result of an access to another field in the instance.

    [ Team LiB ] Previous Section Next Section