Kito:

Hello, and welcome to the JSF Central Podcast Series. My name is Kito Mann. I'm here today with Shay Shmeltzer, who is the Director of Product Management at Oracle. Hello, and welcome!

 

Shay:

Thank you very much.

Kito:

I wanted to get someone on the show to talk about some of the really fascinating things that Oracle's doing with Oracle ADF Faces and specifically Oracle ADF Mobile. I think a lot of the people in the Java and JSF space don't necessarily realize all the stuff that's going on in the ADF world. I'm very happy to have on the show, Shay. For those who don't know you, can you just take a few minutes to give us some background information about yourself, and what you currently do at Oracle, and what you did before you got to the position you're in now?

Shay:

I've been in the software industry for about 24 years now. I started as a developer. Actually, I worked from the start on Oracle products. When I started, it was basically an Oracle 5 database. I've been working with Oracle products for all those years. About 20 years ago, I joined Oracle. Back in Israel, I did every type of development type of work possible. I basically tasted a little bit of doing development and consulting, then moved over a little bit to do sales consulting. Then actually moved over to the US to do a little bit of marketing. Then moved over to Product Management.

For the past, I would say, 13 years, I've been doing Product Management for Oracle's Java development tools. What I'm doing right now is I'm leading a group of product managers who are taking care of Oracle's Java development IDEs, as well as Java development framework, which are now actually extended also to mobile development frameworks. That's my current focus. What I've been doing lately is a lot of work on this front of both web development and mobile development using Java technologies

Kito:

You get to not only oversee how the IDEs, specifically the JDeveloper, the NetBeans, and then also the ... I know there's also a set of tooling for Eclipse as well, right?

Shay:

Yes. There's an Eclipse tooling, which we call the Oracle Enterprise Pack for Eclipse, or OEPE…

Kito:

See, this is why I couldn't remember the full name.

Shay:

Exactly. Oracle was never excellent at naming products. We tend to call them by what they do. The Oracle Enterprise Pack for Eclipse is basically a collection of plug-ins for Eclipse that make for a complete development environment that is able to leverage and integrate with the Oracle infrastructure very well.

Kito:

We should probably start with the ADF side of things. Those who have watched Oracle or worked in lots of Oracle shops are familiar with ADF. But especially for those who are just more familiar with straight up Java, Java EE, and JSF development, could you break down what ADF is, and of course, what it stands for?

Shay:

Yeah, sure. The acronym for ADF is basically Application Development Frameworks. As I said, it's not a very exciting name, but it describes exactly what it does. ADF is basically the framework that Oracle uses to build our own applications and products when we're building web based and mobile based interfaces and applications. What we tried to do with ADF is basically take the Java EE standard, and worked with it while extending it to support additional functionality that we needed. ADF is basically an MVC development framework, like many others in the market. What it provides is extensions in each one of the layers.

We're on the JSF Central Podcast, so we probably should start with the JSF part. At the core of ADF, the web application framework is JSF. We've been doing JSF actually from the get go, from when it first started. What we have for JSF beyond the basics that JSF provides, is we extended it with a set of components, which is what people know as ADF Faces Rich Client Components. This is basically a huge set up for the 150 JSF components with a lot of built in functionality and capabilities. Then we also took the JSF controller layer, and we also enhanced that. We started by enhancing it, by adding more memory scopes for better control of memory allocation.

One of the unique aspects there is that we actually extended it to become more than just a page flow. When you're working with the controller in ADF, you actually are able to do process flows -- navigate from, for example, a page to a function, to a decision point, to another page. Then we took those flows, and actually enabled you to package them in more reusable ways. Reusable ways allow you take one flow and use it in another flow. You can get a hierarchy of flows that call one to the other, but an even more interesting aspect is the ability to take this type of flow, and put it inside a region in another page.

This allows you to replicate a single JSF page, inside of which you're running specific flows that contain other pages. You're basically getting into a situation of a single page interface in this way, and we also extended it to allow you to dynamically exchange which flows run in each section and things like that. That's what we did on the JSF layer. Beyond that, ADF also offers a model layer implementation. First of all, we should mention that we are open to using EJBs, JPA, POJOs, web services, and other technologies, as the sources of data for ADF.

One thing we did do -- I think that's probably the first part of ADF that actually went to production in 1999 -- was something called an ADF Business Components. That's an object-relational persistence layer that we have inside Oracle and we've been using for a while, which is aimed more at people who feel more comfortable with SQL and access to additional databases. As you can imagine, a lot of the developers inside Oracle are coming from this type of background where SQL is our native language. ADF Business Components basically allows us to create Java objects that access those databases and SQL statements very easily.

Kito:

Interesting. So it's completely separate from JPA and all that kind of stuff?

Shay:

Yeah. It was built before JPA was there. It was interesting for us to look at, for example, the advances in JPA and in EJB versions over the years. One thing I'd like to say is that, where JPA and EJB are today, in terms of the architecture, and the ability to create things like entities, and then layers of queries on top of it, and then a façade to form those, is basically where we were about 13 years ago. It's understandable, we've been in the database business for a long time. We knew from the get go how things should work. It took the Java world a little bit longer to get there. I think today, JPA and ADF are very similar in terms of the architecture and how they actually approach interaction with database.

There's a couple more layers to ADF, if we're talking about that. One interesting layer is we have a binding layer, which allows you to very easily connect your UI, or JSF pages, or the JSF controller into your business services. Today, in the Java world, in the Java EE world, it's kind of what CDI gives you for JSF applications. Our implementation is… basic functionality…it gives you something similar. It's still a little different. We actually don't just adhere to using POJOs or EJBs or JPA, as the sources for a CDI object. We actually allow you to use webs services and REST services and XML streams…

The other thing that's really different is we don't require to annotate your business services, but rather we use introspection to figure out the structure, and then we automatically document this for you in metadata. The third part where we are a little bit different is in terms of the development experience for our integration with development tools, both JDeveloper and the Eclipse tooling, we allow to you to just turn this business services into a JSF page. We create all the binding directly for you.

You do get expression language binding in your JSF pages, like in a regular JSF page, but you're saved from the hassle of actually writing any managed bean. It saves you a lot of time that is usually associated with coding JSF. Beyond that, ADF also takes care of other types of user interfaces. One aspect that we can do is we can actually create the user interface using Excel spreadsheets. Then using the same binding layer, same business services layer, and connect your Excel to a Java backend to get the updated data all for your Java logic.

In the last year and a half, we also did ADF Mobile, which is actually an on-device Java based framework for developing mobile applications that's are on Android and iOS. All of these together is what we call ADF. We use ADF internally to build all our big systems, things like Fusion Application, which is everything from human capital management to financial models, to project management, to a lot of our line of business applications, and also a lot of our products are based on idea. It's available for customer to build their own system.

Kito:

Just so people can get an idea of the scale of this, because I still don't think people outside of the Oracle ecosystem really know. How many internal developers do you think there are using ADF, who work for Oracle?

Shay:

We're talking thousands. Just in the Fusion Apps section of the house, we're talking about over 3,000 developers working on that. It's probably one of the largest Java project anywhere, probably the largest JSF project in terms of the amount of development going around it. Again, we're talking about many more than just those, because you will find people using ADF in products like our Enterprise Manager, which is our console for managing the database of the middle layer. You'll find ADF being used in our portal solution, in our BI solution. Internally, inside Oracle, we're talking about thousands of people who are using ADF, who are using JSF as well to build our web interfaces.

Kito:

That's a very important note to make. Obviously, there's a lot of power in what you guys have provided, because you need it in order to provide those really powerful user interface for those applications.

A couple more questions about ADF in general. First of all, this is one of this things I found interesting, you guys build a lot of stuff internally, but you make everything available. You make ADF available to the external developers and also JDeveloper type integration, and also the Eclipse plug-ins as well. Can you give us a sense of what the licensing is? If I'm on a project, and I say I want to use the ADF on my project, what do I have to do? Can I just go and download it? Is it open source? Is it commercial? What's the story?

Shay:

First of all, ADF is not open source. It's actually the Oracle framework, we maintain it, we support it, and we develop it. If you are interested in getting the ADF source code, you can get it if you have an Oracle support license for ADF. It's not open source, it's a commercial framework. As you've seen, it's very critical to everything we're doing at Oracle. We like to know that we're in control of it, and we can do the changes that we need. However, in terms of the actual cost of using it, about 2 years ago we actually announced something called ADF Essentials, which is our free packaging, free to develop, free to deploy, which you can use to basically build applications based on ADF and deploy them for free. 

What is included in ADF Essentials is ADF Faces Rich Clients Components, so all our JSF components. It also includes our advance controller, our binding layer, our object-relational mapping. One thing to understand about ADF is that we believe the power of ADF, the full power, is when you are actually using every aspect of it, using all the layers. But you can actually use each layer separately. If you're just looking for a collection of JSF components, you can pick up ADF Faces, and use just that part. If you're just looking for an ORM layer, you can just use that. If you want to use our UI layer and control layer, and then plug in your own backend and write your own manage beans, you can do that.

It's very modular in the way that you can approach it. In any case, and we're talking about licensing, ADF Essential is free in terms of developmental tools. You can get either JDeveloper or the Eclipse offering, the Oracle Enterprise Pack for Eclipse, both of them come with ADF Essentials built in -- all the libraries you need. You can develop and run new applications.

There's also the full ADF. The full ADF is the product that you actually license from Oracle. It has either its own license, or if you're getting any WebLogic addition, ADF is included in there. It's a server-based license where you're paying based on the size of the server that is used for your implementation. 

Another aspect to mention here is that you can also get ADF as part of the Oracle Cloud offering. If you're getting the Java Cloud Service from Oracle, which allows you deploy Java Applications in the cloud, ADF is included, and you can deploy ADF applications there as well. At the end of the day, it's whatever you are interested in. If you're interested in a free offering, we have that. If you're interested in the full featured functionality, all the customization layers, and security aspects, and integrations with other aspects of Oracle, it's part of what you get with the full ADF.

Kito:

Is it possible to use ADF with a database other than Oracle, or without WebLogic? What sort of restraints are there?

Shay:

First of all, if we're talking databases, at the end of the day, we're just using JDBC. You can use it with any database you want. We actually internally tested it also with a DB2 SQL server and MySQL, beyond the Oracle database. It's completely open in that aspect. Again, as the backend for your ADF application, you can use JPA and EJBs, so we don't care what they connect to, In terms of the middleware and the application server… WebLogic of course is supported and certified for ADF Essentials. We also tested and certified it on GlassFish. We have people who are running ADF Essentials on Tomcat. At Tomcat there's a distinction between an environment that we actually test and an environment that we support. We have limited resources in the environments that we can test. We do make sure to test ADF on other platforms and make sure that it works. Of course it works best, when you're working in the Oracle platform…

Kito:

You mention before the sort of Oracle ADF flow Feature. I don't know what the official term for it is…

Shay:

We call it Task Flows

Kito:

You call it what?

Shay:

We call it either the ADF controller or Task Flows.

Kito:

Task Flow, right. I notice during the process of developing JSF 2.2, we now have something called Faces Flows, which is very heavily influenced by some of the flow features for the ADF layer. Do you know what the plans are in terms of integrating the two in the long run?

Shay:

No, I don't know exactly what the plans are, or even if I know, we can't talk about it externally. But one thing we do make sure to do is be a good citizen In the Java ecosystem. We've been part of the JSF expert group since the founding of JSF. We are trying to fit some of the innovations that we're doing on the ADF side, back into the standard bodies to make it more standardized and also available to other developers outside of ADF. We're definitely planning to share the knowledge and the implementations that we develop with the community.

Kito:

I think that's actually another sort of important thing to point out is that in terms of JSF, a lot of the original concepts came from…I think it was the UIX framework. Was that what it's called back then?

Shay:

Yeah. Oracle has been doing component-based web development for a long time. It was actually great for us to see something like JSF materialize, allowing us to share, again, our experience of what actually works in enterprise development and web development, and actually have a standard based around it, and use it in our systems later on.

Kito:

It's been really nice to watch. You guys have Oracle ADF Faces Rich Client, which is a suite of 150 or so components. Before that, there was just ADF Faces, and there's also something called Apache MyFaces Trinidad, which is open source. Can you just explain the relationship between the three of those?

Shay:

It's the evolution over the years of the technology. As you said, we started with something called UIX before JSF was there. That was our set of components at that point of time. Then when JSF got started, we converted those components to be JSF compliant components, and we call them ADF Faces. It think that was somewhere around 2005 or 2006, in terms of transferring. It was a set of around 100 components that allowed you to build JSF applications. Because JSF, as you see, is very important to us, we wanted the community to be able to adopt JSF, and more people to actually use this standard. 

We took those components and contributed them to Apache, and that created the My Apache Trinidad project, which is basically an open source branch of what ADF Faces is. We were actively involved in creating the project and maintaining the code, and we still do. At some point, the UI technology and web technology started to evolve very fast. We saw the rise of things like Ajax interactions, and much more dynamic types of user interfaces. We realized that we needed to upgrade and update our UI components. We basically took Trinidad as the base code, and then created more modern rendering capabilities on top of it, and added more features. 

That's what evolved into our ADF Faces Rich Client Components, which is what we've been using in our 11G, and 12C versions of our product. That's basically the core, if you look at the libraries, it's still based on Trinidad, but the rendering is much more advanced. We have other components that are not included in Trinidad. Again, those components right now are not open source, but they are free, if you are using ADF Essentials. That's the components we've been using for the past 5 years.

Kito:

As you point out they're a lot, more slick too. If you look at the Apache MySpace Trinidad showcase, because it's sort of older, it doesn't look terribly slick.

Shay:

It's amazing to see the advancement in UI and what can be done in the browser over those years. That's one point about systems today. You can actually look at the system, at the web application, and you can guess what year it was built in.

Kito:

Yeah, very true. Let's talk a little bit about ADF Mobile. When it comes to mobile applications, there are several different ways you could write an application. You can write a custom native application in Objective C or Java on Android devices, or whatever language the device supports. You can just have a website that has good mobile support, which surprisingly still some websites don't, where essentially, you can go to the app, go to the site, and you get a look and feel that actually works well on an iPhone, or an iPad, or an Android device.  

Or you can have a hybrid approach, where you actually download an app. The app maybe uses some HTML5, does some rendering locally, maybe it talks to a RESTful service in the backend, and sends JSON back and forth. Who knows? But essentially you can still download an app, but there's some hybrid sort of integration and some use of HTML5. If you look at what you see in terms of JSF, there's ...what I've seen is a couple of different options. There's the pure HTML approach, which PrimeFaces Mobile takes. There's the more hybrid sort of approach, which ICEsoft is taking with ICEfaces. I believe that's sort of where ADF Mobile is. Could you tell us how that works?

Shay:

As you mentioned, there's basically three approaches for building with mobile application today. One thing to say up front is that ADF Faces is basically supporting the web-based approach of mobile development. One thing we've been focused on for the past couple of years on ADF Faces is adding features that will allow you to create a web application built with ADF Faces, and running on a mobile device. This includes things like supporting touch gestures and those types of animation, moving some of our rendering that was based on Flash components to being based on HTML5 so it would render properly on mobile devices, and introducing new components and new capabilities in existing components specifically targeted to that area. That's ADF Faces. 

ADF Mobile is a separate thing. ADF Mobile is actually a hybrid mobile solution. What it allows you to do is build an application that runs on both iOS and Android. Everything is running on the device itself. The development that you do, you basically code in Java. Then you use components and a flow and controller layer to design your user interface. The concept of ADF Mobile should be very familiar to someone who's doing JSF today. It's not JSF, you're not actually running JSF on the device, you're running ADF Mobile. We have a container that, as mentioned, allows you to install the application on the device and run it there. 

It allows you to interact with device features, invoke the camera, get to the contacts, and send an SMS for example. It also allows you to run in an offline mode where you're just running on the device connecting to a local database. That's the architecture. The interesting part about ADF Mobile is the development. the development approach, what we try to do at ADF Mobile is take all of the thousands of developers you mentioned before, that are working inside Oracle and are currently web developers, and be able to move them to become mobile developers as smoothly as possible. 

We took the same development approach, the same way that you construct the page by picking components and nesting them one inside the other. The same way that you define flows between pages and process using an MVC approach, and the same way that you do binding of UI to backend services using expression language, and the same language that we use for coding your business logic, whether it would be in reaction to UI events, or in the controller layer, or in the model layer, basically Java, and bring all of this to run on mobile devices. That's what ADF Mobile is. It's basically the simplest way to take a Java developer and turn him into an iOS / Android developer.

Kito:

Interesting. In terms of how do you make this work, give us a little more detail. Because what I'm hearing is, I develop a page as a Facelet page essentially, or an XTML page. I put tags in there, which are just like JSF tags. Then I write some Java code, and I package it up, and I run it. It runs just almost like it was running on the server, except obviously it's running for an individual person. There's a couple of things here. Someway, there must be a web server of some sort, and there must be a JVM running, and is there a full-fledged app server running? What server is actually running in the container?

Shay:

There is a JVM, but there is no web server or middleware layer. In order to run the Java part, the logic, we do include a lightweight JVM inside your container. Most of the containers for hybrid applications that you find in the market, what they can do is they run HTML5 and JavaScript. The most popular one is something called Apache Cordova, the commercial version of it is called PhoneGap. That's all they do. They can only run HTML5 and JavaScript, and they can communicate with the device feature. We took this concept, and we also allow you to run HTML5 and JavaScript, like those containers, but we also added the ability to run Java logic.

What we did is, we don't run JSF, we don't run Facelets, and we don't run Servlet. We're running a similar concept. You define your user interface using components in an XML file, just like you'd do today in JSF. You have a set of components that include things like layout components and input components, along with data visualization component of things like maps and charts and other components. With them, you construct the metadata that describes your page. At run time, our framework takes those components and renders them using HTML5 on the device. 

In some cases, we actually use the native component on the device to render the user interface. For example, when you have a date component, you're actually using the date functionality that is provided by, let's say, iOS, so this type of scrolling, this type of UI to select the date. The UI is defined declaratively at run time.  It uses HTML5 and JavaScript to render itself. Then the framework itself allows you to also define a controller layer. We have basically something that understands the controller and knows how to navigate between pages. 

There is no JSF life cycle involved here. The life cycle that is behind the page is a little different. It's a little bit more ... Because there's no traffic to the server for UI, everything is on the client. The life cycle is a little bit different, but again, the concept of development is the same. There's a JVM that we are able to run on both iOS and Android as part of our container.

Kito:

What kind of constraints are there in the logic that you can write in Java, because obviously you can't do everything, because you have a limited JVM. It's not actually talking to WebLogic directly. What are the limitations out there?

Shay:

First of all, if we are talking to the backend, we are basically supporting either REST or SOAP services. If you need some data from the server, if you need to send data or receive data, you're going to use SOAP or REST interfaces. Again, we have our data control concept to simplify the way that you interact with them. In terms of writing the logic on the device, if you need for example to write some logic behind a button that is pressed, if you need to write some logic that access a local database on the device, or if you need to write logic that access device feature, you're using Java. 

Right now we are using a profile for Java that is based on J2ME. It's basically JDK 1.4 at this point. We are looking in to the new features that were introduced in JDK8 and the profiles of JVM, that you can create there, to have a lightweight JDK8 based JVM available in future versions of our offering.

Kito:

I'm just grokking all this, because there's some aspects, which are very fascinating here. Were there any particular challenges you guys had with getting an embedded Java VM running? Because I know in the past it seems like it was difficult to get Java running on an iPhone, for example.

Shay:

What happened is basically, Apple didn't want a JVM, per se, on their iOS, that you will install something that will allow you to run another program. The way that we are working is that our JVM is basically compiled as a native library that is provided as part of your application. It's not a JVM that you install on iOS. You install your application, and one of the libraries there is basically a JVM. This is the reason that we were looking for a lightweight JVM solution, something that wouldn't make your application go to the size of 17 megs or something like that. 

Also, there's a lot of parts of the JVM that we don't actually need on a mobile device. We don't need Swing, or Java Effects, or things like that as part of this solution. We're mostly interested in Java just as a pure development language. In a lot of people's mind there's this notion that you can't run Java on iOS. That's the common knowledge among Java developers. It's simply not true. We're actually allowing you to run Java on iOS, just by including the native library that deals with JVM.

Kito:

How do you interact from the actual web page, the page where you have whatever components? How do you interact with the Java code running in the local JVM?

Shay:

What you're doing is, when you're defining an ADF Mobile application, you're defining managed beans, just like you do in JSF. You can associate…for example, if you had a button on your page, you associate an action or an action listener to this button. When you press this button, we go off and we call your Java code that you wrote in the managed bean. This Java code can go off, for example, and access a SOAP service or a REST service to get some data from the server. Or alternatively, if you want, for example, an offline application, you have a SQLite database that comes as part of ADF Mobile. It can include data that you're storing on the device, and when you press the button in your JSF page, we call your managed bean. Your managed bean can go over and, using JDBC, access the local database. That's as simple as it gets.

Kito:

I guess you don't have to worry about scopes, which must be really nice.

Shay:

We actually do have scopes, but it's much more limited in what we needed in the world of JSF. We do have an application scope and a process scope…

Kito:

Is ADF Mobile part of ADF Essentials, or is just part of the full-fledged ADF?

Shay:

ADF Mobile is not part of ADF Essentials. ADF Mobile is actually something that we're starting to license in a different way than web applications. The world of mobile and mobile frameworks is a little different than the world of web frameworks . The common way in the market today to charge for those type of applications is basically per app, because there is no server component per server that runs. You can't charge per the server. So ADF Mobile is licensed per application on device. You can have either the license that is for an unlimited number of users for the application that you built, or if you know that you're developing an application for a specific number of users, you can basically license as a per user license for ADF Mobile.

Kito:

Fascinating, okay. When did ADF Mobile come out? Hasn't it been a year or two, if I remember correctly?

Shay:

It's basically right after OpenWorld 2012. We're getting close to the 2 year mark. In the mean time we have several major and minor releases of this technology.

Kito:

What's sort of applications are you seeing people build? I'm assuming you guys are using it internally for your own product. Can you give us a sense of what ...any particular Oracle products that use it and any client products that you can think of that are particularly interesting?

Shay:

The first thing to understanding that ADF Mobile is really not aimed at, let's say, developing the next Angry Birds or Temple Run type of application. We're really not in that area or that business. What we're focusing is what you would call enterprise application. As mentioned, internally inside Oracle we've been using it, for example, to build a mobile phone app to things like our PeopleSoft and E-Business Suite and Fusion Applications. 

Just an example: one of the first applications that was out there is something from our PeopleSoft out of the house, which allows students to register for course, that type of activities. It's a mobile application that students can install on their device. It's customized for each university that purchased it. They can see a list of the courses, see the information about the university and everything from their mobile device. We have a lot of situations where the applications that you're building is basically a mobile phone app dedicated to a mobile site for a backend server that does some approval or shows you some data.

But we also see a lot of situations where our customers are actually leveraging the device capabilities. A couple of examples: we have a customer that is in the cement distribution business. Apparently, in that industry it's very important to figure out where your shipment is and how soon it's going to get to somewhere, because cement has the tendency to harden after a while and become unusable. They actually built a mobile application that leverages the GPS on the mobile devices that allows their customers to track exactly where the shipment is and get notification on their mobile device. 

Another example is…mobile devices also are able to work in an offline way. We have a customer in the energy sector that built an application for their inspectors to go around energy plants and do inspections on their iPads. They have a list of things that they need to inspect, and they can check those, working offline. They can also take pictures with their device. With the iPad they can actually take a picture of something that is not correct, for example, and log it. Then when they come back to the office, they can reconnect to the system and upload all this data to the main database. 

We see two things that people are doing. The first thing that people are usually doing is just mobile enabling or giving mobile access to the existing systems. Then the next step in evolution is actually thinking a little bit outside of the box, and figuring out what are the unique capabilities that a mobile device gives you, and how you can leverage them to build more intuitive or more advance interactions with those systems.

Kito:

Okay, nice. If you could pick one feature of ADF Mobile, what would be your favorite?

Shay:

For me it would actually be the development experience and the fact that, as I said, I've been in the Java development industry, I guess, since 1999, so quite a long time. I'm getting to this phase in my life, where it's becoming a little bit harder to learn new technologies. What ADF Mobile gives me is, basically, I was able to very easily pick up this technology, and continue developing in the same way that I was used to with the same language I already know, with the same concepts, let's say, of how you create user interfaces, and actually become a mobile developer. I think that the experience is very similar. 

Then because I'm doing a lot of product demonstration, and a lot of outreach to customers, what I really like about it is the visual experience of development. The fact that you can actually invest 10 minutes in doing the demo of developing an application, and show people something that works, that is much more than just a Hello World application. It's something that actually goes over, and picks up a REST service, and gets the data and shows it in multiple ways, and shows you charts, and shows you data, and then allows you to invoke some camera on the device. All of this inside a 10 minute timeframe of doing the demo. 

Also, all the development experience is very encouraging to me. I don't feel like an old developer. I'm feeling like "Hey, I'm now a mobile developer."

Kito:

That's one of the things I've always liked about a JDeveloper, that the visual development experience is very nice, which is just nothing else is really ...no one else would've done a very good job with that. I think that's definitely a plus. Just one last question for you. Is there anything interesting, exciting coming up for ADF Mobile or ADF Faces Rich Client that you could talk about?

Shay:

Again, we're limited about what we can say about the future. I can tell you some focus areas. For ADF Faces in general, we're constantly improving, and adding new components, and new capabilities, a lot of new visualization aspects. We found out that a lot of people like to see their data in pictures and innovative ways of graphing information. That's one of our focus area. The second one would be taking and making sure that something you build with ADF Faces is really efficiently running on a mobile touch device.

We already have this, but we're also working on aspects of adaptability and responsive design, and again, adding more features. That's kind of where the Faces side of the house is focused right now. On the mobile phone, one thing that we would really like to do is extend this implementation and technology to a lot more Java developers out there. Something we just demonstrated in the last Eclipse conference here is the support for this mobile framework inside Eclipse, so extending it to beyond just JDeveloper to also provide Eclipse based tooling. This is coming hopefully shortly. Then a lot of other features that revolve around extensibility of the framework, allowing you to plug more things into the framework, and make the framework richer.

Kito:

Thank you so much for your time, Shay. Is there anything else you'd like to add?

Shay:

The one thing I would like to add is, I know a lot of people had preconceptions about Oracle, in what we're doing and our tools. I think a lot of those preconceptions are based on long past experience. I would very much encourage people to give it a try. All our tools are available for free download, and we would like you to try it out. Especially for JSF developers -- as you're moving into the world of mobile, I think ADF Mobile has a very attractive offering for you. Just give it one day of evaluation, I think you would like what you'll see, and we'll be happy to have you as one of our users.

Kito:

Thanks again, Shay. I appreciate you joining us.

Shay:

Thanks.

Kito:

Thank you. I think that's it for today.