I am a Principal Product Manager at Oracle, working with Oracle Forms, Oracle's oldest development tool that is still in production. I am originally from Sweden but have lived and worked in the US since 1999.


Syndicate this blog

Forms and Java Web Start

Now that Sun's new plug-in technology, v1.6.0_10, is close to being released (a Release Candidate was released last Friday) I have been playing around with the new Draggable Applet feature. I am not finished with that yet but to make that work I needed to have a JNLP file describing the APPLET. So I made one and to my surprise it just worked. I didn't have to employ any tricks.
I could start Forms directly from the JNLP file both from a browser (if I set the mime type correctly) and from the desktop. Forms starts in a Java frame that is independent of the browser. We have, so far, said that Forms is not supported running with Java Web Start and that is still the case but it works!

Here is what I did to make it work:

Sun's plugin 1.6.0_10.
You'll need the latest Java Plugin (JRE) from Sun. Its available here. It will automatically install Java Web Start. I think there are different version now so choose the fullest version. The Kernal version will possibly not have the Web Start feature included.

The JNPL file

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" href="http://localhost:7777/forms/java/forms.jnlp" 
        <vendor>Oracle Inc.</vendor>
        <description>Summit Demo</description>
        <description kind="one-line">Summit</description>
        <description kind="tooltip">Summit Demo</description>
        <description kind="short">Summit Demo</description>
        <shortcut online="true">
            <desktop />
        <all-permissions />
        <j2se version="1.6+" />
        <jar href="frmall.jar" size="" main="true" />
<applet-desc main-class="oracle.forms.engine.Main" name="Forms" width="800" height="600">
        <param name="separateFrame" value="false" />
        <param name="lookAndFeel" value="oracle" />
        <param name="splashScreen" value="" />
        <param name="background" value="" />
        <param name="colorScheme" value="blue" />
        <param name="serverURL" 
         value="/forms/frmservlet?ifcfs=http://localhost:7777/forms/frmservlet" />
        <param name="serverApp" value="default" />
        <param name="logo" value="false" />
        <param name="serverArgs" value="module=customers.fmx usesdi=yes
        userid=summit/summit@loc sso_userid= debug=no buffer_records=no
        debug_messages=no array=no query_only=no quiet=yes render=no
        host= port= record= tracegroup= log= "

I named the file forms.jnlp.

At closer inspection you'll see how similar this JNLP file is to the OBJECT or EMBED tag that you use currently and that came with the Forms installation. All the PARAM attributes are there and the values look like the values you see there if you open the source in the browser. There is no substitution variables in it and the Forms Servlet doesn't know how to perform substitution on it if you put them in so you'll have to translate your base.html or basejpi.html to the JNLP format with this as your guide.

Some potential pitfalls:

  • Substitute "localhost" with the name of your host and the port number for the one you use in all places.
  • The HREF in the JNLP tag should point to where the JNLP file is stored and that location must have a virtual path defined to it so it can be reached from a browser.
  • Substitute the userid (the normal connect string) and module (the name of the form you would like this JNLP file to start, which must be in the forms_path of course) parameters in the serverArgs tag for values that makes sense to your application.
  • The j2se tag's version attribute should probably stay like it is. I have not tested this with 1.5.
  • The tag called shortcut in the information tag is the tag that is needed for Draggable Applet support. It is not strictly needed here but I included it here for completeness sake.

Mime mapping
To make it possible to serve this JNLP file up from a server and making it possible for a user to start a Forms application in a local Web Start container by clicking on a link in their browser you need to set up a virtual path to the location of the JNLP file or just put the JNLP file in a location on disk that already has a virtual path set up for it.
You must also add this to the httpd.conf file in the Apache config directory:
    AddType application/x-java-jnlp-file .jnlp

Find the place in the file where other AddType directives are and add it right under the last existing one. In my installation they were located under an IfModule directive for mod_mime.c. The httpd.conf file itself is located in $ORACLE_HOME/FRHome/Apache/Apache/conf
Restart Apache to make the type change take effect.

After you perform these steps it should be possible to serve up the JNLP file from a URL both in an HTML file and as a bookmark, meaning that users can have a bookmark in their browser or on their desktops that starts up a Forms application in Java Web Start. The application is independent of the browser so it can be closed as soon as the application has started up. If you copy the JNLP file to the users' machine the browser doesn't even start up when the user double clicks on it.

This blog entry is not an announcement of support for Web Start. We don't certify Forms with Web Start so we don't know for sure that this works. We might choose to perform certification using Web Start in the future but we don't currently and have no plans to do so in the near future.
My intention with this entry is to share what I found and perhaps create some interest in the Web Start deployment option that I can take to the table at new-feature-discussion time.

Feedback and/or corrections are welcomed in the comments to this entry.


Comment from: Andreas [Visitor]
This sounds great, Jan! We're eagerly waiting for JRE 1.6.0_10 (and Oracle Forms certification for it) to arrive. Not only for Vista support - finally! - but for features such as the Java Webstart so our customers can get rid of that extra browser window that's currently needed to hold the Forms applet. I think supporting / certifying Webstart with Forms would make Forms applications feel more like a desktop application, at least when used together with separate_frame=true. And in most cases, that's still what our customers want. Being able to run Forms over the web from any computer with a JRE is great but most often it should feel like a real desktop application.

Hoping for more good news!

Permalink 08/15/08 @ 07:09
Comment from: Friedhold [Visitor] · http://friedhold-matz.blogspot.com/
Great news Jan ! So we have good arguments to migrate to Forms 1xg for our customers.

Best wishes

Permalink 08/15/08 @ 23:21
Comment from: Mark [Visitor]
Great news, I hope it will be supported in the near future. This is what a lot of my customers want.
Permalink 08/16/08 @ 16:35
Comment from: Kay Basler [Visitor]
We use Java Webstart and Forms because of better "Client-Like" behaviour since 2007.
For that we developed a very small wrapper around oracle.forms.engine.Main so that we get more control of Java Applet (windows controlling, event handling).
Additional we've built a servlet for creating dynamic JNLP files. With an URL our system returns an JNLP file based on static HTML file (basejpi.htm and formsweb.cfg) and sent URL parameters.
All problems with our Java Webstart environment also occur when the Forms Applet runs in a browser. At the moment we don't have any problems with Forms and Webstart - support.
So we wish us as soon as possible an Oracle support for Java Webstart and Forms!

br Kay
Permalink 08/18/08 @ 09:53
Comment from: Jacob [Visitor]
Hi Jan

Very interesting information! Yet another reason to look forward to 1.6.0_10. I really hope, that WS will be officially supported at some time, so we can get rid of the underlying browser in an "official" way.

To Kay Basler: I'm curious about this wrapper you tell about. Could you tell a little more about how this works? Would it be possible to see the source for this wrapper?

Permalink 08/19/08 @ 10:08
Comment from: Jacob [Visitor]
To Jan: we have encountered a critical issue with 1.6.0_10 when used with Forms, which I hope you will check for when certifying the final version, whenever it comes.

Try opening any form with 1.5.0_xx, 1.6.0_07 and 1.6.0_10 with separateFrame=true. The form should not be maximized. Try dragging the form around by clicking the title bar of the form.

In any version but 1.6.0_10 RC - 1.6.0_07 and 1.5.0_xx - you can do this dragging smoothly. But in 1.6.0_10, for some reason dragging a window around is painfully slow.

If this issue is not fixed in the final 1.6.0_10, we can't use it, because our Forms applications use a lot of overlapping windows, where the user needs to be able to drag a window quick and smooth.

Please check this, when the final 1.6.0_10 is out.

Permalink 08/20/08 @ 13:21
Comment from: Jan Carlin [Member]
Thanks for that Jacob. I will check it out for myself and if I can reproduce it I will alert QA.
Permalink 08/20/08 @ 17:20
Comment from: Kay Basler [Visitor]
To Jacob:

We implements AppletContext and AppletStub in our MainWrapper class. So we build our own applet viewer.
Why we have it done?
- If you have opened different forms and you press close cross on Main Window (Applet Viewer Window) - your whole application will closing!
- You can manipulate parameters
- You can set window decoration
- You can control applet context and parts of your application

With this wrapper we generate an SWT application with SWT components and inside of this application we run in Tab folders different forms applications - start menue runs complete in java and forms self runs in a JFrames.
Next step could be - take out parts of our application (different forms) and redesign in Java. But that is more dreams of the future!

Here is a code snippet:
public class MainWrapper extends JFrame implements AppletContext, AppletStub {
public static void main(String[] args) {
// fill HashMap with Program arguments
// same as with applet parameters
final MainWrapper main = new MainWrapper(map);

// manipulate HashMap

// default close operation of JFrame should be disabled

main.getContentPane().setBackground(new Color(0,0,120));


final Main oracle = new Main();

// add window listener to handle close cross
main.addWindowListener(new WindowListener() {
public void windowClosing(WindowEvent e) {
if (oracle.isRunning()) {
main.messageOK("System - Information", "Please use Exit button on Form!");

main.getContentPane().add(oracle, BorderLayout.CENTER);


// run applet in wrapper
EventQueue.invokeLater(new Runnable() {

public void run() {
try {

} catch (Exception e) {
System.out.println("Error: " + e.getMessage());


// manipulate Applet methods - e.g. show_document
Permalink 08/22/08 @ 09:29
Comment from: Peter de Vaal [Visitor]

I know some companies already used WebStart for Forms. We never advised it to our customers because it is not supported by Oracle.
The result with this JRE version is so promising that we think it is a great idea to get it supported. We then finally get rid of the browser dependencies.
I tried it out with a real application and it looks nice, both on Windows and (even better) on Mac OS clients.
I have some remarks though.

1. The mimetype directive:
AddType application/x-java-jnlp-file .jnlp
(application not applications)

2. I use for serverURL:
It did not work with frmservlet instead of lservlet.
The problem this way is that it does not pickup the workingDirectory and envFile settings this way, and that I cannot specify a config. I can work around this by making a version of formsweb.cfg for each application and make a servlet alias for each application pointing to the correct formsweb.cfg, but better would be to be able to specify a config.

3. Single Sign On
It does not seem easy to run Forms with SSO this way. Maybe it is possible if SSO is configured to use client certificates, but an SSO login screen would pop-up in a browser, which I guess does not share its session cookies with the JRE this way. The other way around, running a report from Forms might require an extra login on SSO. Or am I wrong?
Permalink 08/27/08 @ 08:27
Comment from: Jan Carlin [Member]
Thanks for a thoughtful comment. I am working internally to get this supported. Hopefully I will get some traction on this soon.
Thanks for spotting the typo of the mime mapping. I have changed it.
I don't know why you cannot get the serverURL to work as written. It works here.
Single Sign on is a know problem with this and I am pushing for a solution to that as well.
Permalink 08/27/08 @ 18:08
Comment from: Jacob [Visitor]
Hi Jan

One update from me on the issue I posted earlier: it seems, that this only happens on Windows Vista... I have encountered it on 3 different Vista systems, but I just tested it in a VMWare running Windows XP, and it did not happen here...

But since many of our customers are on Vista now, it doesn't really change anything for us - but it's of course important, if a bug is to be logged.

If you manage to reproduce it, please post your results here. I hope you can get a bug logged at Sun.

Also, I am glad to hear, that your working on getting support for JWS. Looking forward to further updates on your blog.

Permalink 09/03/08 @ 16:00
Comment from: Jan Carlin [Member]
I don't have a Vista machine to test this on, believe it or not. Would you be willing to call Support and report the problem? They should have machines running Vista to confirm this on.
Permalink 09/04/08 @ 20:19
Comment from: Jacob [Visitor]
Hi Jan

For you information, I have created SR 7074423.993 on Metalink with a reference to this blog entry about the issue, if you want to monitor it. I hope Support can help getting a bug logged with the JDK team.

In any case, please keep it in mind somehow, when you're about to certify the final version with Forms, whenever it's out.

Permalink 09/05/08 @ 11:12
Comment from: Sunny Patel [Visitor]
I'm the support engineer to the Oracle Support SR logged by Jacob. FYI, I can reproduce this on XP using 1.6.0_10. So, I think the issue is not related to platform but 1.6.0_10 itself.

Jacob : I'll continue with the investigation from the SR itself.
Permalink 09/05/08 @ 14:44
Comment from: Jacob [Visitor]
Hi Jan

I managed to find the root cause of the mentioned issue. Sunny might already have notified you of the bug #7396079 on MetaLink, he logged on my behalf, after we verified together that the problem seems to occur on any system with a DirectX 9-compatible graphics card.

It must have something to do with the new "Direct3D pipeline" feature in JRE 1.6.0_10, which in some way is broken when used with Forms, since you can work around the problem by setting a special parameter in the Java Control Panel, which disables this feature - see the details in the SR and bug description.

In any case, I hope you will help getting this problem corrected, in one way or another, sometime before the final version of 1.6.0_10 is certified with Forms. I believe the final release might be close, since Sun just released Release Candidate 2.

Thanks in advance,
Permalink 09/13/08 @ 10:10
Comment from: Peter de Vaal [Visitor]
The SUN 1.6.0_10 plugin is now production. It seems to work fine.
Permalink 10/22/08 @ 14:56
Comment from: Jan Carlin [Member]
I am glad that it works for you. It has worked for me as well when I tested the RC.
Permalink 10/22/08 @ 23:26
Comment from: Peter de Vaal [Visitor]
We are now using JWS for Forms for our own admin application and for the application of a customer, and everybody is very happy with it. In both cases there was hardly any control over the client machines, and then differences in browser versions, settings and Windows versions often prevented Forms to run correctly in the browser. These problems have all gone when using JWS.
We have solved a number of issues:
1. SSO.
The application runs fine with Single Sign On. You just get the Java authentication screen instead of the SSO server login screen, and you can login with the SSO credentials without problems. The main issue to cope with is integration with Reports. When using Run_Report_Object built-in the report just runs, but getting output with rwservlet requires re-logon. It is possible however, to use webutil functions to download the report output to the client and open it in Acrobat Reader (or another applicable viewing tool).
2. Control over the MDI window
We have created a javabean to control the MDI window. This bean has functions to set properties, such as the Resizable property of the JWS window, its title and what happens when the closebox is clicked.
3. Config
It is possible to pass the config parameter on the string of the serverURL applet parameter.
Permalink 11/17/08 @ 10:24
Comment from: Marco Marçal [Visitor]
Hi Peter and Jan,

I am curious and i would like to see the .jnlp sample you used in order to use the SSO feature.

I am new to "Oracle Forms" and i am a bit confused with the serverArgs parameters of the jnlp file.

1. What's the difference between "used_id" and "sso_userid" in a SSO context ?

2. Which parameters do u set up in your SSO .jnlp file ?

Thank you !

Permalink 01/13/09 @ 13:53
Comment from: Najeeb Mayan [Visitor] · http://www.mhdoman.com
Hi jan,
Thanks a lot for the blog ,It is very helpfull.We configured our application with jnlp am able to run the application.it is now on test run,Here some of our users are facing a problem like Once you open Oracle forms after few minutes it is crashing and nothing can be done or seen on the screen.Can you help me out to solve this issue.
We are using OracleAS10g,JRE Version 1.6,Windows xp.
Thanks & Regards
Permalink 02/11/09 @ 11:31
Comment from: Jan Carlin [Member]
I am glad you like my blog.

We are not yet supporting using Web start because we have not yet tested it thoroughly so if you have problems using it I suggest you revert to the normal way of starting Forms and if the problem occurs then as well call Oracle Support and have them analyze the situation and perhaps log a bug, if necessary.
Permalink 02/11/09 @ 16:31
Comment from: Peter de Vaal [Visitor]
The problem is known and should be solved when you upgrade JRE to However, this upgrade might break your application when using Webstart, see below.

Our application functions well using Webstart with JRE After upgrade to, however, it stops working (it still works using the browser). The application window opens, but stays blank except for the 'Window' menu, and does not respond to anything but closing the window. The test.fmx does not have the problem, so I think it might have to do with webutil functionality that we have in our form.
I will try to debug it, and report back when I find the cause.
Permalink 03/02/09 @ 09:08
Comment from: Peter de Vaal [Visitor]
I have found where it goes wrong with JRE It is the database login screen that should popup when you have not specified the userid parameter.
When a valid connectstring is specified for userid then the application starts.
When a connectstring is specified with only the database name (e.g. '@orcl') then the loginscreen pops up (allong with an error dialog which can be dismissed). After fillig in correct credentials the app starts.
Only when no userid is specified the form hangs.
Permalink 03/02/09 @ 15:12
Comment from: Jan Carlin [Member]
Is there any condition under which this happens running the "normal" way? If so, please log a bug and I'll see if I can drive a fix thru.
Permalink 03/02/09 @ 18:16
Comment from: Peter de Vaal [Visitor]
If I take out the ON-LOGON trigger of test.fmb then it already happens, but only when using the jnlp. Starting Forms using the browser everything functions well. So it is a specific webstart problem.
Permalink 03/03/09 @ 08:33

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.
Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, a, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
URLs, email, AIM and ICQs will be converted automatically.

Enter the numeric code you see in the image below
(Line breaks become <br />)
(Set cookies for name, email & url)