The Java importer facility gives you the ability to use an Enterprise Java Bean (EJB) or Business Components for Java (BC4J) component as the BASIS of a Forms Block. However, we recommend that you do not do this for the following reasons:

Calling out to Java from Forms has a small but significant performance implication. The Java Native Interface (JNI) that is used to call out from the Forms C code to Java does impose a bottleneck on the operation as values and method calls are transferred. Although this overhead is not noticeable in a simple function call, it will BECOME evident if a Form Block is based on Java in this way. The normal functionality of the block requires many calls back and forth to the datasource and in this case the delay imposed by the JNI bridge, on each call, will result in noticeably slower performance than that for a block based directly on a table, view or PL/SQL stored procedure.

Whenever a Forms process calls out to Java, it must have a Java Virtual Machine LOADED into memory. This will increase the memory footprint of your application.

Using a foreign data source in this way is a complex task in terms of hooking the Java Code up to the Forms transactional TRIGGERS. The maintenance burden is also high if changes have to be made, as both the PL/SQL interfaces and the Java code itself may need to be changed.

An EJB or BC4J component will create it's own JDBC connection to the database and not re-use the EXISTING Forms connection, doubling the user load on the database.

The Java importer facility gives you the ability to use an Enterprise Java Bean (EJB) or Business Components for Java (BC4J) component as the basis of a Forms Block. However, we recommend that you do not do this for the following reasons:

Calling out to Java from Forms has a small but significant performance implication. The Java Native Interface (JNI) that is used to call out from the Forms C code to Java does impose a bottleneck on the operation as values and method calls are transferred. Although this overhead is not noticeable in a simple function call, it will become evident if a Form Block is based on Java in this way. The normal functionality of the block requires many calls back and forth to the datasource and in this case the delay imposed by the JNI bridge, on each call, will result in noticeably slower performance than that for a block based directly on a table, view or PL/SQL stored procedure.

Whenever a Forms process calls out to Java, it must have a Java Virtual Machine loaded into memory. This will increase the memory footprint of your application.

Using a foreign data source in this way is a complex task in terms of hooking the Java Code up to the Forms transactional triggers. The maintenance burden is also high if changes have to be made, as both the PL/SQL interfaces and the Java code itself may need to be changed.

An EJB or BC4J component will create it's own JDBC connection to the database and not re-use the existing Forms connection, doubling the user load on the database.