The 12c release is a major milestone both for ADF and JDeveloper. Most of you already know how strategic ADF is to Oracle; day after day, thousands of our own developers use it to build Fusion Applications, Enterprise Manager, SOA Suite and WebCenter among others. What is not readily apparent is how much maturity there is in the framework. The roots of ADF can be traced back to 1999, when the first release of Java Business Objects (JBO) was made available. The ancestor of today's ADF Faces components, User Interface XML (UIX), has been introduced in 2002. More than ten years later, ADF is still going strong and the best is yet to come.
I have been developing with ADF since 2007. Since then, I often had the opportunity to introduce new developers to it. While I was often greeted with skepticism, the natural qualities of the framework and the productivity brought by JDeveloper usually won minds if not hearts. I saw this once again at OpenWorld 2013. Obviously, ADF is not perfect and there are several worthy alternatives in the market. But what surprises me is that many of the objections made against ADF stem from misconceptions - even after all those years. Here are five of the most common ones:
- ADF is not open.
- ADF is just for huge enterprise applications.
- ADF is proprietary.
- ADF is tied to JDeveloper, Weblogic and Oracle Database.
- ADF is expensive.
My aim in this post is to get the facts straight. Let's discuss each of them.
ADF is not open
This is something I heard frequently. But what does « open » mean? Is it about access to the source code? About technical interoperability? Maybe about stewardship? Customers covered by a valid support contract can request access to the ADF source code. Not only that, but some of its components have been released under open-source licenses, the most significant being Apache MyFaces Trinidad. And since ADF is built on the top of Java Enterprise Edition, it integrates with other solutions running on the platform. True, Oracle keeps full control over strategic orientations and new features. But our company is making significant efforts to better address the concerns of the community. The ADF Enterprise Methodology Group, for example, is a great forum to propose and discuss new features. We follow closely what is posted there and will never hesitate to open enhancements requests if needed.
ADF is just for huge enterprise applications
This is a funny one, and probably comes from the fact that ADF is based on Java. Yet, small and simple applications are a cinch to implement with the framework; it focuses on productivity first. Lots of people forget that ADF favors a code last approach. In other words: most ADF artifacts can be implemented declaratively rather than through code. In addition, most of the time, developers will build the user interface simply by drag and dropping attributes from the data controls palette. Moreover, ADF puts great emphasis on reuse. Entity Objects, View Objects, Task Flows and Page Fragments are inherently reusable. You can push this even further by using page fragments, JSF templates and declarative components. Thus, you can reduce the actual size of your applications by sharing code extensively between applications. It is also essential to remember that ADF implements several common software patterns, such as Model-View-Controller, for you. This results in a little more complexity, but ensures that even the smallest of your applications adhere to industry best practices.
ADF is proprietary
ADF is certainly unique to Oracle. In fact, it represents one of our biggest competitive advantages in the marketplace. Yet, some people conveniently forget it is a superset of Java Enterprise Edition first and foremost. ADF Faces, for example, is probably the most comprehensive set of JSF components available right now; the Data Visualization components now render to HTML 5 instead of Flash. On the other hand, ADF offers extensive support for the SOAP protocol and the WS-* extensions, which are industry standards. Yes, ADF deviates from JEE in some cases - but typically this is because it was ahead of the curve. ADF BC is rooted in JBO, a technology introduced in 1999. EJBs didn't deliver the performance and features required by developers at the time. In 2008, ADF Controller and Task Flows brought more flexibility than the standard JSF controller - which finally caught up in 2013 in JEE 7. We even make it possible to use EJB or JPA to implement business logic if you prefer them to ADF BC.
Moving forward, you can expect ADF to integrate many more standards, but not at the cost of innovation.
ADF is tied to JDeveloper, Weblogic and Oracle Database
This one was true a few years ago. Nowadays, you can build ADF applications in Eclipse by installing the Oracle Enterprise Pack for Eclipse plugins. You can use almost any SQL92-compliant database with ADF, and we even offer optimizations specific to IBM DB2 and Microsoft SQL Server. Best of all, we offer integration to various Application Lifecycle Management platforms in JDeveloper and OEPE, but are not offering one ourselves. You get to choose the tools you prefer to support your development process. And with the free ADF Essentials, you can deploy your ADF applications to nearly all containers implementing the Java Enterprise Edition web profile. GlassFish server is an obvious choice here, but old favorites like Apache Tomcat and JBoss can be used too.
ADF is expensive
No, it's not. For a long time, ADF has been merely inexpensive as it was bundled with WebLogic Server. With ADF Essentials, the core features are free; the features cut from from it are essentially hooks to other Fusion Middleware products. The developer tools, by the way, are completely free. You cannot really appreciate that fact unless you had to pay for multiple IDE licenses for your team, something I had to do earlier in my carrier when I was building software for IBM and Microsoft platforms.
ADF 12c is there. And it's here to stay. Maybe you should consider it...