At our Oracle Competence we run a succesfull Designer/Developer migration solution in which we had to upgrade a Designer 1.3.2 repository to 10g, including the use of the latest version of Headstart.

It’s no fun to modify all the Forms code that call the old Headstart procedures, so we developped a ‘wrapper’ library that implements all the Headstart 3.4.2 functions and calls the corresponding Headstart 10g functions.

A new installation of Headstart 10g in the database, some corresponding ‘wrapper’-packages and a few simple database scripts to migrate the data to the new Headstart tables finished it of.

A job well done.

The arguments against running webforms in a browser are for example:
- you loose part of the window because the browser menu, button bar, tab-pages, google searchbar, etc. all need space.
- using the back and refresh buttons on the browser closes the session (and data changes may be lost)

When your application runs in a separate browser window you still have this ‘empty’ browser window which may not be closed.

It’s too easy to say the users will have to adapt; so we looked for a different approach and found the following solution (although not supported by Oracle): Java Web Start.

With Java Web Start you can have
- a desktop icon to launch the application
- a separate application window
- jar-caching similar to using Jinitiator or the Sun Java plugin

Here is an example of a JNPL file:

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for testing Java Webstart -->
<jnlp codebase="http://[name of Oracle Application Server]:7777/forms/java” href=”DemoJavaWebStart.jnlp”>
<information>
<title>Oracle Forms Java Webstart Demo</title>
<vendor>LogicaCMG</vendor>
<description></description>
<description kind=”short”></description>
<offline-allowed/>
</information>

<applet-desc documentBase=”http://[name of Oracle Application Server]:7777/forms/java”
name=”OFJWD”
main-class=”oracle.forms.engine.Main”
width=”1020″
height=”710″>
<param name=”lookAndFeel” value=”Oracle”/>
<param name=”colorScheme” value=”Blue”/>
<param name=”width” value=”750″/>
<param name=”height” value=”600″/>
<param name=”serverURL” value=”/forms/lservlet?ifcfs=http://[name of Oracle Application Server]:7777/forms/frmservlet” />
<param name=”serverArgs” value=”escapeParams=true module=demo0000.fmx
sso_userid= sso_formsid= sso_subDN= sso_usrDN= debug=no host= port= buffer_records=no
debug_messages=no array=no obr=no query_only=no quiet=yes render=no
record= tracegroup= log= term=”/>
</applet-desc>
</jnlp>

Note that the security settings have all permissions set: <security><all-permissions/></security>. This is not without risk and requires all JAR files to be signed.

A second note is that jar-files added to the list with resources must be signed with the same certificate.
As the Oracle Forms jar “frmall.jar” is signed, other jar-files can not be simply added. However,
there is a workaround by calling a second jnlp-file from the resources tag. This jnlp-file contains
the additional resources that are needed.

<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for testing Java Webstart -->
<jnlp codebase="http://[name of Oracle Application Server]:7777/forms/java” href=”FormsJars.jnlp”>

<resources>
<j2se version=”1.4+”/>
<jar href=”webstart.jar”/>
<jar href=”formsDemo.jar” />
<jar href=”webutil.jar”/>
</resources>
</jnlp>

The two jnlp-files are stored on the Oracle Application Server in the /java-directory.

We use Java Web Start to run Forms using client integration with Oracle WebUtil without problems.

But Java Web Start has its disadvantages too. As you need at least a URL on the client (for the first jnlp-file), now you have to start deploying client installations once again…