Oracle JDeveloper and Oracle ADF Blog

Oracle ADF and Oracle JET - What's the Story?

Shay Shmeltzer
Director of Product Management - Oracle

One of the key announcement at Oracle OpenWorld 2015 was the release of Oracle JET - the Oracle JavaScript Extension Toolkit. We know that this might raise some questions among ADF developers, so we wanted to clarify the answers to some of the possible questions about the relationship between Oracle ADF and Oracle JET.

Why a new framework?

Java is the leading language in the industry today,  and with Oracle ADF we have a great offering for developer looking to be more productive leveraging Java on the Oracle platform. But there are other languages in the market too, and JavaScript is quickly gaining popularity and by many accounts is the second most popular language today. JavaScript is very popular for front end development of web interfaces, and even inside Oracle we had product-development teams that were looking to leverage the advantages of JavaScript in their UI. However the JavaScript ecosystem was missing some capabilities that we require for our products (such as accessibility, internationalization, and other advanced technical aspects). We wanted to have a toolkit that will guarantee that developers inside Oracle who are going with this architecture of JavaScript/HTML/REST comply with our standards for product delivery - this is why we created JET - which initially was only targeted for internal use inside Oracle. (This by the way has been going on for three years now).

Over the past couple of years, we also started to hear from customers and partners who wanted to use JavaScript based UI development and were looking to see if Oracle can help them. We realized that JET can help our customers, especially if they are working on the Oracle platform and looking to leverage things like the Oracle Alta UI or REST services exposed from our SaaS applications. This is why we released JET publicly for our customers.

Should I be using JET or ADF for development?

You can answer this question in two ways.

One way is to ask what are the skills of the developers in your company. ADF and JET target completely different audiences. ADF is for Java developers, JET is for JavaScript developers. ADF is aiming to provide a declarative development approach while JET is staying true to the code-centric approach that JavaScript developers are used to. Also ADF is very easy to get started with even if you have no previous experience - go through the tutorial and you'll be able to build a basic application. JET on the other hand is aimed at developers who are already experienced with JavaScript development - it's not for the total rookie.

The other distinction is architecturally based, ADF is a Java EE framework running on the server and covering the full set of layers of your application. JET is a client side framework that takes care of UI and binding to REST services. Each of these architectures has its benefits and places were it will shine, so choose the right architecture for the implementation you are aiming to do.

Are those the only differences between the two? 

While the two distinctions above are the main thing to consider, there are other aspects that you would want to look into.

For example, how do you feel about protection from technology shifts?

ADF does a great job of abstracting you from the underlying technology by using meta-data driven implementation. So as an ADF developer you were mostly oblivious to changes such as transition from JSF1 to JSF2, or from using Flash in rendering charts to using HTML5, or from exposing ADF BC as SOAP to exposing it as REST. These type of changes didn't require you to re-write your app, and you were able to get your app upgraded to use the new technologies in a seamless way.

Oracle JET doesn't offer that level of abstraction from the technology - you are actually directly coding at the technology level, and at that level things might change in the future. The JavaScript eco-system is still volatile and shifts do happen. When we designed JET we took this into account and put a lot of focus on building a modular architecture. This means that you could switch parts of the toolkit as needed. This also means that we can't promise that you won't need to re-write parts of your app if you'll want to leverage new technologies when JET picks those up. Oracle JET's modular approach aims to make it as painless as possible to adjust to future changes. 

Here is a slide we used in OOW sessions that lists some other differences between the two framework.


Which one is the strategic framework for Oracle?

Both are. We don't see either one of them as a replacement for the other, we believe the market has a place for both frameworks. We didn't create JET to replace something - we created JET to add a solution to our tools-belt for capabilities and languages that we didn't have a solution for before.

Inside Oracle you can actually see both of them being used. All our SaaS applications are built and continue to be enhanced with Oracle ADF, and so are various other cloud products.

Other cloud products use JET for their UI layer - examples include Mobile Cloud Service, BI Cloud Service Visual Analyzer, Developer Cloud Service.  

Each one chose the technology based on the developers skills and functionality they needed.  

Are there integration points between the frameworks?

From our perspective as the development organization behind both frameworks, we share resources and knowledge among the frameworks, for example the same team builds data visualization components for both JET and ADF (and MAF) - and you can see the same components available in those frameworks.

In terms of using them together, JET UIs can access any REST service at the backend - for example JET can access REST services exposed from ADF Business Components. (In fact, JET knows how to leverage the detailed description provided by the ADF BC REST service to simplify binding UI to the data).

On the UI side, ADF Faces provides a complete JavaScript API that can be used to interact with JavaScript components on the page - since JET components are such components, you could embed them in an ADF page. Be aware that their lifecycle is independent from the ADF page lifecycle - so do the integration with care.

What's the bottom-line?

At the end of the day, we are continuing our commitment to support developers with tools and frameworks that will help them leverage and integrate with the Oracle platform using their language of choice. We are now expanding to cover JavaScript UI developers.

[Update Feb 2019 - For some more up-to-date thoughts on this topic read this blog]

Join the discussion

Comments ( 9 )
  • guest Thursday, February 18, 2016

    When I add JET java script libraries in ADF page (jspx or jsff), my page does not open up. I see an error "ReferenceError: AdfRichInputText is not defined"

    <script data-main="/contextRoot/js/main" src="/contextRoot/js/libs/require/require.js" xmlns="http://www.w3.org/1999/xhtml"></script>

    this is how I am adding the JET to ADF

  • Shay Shmeltzer Thursday, February 18, 2016
  • guest Thursday, March 24, 2016


    Can I develop JET in Application Cloud Service but what are my choices for deployment?

    1) Apache Server?

    2) Any Oracle Cloud Service?

    3) AWS?

    Please advise.

  • Shay Shmeltzer Friday, March 25, 2016

    guest - JET applications are just HTML/JavaScript resources that can be served from any web server. In most cases you will also want to have some server side REST services that provide data to pages from various sources - again these REST services can be hosted on any platform.

  • guest Thursday, April 28, 2016

    Hi Shay,

    Few comments on your statement, above:

    "ADF does a great job of abstracting you from the underlying technology by using meta-data driven implementation. So as an ADF developer you were mostly oblivious to changes such as transition from JSF1 to JSF2, or from using Flash in rendering charts to using HTML5"

    Indeed, but in terms of moving towards HTML5, ADF still has a lot of work to do:

    Problem A. Make use of powerful validations on client side:

    <input type="range" size="2" name="satisfaction" min="1" max="5" value="3">

    This is one of the biggest weaknesses of ADF (with BC): for the simplest validations in ADF BC (eg check if a number greater than 0), a server round trip is necessary. All this, when such validations can be kept on browser level, using javascript

    Why not enhance your Validator's Client side part?

    Problem B: Websockets. we are waiting for websockets support for years in ADF.

    Problem C: ADF Javascript calendar popup.

    Opening the calendar (the one next to any input field) requires a server round trip. I remember using javascript calendars 10 years ago, on web.

    Every time I show ADF to a web developer (non ADF), I am being ridiculed for this.

    Problem D: ADF Javascript API : far too thin.

    With latest standards, we get a database in the browser:https://en.wikipedia.org/wiki/Indexed_Database_API

    No point for caching user data on server anymore.

    Therefore, I think we need ADF BusinessComponents on javascript layer. But maybe I am asking too much.



  • Shay Shmeltzer Thursday, April 28, 2016

    Florin a couple of notes

    A. Client side validation is supported with the ADF Faces validator tags which are executed on the client with no need to go back to the server.

    For example af:validateDoubleRange


    B. ADF Faces has active data services letting you push updates to the client - so in terms of functionality you get something similar to what websocket offers.

    C. This could be something that we can add in future releases as we add more client side behavior to ADF Faces components.

    D. Client side databases are limited in functionality and size today - they are not targeted at replacing your main data storage. ADF BC won't make sense here - since ADF BC runs on the server and not on the client. We'll be interested to hear about a real use-case for a browser DB in an ADF application.

  • guest Thursday, April 28, 2016

    Hi Shay,

    A. You are right about af:validateDoubleRange firing on client side.

    However I am referring to BC layer's validations case. JDeveloper doesn't associate a af:validateDoubleRange to a validator defined on an Entity Object attribute.

    While BC layer remains the most productive way of building ADF large scale applications, it would be tremendously productive to have some of the basic validations defined on Entity Objects -> executing on the client.

    B. Active Data Services have never been production stable.

    We got burned with it when delivering a solution with ADS to a customer which couldn't handle more than 5 concurrent users. There it must be a reason why nobody from ADF Management Team didn't come out with the simplest ADS example.

    We had to move to websockets for getting a proper solution.

    But even if ADS would have worked, any HTTP long polling solution is far from what a websocket can offer.

    C. This is a great news.

    D. Client side databases are targeted to replacing server user cache (exactly what ADF BC does).

    If you check BC Layer objects size for one user, it would hardly be more than 1-2 MB - therefore it would fit easily in browser database limitations (https://www.raymondcamden.com/2015/04/17/indexeddb-and-limits/)

    Here is one architecture (in theory): JET + REST, but JET caching the screen data in an IndexedDB database.

    Then, we won't need Middle Layer for holding client state.

    Of course, a Javascript-based Business Components layer would be far less comprehensive than the server counterpart.

    But a nice way to cache data returned by REST calls, don't you think?

    IndexedDB is a standard nowadays and people are already releasing offline solutions with plain HTML. HTML5/IndexedDB are turning the web development concepts upside-down. The need of JSF technology with HTML5 is harder and harder to justify. Unless JSF moves on the client.

  • Shay Shmeltzer Monday, May 2, 2016

    Florin some points:

    A. This is not going to be trivial, if we replicate the ADF BC validation automatically in the client side, then changes to the validation rule in the middleware won't automatically be reflected in the UI. Since validations in ADF BC can be dynamic using Groovy - this won't be a trivial thing to replicate on the client automatically.

    B. Active Data Services seems to be working fine for us. For example our Oracle BAM product is using it heavily.

    Not sure what specific issue you ran into.

    C. Indeed.

    D. If you are looking for a "we don't need middleware layer/JSF on the client" ADF might not be the right thing to look into. JET and its client focus architecture might be better specifically for these type of situations.

    There is a reason why JET is separate from ADF, and trying to force ADF to work just like JET is not our goal.

  • guest Monday, December 26, 2016

    is there any step by step example for JET with ADF

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.