Why use an Abstract Class ?

I am new to Java and for some reason I can't get my head around why to use an abstract class. I understand that an abstract class is something like:
public abstract class Food{ // abstract class
public void eat(){
// stub
public class Apple extends Food{
public void eat(){
// Eat an apple code
}So basically the idea above is that you can eat an "apple" but you can't eat "food" because you can't instantiate an abstract class.
I understand what an abstract class is and how to write one. What I don't understand is why you would use it? It looks to me like I could have just created a normal class called "Food" and just not instantiated it. What are the benefits of using an abstract class?

807479 wrote:
I am new to Java and for some reason I can't get my head around why to use an abstract class.One of the first books I ever read about Object-Oriented design contained the following quote from [url http://en.wikipedia.org/wiki/Lucius_Cary,_2nd_Viscount_Falkland]Lord Falkland:
"When it is not necessary to make a decision, it is necessary +not+ to make a decision."
It took me quite a while to understand, but it's all about flexibility: As soon as you cast something in stone, you lose the ability to change it later on if something better/more appropriate comes along. Interfaces and abstract classes are all about delaying that decision.
As jverd said, interfaces allow you to specify what is required without defining the how; and as ErasP said, abstract classes are usually incomplete: ie, they define some of the 'how', but not all of it.
What is most important about abstract classes though is that they cannot exist on their own: They must be extended by a concrete class that completes the 'how' before they can be instantiated and, as such, they declare the intent of the designer.
One of the most important uses of abstract classes is as "skeleton implementations" of interfaces, and there are a lot of examples of these in the Java Collections hierarchy. My favourite is probably AbstractList, which contains a skeleton implementation of a List. Because it exists, I can create a class that wraps an array as a List with very little code, viz:public final class ArrayAsList<T>()
   extends AbstractList<T>
   private final T[] values;
   public ArrayAsList(T... values) {
      this.values = values;
   @Override
   public T get(int index) {
      return values[index];
   @Override
   public T set(int index, T element) {
      T value = get(index);
      values[index] = element;
      return value;
   @Override
   public int size() {
      return values.length;
};and somewhere else, I can use it:   List<String> letters =
      new ArrayAsList<String>("a", "b", "c");or perhaps, more practically:   List<String> words = new ArrayAsList<String>(
      bigTextString.split(" +") );Now that may not seem like a big deal to you, but given all that Lists can do, it's actually a very powerful bit of code. The above example is from "Effective Java" (p.95).
HIH
Winston

Similar Messages

  • Why does this abstract class and method work without implement it?

    hi,
    I have seen many times that in some examples that there are objects made from abstract classes directly. However, in all books, manual and tutorials that I've read explain that we MUST implement those methods in a subclass.
    An example of what I'm saying is the example code here . In a few words that example makes Channels (java.nio.channel) and does operations with them. My problem is in the class to make this channels, because they used the ServerSockeChannel class and socket() method directly despite they are abstracts.
       // Create a new channel: if port == 0, FileChannel on /dev/tty, else
       // a SocketChannel from the first accept on the given port number
    private static ByteChannel newChannel (int netPort)
          throws Exception
          if (netPort == 0) {
             FileInputStream fis = new FileInputStream ("/dev/tty");
             return (fis.getChannel());
          } else {
    //CONFLICT LINES
             ServerSocketChannel ssc = ServerSocketChannel.open(); //<--I have never thought do that!! Anyway, how it is static method may work.
             ssc.socket().bind (new InetSocketAddress (netPort)); //<--but here, this method (socket) is abstract. WHY RETURN A SOCKET????????  this mehod should be empty by default.
             System.out.print ("Waiting for connection on port "
                + netPort + "...");
             System.out.flush();
             ByteChannel channel = ssc.accept();
             ssc.close();
             System.out.println ("Got it");
             return (channel);
       } I test this code and works fine. So why can it be??
    Also, I read that the abstract classes can't have static methods. Is it true???
    Please Help!!
    PS: i have seen this kind of code many times. So i feel that I don't understand how its really the abstract methods are made.
    PS2: I understand that obviously you don't do something like this: *"obj = new AbstractClass(); "*. I dont understand how it could be: ServerSocketChannel ssc = ServerSocketChannel.open(); and the compiler didn't warn.

    molavec wrote:
    ServerSocketChannel ssc = ServerSocketChannel.open(); //<--I have never thought do that!! Anyway, how it is static method may work.
    The static method creates an instance of a class which extends ServerSocketChannel, but is actually another non-abstract class.I thought that, but reading the documentation I saw that about open() method:
    Opens a server-socket channel.
    The new channel is created by invoking the openServerSocketChannel method of the system-wide default SelectorProvider object.
    The new channel's socket is initially unbound; it must be bound to a specific address via one of its socket's bind methods before connections can be accepted.
    ...and the problem is the same openServerSocketChannel is abstract, so i don't understand how it could return a ServerSocketChannel.There is a concrete implementation class that has implemented that method.
    I guess that really the open() method use a SelectorProvider's subclase but it doesn't appear in the doc.It doesn't need to. First, you don't care about those implementation details, and second, you know that if the class is abstract, it must use some concrete subclass.
    Ok, I speak Spanish by default (<-- this sounds like "I am a machine", ^_^' ). So, I didn't know how to say that the method would be {}. Is there a way to say that?? I recommendable for me to know, for the future questions o answers.Not sure what you're saying here. But the other respondent was trying to explain to you the difference between an abstract method and an empty method.
    // abstract method
    public abstract void foo();
    // empty method
    public void bar() {
    Which class does extend ServerSocketChannel? I can not see it.It may be a package-private class or a private nested class. There's no need to document that specific implementation, since you never need to use it directly.

  • Why are we using Abstract class?

    Why are we using Abstract class? What is specify use of Abstract class?

    The way I understand it....and I may be wrong because
    I am very new....is that by making the class abstract
    you will add abstract methods to it. Those abstract
    methods MUST be defined in in any subclass that
    inherits from the abstract class thereby making the
    abstract a template for subclasses.
    If your animal class is abstract then you would need
    an abstract method (Which is just siganture, no body)
    of say "numberOfLegs". Then in your dog and cat
    classes which extend animal you must define a
    "numberOfLegs" method with appropriate code.it isn't mandatory for an abstract class to have abstract methods. if a class does have abstract methods, the class must be abstract. but the following is perfectly legal
    public abstract class NoAbstractMethods {
      public void doStuff() {
         // do stuff
    }a subclass of an abstract class can also be abstract, and as such need not implement any additional methods

  • How to use function of an abstract class??

    Hi all,
    I want to use the format(object obj) function of the package java.text.Format. But as the Format class is an abstract class i could not instantiate it, so that i can call the format(object obj) method using the dot(.) operator.
    I know what is an abstract class. i've studied and tried to understand. as everybody knows, studied the perfect example(because i've read it in all the abstract class tutorial, books) of the Shape class. But still i dont understand how am i going to use that format(object obj) method. Please help me..

    Instead of using the abstract class Format use the
    concrete classes DecimalFormat
    SimpleDateFormat etc check java.text APIS
    http://java.sun.com/j2se/1.4.2/docs/api
    Hi!! Thanks both of you.
    If Sun has a abstract class then there must be a
    concrete class which extends that abstract class .It
    is always better to check the APIWhat do you mean by this line. Is it true for all the abstract classes in the jdk?

  • Abstract classes: Why do they need constructors?

    As we cannot instantiate an abstract class. Why does an abstract class need a constructor?.can anyone please help me out..Thnq in advance
    OBELISK

    import java.util.*;
    import static java.lang.System.out;
    interface LineItem{
        public int getCost();
    abstract class AbstractLineItem implements LineItem{
      protected String name;
      AbstractLineItem(String name){
         this.name = name;
      public String toString(){
        return this.name+" "+getCost();
      public abstract int getCost();
    class ProductItem extends AbstractLineItem{
       private int quantity, peritem;
       ProductItem(String name, int quantity, int peritem){
         super(quantity+" "+name);
         this.quantity = quantity;
         this.peritem = peritem;
       public int getCost(){
         return this.quantity*this.peritem;
    class FlatFeeItem extends AbstractLineItem{
       private int fee;
       FlatFeeItem(String name, int fee){
         super(name);
         this.fee = fee;
       public int getCost(){
         return this.fee;
    public class Test{
      public static void main(String ... args){
        List<LineItem> items = new ArrayList<LineItem>();
        items.add(new ProductItem("Banana",6,1));
        items.add(new FlatFeeItem("Some boring thing or another",35));
        items.add(new ProductItem("Kiwi",3,3));
        for(LineItem item : items)
          out.println(item);
    }

  • Using sap.m.TablePersoProvider abstract class

    hi all,
    i have to use a table personalization. i have seen in the API that i can use the TablePersoProvider.
    but this is an abstract class.
    how I am able to use this abstract class in Javascript?
    Best Regards,
    Alexander

    Hi Mario,
    Good idea, really! It'll make your life easier any time you need to work with Characteristics. But...
    I wouldn't use that class if I were you... On our ECC 6.0 it's "Released Internally" (Class Properties > General Data). This means it's released only for internal use of SAP, not for customers.
    You can still build the framework implementing Characteristics BAPIs.
    Regards,
    Andres.

  • Difference between abstract class and the normal class

    Hi...........
    can anyone tell me use of abstract class instead of normal class
    The main doubt for me is...
    1.why we are defining the abstract method in a abstract class and then implementing that in to the normal class.instead of that we can straight way create and implement the method in normal class right...../

    Class vs. interface
    Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.
    For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.
    With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.
    This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.
    Interface vs. abstract class
    Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.
    Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

  • Abstract class extends other class?

    What happens when a abstract class extends other class?
    How can we use the abstract class late in other class?
    Why do we need an abstract class that extends other class?
    for example:-
    public abstract class ABC extends EFG {
    public class EFG{
    private String name="";
    private int rollno="";
    private void setName(int name)
    this.name=name;
    private String getName()
    return this.name;
    }

    shafiur wrote:
    What happens when a abstract class extends other class?Nothing special. You have defined an abstract class.
    How can we use the abstract class late in other class?Define "Late". What "other class"?
    Why do we need an abstract class that extends other class?Because it can be useful to define one.

  • Abstract Class & Interfaces

    Can anyone please tell me as to why we need both an abstract class & an interface? I was asked in an interview as to why we need 2 separate concepts when we can get the similar functionality of an interface by using an abstract class. I had just sited their differences like:
    1) An abstract class can have both abstract & normal methods & that we can specify different access specifiers for its class members.
    2) ABAP does not support Multiple inheritance but that we could simulate the same using interfaces concept in ABAP.
    But he wasnt satisfied with the answer. I guess he was expecting something from a practical point of view. I did try searching the old threads but there wasnt anything similar to this. Anyone please explain by citing a scenario as to why we would need 2 separate concepts & not just one .
    Thanks in advance

    Hi
    Abstract classes
    Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, for example to define a uniform interface.
    Classes with at least one abstract method are themselves abstract.
    Static methods and constructors cannot be abstract.
    You can specify the class of the instance to be created explicitly: CREATE OBJECT <RefToAbstractClass> TYPE <NonAbstractSubclassName>.
    Abstarct classes themselves can’t be instantiated ( althrough their subclasses can)
    Reference to abstract classes can refer to instance of subclass
    Abstract (instance) methods are difined in the class , but not implemented
    They must be redefined in subclasses
    CLASS LC1 DEFINAITION ABSTARCT
    PUBLIC SECTION
    METHODS ESTIMATE ABSTARCT IMPORTING…
    ENDCLASS.
    <b>Interfaces</b>
    Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation.
    Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task.
    The user never actually knows the providers of these services, but communicates with them through the interface.
    In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required. This is known as polymorphism with interfaces.

  • Why use an interface?

    Hey everybody,
    I posted a message in another thread about why to use an abstract class. I have another question and again I am not asking how but why and when. But this time about interfaces. Why would I need to write one? Any example that is not too technical would be great!
    I have read a lot about interfaces but mostly it explains how to write one and not when and why to use them.
    Thanks in advance for your help!

    807479 wrote:
    So my question is basically how does implementing an interface help if there is no code in any of the methods?Because it says to anyone who wants to know "this class fulfills the contract for <tt>x</tt>", where <tt>x</tt> is the behaviour (methods) associated with the interface.
    Furthermore, in the same way that the language allows you to use a superclass as a type, it also allows you to use interfaces as types.
    I presume you're aware that an object can be passed to any method that takes its superclass; well, it can also be passed to any method that takes an interface that it implements.
    <tt>String</tt>, for example, implements <tt>Comparable</tt> (a good real-world interface to get familiar with, BTW), so a <tt>String</tt> object can be passed to either of the following methods:public String append(String s)...
    public int compareWith(Comparable c)...Now, how does that help you? Suppose you write a program that uses a <tt>List</tt>. A common beginner's mistake is to type everything to the nth degree, viz:ArrayList<String> myList = new ArrayList<String>();and then write methods in the same way:public void addSomeStrings(ArrayList<String> list,
       String... items) {.....but, while it will work, it's quite brittle.
    Suppose you decide later on that an <tt>ArrayList</tt> isn't the best way to store your Strings ... what do you do? You have to refactor every bit of code that took an <tt>ArrayList</tt> to now take a new type of List (eg, a <tt>LinkedList</tt>).
    Suppose instead that you wrote your program as follows:List<String> myList = new ArrayList<String>();and then your methods (hopefully ALL of them) as:public void addSomeStrings(List<String> list,
       String... items) {..... Now to change the program to use a <tt>LinkedList</tt>, the ONLY thing you have to change is:List<String> myList = new LinkedList<String>();and your program will work just fine.
    This is what a lot of the posts that talk about "programming to interfaces" are on about. It's a very good technique to get familiar with.
    HIH
    Winston

  • Abstract Classes versus Interfaces

    Somebody at work has just made an interesting observation and its bugging me, comments please.
    When I started Java I just used classes (and abstract classes), and didnt bother with Interfaces I understood them to be a way of getting round the lack of MultipleInheritance and it wasnt a problem that concerned me.
    But as time went on I found that sometimes I did want classes that had little in common to provide some additional feature (such as logging), and interfaces were great for this.
    ..so I was happy ..
    During all this time if I want a HashSet I would write code like this
    HashSet dataSet = new HashSet();but then I read that HashSet was an implementation detail and we should be using Interfaces as follows:
    Set dataSet = new HashSet();So whereas before I might have had a class hierachy with an Abstract class at the top , I started slotting in Interfaces above that and viewing the Abstract class as just a convenience to implementing the Interface.
    So which is the right method , originally I saw subclassing object as an 'is a ' relationship and implementing an interface as a 'implements' relationship. But more recently it seems to be turned on its head and implementing an interface is an 'is a' relationship (but supports multiple inheritance)
    Also it seems to be the trouble with this second approach is that anyone can implement an interface, for example I could implement Set,Map and List with one class, the class hierachy is not so helpful .

    Thanks, but the question was alot wider than that,
    the HashSet example was just one part of it.I think it is representative of all the situations that you talk about, which are whether an instantiator should handle the instantiated object by its interface or by its implementation.
    I suppose the question is
    "How do you code model "is a " relationship in java
    through extending a class or creating an interface
    and implementing it"
    MySubClass extends MySuperClass implements MyInterface {}MySubClass is a MySuperClass and a MyInterface. The way that I view it, the "is a" relationship applies to all type inheritance, even for the multiple type inheritance that you can have with interfaces. The "is a" relationship doesn't doesn't have to be a 1:1 mapping. There's no point in thinking about it differently since that's how the language behaves.
    an alternative question is
    "is it correct to mix/match both methods I described
    above"I thought I gave an answer. You said that my answer is not "broad enough." How so? My answer was that handling an object that you instantiate by its interface can reduce the amount of changes you have to make if you change the implementation. You will have to make one change (the line of code that instantiates the object) instead of many. Also, handling it by its interface makes it easier to switch from object A instantiating object B to object A being passed a reference to B and to object A getting its dependencies injected by XML configuration.
    It seems weird to handle an object by its interface if you already know it's implementation, but it's commonly seen and this is why I think it must be used. As I said, it's a small benefit of abstraction.
    The times when you may not want to do this is when the instantiator has to call methods from different interfaces of the object. You can handle it by its interface by casting between the different interfaces you have to work with, or you can just handle it by its implementation, gaining access to all of the object's interfaces.
    Note that everything I explained concerns the type by which the instantiator handles an instantiated object. If a class does not instantiate a certain object, then it almost always should receive it by its interface, unless it's some really common implementation that's never going to change.
    I use interface, abstract class, and base class interchangeably. It's up to you to decide which to use for type inheritance. It's good practice to favor interfaces.

  • Abstract classes vs adapter classes

    Hi,
    If we need to make use of an adapter class, why do need the interface -- won't abstract classes serve the same purpose???
    I mean if we are going to extend the adapter class and then override the method we want to implement -- why the need for the interface at all -- wouldn't it be simpler if we just used an abstract class and override the function we want to implement????
    Thanx,
    TheJavaKid

    Every once in a while, you'll want to make a WindowListener (for example) that also extends another class. You couldn't do this if WindowListener weren't an interface.

  • When we will go for an abstract class and when we will go for an interface?

    it's always some what confusing to choose an abstract class and an interface,can anybody post a suitable answer for this.

    jwenting wrote:
    with experience and the insight it brings, you will know which to use when.
    Without it, it can't be explained.
    More often than not there's no X OR Y anyway.It's fortunate that there are posters here who possess the insight and experience necessary to explain this. The principal differences between an abstract class and an interface are,
    1. An abstract class can carry implementation, whereas an interface cannot.
    2. An abstract class is singly inherited, wheras an interface is multiply inherited.
    So use an abstract class when the implementation it can carry outweights the fact that it cannot be multiply inherited That's the gist of it.
    The inheritance relationship where this happens is when the supertype is a general concept of which all potential subtypes are special cases. This is called a specialization (or sometimes a generalization) relationship. For example Apple and Banana are Fruit. Or Car and Bike are Vechicle. The Fruit and Vechicle supertypes are general concepts of which their subtypes are special cases. In this case make Fruit and Vechicle abstract classes because the subtypes will benefit from a shared implementation.
    If you don't have a clearcut specialization/generalization relationship make the supertype an interface. An example could be the Comparable supertype. The potential subtypes aren't supposed to be specializations of the Comparable concept, they're suppose to become Comparable (and make this property an integral part of their being). This is not a specialization/generalization relationship. Instead the supertype is intended to add character to the subtypes. The subtypes are unlikely to benefit from an inherited implementation. So make Comparable an interface.

  • Abstract class Vs interface

    Hi,
    I have to buid a report in ECM with complete details of the engineering as well as production. This include workflow as well as various fucntionality depends upon the criterion and user's event.
    I am implementating in OOPS and I Want to know that when I should use the Abstract class and when interface  ?
    Because as per me both serve the same purpose. Kindly send me the exact difference so that i can efficiently use the same.
    Thanks
    Prince

    When inheriting A Interface We have to inherit all the methods of the Interface there's no other option whereas with abstract classes we can inherit the members that we are in need of.
    Just the interface has to have body of the method and the method is to be used by the classes inheriting it. Whereas in the case of Abstract Class it can have declarations (Other than the abstract method) and it can be further extended in the classes inheriting the Abstract Class.
    Interface contains all abstract methods,all methods compulsory implemented by particular class, interface does not contain Constructor
    abstract classes are designed with implemantion gaps for sub-class to fill in.
    interfaces are sintacticlly similar to classes but they lack insance variables & methods.
    abstract classes can also have both abstract methods & non-abstract methods. where as in interface methods are abstract only, & variables are implicitly static&final
    regards
    Preetesh

  • Abstract class confusion

    I am writing a J2ME application, and I want to write a Record management system (RMS) that I can use in other J2ME programs. I have a Record class that RMS classes need to know about. The idea is that the Record class is abstract, and the implementation is defined by a subclass - depending on what the application needs to store. Any Record must provide the following:
    1) A constructor which takes a single byte[] parameter, which is the data read in from the RecordStore by the RMS. The implementation depends on what information is stored in this type of Record - it might be a String, series of ints, etc...
    2) A method getStorageFormat() which returns a btye[] representing the data to be stored in the RecordStore. Again, this is dependent on the application.
    I think that I have to use an abstract class here, so I have written an abstract class called Record - here's what it looks like:
    public abstract class Record {
         public Record(byte[] bytes) { }; //Should this be an empty constructor?
         public abstract byte[] getStorageFormat();
    }My problem is that I can't define a subclass of Record that works! Here's an example:
    public class MyRecord extends Record {
           String data1, data2, data3; //Some data that is stored in this record
           public MyRecord(byte[] bytes) {
                  String data = new String(bytes);
                  // do some processing to extract the data...
           public byte[] getStorageFormat() {
                  String sep = ","; //A seperator
                  String tmp = data1 + sep + data2 + sep + data3; //put all the data together with
                  return tmp.getBytes();
    }}I get an error in Eclipse with the MyRecord constructor that says:" The implicit super constructor Record() is undefined. Must explicity invoke another constructor". I tried super() but I get the same error. Can anyone please tell me what I am doing wrong? It seems to me that I am misunderstanding something about how abstract classes work.

    Because you defined a ctor that takes args, the implicit one that takes no args--super()--is no longer implicitly supplied. You have to either put a no-arg ctor into the parent class, or call the one that you already have.
    public Record(byte[] bytes) { }; //Should this be an empty constructor?
    public abstract byte[] getStorageFormat();
    }No. You don't want a ctor that takes args and does nothing. If you're taking that arg, then you should use it to initialize the state of the object.
    Here are the rules for constructors--"ctors" because I'm lazy. Also, because I'm lazy, "super(...)" and "this(...)" mean any super or this call, regardless of how many args it takes, including those that take no args.
    1) Every class has at least one ctor.
    1.1) If you do not define an explicit constructor for your class, the compiler provides a implicit constructor that takes no args and simply calls super().
    1.2) If you do define one or more explicit constructors, regardless of whether they take args, then the compiler no longer provides the implicit no-arg ctor. In this case, you must explicitly define a
    public MyClass() {...}
    if you want one.
    1.3) Constructors are not inherited.
    2) The first statement in the body of any ctor is either a call to a superclass ctor
    super(...)
    or a call to another ctor of this class
    this(...)
    2.1) If you do not explicitly put a call to super(...) or this(...) as the first statement in a ctor that you define, then the compiler implicitly inserts a call to super's no-arg ctor
    super()
    as the first call. The implicitly called ctor is always super's no-arg ctor, regardless of whether the currently running ctor takes args.
    2.2) There is always exactly one call to either super(...) or this(...) in each constructor, and it is always the first call. You can't put in more than one, and if you put one in, the compiler's implicitly provided one is removed.

Maybe you are looking for