Java Programming @ SAP - the poor cousin?

[Former Member]

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?

[Former Member]

Thomas Wurcher - I just wanted to add that after getting very deep into WDA this past year, I consider it part of the "core" already - something that can be built on if SAP decides to augment the core into some facsimile of an Enterprise SOA engine.

[Former Member]

Stephen -

I think this is an excellent point and that you made it very elegantly.

Anton -

I think your analogy really helped drive Stephen's point home.

***

I would only add that unfortunately, since the rise of the "new industrial state" documented by Galbraith in his book of the same name, what people want is often determined by advertisers and others whose job it is to create markets.

This is my main objection to what I call "bling" software (what people are made to think they want) vs "real" software (what people really need.)

I hope that SAP finds a way to maintain the balance between development of the two kinds of software, so that no talent within the greater SAP community goes unused.

And as I have said before, I think its time for Alan R and Jocelyn D to take center stage and show everyone how workflow can lead more SAP customers from >=4.6c to NW200xy in a comfortable, logical, and cost-effective way.

Regards

djh

[Former Member]

David,

Talking reality and "bling": For me there seems to be a wondrous gap between the presentation sheets of SAP, which fantasize of ESA, Enterprise SOA, xApps, Composita Applications, modelling, orchestrating and anything else SAPs marketing masterminds had come across with, and customers daily problems and their solution.

I' m sure that are lots of customers, consultants and even trainers who - after the diffusion progress of so called innovations in SAPs product range - have completely lost track of all these "technological advances", all these euphonious names - NetWeaver 2004/2004s, Web AS Java 6.4, NetWeaver AS Java 7, XI 3, PI 7, BW 3.5, BI 7, ECC 5.0, ECC 6.0, ERP2004/2005, Visual Composer, Enterprise Portal 6/NetWeaver Portal 7, Collaboration, Knowledge Management, Usage Scenarios a.s.o.

And there' s still no reasonable code completion in sight for the ABAP editor. There are still countless function modules, which could help in daily work, but are still not released. There are still tons of business logic buried alive in reports without any possibility of reuse!

Regards,

Thomas

PS: What the hell came over SAP to think they have to step into the market of Application Server Providers in a completely new business area - and in a mature market with heavyweights like IBM and BEA, who already know SUNs game of short dated product life cycles and shady product improvements?

[Former Member]

Thomas, if this were church here in the US South, I'd be shouting "Amen, brother" so loud that they might could even here me in Walldorf.

Although I think we have the same vision, we might differ a little on the details.I As I have blogged about several times over the past year, if SAP doesn't get its data dictionary<->code dictionary up to par, there is no way that the core will be able to support Enterprise SOA, because by definition, Enterprise SOA designers need to know little pieces of the SAP puzzle from all over the place - i.e. they are not experts with deep knowledge of one or even a few application components.

Anyway - my hat is off to you!

djh

[thomas_jung]

>And there' s still no reasonable code completion in sight for the ABAP editor.

I don't know if you would say its not "in sight". The development of full code completion is actual done. By full I mean global objects, not just local or referenced objects. It also works for structures/fields, exceptions, forms, function modules, method, object creation, etc. I find that it has really changed the way that I code. I do much less forward navigation and need fewer sessions open at once. It is particularly useful when working in Web Dynpro ABAP for the coding to access a Context.

The development was finished late last Summer (we showed the first sneak peak at SDN Days during TechEd), but currently it is tied to the next major release of NetWeaver. In a perfect world, the ABAP development environment would be separated enough from the NetWeaver platform that we could introduce new editor features without needing to go through a whole plaftorm and/or Application upgrade or a major backporting project. But we don't live in a perfect world (yet).

If you are interested in seeing the code completion, drop me an email. I would be happy to send you a video.

[Former Member]

OK, now I' m really frustrated finding that even the last advantage development of Java and WDJ still has - that is benefitting from Eclipse fabulous code completion and the Java feature of nested calls - is about to fading away in foreseeable future.

In fact, the whole Eclipse thing will be swept away by the degree of integration of these ABAP Editor features within SAPs core - class library, ddic a.s.o. - I couldn' t believe my eyes.

You' re right with stating that this will probably change the way we developers work completely - and finally permit even us to focus on core development tasks instead of navigating around between dictionary, editor a.s.o.

Thomas, I know that it' s not easy for you as SAP employee to comment on this issue, but on the other side you' re as well a developer like many of us who - I remember your blog - also crossed the divide (at least temporary) and tried out the other language.

Could you perhaps share your thoughts on the different levels of support a developer - and therefore a customer, too - is about to acquire when he decides to focus on ABAP or Java and how you think this will have impact on the evolution of development techniques within SAP environment? Is - as it seems to me - Java just a language SAP implements some of its products in, but cannot be taken serious for customer development any more.

Regards,

Thomas

Once again thanks for the sneak preview of the brave new ABAP world.

Regards,

Thomas

[thomas_jung]

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.

[thomas_jung]

PS.. I'm glad you liked the Code Completion. My only wish is that every ABAP developer could have it in their environement right now. Of course I'm biased as this was the first big development project that I got to be a part of at SAP. You worry sometimes that you are perhaps too close to the project and can't view it objectively; so it is nice to have feedback from someone viewing it for the first time.

[Former Member]

Abap versus Java.... That's a very interesting topic you're bringing here Thomas.

I did exterme searching on that topic using Google, SDN search, service marketplace using lots of different keywords "abap vs java" or "java versus abap"...

First of all the funny thing is that if you search "abap versus java" and "java versus abap" in Google you'll find diffrent results with interesting content from each search.

Anyway, I had to a list of requirements (technical, functional, performance, skillset, time to market, budget...) to build a solution and I had to propose a solution architecture. After heated debates, phone calls to experts in both, I wound up with an entire Abap based solution.

I think the bottom line is for an software solution that is for business application (analytical or process oriented), Abap beats the crap out of Java...in an SAP environment (customer/partner).

But if you're into building a software solution for device management or gaming or whatever else that doesn't relate to business applications, I'm pretty sure Java beats the crap out of Abap.

Unfortunately for me I won't do well in telecom or mobile industry. My abap skills there are totally irrelevant. Your Java skills should do well there.

[stephenjohannes]

Another analogy on this would be the following:

ABAP:

- You are looking at solving a specific set of problems(aka business applications)

- You don't care about low-level internals, you assume it is taken care of for you.

- You worry about how to model/solve the process not the "technical foundation"

- The "modern cobol"

Java

- You want to solve any problem, on any platform

- You care about more about low-level details

- You worry about the technical foundation and then worry about the model/process

- The modern "C++"

Once again it all goes back to what are you trying to accomplish. You use the right tool for the task at hand.

Take care,

Stephen

[Former Member]

just because i needed it today:

requirement: create an SHA-1 hash of some string.

Java: 1 minute.done.

ABAP: not possible

until recently(and only added due to the 'threat' of Java):

requirement: do a little complex string manipulation

Java: 5 minute one liner using regexes

ABAP: a major pain in the ass

and another one: create a little .png graphics visualizing some data

ABAP: install a graphics server and still feel limited with the options

Java: a trillion freely available libraries. nothing to worry about

ABAP has its merits, don't get me wrong but it's unbelievably limited regarding functionality compared to any other contemporary language.

For me the biggest plus of Java is this: 'This functionality is not possible' does simply not exist in Java but it does exist in ABAP. And it's coming up more often every day.

anton

[thomas_jung]

>'This functionality is not possible' does simply not exist in Java but it does exist in ABAP:

Of course part of the beauty of Web Services is that the answer doesn't have to be "This functionality is not possible". You can write your more specialized code, like encryption, in Java and expose it to ABAP via a Web Service with minimal trouble. <i>The Right Tool for the Right Job.</i>

Then again, are you sure you can't do those things in ABAP.

Have a look at the function module CALCULATE_HASH_FOR_CHAR in Function Group SECH.

Also ABAP supports Regular Expressions. Was this functionality really added due to the 'threat' of Java? I can't say, but does the reason for the added support really mater in the context of your argument that ABAP is 'unbelievably limited' (your words, not mine).

[Former Member]

Hi, Thomas!

A great honor that Mr. ABAP himself joins our discussion. And - as usually - you' re getting right to the point.

Within the last 30 years, there has been a reuse component creating within ABAP for nearly every requirement in every application part - technical ones as well as process oriented. One just has to consider the possibilities you get through usage of standard functionalities like these - and that' s what makes up a good developer within SAP environment: knowing the standards and how to use them. Ask a ABAP developer how to achieve a specific aim - he will most certainly answer: "There's a function module ...". Ask an Java developer the same thing, he' ll answer: "What' s a function module ...".

It' s not only that the language itself seems inferior to me for solving the common business requirements within a SAP oriented development environment - restricted access to sources, debugging possibilities, high complexity through distributed components, extraordinary costs to implement simple functionality (try to implement a simple report within Java - and then use a logical database in ABAP) a.s.o.

It' s not only the customers the whole business logic and data already implemented through decades, which are accessible for direct usage in ABAP, but have to be extracted cumbersomely through JCo and others via Java.

It' s not only the half-hearted implementation of standard ABAP features like the DDIC, Open SQL (who did ever work with SQL/J?), modification tools, Web Dynpro a.s.o.

It' s not only the customers, who invested a fortune in building ABAP competence and don' t even think about spending another one to gain Java knowledge and therefore reject everything associated with Java - why is SAP already reimplementing WDJ applications in ESS in ABAP?

It' s also the Java developers, who - as usual - are head over heels in love with design patterns, gadgetries, formal language beauty, but have - after years - still no idea what "MARA" could be.

Therefore, for customer development is already brain dead and - to me - seems only a possible organ donor to ABAP - think of WDJ, which' courses SAP had to cancel because of lacking interest, and WD4A, where SAP has to insert additional training units because of customers high demand to learn the new face of SAP.

Regards,

Thomas

[Former Member]

maybe you're kind of right with your assesment in retrospect (though I wonder how someone who pretended to be a Java developer in the beginning of this thread can get so emotional and express such enmity towards 'his' language - but that's your business not mine).

so probably WDA seems to become a reasonable option for the ABAP community and probably thats a good thing.

but I want to share one observation of mine: until Java came up in the SAP world, ABAP was in a paralytic state. Though ABAP Objects had been introduced it hasn't been adopted by the ABAP developers. MVC? Bahh they said. Patterns? BS. Standardized Communication? Why? SAP is the center of the universe and we have RFC. Period. And on, and on, and on....

I strongly believe that without JAVA and WDJ, ABAP and the WAS ABAP were still in agony. The maintainers didn't never have felt a need for WDA. Like they would never have seen a need for XML processing, for SOAP, etc...

So, if Java isn't much good for as you seem to suggest (and which I would dispute in a serious assessment) it has it's very merits in waking up the ABAP and WAS ABAP maintainers to advance their product and enrich it with fatures of a modern development and application platform and not remain in their 1990ies agony.

my 2 cents,

anton

[Former Member]

I have once been what you call "Java Developer", but - probably because of this - am now flaming more fierce against the kind of language implementation and usage SAP offers now for its clients - like a former smoker is now the most commited non-smoker.

Did you ever come across questions like - "How do I debug in productive system?", "Source on developers laptops? What if he' s caught by a truck before checking in?" "Just modificiations possible?" "No select * from mara possible?" - in meetings where an evaluation of implementation possibilities should be made?

Well I am, and I can tell you that this is becoming tedous after some time - always to hear the same questions without having appropriate answers!

Nevertheless, what you say is right and argues for my organ donor-thesis, but - beside all flaming - I would like to hold a serious discussion on this topic as it seems too important to me.

E. g., we now have a Java EE 5.0 application server - or a sneak preview of it, to be more precise, which won' t be available as plattform for most SAP products (portal, xi aso) before 2010. So what' s the use of this then? Having posted dozens of tutorials on how to do JSF, EJB 3.0 development, use JPA a.s.o. - what for? Until SAP takes its now innovation in productive use and it is largly adopted by its customers, we' re in the middle of the next decade.

I don' t think this is a reasonable time schedule for either a decision-maker or a developer to commit to a new plattform and think about migration strategies or so. And talking about new plattforms: What' s the use of the JSF implementation? Having another UI technology on hand? Who needs it? SAP should better focus all development capacities in bringing WDJ back on the track - ALV, Select Options a.s.o. Multiple ways of perform access to persistent storages, but still no direct access to ABAP DB Schema and no tidy DDIC available.

That' s what should be a matter of discussion and cause some statements of SAP officials.

Regards,

Thomas

[Former Member]

great thread, a real eye opener for me. One thing related to WDJ and the use of Java in SAP, particularly in the portal area these past few years. SAP offered the PDK with it´s many good examples for sure but developing applications was a real pain a few years back. Wanting to move all our developments to WDJ, we didn´t really get access to proper training or other resources to be able to migrate our old java iviews to WDJ. Now with the training in place (finally) we hear about and see WDA and given the option of training our many ABAP resources in that instead of converting them to ABAP/Java people, well perhaps the window of opportunity has been closed and WDA is the preferred way for us and many others that have written tens of thousands of lines of java custom code for the portal. (or possibly moving some of them to VC and Flex)

my 2 cents, Bjorn

[Former Member]

I know this is redundant and repetitive because I've made this comment at least three times before at SDN ....

... hashed internal tabless of virtually unlimited size ...

To me, the comparison/discussion stops there, at least for folks who are interested in coding real business applications and not bling.

But I agree with Bjorn - it's very interesting to see the different attitudes surface.

djh

[stephenjohannes]

David,

Another way of looking at is that with ABAP and business applications the following quote from the "great philsophers" holds true:

"You can't get want you always want, but if you try some times you might get what you need".

Once you understand that ABAP gives you what you "need" for the business application and Java gives you what you want for business applications, it goes back again to using the "tool that best fits your needs".

Take care,

Stephen

[Former Member]

i am just thinking of two restaurants. one serving me what i want the other one serving me what i need. i didn't have to think long which restaurant to choose. the same holds true for two banks, two clothing shops, two barbers, two software vendors, two almost everything. but probably this is a personal attitude.

usually, in the society where I live, we primarily get what we want (and we fight for that system), then we too often get what we don't need, and after that we (only) get what we need. maybe you just live in an evironment with less choice.

anton

[Former Member]

I want to add some kind of historical perspective to this discussion.

Lets go back to the years before 2001.

At that time, we were faced with a large number of completely different approaches to create SAP web applications like ABAP + ITS, Java + RFC, HTMLB for Java, applet based UIs etc., that had grown over time in different places at SAP.

There was the requirement to consolidate all these different approaches into a new <b>programming model </b> that could serve as the basis for the development of future SAP web applications.

This programming model should be an evolution of the classic Dynpro model with features like DDIC-based validation and automatic value help, should allow for device-independent programming such that applications could be run without change in browsers, mobile clients or even clients that even did not exist yet (think about smart clients).

Further, the development of user interfaces should be model-driven with automatic data binding, based on MVC, using a model abstraction layer and so on.

You see, these were a lot of requirements.

It was clear from the beginning that this programming model would have to be implemented in Java and in ABAP. In Java, to consolidate all the existing outside-in approaches and in ABAP to enhance the ITS/Dynpro programming model.

It was never meant that the J2EE platform should somehow replace the ABAP platform.

IMHO it was reasonable to start the implementation on one platform first (in this case, on the J2EE platform) and do it on the ABAP platform afterwards.

And so we started back in 2001 with Web Dynpro for Java.

Armin

[Former Member]

adding to the historical perspective:

I think 'web enablement' of SAP had to be re-started all over, since until then it has been only used by classical ABAP programmers who, simply put, had no senses for the 'world outside' and it's requirements, and lots of ITS/HTMLB looked accordingly. That is, awful and problematic from the point of usability.

so, though it maybe wasn't on purpose, the 'fresh blood' from outside due to the competition with the more 'world aware' Java community and the appliance of commonly known programming models to SAP platforms, helped the whole thing gaining momentum.

my 2 cents,

anton

[Former Member]

Armin,

Thanks for the history lesson! Don' t get me wrong with above mentioned statements: Web Dynpro as a programming model as well as its implementations - both! - are ingenious and the most beautiful way of creating Web UIs nowadays - and the only one if you' re the most untalented web designer in the world like me. So you' ll never hear any critic from me about that.

But: Compare options you get via WDA with the ones WD4J offers. Think of the implizit Customizing-, Configuration and Personalization features, the Enhancement possibilities, the easy integration of DDIC search help, the marvelous components ready for use (ALV, Message Component), the Code Wizard - I could continue till tomorrow.

And I' m not only talking about Web Dynpro - the general access to SAP Core via Java - and that' s what the whole Java Stack is about - seems quite limping to me because of the above mentioned problems - data access, lacking enhancement features.

And these - together with the missing Java skills in SAP departments - are the KO criteria when it comes to the decision whether to implement a project in Java or in ABAP. And the more decisions taken against Java, the more code will be implemented in ABAP. The more code implemented in ABAP, the more developers will be trained in this language. The more developers trained in this language, the more features will be provided for it. The more features a language contains ... a.s.o. A vicious circle!

I always hear it depends on a) the customers skill set, b) the requirements and c) the existing code base whether to use Java or ABAP. Well, if so, I guess 99% of all decision processes concerning this matter are prefixed from the beginning on.

Regards,

Thomas

[S_Borhauer]

Hi,

of course SAP delivers a flexible technology for mySAP ERP 2005 /NW04s Self-Services! A modification-free screen adaptation of Web Dynpro (Java) application is possible! Have you already heard of this two tools?

a) Web Dynpro Personalization (you can hide/unhide fiels elements, change fields attributes; adding elements for informative reasons, personalize applications centrally by administrator or allow personlization by end users etc.)

For more details check out the documentation in the SAP Help Portal:

http://help.sap.com/saphelp_nw2004s/helpdata/en/42/ed3ce7f8593eebe10000000a1553f7/frameset.htm

b) Role Self-Service Administrator available in the Portal (Business Package is already available for HCM Self-Services such as ESS, MSS based on FPM) ( allows configuration of the set-up of iviews (Layout), adding additional context-specific links, change Road-maps etc.)

Regards,

Sibylle Borhauer

SAP AG

[Former Member]

Hi, Sibylle!

Thank you very much for your advice - I will go through these documents asap. But the one thing I can say already considering the meaning of terms "Personalization" & "Configuration" in ABAP:

Enhancements should go far beyond this and include the possibility to implement own logic at predefined extension points, own data structures in the data processing flow via customer includes a.s.o.

Nevertheless: Thanks for your hints!

Regards,

Thomas

[Former Member]

IMHO

<i>...to enhance SAP Standard programs modification free...</i> is a contradictio in adjecto or an oxymoron with the practical implication in the ABAP world that such customer enhanced standard programs became a major pain in the ass for everyone having to maintain or support such things.

I am pretty sure that the designers of WD4J tried to learn as much as possible from the ABAP world and they finally decided purposefully not to include such mechanisms.

There are of course possiblilities to 'enhance the standard' in the Java world too(e.g. JSR-168), but they are much more reliable than there ABAP counterparts and do not cause the adverse effects, BAdIs or user exits potentially do.

my 2 cents,

anton

[Former Member]

But what to answer a Customer that expects exactly this from a SAP program: to be highly customizable through database configuration via maintenance views and enhancable through the pain-in-the-ass-mechanisms.

That' s what the know, that' s why they bought SAP - because they can enhance nearly everything to suit their needs: programming logic, UIs, data-structures, workflows a.s.o. - make a ZAP outof SAP.

Regards,

Thomas

[Former Member]

Really I don't find any sense to this thread,

of course that you can extend any java application, just you have to have the code...there is not a badi concept in java....if you have the code you can change everything not just a place to put your "enhanced code"

btw if you are cooking you are using knifes, spoons and other elements...you are not going to say "I don't like spoons..." sometimes you have to use ones or others, some in development....ABAP is great to a lot of things and Java is great to other things....It's all about your capacity to get the most of every each.

[Former Member]

Ignacio!

I think most customers have certain expectations regarding SAP products - thing like I mentioned above as well as e. g. a Transport System, the support for large development groups, common UI feeling a.s.o.

SAP realized that Java lacks a lot of features developers need - regarding Software Lifecycle and Change Management. That' s why they implemented NWDI. But I don' t think that' s not enough to stand the challenge the ERP business keeps for a programming language and development concept.

I' m not sure if I understand your comparison with spoons, knives a. s. o., but if I try to follow the picture, with Java in SAP we have to cook a 6-course-meal for a 1000 person gourmet society and only spoons for preparation.

I' m asking why there is no BADI concept - although there could be one - for Java, and considering the price one has to pay for Java development licenses it cannot be the developers task to invent one - especially with SAP where every marketing presentation waxes lyrically about how the SAP development concepts enable programmers to concentrate on business logic.

I see a lot of need for threads like this - as a developer you rack your brain about many things of daily business and probably run the risk of looosing the big picture out of sight. And as a Java developer it seems to me that SAP has had overblown plans with Java in their business, but customers don' t even care about this and try to keep their fingers from the Java stack as long as possible. And if it can' t be avoided any more, the encounter an enourmous amount of problems - because of Java lacking such fundamental things.

Finally: I am a Java Developer and believed in SAPs Marketing Verdicts. That' s why I changed the branche and made the NW Java Certification, but the more I get to know ABAP the more superior I find all it' s concepts - all of this in SAPs core business, of course. I won' t consider programming Handy Games with ABAP - a thing Java is great in - but that' s not what we' re dealing with most commonly.

Regards,

Thomas

[Former Member]

Hi Ignacio,

The fact that you can "change everything" is a fundamental problem. Come upgrade time or the release of a new SP from SAP some poor Java developer has to churn through the code sorting out the custom stuff that has been added all over the place and figuring out how to implement it in the newer version. If there was a structured approach to this it would be easier. What about a standard Customizing custom controller in each standard WD app that has hook methods called from the wdDoModifyView, wdDoInit, wdDoExit, etc that are called before and/or after the standard processing, similar to the way BADI methods can be implemented. Then there would be a standard approach to adding custom logic at the start and/or end of the WD methods.

Thomas isn't saying that you can't change standard SAP Java - what he is saying is that there is no structured framework for doing so. In the ABAP world it is an absolute no-no and a last resort to modify standard SAP code - instead user-exits or BADI's or similar are sought to add/remove/adjust functionality. Come upgrade time all custom code is in one place and is more easily managed.

I'm currently customising an ESS system for a customer and its a complete nightmare as the standard code is all over the place with some dynamic generation of views, some hardcoded and some controlled by backend config. There are virtually no comments in the code and due to the customer's restrictions I cannot debug. We've had to make changes in various places with the hope that our documentation will be enough in the future if the customer ever decides to upgrade or customise further.

Gareth.

[Former Member]

I actually don't like Java...For me, it's wasn't the SAP's best choice....Still I can't deny that for the one who likes Java it's a great and powerfull tool....So makes me sad that all the gurus haven't answer your simple question -:(

You complaint about poor tools??? What about Scripting Languages Developers??? Even when we have a nice Scripting Tool....It's based on Eclipse...which I don't like for some obvious reasons...

People like you should encourage the use of Java technolgy in SAP to get more attention and better tools -:) That's why I do for Scripting Languages -;)

Greetings,

Blag.

[Former Member]

You' re definitly right with your assumption that introducing Java as a second core programming language was not one of SAPs smartest moves - thinking of what SAP development made up until that time: being truly Open Source and widely accepted by the customers which had plunged billions of € to build appropriate knowledge.

Some of my collegues who are in business 15+ years even think that SAP should have concentrated more on its key competencies and improve its own language as well as its processes than waste its own and customers money into adopting a new program paradigma and language - especially when you consider that by 4.6 ABAP has become OO and thereby a mature, modern language which leaves - with BSP and now WDA - nothing to be desired.

Don' t get me wrong: I' m a big fan of Scripting Languages and all the other new stuff that has risen in the last year(s) and I really think they open the SAP world to another clientele and applications, too. But thinking of core processes, business logik - central issues - no customer could think of switching to Java driven development without the basic features I started this thread with. And why should he?

[Former Member]

Hi Thomas,

You have to remember that SAP and their customers are driven by 1 thing and 1 thing only... Money/Profits.

A few years ago the SAP market was pretty grim and a lot of ABAP developers were struggling after charging very high rates to suddenly getting very low rates offered to them. SAP also saw that Java developers grossly outnumber ABAP developers across the world and hence you could assume that it would be easier for customers to get development done for less money using Java developers.

This brings me on to something I consider very lacking in a lot of the new SAP developers. They assume that as they know Java they can become SAP consultants and developers but as you have said, they ignore the backend systems and don't make the effort to understand ABAP. Very often in the Java Programming forum I see questions asked about how to call an RFC from people who the day before were talking about quite complicated Java.

For me, it is important to be able to work with both technologies and also to understand the way SAP business processes work - but I'm going off on a tangent so will stop now!

Gareth.

[Former Member]

So - if I understand you right - in the end we Java developers are just here to cut the prices of developer man-days. What a backslash for my already ruffled ego!

[Former Member]

lol

No, its not that clear really. I think SAP were simply responding to a market in heavy decline for years and trying to find a way to ensure they were still selling implementations and still getting projects from customers by shifting the cost implications.

Things have changed again and the global market is a lot more strong again. I see Java developers being equally important as ABAP developers to SAP in the future, the key is the extra skills the Java or ABAP developers posess. You already talk about going on the BC400 ABAP courses and I applaude you for doing so - this is by far the best attitude and approach to SAP development. We are currently seeing a big push from SAP for E-SOA and their CAF framework. This is going to require skills in a number of areas - ABAP, VC, WD, Java, .NET (eventually), etc - the key is it is a range of skills. I see straight ABAP developers in my company on shakey ground soon - they simply don't have the skills to compete with outsourcing...

My point then is that developers who have multiple skills and experience across different areas in SAP and generic Java/J2EE will be in a much better position than the hundreds of core Java programmers who have had 6000 .pdf documents emailed to them from this forum about SAP who think they are true SAP consultants. That's my opinion anyway.

Gareth.

[suresh_datti]

& now we have WebDynpro ABAP too.. I think the real reason for the 'slow' growth of Java in SAP is that all the core Business Logic is still in ABAP.. though most of it is getting 'class'ified (ABAP Objects) with every new Release.. the next big Rel after ECC6.0 is going to be in 2010 .. hold your breadth till then.. your 'wish' might come true..

~Suresh

[Former Member]

Unfortunatly you seem so right - or should I say luckily. The funny is that most Java developers that got into SAP business seem to stick to their technology, ignore its problems in daily developers life and - most gravely - don' t really care about either ABAP nor the whole SAP application, its logic and functionalities.

I had been forced to do the first ABAP courses (BC400, BC401), but now I' ve acquired a taste for it - ABAP Objects is already now with its inherent event mechanisms and high degree of integration a dream to develop in. The workbench is - with its Navigator - probably the most powerful IDE I' ve ever worked with (Borland, Netbeans, Eclipse, NWDS and all others) - okay, let' s for one moment forget about code completion (what do we have the wizards for?). And the introduction of WDA was a deadly shot right in WDJs back.

Regards,

Thomas

[stephenjohannes]

Thomas,

You comments here are so interesting. I came from the background of learning C/C++/Java/Perl before I ever looked at a single line of ABAP code. The most interesting part of the ABAP language that I liked, coming from that background is that you just "don't worry" about low level details. The focus was always on the business process problem at hand, and not the nitty gritty low level details that are fun for building games, but take too much time when you need something quick.

The hyper-navigational source capability of ABAP workbench is something that makes life easier. The other feature is the "strong-syntax" check that basically prevents you from memorizing complex ABAP syntax. If you don't remember a variant of some statement, just hit F1 to get what you need and a pratical example. This is why in my opinion somebody can be productive so quick.

Honestly the language from a "technical" perspective is not hard to master, it is learning how the modules are structured, is where all the values comes into play, and learning how to search for that information. That is what separates the good from the bad.

I remember reading a Java Developers Journal magazine many years back and the focus was always on "pure technical" design issues. Even most "technical" ABAP issues always end up having some business process related to the core. You think differently when you design ABAP transactions. The focus is always on the business process flow and not on how to build "beautiful design models". You use the "design models" to support the flow and not the other way around. This is a radical concept where the business process drives the design not the technical details.

I guess when you have this "rich" of an environment, why switch over unless something is truly better or you have to be "trendy". I guess I would fully switch once java has "all the features" that we have in ABAP land. However with WDA available I don't really have a reason to switch.

Take care,

Stephen