IDE, the ABAP way
Lately I have been musing (contemplating, meditating on) the term “IDE” or “Integrated Development Environment”. What is it that makes it integrated? Well, you have of course an editor, a compiler and a debugger (or any other combination of tools) integrated into one program. However, the program itself is still pretty much standalone. It is usually not integrated into anything else. So much for “integrated”. Tsk, tsk.
Enter the ABAP platform. I’ve been rambling on about it before, but one of the features that makes ABAP such a great environment to develop in, is that the development environment and the runtime environment are all one. Now that is what I call integrated, my friend. True integration, if you ever were looking for it. You need look no further.
Imagine if something similar could be done for, let’s say, a J2EE server. How do you currently develop J2EE apps? You create an offline environment, including (snicker) an Integrated Development Environment and tons and tons of libraries to make sure you’re not missing any dependiencies. Then you write something, compile it, package it, and deploy it to the server.
Instead, what if you could develop directly on the system? Imagine opening a browser and being presented with a window where you edit code. Maybe a browser is not suitable, so imagine it was a rich client app (to be able provide certain features more easily) where you edit the code. However, you’re not really developing locally; when you save your work, it’s on the server. The syntax check and compilation all happen on the server (and so does the version management). Moreover, all the libraries are there, so there are no dependency issues. When you compile, the program is already part of the server environment.
That sounds like a fantastic way to work. It certainly is. Of course, if you come from the good old mainframe days, the idea of development taking place directly on the server is nothing new to you. It’s only in the recent age of web development, where the use of “stiff” compiled languages for use in web applications have resulted in complex ways to be devised to package and deploy software to a server environment.
Using scripting languages for web development of course makes things a lot simpler. You can make a change to a text file, and provided the environment can be reloaded, the change is instantly visible. Nonetheless, you still don’t have that “integrated environment” that, to my mind, represents the “holy grail” of server development.
In ABAP, the base system is a complete ecosystem comprising not only of development tools, but a host of applications that support maintenance of the environment, including change management across the landscape, as well as the core functionality required to create really robust business applications.
Now imagine if the same could be built on top of a J2EE system. It would be a huge undertaking, considering that literally decades of development have brought the ABAP platform to where it is now. However, getting the basics of an integrated development environment (and I use the term in the sense of it being integrated into the system) to work might not be so difficult. Once you have that up and running, developing apps for such a system would become easy enough to create a really useful ecosystem or platform for further development.
(If you haven’t done so already, you might want to read my articles entitled Why I like ABAP and What makes a platform?)