Skip to Content
Author's profile photo Tobias Schnur

Things that would make our life easier when working with Eclipse

Hey folks,

I am working with ABAP in Eclipse for quite a while now and luckily most of our customers have later Netweaver release that supports eclipse with its latest features. I usually work with ABAP OO only and I can ignore the existance of some older concepts (forms, screens etc.). I really love the capabilities of eclipse in its current version for ABAP OO objects and I can actually feel that my development speed has distinctly increased compared to SAP GUI. Nevertheless, there are some features that would very nice to have. I actually have a list of over 20 items. That would be definitly to much for a single blog post. So, I will start with the quick-fix and editor related items. Hopefully a member of the ABAP in Eclipse developer team is reading this 😀

1.) When create a new global variable of a class (static or instance) via quick-fix there is only an option for creating it private.

When I want to have protected/public variable I have to create a private one first, navigate to it and change it’s visibilty using another quick-fix. So, a lot of clicks for a very simple operation are necessary. Since protected is the preferred option in most cases for any developer who actually cares about visiblitly this is very annoying. Why should I explicitly prevent others from inheriting from my class and chosing a variable private? That just makes sense in very special cases. Therefore, default for the quick-fix should either be protected (instead of private) or even better all options (public/protected/private) should be offered as quick-fix.

2.) When a new class is created using the wizard there is no chance to remove the final flag. You have to manually remove it in the source code.

For modern object-oriented APIs there is almost no case where I can image that a final class makes sense. Therefore, the wizard should either offer a checkbox to set a class explicitly to final (it should NOT be checked by default) or create the class without the final additon by default. If someone really wants to have it final the “final” addition in the source code can be added manually. That was also one of the most annoying things in se24 class builder. Classes are set to “final” by default. Therefore, a lot of SAP standard classes have this flag though SAP does not want to prevent anyone from inheriting of their class. We usually have to open a SAP OSS ticket for this and the flag is removed by SAP in standard…I think I have opened more than 20 tickets just because of this flag.

3.) When a class inherits from a superclass it’s often necessary to redefine some methods. It would be very helpful to have a quick-fix that offers a redefinition of all public/protected methods of all super classes. If you are in the scope of the subclass it’s not easy to get an overview of all existing super methods that could potentially be redefined without doing some navigation. If the super classes are very big this could lead to a lot of quick-fix entries. Maybe it would be better to have a single quick-fix entry like “create a redefinition” and it opens a wizard that shows all the public/protected methods of the super classes and one can chose some of them.

4.) Very similar to 3.). When I accidently add a redefinition of a protected method to the public section I get the following ABAP error:

Quick-fix offers the follwing items:

“Add implementation” makes no sense in this case. There cannot be a method of the same name in the sub-class (remember that copy_rights_from_ip is a protected method of the super class). There should be an option like “Make copy_rights_from_ip protected”.

5.) When you have to deal with a varibale defined as a table type in the code there is no easy way to navigate to the underlying workarea. Example:

“crmt_orderadm_i_wrkt” is a table type and it’s underlying workarea is not 100% compatible with DB table crmd_orderadm_i. When I click F2 on “crmt_orderadm_i_wrkt” in the code the following popup opens:

What I actually want to see are the components of the structure “crmt_orderadm_i_wrk” (note the missing “t” at the end).

My workarounds here are either to copy the workarea name and open this object manually via CTRL+SHIFT+A or open the table type from the source code with F3 and double-click on the workarea name in SAP GUI.

It would be more convenient if it could be opened with F3 directly from the popup or the workarea information could be displayed with F2 from the popup. I do not really want to open SAP GUI here. I basically want this view:

5.) It would be very nice to have the possiblity to create getter/setter methods via quickfix (for single attributes by using the quick-fix on a specific attribute and for all attributes by using the quick-fix on the class name).

6.) It would be nice to offer a possibilty to create an abstract class in the wizard for creating classes. I guess this should be easy to implement.

7.) When using the quick-fix to generate a factory methods the old ABAP syntax for object creation “CREATE OBJECT” is used. I would prefer to use the new syntax “NEW” instead (this is just a personal preference).

I think that’s enough for today. I would be very happy about some feedback 😀 .

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ondrej Seman
      Ondrej Seman

      Hi Tobias,

      I completely agree with number 2. and the first number 5!

      I also agree with nr. 7.

      For the others I don't have any opinion, while I don't use those (at least not that much...)

      Have a nice day!


      Author's profile photo Former Member
      Former Member

      Hi, Tobias

      Completely agree with you regarding items 1, 2, 4, 5(2), 6, 7

      but let me discuss about 3 and 5 (1)


      according to Eclipse style it would be better to have separate item in Refactoring menu

      wich more suitable for such mass-operations

      While quick-fix is intended for single corrections


      I think IDE must not make any analyzing of displayed type, when you press F2.

      It have to show the type that was required by F2 exactly.

      But I agree that it is not easy to obtain the underlying type.

      There is a elegant solution of the issue.

      All we need is cross reference links in F2 documentation.

      In your example, structure type crmt_orderadm_i_wrk should be displayed as link and clicking on it should show description of the structure crmt_orderadm_i_wrk with all the components.


      Best regards,


      Author's profile photo Tobias Schnur
      Tobias Schnur
      Blog Post Author

      3 + 5(1): makes absolutely sense. Thank you for this suggestions.

      Author's profile photo Hill Mireille
      Hill Mireille

      I agree with you in all points.

      5(1) and 3 would be the most helpful features for me.

      Author's profile photo Michael Gutfleisch
      Michael Gutfleisch

      Hi Tobias,

      thanks for your feeback!

      Quite a lot requirements, let me comment at least some of them:

      1) Well, making attributes 'protected' by default is not the best option. From an encapsulation view it is the same as making them public. In both cases you cannot change them anymore without taking the risk to break other classes.

      But we think about offering all options. For this we see two possibilities...

      a. providing one quickfix followed by a popup where you can decide about the visibility. Default would be 'private' of course 😉

      b. providing 3 or even 4 qickfixes, one for each case (don't forget 'public read-only')

      What would you prefer? By the way, it is the same question as for the parameters... you can see it in your screenshot above. Here we currently provide 4 quickfixes, one for each parameter kind. Alternatively we could change this to the popup-solution.

      7) We have already implemented that and it will be available with release 7.50.

      I think I will comment more of your requirements within the next days.


      Michael (Product owner of the topic 'refactoring & quickfixes')

      Author's profile photo Tobias Schnur
      Tobias Schnur
      Blog Post Author

      Hi Michael,

      Regarding 1): You are right. I forgot about the read-only option. Usually don't use this concept. I prefer protected variable with public getter method (without setter) or constants depending on the case.

      Nevertheless, I think both proposals you made have it's advantages/drawbacks.

      Popup : Creating a popup would also offer the possibilty to enter a type for the attribute. Currently it's generated of type "any". So, in most cases we have to navigate to the newly created variable anyway and adjust the type. Even the "read-only" option for public variables could be included in the popup. Additionally, you can offer a choice in the popup if the newly created variable is "instance" or "static". In static methods there should be no choice since we cannot use instance variables there. But it's possible to use static variables in instance methods. The obvious drawback of the popup approach is that I have to use my mouse. As a versed Eclipse user I tend to stick to the keyboard with my fingers as often as possible. As a conclusion, I would say this approach is slower but much more flexible.

      Providing 3/4 quick-fixes: I don't have to use my mouse for this and that's obviously much faster. We still have the drawback that a navigation for the type change is necessary. Is it possible to jump to the "any" statement of the newly generated variable with the cursor after using the quick-fix? If so, I would say this approach is also viable and the same technique could also be used for the importing/returning/changing/exporting if they are created with type "any" (that means only if their type cannot be derived from the context). Otherwise the popup approach seems much better for me since a manual navigation to the "any" statement also loses some time. I would ignore the static/instance problem in this approach since it does not happen that often that a static variable is newly declared while implementing an instance method. There would be too many options in the quick-fix menu then. I would also ignore the read-only option here. I don't think this is used too often in general and if it's needed the keyword "read-only" can be added manually. The quick-fix menu should stay as slim as possible and not cover every "special" case.

      I basically can live with both approaches since both are an improvement over the current implementation.

      I am looking forward to have the best ABAP development environment ever. You guys are really doing a great job! Thanks for that!

      Best regards