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.
Fascinating project. I shall be reading your subsequent blogs with interest.
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.
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 😉
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.
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.
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.
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...
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.
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 😉
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?
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. 😉
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!
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.
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)... 😉
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.
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 -;)
Glad you like it! And I have some good news for you: Caffeine is now publicly available for download (through CodeExchange). Simply sign up on https://code.sdn.sap.com/ and join the Caffeine project.
Happy hacking! 🙂
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?
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.