Skip to Content

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.

You must be Logged on to comment or reply to a post.
  • Will this subset of ABAP be based upon ABAP Objects, or using procedural ABAP – forms and function modules. Or is that already exceeeding the bounds of the subset?

    Fascinating project. I shall be reading your subsequent blogs with interest.

    • The current subset is based on procedural ABAP (a special kind of function modules). I will go into more detail in the next blog post, but the Caffeine type system is based on ABAP structures and internal tables. This means that apart from control structures you will have all the neat little things like “loop at into where” or “move-corresponding”. We started with a quite small subset and are extending it carefully since I believe we should keep ABAP a real business DSL this time and not try to make it a full blown “general purpose language” (sorry Blag, no intention to integrate OpenGL 🙂 ).  After all, this time we are running on a real multi language stack and can break out into another language if we really need an exception here or there. However, I am sure that once people start using it in the real world there will be many reasonable feature requests that will be finding their way into the subset and make it more usable and valuable.
      • While I find Caffeine extremely cool and encouraging, I am really disappointed that it sounds like it only supports procedural, function module based designs.

        If the goal is to allow developers to implement libraries in ABAP, then we really should have support for an OO approach, and in my opinion you would be doing the ABAP developer community a favor by de-emphasizing function modules altogether in favor of the ABAP Objects approach. In my opinion, the last thing ABAP needs is another reason for developers to think they don’t need to transition to ABAP Objects.

        On the bright side, at least it sounds like it doesn’t support forms and reports. It doesn’t, does it? 😉

        All that said, Caffeine sounds absolutely great. Hopefully some of the awesomeness backing internal tables in Caffeine makes its way back into the base Netweaver ABAP implementation.

        • Ethan,
          I didn’t say we never will. As mentioned before the current subset is just the beginning and is intentionally (too?) small because it is easier to add stuff than to remove it once people started using it. If there are good use cases and a broad demand for ABAP OO then we might add it in the future. Also keep in mind that this is a prototype project which aims at proving the value and feasibility of such an approach, not to come up with a finished product.
          As for reports, they are on our “to-do list” right after the OpenGL integration 😉
          • The “use case” for using ABAP Objects is all the advantages that OO design brings. An OO implementation should be the goal from the start. Not something determined by demand. It depends whether you’re targetting ABAPers who have an interest in programming, or those that don’t…

            Follow the procedural paradigm and you’ll end up with the the plethora of poor written programs that you’ll find in most SAP implementations.  Which would be sad, and ultimately could ruin the whole Caffeine concept.

          • Don’t get me wrong, I am a big fan of OO design in general. However, I am also a fan of “use the right tool for the job” and OO usually makes for great architectures in medium to complex applications. However, assuming that your main use case is to validate input data or to retrieve data from different backends and adapt it to your needs, then I am not sure whether OO really adds value or just complexity. Creating an object with 2 static methods is not OO. And in my experience, this is exactly what you get if you force the kind of developer you describe to do OO.
            I believe the functional approach definitely makes sense for the “simple library” use case, but maybe adding OO once we identify more complex use cases will be a logical step.
          • Hi Daniel,

            This is exactly my concern. I don’t understand the use-case for Caffeine for simple programs that will fit in a single method or function module. In a scenario this simple, why wouldn’t you just use the native language (the language the rest of your program is written in) to do this? When I think of libraries, on the other hand, I think of encapsulating complex functionality in an easy to use library. In ABAP, hopefully people are doing this in an OO manner using ABAP Objects.

            Maybe I’m missing the point. I think a few real-world examples of the type of use-cases you are thinking of would help a lot.


          • I don’t think ABAP OO is the remedy for poorly written programs. Not to mention the fact that I personally think it’s rather silly from SAP to push OO and declare anything non-OO as obsolete.

            Far too often I’ve struggled to fix programs that were poorly structured and had unwanted side effects – and it’s as easy to create them in ABAP OO as in procedural programming (it’s not really a feature of the language, it’s a feature of the programmer producing the code). Not to mention the fact – as Daniel pointed out already – that OO modeling is not necessarily the best solution (depending on your problem space).

            It’s interesting that Ethan mentioned “you would be doing the ABAP developer community a favor by de-emphasizing function modules altogether in favor of the ABAP Objects approach”. I actually think it’s the other way round: SAP would’ve done us all a *really* big favor by introducing better functional programming approaches in ABAP and leaving the developer the choice to pick the right approach for a given problem. After all, there’s a reason currently functional programming seems to be coming back. And the first rule of development should still be KISS in my opinion…

            Cheers, harald

          • Yes, the reason functional programming is coming back is because there was a massive parentheses surplus 🙂

            But seriously, I am as supportive of this as anyone. In fact, I work on the ESME project in Scala in my spare time and I love that Scala combines very full featured functional and OO programming models.

            It would be great if ABAP did this too, but the reality is that it doesn’t. ABAP has no concept of a first-class function and has taken a very OO direction over the past several years. The OO structures in ABAP simply provide more modern tools for structuring and managing a code-base than the older function-module based concept. Since Caffeine is an implementation of a subset of ABAP, I think it is going to need to work within this reality.

            So yes, KISS, but as soon as you have a function module or method that is getting a little bit long, it’s time to start thinking about how you can structure it better, probably using ABAP Objects.


          • >> “ABAP has no concept of a first-class function”

            Ethan, you are thinking like somebody who knows their programming language concepts. Not that kind of ABAP developer the ranting thread is all about 🙂
            Playing devil’s advocate (with “devil” being a pragmatic ABAP developer with no programming language background and interested more about not getting error messages during extended program check than beautiful code), I’d say the following:
            Passing the name of a function module into another’s function module importing parameter and doing a call function IV_FUNCNAME comes close enough to first-class functions…


            PS: To the ABAP developers who reads this an feels insulted – I didn’t talk about YOU, I meant that other ABAP developer 😉

          • Interesting you use the word “Pragmatic”. There’s a book about programming style called “The Pragmatic Programmer”.

            While pragmatism might lead a developer to thinking that getting no errors in the extended program check is more important that beautiful code – that’s wrong.

            Beautiful code (Encapsulated, modularised) is a) easier to understand. b) easier to fix if it goes wrong c) easier to enhance and so … CHEAPER!

            E.g. the reason why you shouldn’t use global variables, is because a deep down form could change the value after an enhancement by someone who doesn’t know the program, and it is very difficult and therefore EXPENSIVE, to work out what’s gone wrong. If you only use form interfaces to pass global variables, at least you know it’s restricted to those forms.

            I think it is far easier to write bad code in procedural ABAP. It encourages that mindset. At least with OO you have to think about types. And the structure of your program. Of course, if a programmer hasn’t the first clue about OO paradigm, and, more importantly, doesn’t want to (or can’t), then you’ll end up with bad ABAP Objects code. Which is probably worse than bad procedural code.

            To me “…lowering the barrier for traditional ABAP developers to enter the more consumption driven (e.g. mobile) space” is not good. Personally I’d like to lock out bad programmers as much as possible. Ultimately, bad programmers are far more expensive than good ones, and shouldn’t be encouraged to work in +any+ space!

            This is not to insult good traditional developers. But if you’re good, you’ll be able to, and want to, make the transition to objects. Won’t you?

          • As much as I agree on beautiful code and wish we could deal with less poor programs, I don’t see ABAP OO as the salvation. ABAP OO does not at all enforce any better programming style (obviously the few stricter syntactic requirements don’t really count). Often it actually adds to the confusion, because there’s no proper modeling, liberal use of confusing class/instance attributes as a replacement for global variables, more overhead, etc. (so yes, I’d agree and say this is “worse than bad procedural code”).

            And though I avoid global variables, they can actually be a blessing in poorly structured programs written by others, because it is very simple to do a quick cross-reference and they are very easy to track during debugging.

            I favor checks (e.g. code inspector) that report nesting level, number of statements per coding unit (method/form/function) as this can be used for automated enforcement of some standards. Of course that’s also far from a guarantee that the coding is well done, but it’s at least a start.

            KISS and proper tooling support (e.g. source code-based class editor, which only comes in NW 7.0 EHP2) are to me an important factor when choosing solutions. Less boilerplate, more meaningful coding (having an RFC module with an ABAP OO class for the actual code does not necessarily make sense).

            How many of us make a conscious decision not to use ABAP OO in certain cases? Do you implement all your requirements in ABAP OO (I certainly do not)?

            I think Caffeine is a cool project, though I don’t necessarily see that it’s desirable to have ABAP-only developers write business-logic fragments for applications on mobile devices: There are (still) usually less resources available and thus implementation details tend to matter more. It can be a big benefit though if more people (e.g. functional folks) can read coding which implements business rules. Not to mention the fact that it’s nice to give more choices to the developers (which language they can choose).

            My apologies for this overlong ranting, but the amounts of poorly written programs I have seen and SAP’s drive to declare all non-OO ABAP as obsolete unfortunately have lowered my threshold for proper self-control. 😉

          • Do you implement all your requirements in ABAP OO (I certainly do not)? Yes, I do.

            I’ve been writing most of my developments using global classes for the past five years, and as a result, for many general programming tasks, I’ve got a class that does it already. Also, when enhancements are needed, I can do it a bit more quickly than I could with procedural. For me, at least, one of the benefits of the OO framework, is that it helps organise the structure of the development – that is, if you want it to!

          • Hi Matthew

            As a programmer fluent in ABAP, Java, Ruby, Python and others I agree. However, Daniel made the point that Caffeine if about lowering the barrier for traditional ABAP developers to enter the more consumption driven (e.g. mobile) space. I am not sure this “tradition ABAP developer” will care too much about OO. It has been outlined in other comments that not all ABAP programmers are great computer scientists and while I won’t join the ranting here – but I won’t argue with that point either… Just making the observation that a lot of existing ABAP OO code is just Classes with a few static methods. The ABAP OO representation of a Function Group is you will… Also adding the observation that when trying to explain thinks like encapsulation, inheritance, late binding to ABAP developers at SAP, I did run into some “ok, fine, but what can it do what I can’t achieve with a global variable and a few form routines?” questions. Maybe times have changed – I hope times have changes, because these conversations can get pretty frustrating…
            So I think it’s quite smart to start with the feature set that has the highest adoption within the target group and add more features upon request.

            my $0.02

  • Hi Daniel,
    this is certainly impressive, but when I heard this first I couldn’t quite believe it:
    1) Despite all those nice and new features in ABAP it remains a rather verbose language and I can’t really think of any killer feature that other general purpose programming languages don’t have.
    One big benefit of ABAP is probably the integration with OpenSQL; however, outside NW AS I suspect that’s not really present and has to be substituted by RFCs or similar techniques?!
    2) Traditionally many ABAP developers don’t really seem interested in programming and thus also exhibit rather poor programming practices – and not knowing any other programming language is in my opinion often a good indicator for that.
    3) You mention one of ABAP’s core competencies as high performance mass data processing, which I wouldn’t place high on the list for the (partially targeted?) mobile application development.
    4) Tooling support for ABAP is not bad, but compared to modern IDE’s we’re still behind. E.g. I’d love to see strong refactoring support considering the huge amount of poorly written code one has to support.
    5) The lack of documentation makes our job an interesting challenge, but I’d hope to see something like javadoc for ABAP (as part of the official SAP supported language stack and tooling) at some point.
    From a technical perspective ABAP on the JVM is definitely mind-blowing and interesting – but I have my doubts how people would use it in real world applications and what the benefits are. But maybe in the end it’s about the choice you mentioned and utilizing existing skill sets.
    So I’ll curiously await your future blog postings including examples and kind of expect that my comments will most likely be proven to be a result of having to support one too many poorly written custom SAP ABAP applications (so my apologies for this long rant)… 😉
    Cheers, harald
    • Hi Harald,

      thanks for your input, these are good questions. Let me try to answer:

      1) Agreed. That’s why I am not trying to push anybody to learn ABAP for his/her next mobile app. It’s about the ABAP developers that do not “speak” other languages. I want them to be able to ASSIST the actual app developer by quickly contributing libraries in the language they know.

      3) Correct, but you might still end up shuffling, sorting and arranging some data the way you need it on the client side and knowing that the underlying runtime is fast and efficient provides some peace of mind when coding. 😉 Also, since Caffeine runs natively on the JVM one might also dream of some future use case closer to the data, but this is not what I’m currently targeting.

      4) Tooling support is a good point. The fact that we are compiling to Java byte codes directly enables us to reuse a big amount of the tool support from the Java world. We are just about to implement an Eclipse based debugger for instance (based on the Java debugger – I will blog about it once we’re finished). Refactoring would have to be implemented from scratch though and is not really in the scope of this project (although I agree that ABAP refactoring would be an extremely helpful feature).

      I would be very excited to see how people actually use it in the real world. As I said, I am targeting the reuse of skills locked in the “ABAP mind” of people but I am sure that there are many other potential use cases. After all, Caffeine is a toolset that could be applied to many problems.


      • Thanks for the detailed answer. I’m looking forward to your next postings and updates on this interesting project. I’ll definitely have to give it a try when I find some spare time…
  • This gives an excuse to rewrite the “poorly written” abap code – customer code, I mean.  As far as what a real strength of ABAP, ITABS!!!

    Good stuff!

  • Daniel:

    This is one of the most interesting things I have ever crossed since the good days of SAPRfc, Rfc::Ruby and BlueRuby. Caffeine suits me just right -:)
    I’ve been an ABAP developer since the last 10 years, but been involved since programming since the last almost 13 years. I love ABAP, but I love as well PHP, Ruby, Flex, C++ and every nice programming language that you could put in front of me.
    This projects opens IMHO a world of possibilities. I believe there’s nothing we can’t do with ABAP (Still waiting for some OpenGL projects LOL)…we just need the right tools to do it. I have played with SAP and Mobiles using PHP, WML and BSP…but using ABAP on an IPhone or Android really goes to my wildest dreams.
    Thanks a lot for this and I’m eagerly waiting for the upcoming blogs and why not? A test environment to start coding -;)


  • Hi Daniel,

    You had a great idea and a very nice post. By the way, where can we download and giv e a try of Caffeine?

    Is there anyway it could be available for testing?



    • It’s not missing, it’s already there 🙂
      Check out the successor blog post (Caffeine in Action) which contains a link at the bottom to SAP CodeExchange where I provide a binary distribution of Caffeine for testing purposes.