Java Programming @ SAP - the poor cousin?

Question

Hi!
Recently I' ve started a kind of poll in the Java forums asking if someone knew any enhancement possibilities for java-side development at SAP mentioning the ABAP customer exits, BADIs, customer includes and enhancement spots as example.
Guess how many answer I received - from WDJ, Java Programming, NWDI and NW Java from: None! All the gurus who usually bubble over with wisdom remained wondrous silent. I also run over help pages searching for some hints regarding this - in my opinion fundamental - questions, with the same result.
Has really nobody at SAP spent a thought about one of the most precious features SAP offers its customers - the possibility to enhance delivered standard-programs and thereby adapt them to their needs without modification?
How are we as Java programmers then supposed to stand the mistrustful glances of our ABAP collegues who wonder why there has been so much noise about this Java thing in the recent years. Thinking about the disadvantages a developer working with Java at SAP has to bear compared to his ABAP collegue - no direct data access, no comfortable debugging possibilities, lots of standalone tools with strange UIs (SDM Remote GUI, Visual Admin - only to name the least glorious ones - he to manage and - last, not least - no chance to enhance SAP Standard programs modification free I have to agree upon one ABAPers opinion on Java: "The hype is over!".
Regards from a very pessimistic Java Developer
Thomas
PS: Does anybody know a way to unbureaucraticly swap a Java certification against an ABAP one?

Answer 1

I get the question - should I do my development in ABAP or Java - quite often. My answer has become "It Depends."  I getting pretty good at those ambiguous consulting answers, aren't I.
In all seriousness I really do think the answer depends upon several things.  As a company or development group you should analyze the skills that you already have in house.  As you have seen the two development environments are quite close.  The advantages of one over the other will continue to vary over time.  ABAP will add nice features from Java and vise versa.  In the end it is more important that companies leverage their skill sets and existing infrastructure (Software Lifecycle Landscape) to their maximum. 
If you are already a java shop then it makes sense to continue down that development path because your developers will still be very efficient even if they have to access ERP and other SAP application logic and data via RFC or Web Services. 
On the other hand, ABAP certainly isn't as dead as some people claimed it would be by now. Thanks to Web Services ABAP has more flexibility than ever before.  It isn't nearly the closed box that it used to be.  Also the workbench team isn't going to stop innovating either. 
The next question I get is what does SAP do internally when deciding on a language to use.  To a large extent they use the same criteria - what existing skill sets do I have to work with.  They also look at where the data is located. 
That means products like Portal aren't about to change from Java to ABAP.  On the other hand ERP suite development is still heavily ABAP.  The new UIs coming from ERP will primarily be done in Web Dynpro ABAP. 
Even in some newer products that haven't been released yet - the UI was done in Java or Visual Composer and the backend business logic was done in ABAP. It is all about taking advantage of the unique strengths of each environment and the skill sets you have in each.
In the end I don't think Java is the poor cousin any more than ABAP is going to die.  Look at NetWeaver CE and the huge investment SAP has made on top of Java Development there.  At the same time our investment in Java has not come at the cost of the ABAP environment.  Innovations will continue to take place there as well.  I can assure you that within SAP it is the hope and goal to have two top notch development environments within NetWeaver.
Now let me share a little story with you.  My background is obviously ABAP and I doubt I will ever lose my particular passion for the environment.  At the same time I have done a fair bit of NetWeaver Java development in the last year and half or so.  I'm not a super deep expert, but I can hold my own. 
I recently had a requirement to build an MDM Application.  I only had two days in which to build it.  My choices were to use the Java API or the ABAP API.  They are quite similar and both meet all my interface requirements.  I was building a Web Dynpro UI, so the end user wouldn't be able to tell the difference.  Interfacing capabilities being the same and UI output being identical - my decision came down to the environment where I personally could be most efficient.  I could have completed the project in either environment.  But because I knew the ABAP Programming Environment (you know the stuff that goes beyond the basic syntax - the real knowledge that lets you squeeze every last drop of performance out of an application) so well I personally could build the best application in the shorter time in ABAP. 
Now someone with a different background might well have taken the Java path and done just as well.  This is the advantage that SAP provides by continuing to support both ABAP and Java development.  Does every feature and function of both environements line up exactly - of course not.  I'm sure they never will.  But do these differences keep experts in either environment from being able to make any application do amazing things - certainly not.  Personally I feel less constrained in either ABAP or Java today than I have ever felt programming before.