OA Framework Best Practices and Standards

OA Framework Best Practices and Standards

1. You should have only one top level "outer" class per Java file. Inner classes are permitted, but remember that the concatenated name (combination of the outer and inner class names) can't exceed 50 characters.

2. Public constants should be used sparingly, and should never be changed after code is shipped.

3. Member variables may have the public, protected, private or default visibility, however, member variables that are "public" should usually be made private with public accessors defined for them: setXX(), getXX().

4. Avoid client-side Java (Swing, EWT, applets and so on).

5. Never use Java in the database.

6. Never catch and "swallow" exceptions unless you can fix the cause of the exception, and no user action/notification is required.

7. Do not use the browser cookie to store state information.

8. OA Framework File Standards (Naming, Package Structure and Standard Content) has been followed.

Performance

1. Use a StringBuffer for concatenation.

2. Size your StringBuffer properly.

3. Use String.equals() for String equality testing.

4. Do not use exceptions for regular code path execution.
      For example, some OA Framework developers have used ViewObjectImpl.findAttributeDef() which throws an exception when the attribute is missing.
      Instead, you should use the JDeveloper 9i method ViewObjectImpl.lookupAttributeDef() which returns null when the attribute is missing.

5. Size your collections properly.

6. Do not use synchronized collections for thread local or read only objects.

7. Minimize the size of synchronized code blocks.

8. Avoid writing finalizers.

9. Do not call System.gc.

!0. Do not use your own debug classes. Use the standard writeDiagnostics() method.

11. Do not call debug routines (or write diagnostics) without first checking if debug/diagnostics is enabled for the level at which you want to record a log entry.
      Avoid adding too many calls to the debug class. In this case, "too many" is is proportional to the amount of work the method is doing.

For example, logging in a given method should not be doing more work than the method itself (this usually happens when extensive logging is added during development
      to debug some error, and never removed).

12. Avoid calling System.err.println or System.out.println in the normal code path execution. Use standard debugging or logging instead.

13. Avoid doing a lot of string manipulation in PL/SQL when you can do it in Java instead.

14. Use Buffered I/O classes such as BufferedReader and BufferedWriter.

Internationalization

1. Do not use resource bundles. Use Message Dictionary to programmatically obtain translated values for any strings that will display in the UI.
    Note that declarative data intended for UI display (OA Framework UI component XML metadata, menu definitions, profile options and so on) are all directly translatable.

2. Do not use Java APIs that rely on the platform encoding or locale.
      Bad Code Examples:
        byte[] bytes = ....
        new String(bytes)
        byte[] b = str.getBytes();
        OutputStream out = ...
        new PrintWriter(out)

Patching Binary Compatible Java

1. Changes to a method signature
  Reason : 
  * Changing the return type or parameter type requires redelivery of the associated class.
  * Changing the return type from String to void, even if no classes use the return type, requires redelivery of the associated class.
  * Changing a type to a super class (or to a subclass, interface, implementation class) also requires redelivery.

2. Changes to final variable values
  Reason :
  * Constant field values (String constant, primitive type constants) are in-lined into the classes. You must recompile and redeliver all the classes that use this constant.

3. Changes to a field signature (type, modifier)
  Reason :
  * You must recompile and redeliver all classes that reference this field.

4. Change a static method to an instance method or vice versa
  Reason :
  * You must recompile and redeliver all classes that call this method.

5. Change of a method location within a class hierarchy (specifically, if you move it down the hierarchy)

  Reason :
  * You must recompile and redeliver all classes which reference the method you move.

6. Change to an interface definition

  Reason :

  * If you change an interface, any class implementing or referencing the interface change will need to be recompiled and redelivered.

Posted in: Best Practices and Standards