First of all I want to thank all the customers and partners who attended the technical stream at the annual Oracle Utilities Edge Conference in Phoenix Arizona. I hope those attended found the sessions helpful. It was a pleasure to meet and chat to many customers and partners during and after the sessions.
We made a series of announcements at the sessions about the future directions of our products and our works program for the future. Customers and Partners who did not attend the conference will get this information as we publically release the facilities we discussed over the next few service packs and releases.
One of the announcements has caused confusion amongst the attendees and I wanted to clarify a few points to make sure that everyone understands the announcement.
We announced that we will be adding support for Groovy as an extension language in a future release. I want to point out a few things about this:
- Groovy support for extensions was added primarily to support our Software As A Service (SaaS) offerings for our products. In SaaS we will lock down the facilities accessible for extensions to protect security and performance. As Java has access low level calls we will not allow Java based extensions in the SaaS cloud. As Groovy is used for a similar role in other Oracle Cloud offerings, we are extending the OUAF to support Groovy based extensions to allow extensions typically implemented in java to be implemented in the cloud. We will be supporting Scripting and Groovy based extensions in SaaS offerings.
- To protect security and performance we will be whitelisting support upon parts of Groovy to prevent inappropriate access. We use a similar technique for scripting and other extension support.
- Java and scripting based extension support will be continued to be supported in the OUAF. You will not be forced to migrate to Groovy for on-premise, Platform As A Service (PaaS) and Private Cloud implementations. We will continue to extend our Java, Groovy and scripting support over future releases. We are not dropping the existing technologies.
- You can use Groovy for on-premise, Platform As A Service (PaaS) and Private Cloud implementations if you desire to use that technology. Java programmers can migrate to Groovy skills pretty easily as Groovy is very similar to Java (at the end of the day Groovy code becomes Java byte code anyway).
In summary, Groovy is being supported as an alternative to scripting and Java, it is not replacing them. It is primarily used to address the lack of access to Java for use in building extensions in Oracle Utilities SaaS offerings. It can be used by any style of implementation if you desire but if you are not using our SaaS offerings you can continue to use all the styles of extension we have available.
Now that I clarified that, I want to clarify one other misconception and that is the performance profile of the different styles:
- When loaded into memory, which what happens to all extensions regardless of technology, raw performance of Java, scripting and Groovy are similar. Java does have a slight edge as it compiled byte code and Groovy/Scripting are interpreted with a small initial overhead. There is not much difference in the performance once it ends up in memory. You have the flexibility of picking any of those technologies with confidence that the code will perform with efficient programming.
- Each language has its facilities and there are some clauses that are unique to each. For example, Java has full flexibility especially with computational type and also has a wide API. Groovy has a very similar API to Java but in our implementation of Groovy, we will be whitelisting clauses to protect security and performance. Scripting has a generous set of programming clauses but it is smaller in scope. In the vast majority of most extensions, scripting is more than enough but you can choose to use Java or Groovy (in the future). The choice if language gets down to skills and what your scope is.
- In most case it is recommended to use scripting first, if that is not appropriate then you can soon use Groovy and even if that is not appropriate then use Java. Java has overheads in deployment where scripting and Groovy will be stored in our metadata.
I hope these clarifications will assist you in extending our products now and in the future. We are looking forward to providing a rich development experience no matter which style or technique you choose to use.