Bjarne Stroustrup mentions in Design and Evolution of C++ that super as a keyword was considered by the ISO C++ Standards committee the first time C++ was standardized.

Dag Bruck proposed this extension, calling the base class "inherited." The proposal mentioned the multiple inheritance issue, and would have flagged ambiguous uses. Even Stroustrup was convinced.

After discussion, Dag Bruck (yes, the same person making the proposal) wrote that the proposal was implementable, technically sound, and free of major flaws, and handled multiple inheritance. On the other hand, there wasn't enough bang for the buck, and the committee should handle a thornier problem.

Michael Tiemann arrived late, and then showed that a typedef'ed super would work just fine, using the same technique that was asked about in this post.

So, no, this will probably never get standardized.

If you don't have a copy, Design and Evolution is well worth the cover price. Used copies can be had for about $10.

In addition to all the above, consider the following scenario:

• You start out with these two classes.

   class A {
      int i = 20;
  
      A() {
          System.out.println("I am in constructor of the parent class");
      }
  }
  

  class B extends A {
      int i = 30;
  
      B() {
          System.out.println("I am in constructor of the subclass");
      }
  }
  

• You compile both classes, it creates two class files: A.class and B.class

• Now you change your mind and rewrite A:

   class A {
      int i = 10;
  
      A() {
          System.out.println("I am in constructor of the parent class");
      }
  }
  

• You recompile A, so you get a new A.class, which you replace the old A.class with

Now the question is: how would B know that As initialisation code has changed? You haven't recompiled B, nor should you be required to do so. After all, B may already be packaged up in a different jar, maybe even in a different product you have no control over.*

The only reasonable way to support this case is for Bs constructor to start with calling As constructor and let A initialise itself.

*This may sound far-fetched at first, but this is exactly what happens when internal implementation details of JDK classes are changed. All the previously compiled Java applications in the world should run seamlessly with the new JDK.

C# equivalent of your code is

  class Imagedata : PDFStreamEngine
  {
     // C# uses "base" keyword whenever Java uses "super" 
     // so instead of super(...) in Java we should call its C# equivalent (base):
     public Imagedata()
       : base(ResourceLoader.loadProperties("org/apache/pdfbox/resources/PDFTextStripper.properties", true)) 
     { }

     // Java methods are virtual by default, when C# methods aren't.
     // So we should be sure that processOperator method in base class 
     // (that is PDFStreamEngine)
     // declared as "virtual"
     protected override void processOperator(PDFOperator operations, List arguments)
     {
        base.processOperator(operations, arguments);
     }
  }