Very good points. In general, when I do presentations about Forms, I usually describe Oracle Forms as a product that allows you to develop desktop/web hybrid applications. In other words, the applications you build are deployed via a web environment, but actually run like a native desktop application. This allows you to take advantage of the strengths from both web and desktop. Tasks like integrating with local applications and even the OS are mostly easy with Oracle Forms and nearly impossible with a true web application, unless you write a java applet for your web app.
Regarding the configuration of WebUtil, for the most part, WebUtil is configured out of the box if you are using a newer version (e.g. 11.1.2). The only configuration to the environment that you need to do is obtain Jacob and sign its jar file. Then place its libraries (2 dll files and 1 jar) into the proper locations. No other configuration is necessary unless you just want to customize it.
We (Oracle) have also discussed building the WebUtil functionality directly into the Forms applet. However, we decided against it (at least thus far) because we didn't want to make the main applet any fatter than it already is for something that is completely optional and not used by many. In a future version of Forms, we will provide an easy way to omit the OLE (Jacob) component of WebUtil. So if you are not going to use OLE you won't need to download and sign this third party piece.
Now that would be great (eliminating the signing thing). It is getting much harder to sign jars as time goes on.
in 2014 using jre 7u51+:
"RIAs must contain two things:
- Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes.
- Manifest Attributes
- Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions.
- Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g. intranet.example.com).
[How does this affect forms? Will customers have to sign forms jars in order to get that Manifest customized? What if you needed to move deployment from one domain name to another domain name? Would
you have to resign the jar to correct the domain name? (location of hosted code)]
(There is another option to deploy a file on the client (deployment ruleset)
but that isn't terribly easy to understand either. How can people test this stuff before 2014? The vendor needs to deploy a testing program for people to test their jar signing and etc
Considering that browsers can make their own decisions about executing plugins (Note chrome threatens to not run most plugins at all in 2014 including I think jre) it is important for people to be able to figure out
what is stopping the jre, the jre itself or the browser or something else?
I don't think some of those old habits of using self-signed certs to sign jars will be flying. We will also need to take into account the timestamp as you don't want your jar signature to expire when the code signing cert expires.
Instructions about signing will have to get a lot more detailed.
One thing I can tell you is that I and our head of development for Forms meets with the Java PM team at least monthly (generally weekly) to discuss how the changes they are adding will impact our product (Forms). We are testing early builds of the Java updates long before they are rolled out. As we catch changes in behavior that might not be acceptable we discuss them. If alternatives are available, the Java team is doing their best to document the requirements and alternatives. Remember that in all of the recent cases, the changes have been in an effort to improve security. And, if you fully understand those changes, you should agree that they have improved security quite well. If you are not interested in involving your end-users with the decisions related to security (i.e. new dialogs), options such as the new Deployment Rule Set can be used. Other alternative options may be provided in upcoming releases.
Regarding the new manifest requirements, Oracle Forms jar files are being updated as the changes are provided to us. Patches will be made available via Support for the latest releases (184.108.40.206 and 220.127.116.11). If you are using older versions, well this might be yet another reason why upgrading is so important. Obtaining patches for 18.104.22.168 and 22.214.171.124 may be possible, but that can be addressed on a case by case basis with Support.
As for browser vendors putting a lock-down on plugins, well they can try but I think there are just too many people using them for that to work. I suspect Chrome and other browsers that do this will lose followers and they will eventually undo their changes. Specifically to Chrome, it is my understanding that in 2014 they will be locking out some plugins, but Java will not be one of them. This is just my understanding - I could of course be wrong
thanks. Most of all, our applications need to work.
We will still need to have to know how to sign jars like signing webutil and any beans someone would write. So I hope more information will be available about that in the future.
One thing to keep in mind is that the idea of signing jar files, setting applet parameters, issues with the Java plugin, etc are all "Java" issues. The reason I bring this up is that many people using Forms, search for answers to these questions in the context of "Forms" and are disappointed when they struggle to get those answers. Out-of-the-box, Oracle provides the Forms product with no need to sign jar files, alter applet parameters, write java code, or anything else significantly related to "Java". The only thing Java related that is asked is that you have a Java plugin installed on the client and even that can be somewhat automated if the client is using IE as their browser. WebUtil might be the other example, but the use of WebUtil is optional. My point is this. If you are having problems creating jar, signing jars, using the plugin, or anything else not directly related to Oracle Forms, I would recommend directing your questions or comments to Java forums, Java Support, etc. We (Oracle) have a Java Support team, various Java forums, Java Documentation and Tutorials, and numerous other areas where you can get information specific to Java and its tools/utilities. By doing this, you are likely to get faster and more current information.
I have been working with the Forms Support team to begin authoring more Java related Support Notes, however many of those notes will direct you to the Java documentation. In other words, although the doc may offer a solution, the note should also explain how the topic of the note really isn't "Forms", but rather "Java" related.
To your point/comment. The Java team has done a great job of documenting the details of various changes recently rolled out. My recommendation for find this documentation is the Java Release Notes. In each new release, the Rel Notes offer high to intermediate level details of the changes made. In the text of those details you will find links to the associated documentation that can be used to help answer your questions in more detail. So for example if you want to know more about the recent changes to Jar file manifest associated with Java 7U45, refer to its Release Notes, found here:
Then in the new Features section read the section titled "Protections Against Unauthorized Redistribution of Java Applications". At the end of the explanation you will find a link that takes you to a more detailed explanation of changes in the manifest and how to use them. Then on the bottom of that page, you will find yet even more details if your really want or need them. Similar will be true for the new signing requirements and so on. That said, here is a good starting place for information about Jar signing:
The key to find most of the information easily is in the Release Notes. All of the Java 7 Rel Notes can be found here:
Hello again. Thank you very much for your responses. It is very helpful. But I don't think you understand what I am trying to say here. We don't have anything against Forms. We love it. Problem is, outside world does not know about it and everybody wants to develop their systems in either Java or .Net.
Like I said, we took our document mgt. system to a customer demo to an insurance company. In the demo, there were also people from the IT department of the Insurance company. Because when a company buys a product, the IT department has a big say about the product, since they get involved in maintenance and other things of the product. So, it is these people who are asking us "Why are you still developing applications using Oracle Forms?". They expect us to develop using Java or .Net. So, we can't argue with potential customers on merits demerits of technologies as Michael pointed out. That is our biggest problem. Some customers we give demos to have not even heard of Oracle Forms. They asks us, "what is this Oracle Forms?". Mind you these are CTOs, IT Managers who asks us questions like this.
So, what are we supposed to feel except really bad and insecure about future? We love Forms, but if the outside world has not heard of it, or not willing to give it a try, considering it a dead product and opting for Java and .Net, what is our future?? Where do we go from here? What are are options???
Marwim the automated migration isn't working (as of today). It may work just for the simple forms and even then it makes the code unreadable.
But what do you think of a product that allows you to run the old Forms with the new ADF Forms simulteneously in an ADF environment? Additionally, what do you think of a lean migration process where you migrate the Forms one by one and still keep the old till you are sure that the ADF migrated form os working and is learned how to work with by the users? Will such a product be useful? And at last but not least it will save 3 months time from expensive ADF consultants.
If the company purchasing the application from your company will be responsible for its maintenance (including code changes) then the original questions I offered apply to them as well. If their IT team is solely knowledgeable in Java (as an example) and they know nothing about Oracle Forms or pl/sql, nor do they have interest in learning it, then yes, the right thing for you to do is build your app using Java.
On the other hand, if your application has already been developed and proven stable and does the job in question, then the cost of re-writing in another language/technology should be put on the customer wanting such a change (at least in my opinion). If your application has not yet been written, then that's a completely different story and providing the customer with what they want makes sense as long as what they want can perform the job.
I think the roadmap for Oracle Forms has been mostly clear. We are currently planning to continue development of the product. We are planning to offer new features and enhancements as new versions are released. If you have an existing application then continuing to upgrade it as we offer updates is a reasonable plan. Further, continuing to take advantage of new features provided is also a good idea both for modernizing your application and improving its security. For projects that will be started from scratch, using Oracle Forms, ADF, APEX, Java, Microsoft .Net, or any other technology will mostly be based on my original set of questions. Clearly if you don't have a single Oracle Forms developer on staff then using Oracle Forms for your next project may not be the best choice. Same might be true of any of the others.
The views expressed in this posting are my own and do not necessarily reflect the views of Oracle.
My point is that instructions about deploying webutil or your own bean in the forms context historically have instructions on how to self-sign jars. That used to work. Now it doesn't and it's getting worse by the minute.
We need good examples of signing jars for deployment in forms in the best way, ways that will work in paranoid browsers like firefox or chrome. Someone has to figure it out. But maybe not you.
I have looked at Oracle's docs and do not find it easy to understand, that is one reason I bring this up. Reading stuff is one thing, actually getting stuff working is another.
Fortunately the browser has nothing to do with jar signing nor does Oracle Forms. The concept of signing a jar is the same regarding of how you plan to use it. The Java Tutorial provides a great step by step procedure for signing and verifying signed jars.
We (Oracle) previously made it easy because we provided the courtesy script (sign_webutil) which did exactly what the above doc discusses, but in a script. The script we provide assumes you want to use a self-generated certificate. Unfortunately this is no longer recommended by the Java team. For cases where you feel that this is not an issue, you can still use self-created certificates, but you will need to import the that self-created certificate into each client keystore. So, for everyone worried about having to purchase certificates, this isn't exactly the case. Other options are also being provided. For example the new Deployment Rule Set (DRS) feature would allow you to continue using self-signed jars. Information about DRS can be found in the Java Release Notes starting in 7U40.
That said, as time permits, I will look into creating a white paper that might make the process easier.
If you want to discuss this further, please contact me directly or start a new post. We clearly have gone off topic.
Message was edited by: MichaelFerrante(Oracle)
But what do you think of a product that allows you to run the old Forms with the new ADF Forms simulteneously in an ADF environment? Additionally, what do you think of a lean migration process where you migrate the Forms one by one and still keep the old till you are sure that the ADF migrated form os working and is learned how to work with by the users? Will such a product be useful?
I don't know. I have seen applications where Forms run smoothly beside ADF modules, but we never evaluated this options, because we do not intend to migrate.
And even when we migrate it is not likely to be ADF. Our company has made a decision about the technology stack for new applications and it is not ADF :-)
Interesting, and thanks for the responses Michael. As a Forms developer since before Forms was Forms (it was IAF) , I haven't used Forms for over a year now as I'm on a datawarehouse using Exadata. The backend is all PL/SQL and OWB and the front end is a BI tool. The monitoring software is .Net. This may be part of the future and I'm happy on the project : huge amounts of data being moved and sliced and diced by very a clever front end that isn't .net or java.
But I've also learnt and used APEX (which is great) and used JDeveloper for java and webservices , XML , XSLT, JDAPI where appropriate - but never a Java front end.
Will I use Forms again ? I don't know - I work on contracts so if there is the requirement then no problem but I doubt I'll build any new systems but will be happy to support the existing systems
I think this is a great topic (what is the best way to develop forms-like apps and what technologies and skills do employers favor in hiring for app development) but clearly the forms forum is not the ideal location. We need something like Forms Anonymous for such a discussion :-)
I find it difficult to believe what Michael says. Because according to the "Oracle® Fusion Middleware Concepts Guide
11g Release 1 (11.1.1) Part Number E10103-09" guide, Oracle Forms is not listed as a "development tool" as part of the middleware solution.
1.4 Understanding the Oracle Fusion Middleware Solution
Oracle Fusion Middleware is a collection of standards-based software products that includes a range of tools and services inlcuding developer tools, integration services, business intelligence, collaboration, and content management. Oracle Fusion Middleware offers complete support for development, deployment, and management.
Specifically, Oracle Fusion Middleware offers the following solutions through its middleware design:
- Development Tools: A unified SOA development tool and framework. An integrated, but modular, set of development tools to build complete applications, rather than using lots of specialized tools. The design tool includes a single design environment for user interface, business logic, service composition, business process or workflow, business rules, and business intelligence. The design tool enables simplified design and debugging, and to improve productivity. Includes Oracle JDeveloper, Oracle TopLink, Oracle Application Development Framework, and Oracle Eclipse.
Where is Oracle Forms?????
I didn't know there was an "oracle eclipse". And what is the difference between "Jdeveloper" and "application development framework". I thought jdev was adf. Hmmm. This implies there are 2 different products there plus that "oracle eclipse". And they do not
mention apex/application express.