Caffeine – ABAP to Go – The Motivation

A few weeks ago at SAP TechEd in Las Vegas I presented the Caffeine prototype project to the public for the first time and the response was so positive that I decided to start a blog about it. I am hoping to create a space that I can use to discuss the concept and the implementation in more detail and to announce new progress, but also to create a space to bundle the public discussion and answer frequent questions asked about the project.

Caffeine is a prototype project “fresh from the labs” and is not related to any current or future SAP product. However, we are working on achieving that.

Let me start with a flashback to where it all began. I am a believer in multi-language stacks. I believe it is a great advantage to be able to execute different programming languages in a common runtime environment. This belief is grounded mainly in two assumptions:

First, there is no “one fits all” kind of programming language. Every language has its strengths and weaknesses and is invented to solve a certain shortcoming of existing languages or to better support a certain use case. I believe that one should use the right tool for the job. The fact that a language is “Turing Complete” does not imply that it is a good idea to use it for everything. Also, the power of a language does not only come from its syntax, semantics, the tooling support or other characteristics like performance. It is also made up by the community surrounding it, by the supply of libraries, documentation and example code that increases development efficiency.

Second, people are reluctant to learn new languages. Learning a new language is a significant effort. It is not only about getting comfortable with a new syntax and new concepts, it is also about getting to know the libraries and tools that one uses every day. This initial effort is often not worth the investment, especially if you think of short-term projects that need to be finished in months rather than years. Additionally there is an emotional aspect to this. Many programmers like their language and thus often dislike other languages because they do not come with a certain feature or concept one learned to love over time.

Long story short, there are a lot of languages out there and they are not going away any time soon. Instead of fighting one or the other and trying to convince people to switch sides we should rather try to bridge these gaps.

The Caffeine project is essentially trying to bridge some of these gaps for ABAP developers.

So what is Caffeine about? Technically it is an ABAP compiler and runtime implementation in Java which runs a subset of the ABAP language natively on the JVM. Using cross compilation techniques we are able to execute the same code on other platforms and runtimes like Microsoft .NET or Android’s Dalvik VM. Thanks to a collaboration with the Sponsored Academic Research, we were even able to execute it on Apple’s iOS and thus on any iPhone or iPad. I have published a highlevel overview article on SDN that explains the concept in a little more detail. From a technical standpoint the motivation behind Caffeine is not only to prove that it is possible to run ABAP outside the well-known Netweaver Application Server, but also to prove that this can be achieved in a very efficient way and that the approach can keep up with traditional ABAP even in its core competencies of high performance mass data processing.

However, the main motivation is more of a social nature.  We want to enable the ABAP developers to break out of the current “ABAP fortress” and contribute their knowledge and skill set to development on other platforms and runtimes directly. I believe that there is a tremendous value “locked” in the minds of ABAP developers and that a technology that enables them to directly code on new and emerging platforms is the key to unlock that value for our customers. The ABAP developer is usually the one who knows the business logic and business process implementations best. The ABAP developer is the one who knows the backend data structures; he/she knows where to find what data and how to aggregate which tables in order to answer a certain request. Of course some of these tasks belong into the backend, but there are also some that make more sense on the client side.

Caffeine wants to enable the ABAP developer to contribute libraries to client and mobile application development.

Let me explain this sentence because there has been some confusion in the past. I see the growing demand for the skills and knowledge of the existing ABAP developer on new platforms and am trying to lower the barrier of entrance for those people in order to increase development efficiency. I am not trying to convince existing Java or ObjectiveC developers to learn and use ABAP for certain tasks of their mobile application instead of the language they are used to and I am not trying to promote the use of ABAP as a language for mobile development in general. Another common misunderstanding is captured in the “contribute libraries” part of the sentence above. The idea is to only write libraries that contain business logic, validation code and maybe backend connectivity. ABAP, or the subset of ABAP Caffeine supports, is essentially a business DSL and should thus be used as such. These libraries are then easily consumable by the actual application developer who implements the UI, the control flow and all other necessary functionality natively in the host language. The Caffeine runtime is making sure that the ABAP-libraries are executed natively and efficiently and are easy to use from the host language.

The next blogpost is going to demonstrate a few example applications of the technology in detail and will show the ease of integration.