"Internal Package Import" errors and how to switch them off

A new functionality in Oracle JDeveloper 11g ( is an audit rule that flags an error when compiling Java files that use internal ADF framework classes. Internal ADF framework classes are public classes that reside in internal packages. For example, FacesCtrlHierBinding extends JUCtrlHierBinding and represents the component model used with the ADF Faces table, tree and tree table components. It  is an internal implementation class that developers should not use in their application development. For this reason, Oracle packaged it in a package structure with the name internal in it:


Similar package structures exist for Oracle ADF Business Components, ADF Controller and other technologies in Oracle ADF. In previous versions of Oracle JDeveloper 11g, this audit rule did not exist, which means that without noticing, developers may have used those classes, which now, after upgrading ADF applications to Oracle JDeveloper, no longer compile, because the new audit rule prevents it from compiling. So there are reasons for you to want the audit rule to change. To change the audit rule settings for internal framework class uses, to either disable (less recommended) or smoothen it (more recommended) by setting the Severity to Warning instead of Error, you choose Tools | Preferences | Audit | Profiles. In here you expand the ADF Java Audit Rules node to change the settings for the internal package import or disable it.

Before disabling this audit rule or change it from Error to Warning, it is important that you understand why this audit is there. Like the Java and Java EE platforms, application development frameworks consist of public APIs and internal implementation classes. While in the normal Java case you protect internal implementations by flagging classes as private and protected, or using inner classes, you can't always do the same in frameworks because the classes may be referenced within the framework, for which they need to be public. Implementation details are subject to change, which means that there is not notification sent out ahead of time before a change happens. Changes may be required for example to add new features, fix bugs or integrate new technologies. Look at the internal classes as "a framework developer's freedom to change" and you get an idea for what they are.

What should you do if you used internal classes in your existing application?

1.       Set the audit rule to Warning so your project compiles.

2.       Take a note about the list of issues found by the audit rule

3.       Look at each use of internal class uses and see if you find public classes to use instead. For example, the FacesCtrlHierBinding class can be replaced by JUCtrlHierBinding for most of its functionality

4.       If you can't find a public API, report this as a problem to customer support for Oracle to provide a public API for the functionality you need to access in Java.

Important note: The Oracle JDeveloper forum on OTN is not Oracle support

5.       For the time being and to avoid using internal classes, use ValueExpressions or MethodExpressions in Java and access the internal functionality through their expression. For example, instead of calling makeCurrent on FacesCtrlHierBinding, you can resolve the EL string #{bindings.treeBindingName.makeCurrent} as a method expression in a managed bean method referenced from a SelectionListener property of a table:

public void onSelecTable(SelectionEvent selectEvent){
  FacesContext fctx = FacesContext.getCurrentInstance();
  ELContext elctx = fctx.getELContext();
  ExpressionFactory exprFactory =     
  MethodExpression me = exprFactory.createMethodExpression(
            Object.class, new Class[]{SelectionEvent.class});
  me.invoke(elctx, new Object[]{selectEvent });

What should you do if you need to use internal classes in your current application?

1.       Post a question on the Oracle JDeveloper forum on OTN and ask for a public API alternative to what you think requires the use of internal framework classes

2.       If you don't find a solution, use Expression language as explained above, starting from bullet #5

Using expression language as a substitution for internal Java API calls is considered a work around, though one that lasts for long. However, given expressions are resolved by the expression resolver before internal framework classes are accessed, it is your abstraction layer – or safety belt in this situation – that protects you from internal framework changes.

In summary:

·         Keep the audit rule as it is

·         Change it to Warning if you have to

·         Avoid switching it off


Post a Comment:
Comments are closed for this entry.

A blog on Oracle JDeveloper, ADF, MAF, MCS and other mobile and web topics inspired by questions and answers posted on the OTN forums.

Frank Nimphius


« February 2015