The few places who tried to migrate their Forms applications to ADF (in my country) have failed in their attempt.
Forms migration usually does not fail because the Forms developers cannot learn the new framework (be it Java, .NET or whatever) but because the application was built with the application logic within the forms modules. There is no tool (at least none I know) to sucessfully extract this business logic. So usually those applications have to be built up anew from scratch.
I maintain some forms applications. There is no (almost no) business logic within the modules. Forms is only there to display data and to let users change them. The logic is within PL/SQL packages. Now we have some new applications that use the same logic and we didn't have to change a single line of code. When we want do replace the Forms with another front end ... no problem (mostly)
As a side effect we developers don't have to feel very insecure and be worried about our future. Maybe we don't build Forms modules anymore, but there is still the greater part of the application within the database that needs maintainance - and every Forms developer should know enough PL/SQL to be able to do so.
How are fellow Oracle Forms developers dealing with the death of Oracle Forms?
No need to deal with death. Maybe there are no new applications built with Forms but there are many many legacy applications out there that will run until I retire :-) this does not mean that I want to maintain them, but if you don't want to change your core technology you don't have to worry. Nevertheless I would never advice a young student to learn Forms (less competitors in the future years for me .-)
My father in law has been asked after his retirement if he didn't want to come back to maintain some COBOL applications. COBOL has been declared dead two decades ago and you can earn a lot of money now when you are a good COBOL programmer.
Wow - I don't really know where to start.
Let me start by saying that Marcus stated it pretty well. But I'll try to expand.
One thing that always amazes me in the technology industry (most of them) is that the minute something new comes to the surface, many people feel the need to jump in with both feet. They usually do this before knowing a single thing about what is at the bottom of the pool they just dove into. Fortunately, when my parents asked me "if everyone else was going to jump off a bridge, would I follow", my answer was "no". Unfortunately this isn't true of many people in the tech world. So, what's my point? Well, just because you believe that no one else is developing with Oracle Forms, I ask, who cares? The questions you need to ask when you choose any tool or technology to do a job (this includes software, hardware, TVs, stereos, hammers, screwdrivers, etc) are things like this:
- What exactly is the task we are attempting to accomplish?
- Does the chosen tool/technology fit into our budget?
- Do we have the skill set to use the new tool/technology?
- Do we have the skill set to use our current tool/technology?
- Does the tool/technology you already have meet or exceed the current business needs?
- Will a new tool/technology offer any improvement to the cost of ownership, employee efficiency, or ease of maintenance compared to your current tool/technology? In other words, what will we gain by starting from scratch?
These are just a few things to consider. There are many more.
So, on to more specific and technical information.
First, the Oracle Forms product continues to live on. Developers are actively working on the next version as I write this post. We will continue to develop it until someone tells me and the team(s) around me to stop. When will that be? Well, I have no idea. By the same token, I also can't tell you when ADF will die, when Microsoft Windows will die, or when any other product on the market will die. Anyone who claims to know is lying. As for Oracle products (specifically Forms for the sake of this discussion), the only exception would be if you hear it from an executive at Oracle or the Oracle Forms Product Manager (in this case, that would be me) or my boss or someone with the authority to offer a press release.
That said, I am here to tell you that I'm not ready to see it die yet and neither are those above me. So, on we go..... We have many new features planned for future releases and we are also hoping to improve on many existing features. Over the next few months you likely will see me post questions and polls asking for your input (the users) on features we are investigating. So keep your eyes open and please participate. Also, I will be traveling the country (US) and likely the world, attending various User Group conferences and of course Oracle Open World (this year's just passed). Please come and see what we have to say. At minimum, I will offer a session at each of my stops where I will be sharing our direction forward. My next stop hopefully will be DOAG in Germany (Nov 2013), although final confirmation is still pending.
As for the idea of working new projects with ADF or other technology, personally I think this is a great idea. Yes, you read that correctly. Not because Forms might not be around forever, but because admittedly, Oracle Forms can't do everything. There are clearly advantages in using ADF over Forms for some functionality. Just the same, Oracle Forms has advantages over ADF. This goes back to my list of questions. Specifically, the first. What is the task you need to address? If ADF can do it better than Forms, why not use ADF if you have the skills to do it? However, if Forms can do it better, then use Forms. If I need to insert a nail into a board, use a hammer and not a screwdriver.
If you or your company is just hoping to see a shiny new face on your existing Forms application, well that can be done without a complete rewrite (at least in most cases). There are many ways to improve the look and feel of a Forms application. However, the problem seems to be that many people are unaware of how easy this can be done. Take the time to ask.
Finally, Markus mentioned that there are no tools or products that allow you to extract or access the business logic embedded in a traditional Forms application. Well, that isn't exactly true. There are some products on the market that can do exactly that. In some cases, they can even offer a way in which the entire UI can be replaced without a single line of code change in your Forms application. One such example is offered by Oracle Partner, AuraPlayer.
Choose your tools wisely and good luck!
Oracle Forms Product Manager
The views expressed in this posting are my own and do not necessarily reflect the views of Oracle
There are some products on the market that can do exactly that.
We evaluated the available products in 2012. Not because we really wanted to migrate, but because it's always a good idea to know the possibilities, just in case. There was only one tool that really transformed the forms modules into Java. But when you looked at the generated code it gave you the creeps - totally unmaintainable code
AuraPlayer does a good job in making the modules/logic available for different technologies, but as I understand it it would not solve the problem of Forms dying. In the background you still have your Forms modules.
What we learned many years ago: keep your business logic away from the GUI (we did this even before any MVC-pattern made it a default). The GUI technologies change quicker than any business, let alone the database.
BTW: our applications usually don't follow standard MVC pattern but are more like the Helsinki approach :-)
Good to hear Michael! I can never find anything easier and faster with which to develop a form against oracle than Forms.
Regarding this statement: "There are clearly advantages in using ADF over Forms for some functionality. " I wish someone could expound on that. What ARE the advantages of adf over forms? I'm serious. I'm not trying to be sarcastic.
I have tried ADF in the past and was overwhelmed by it particularly the amount of duplication of items. The MVC model causes what is one column in one table in the database to explode into objects all over the place representing that column.
For me, I felt like I was witness to where there was an explosion in the column warehouse. We have very large tables representing enormous survey instruments. Handling gigantic forms is quite a plus in Forms. In Forms changing attributes about columns is pretty easy. (We frequently need to upsize columns, even change the type, even change the name, and frequently add columns to tables, etc.)
I won't get into an ADF or Forms sales pitch here. However, each product does have advantages over the other. Regardless, as I mentioned, if Forms is able to do the task you are faced with then you found the right tool for the job. Over the next few months, I will likely try setting up webcasts and other content that should hopefully help everyone make their old looking applications look better. Although I realize that the people making the money decisions in most companies really don't worry too much about how an application looks (especially if they are not the ones using them), there are some simple ways in which you can improve the look and feel of a Forms application and likely make the end-users eyes a little happier. And we all know a employee is a productive employee. No one wants to look at a dark and dreary yesterday looking app all day long. Put some spark into your app. A simple color change can make all the difference in the world to the end user. I will be discussing this and numerous other tips over the next few months. Keep an eye on the Announcements area of the Forms Forum, Forms page on OTN, and Twitter (@OracleFormsPM)
Well now that you mentioned it, I for one would really like to see more colors available, for everything. In our enormous forms we like to use different colors to help keep people on track about what section they are in, what goes with what. Forms doesn't have that many usable colors. We want a lot more "pastel" colors. How about a way to just specify any RGB color? We need this for boilerplate, prompts and fields.
Also it would be a plus if in the object explorer view the items held the same color they are specified to be. That would help the developer to understand groupings in the object view.
Hello everybody. Thank you for your responses. After reading the responses, I think you have to look at this from the point of view of the country you are in as well. I am from Sri_Lanka, a small South Asian country. Here we have a very small IT Industry with about 8000 IT professionals (8000 is everybody including network, project mgt. etc.) in total.
For example, here nobody has COBOL applications. Unlike the in the US where even a retired COBOL developer can get work, we don't have that luxury here. Here all legacy application really died over 15 years ago. Here everybody goes for the latest thing. Java and .Net is the "latest" thing. Even when a company wants to build a new system (say a production system) the company top management (who has very little or no IT background) would specifically request for the technology. So now here, every is asking for Java or .Net. That is our problem.
For example, we recently did a POC for a client for a document management system. After we gave them our demo, one of the questions the top management asked was "Why are you still developing applications using Oracle Forms?". Problem is, we can't ask them the questions given by Michael (i.e. asking the 6 questions). That wont cut it here. People will refuse to accept that logic. They want the "latest" trending thing and that is Java and .Net.
So, I think people in countries like US, Germany have to look at this problem from a different angle and take into account country specific scenarios, especially when it comes to developing countries. I hope you understand.
As Andreas mentioned, if your company has decided that they must use whatever is current then I guess you have to follow their instructions. Regardless of whether that is a good or bad decision, the technical issues remain the same. If you want to move from one technology to another a large scale re-write will be necessary. This will likely be costly and time consuming. How much of a re-write will depend on how the current application was written in the first place. With that in mind, if you are going to use a new technology that claims to offer great benefits over another then I don't recommend using much of the old code. Attempting to recreate your Oracle Forms application in the way it looked and functioned won't make much sense. The only logic that should be shared is the business logic and even that likely needs to be updated, therefore re-writing it might even be necessary.
Problem is, we can't ask them the questions given by Michael (i.e. asking the 6 questions). That wont cut it here. People will refuse to accept that logic. They want the "latest" trending thing and that is Java and .Net.
If your management is suffering from CBD (compulsive buzzword disorder) you might as well tell them that webforms are in fact using JEE technology (the forms and the listener servlet) and Java Applets on the client. There is no need to tell them that the majority of work is done in the plain old c forms runtime and the servlets are just there to talk to the applets on the client
Well, if your management has already made up its mind about the technology you should use then obviously there is not much to debate about when to use forms and when not to use it.
You might ask them what the benefits of using JEE at all costs they see. As said - forms uses this groundbreaking new (muahaha) JEE technology as well - so if they are buzzword happy just add those to the technology stack of forms, as it is used by forms. There would be no webforms without JEE.
Be also sure to add words like webservices (after all you can implement those with the forms installation) as well as cloud (the upcoming forms version 12c has the C for cloud, so it has to be cutting-edge, right? though carefully dodge the ball if they ask about details ) BI (if you choose to use the 11.1.x version bundled with discoverer this also should be covered) and some other buzzwords you might dig up from the documentation.
What also might make them change their mind is to do the math and tell them how much the company would have to invest to bring all developers up to speed on a new technology with a new programming language they probably also would have to learn.
That is the case here that java and dot net are the most popular job requirements and they are strangely asked for together in job ads. You would think they could hire java developers and dot net developers separately but no, they want people with a lot of training and experience in both. So they expect people to be familiar with linux and maven and eclipse and cvs and appservers and servlets and all that stuff AND be familiar with visual studio and dot net and sqlserver and windows. It's weird. While c# does greatly resemble java, there's a lot of differences there. I have been told by java experts that the good way to do things is via servlets with jdbc code in the mvc model to talk to the database. So they can switch between oracle and sqlserver or whatever database if they coded their jdbc in the proper way. There is a lot to be said for being database neutral. However, dot net is not very database neutral, I don't think but there is odac to get dot net to talk to oracle. I suspect that what people are trying to do is get away from database lockin. Oracle forms only works against oracle database, right? I think it would be better if oracle forms could achieve compatibility with other databases, removing that db-lockin mark against it.
A plus regarding applets is that applets can do things that most web applications cannot do, such as speak to devices on the client. I'd like to see forms find an easier way for developers to enable such features. I have yet to get webutil to work in forms and I'd rather not depend on that but instead see those functions built into forms and an easier way to launch code than java beans. That takes more expertise than I have been able to summon. My point it is that since applets have inordinate abilities the applet capabilities should be maximized and made easier for developers to use.