Constructors, Static Members, this, final and Software Development Life Cycle

Calling contrast — step by step

• Method call: ABC a1 = new ABC(); first creates a1 (constructor runs). Then a1.getData(); explicitly calls getData on that object via dot. Without the second line getData never executes.

• Constructor call: ABC a1 = new ABC(); — the ABC() part is the call. No a1. prefix, no second statement. The new operator looks for ABC() and transfers control into it before returning the reference. Writing a1.ABC(); is not valid Java for a constructor.

This automatic tie between new and ABC() is why a class with no constructor still allows new ABC() — the compiler supplies one, as seen next.

Account class without explicit constructor printing default values 0 null 0.0 — full trace

Setup:

class Account {
    int acc;
    String name;
    float amount;
    void display() {
        System.out.println(acc + " " + name + " " + amount);
    }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account();
        a1.display();
    }
}

Steps:

1. Class Account declares three instance variables: int acc, String name, float amount. No code looks like Account() { }, so no explicit constructor exists.
2. The compiler silently inserts a default constructor — conceptually Account() { } with an empty body — so that new Account() has a target. Without this insertion new Account() would fail to resolve.
3. Execution reaches Account a1 = new Account();. The runtime allocates memory for acc, name, amount, fills them with system defaults (int → 0, reference → null, float → 0.0), then calls the empty default constructor which does nothing further.
4. a1.display(); reads the three fields through the dot on a1 and prints acc + " " + name + " " + amount.

Output — bolded final answer:

0 null 0.0

Sense-check: 0 is the defined default for int, null for any object reference such as String, 0.0 for float. Until you assign, those are exactly what any new Account shows. The empty constructor explains why the program compiles and runs despite having no visible Account().

Explicit default constructor initializing amount to 1000 — full trace

class Account {
    int acc;
    String name;
    float amount;
    Account() {
        System.out.println("the default values are:");
        amount = 1000;
    }
    void display() {
        System.out.println(acc + " " + name + " " + amount);
    }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account();
        a1.display();
    }
}

Step trace:

1. Account a1 = new Account(); allocates acc, name, amount as 0, null, 0.0.
2. Control enters Account() — the explicit default. First line prints the default values are:.
3. amount = 1000; overwrites the 0.0 default. acc and name stay 0 and null because they are not assigned.
4. Constructor returns; a1.display() prints 0 null 1000.0.

You could just as well write acc = 1; name = "unknown"; amount = 1000; inside that constructor if you wanted a fully formed default. The constructor can contain any statements — printing, calculation, validation — not only assignments. The instant new Account() executes, that body runs.

Compare two runs — 0 null 0.0 vs 0 null 1000.0

Case A — no explicit constructor (implicit empty default).

class Account { int acc; String name; float amount; void display() { ... } }
// Test: Account a1 = new Account(); a1.display();

• Compiler supplies Account() { } empty.
• a1.display() reads defaults.

Output A — bolded:

0 null 0.0

Why: int default 0, String default null, float default 0.0. No assignment has overwritten them.

Case B — explicit default that sets amount and prints.

Using the code in 17.2.2, Account a1 = new Account(); executes the body, then a1.display();.

Output B — bolded (two lines):

the default values are:
0 null 1000.0

Line 1 comes from inside the constructor (System.out.println). Line 2 comes from display. Now amount shows 1000.0 instead of 0.0, while acc and name remain 0 and null.

Sense-check: 1000 is exactly what the constructor assigned; if you changed it to amount = 500; you would see 0 null 500.0. This pair proves you can change any data member at construction time by assigning it there.

Account with three parameters versus insert method — two ways to reach 111 Asha 5000.0

Old style — separate method named insert (requires three statements):

class Account {
    int acc; String name; float amount;
    void insert(int a, String n, float amt) {
        acc = a; name = n; amount = amt;
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
// usage
Account a1 = new Account();          // step 1: object exists with 0 null 0.0
a1.insert(111, "Asha", 5000);       // step 2: explicit fill — easy to forget
a1.display();                        // step 3: now shows intended values

Trace: new Account() uses the implicit empty default → 0 null 0.0. The insert call then overwrites: acc = 111 (parameter a → field acc), name = "Asha", amount = 5000. display finally prints 111 Asha 5000.0. The commented-out insert lines in the lecture code did exactly those three assignments, but needed a separate dot call, leaving a window between lines 1 and 2 where a1 was in a half-built 0 null 0.0 state.

New style — parameterized constructor (requires two statements):

class Account {
    int acc; String name; float amount;
    Account(int a, String n, float amt) {
        acc = a; name = n; amount = amt;
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
// usage
Account a1 = new Account(111, "Asha", 5000); // creation + initialization fused
a1.display();

Trace: new Account(111, "Asha", 5000) allocates fields (0 null 0.0) then immediately enters Account(int a, String n, float amt) with arguments a=111, n="Asha", amt=5000. Inside, acc = a copies 111 into the field, etc. By the time new returns, the object already holds 111 Asha 5000.0. Only two statements were needed: create-with-values, display.

Output — bolded (both styles converge):

111 Asha 5000.0

Sense-check: Every value printed is exactly the argument you passed; changing the call to new Account(222, "Ravi", 3000) would print 222 Ravi 3000.0. The constructor guarantees the object is never observed as 0 null 0.0 between creation and use, which the insert pattern cannot guarantee.

Sharing mechanics with a and b

Imagine class ABC declares int a; int b; (non-static) and you create O1 = new ABC() and O2 = new ABC():

• If non-static: O1.a = 10, O1.b = 20 and O2.a = 30, O2.b = 40. Reading O1.a yields 10; O2.a yields 30. They are independent instance copies — two separate boxes.

• If static: static int a; static int b; → one slot for a, one for b on class ABC. Initialize that slot to a = 10, b = 20. Now O1.a and O2.a both read 10 because both dots reach the same slot. If you modify via one object, O2.a = 50, then O1.a also reads 50.

This is why static is called a class variable: modification through any path (O1, O2, or ABC) is visible through every other path because there is only one underlying box.

Example A — Static variable StaticWhereX myClassVar Java programming accessed by class name and overwritten to Python programming

Setup (no objects yet):

class StaticWhereX {
    static String myClassVar = "Java programming";
}
class Test {
    public static void main(String args[]) {
        System.out.println(StaticWhereX.myClassVar); // Java programming
        StaticWhereX.myClassVar = "Python programming";
        System.out.println(StaticWhereX.myClassVar); // Python programming
    }
}

Steps:

1. Class loading: StaticWhereX loads, its static slot myClassVar is created and initialized to "Java programming". No new StaticWhereX() has run.
2. StaticWhereX.myClassVar with class-name dot reads that slot → prints Java programming.
3. StaticWhereX.myClassVar = "Python programming"; overwrites the same slot. No object is involved.
4. Second read StaticWhereX.myClassVar → prints Python programming.

Bolded outputs in order: Java programming then Python programming. Demonstrates class-level ownership: the variable is reachable without any object.

Example B — Static variable shared through obj1 and obj2 both printing Java programming then both Python programming after obj2 modification

class StaticWhereX {
    static String myClassVar = "Java programming";
}
class Test {
    public static void main(String args[]) {
        StaticWhereX obj1 = new StaticWhereX();
        StaticWhereX obj2 = new StaticWhereX();
        System.out.println(obj1.myClassVar); // Java programming
        System.out.println(obj2.myClassVar); // Java programming
        obj2.myClassVar = "Python programming";
        System.out.println(obj1.myClassVar); // Python programming
        System.out.println(obj2.myClassVar); // Python programming
    }
}

Steps:

1. Two objects obj1 and obj2 are created; each logically has a dot that points to the same central myClassVar slot already holding "Java programming".
2. obj1.myClassVar prints Java programming; obj2.myClassVar prints the same Java programming — two reads, one slot behind both.
3. obj2.myClassVar = "Python programming"; writes through obj2's dot but lands in the shared slot, overwriting it.
4. obj1.myClassVar now prints Python programming (visible change though obj1 was not touched); obj2.myClassVar also prints Python programming.

Bolded sequence in order: Java programming, Java programming, Python programming, Python programming. The common-box diagram captures it: one box between obj1 and obj2; obj2's write is visible to obj1. Access via object is allowed but still reaches the class slot — the compiler even warns to prefer StaticWhereX.myClassVar.

Sense-check: If myClassVar were non-static, step 3 would affect only obj2 and obj1 would still show Java programming. The fact both flip proves shared storage.

Exam note: questions deliberately test that misconception. Remember the four-print pattern Java, Java → write via one object → Python, Python.

Cross-class static access ABC classVar read from XYZ via ABC.classVar without object

class ABC {
    static String classVar = "Java programming";
}
class XYZ {
    public static void main(String args[]) {
        System.out.println(ABC.classVar); // Java programming
    }
}

Steps: XYZ creates no ABC object. It writes ABC.classVar — the name of the owning class dot variable — and reads the shared slot directly. The cross access is reached from XYZ via ABC.classVar without creating an object or calling a constructor. If XYZ later did ABC.classVar = "Python programming"; every future read from any class would see "Python programming". This cross-class reach works because the static field lives on the class, not inside an instance.

This also explains why static variables are sometimes described as controlled globals: reachable anywhere by ClassName.field (subject to access modifiers) without passing an object reference.

Instance variable str instance variable independent copies — obj1 remains instance variable while obj2 becomes change text

class InstanceWhere {
    String str = "instance variable";
}
class Test {
    public static void main(String args[]) {
        InstanceWhere obj1 = new InstanceWhere();
        InstanceWhere obj2 = new InstanceWhere();
        System.out.println(obj1.str); // instance variable
        System.out.println(obj2.str); // instance variable
        obj2.str = "change text";
        System.out.println(obj1.str); // instance variable
        System.out.println(obj2.str); // change text
    }
}

Steps:

1. str is declared without static, so each new InstanceWhere() allocates its own str slot. Field initializer = "instance variable" runs per object, so both boxes start as "instance variable".
2. obj1.str prints instance variable; obj2.str prints the same instance variable — two reads from two independent boxes that happen to hold equal strings.
3. obj2.str = "change text"; writes only into obj2's box; obj1's box is untouched because they are separate allocations.
4. obj1.str still prints instance variable; obj2.str now prints change text.

Bolded outputs in order: instance variable, instance variable, instance variable, change text. The third print staying instance variable (not becoming change text) proves independence — the direct opposite of the Java programming → Python programming shared pattern where both flipped.

The same numeric pattern: O1.a = 10 and O2.a = 30 coexist after O2.a = 30; reading O1.a still yields 10. No cross-object leakage occurs.

Sense-check: Change the assignment to obj1.str = "hello" instead — then obj1 would show hello while obj2 stayed instance variable. Each object's page is isolated.

Static method overloading Main assign with one parameter and two parameters via Main.assign

class Main {
    static void assign(int a) {
        System.out.println("one: " + a);
    }
    static void assign(int a, int b) {
        System.out.println("two: " + a + " " + b);
    }
    public static void main(String args[]) {
        Main.assign(10);      // calls assign(int a) — one-arg form
        Main.assign(10, 20);  // calls assign(int a, int b) — two-arg form
    }
}

Steps:

1. Main.assign(10) — compiler searches for assign with one int. Finds assign(int a) and generates a call to it. Output one: 10.
2. Main.assign(10, 20) — searches for two int params. Finds assign(int,int) and calls it. Output two: 10 20.

The two forms are independent; the one-param version might store a single static config value, the two-param version might store a pair. No extra qualification is needed because both are static and owned by Main.

Bolded outputs in order: one: 10 then two: 10 20 (or any analogous prints showing the matched overload). The pattern proves that static + overloading behaves like normal overloading — parameter count selects the method, and the class name selects the owner.

Sense-check: Changing the call to Main.assign(10, 20, 30) would fail to compile — no three-arg assign exists — exactly as for instance overloads.

Static block in class abc printing inside static block and initializing i to 20 accessed as abc.i — execution order

class abc {
    static int i;
    static {
        System.out.println("inside static block");
        i = 20;
    }
}
class xyz {
    public static void main(String args[]) {
        System.out.println(abc.i);
    }
}

Steps:

1. xyz.main starts; its first mention of abc.i forces the runtime to load class abc (if it was not already loaded).
2. At class-load time, before the field read completes, the static block executes: it prints inside static block and assigns i = 20 to the class-level slot. Field static int i; without initializer had started as 0; now it becomes 20.
3. After the block finishes, the read abc.i completes and returns 20 to System.out.println.
4. Output order on two lines:

Bolded outputs in order:

inside static block
20

First line originates inside the block during loading; second line originates from println(abc.i) which now sees 20. If a second static block existed after the first, its statements would run immediately after i = 20, preserving source order, before the read.

Sense-check: Move System.out.println(abc.i) to be executed twice — you would still see inside static block only once, at the first access, proving "once per class load."

Extension used in companion text (UseStatic): static int a = 3; static int b; static { b = a * 4; } prints Static block initialized. then b becomes 12. Same pattern: block computes a static field after simple initialization.

this keyword fixing shadowing with this.acc equals acc this.name this.amount versus 0 null 0.0 output

Failure case — shadowing hides the field:

class Account {
    int acc; String name; float amount;
    Account(int acc, String name, float amount) {
        acc = acc;
        name = name;
        amount = amount;
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account(832345, "Asha", 5000);
        a1.display(); // prints 0 null 0.0
    }
}

Why 0 null 0.0? Parameter names acc, name, amount hide the fields of the same names (shadowing). Inside the constructor, every bare acc resolves to the parameter, not the field. acc = acc assigns the parameter to itself; the field this.acc is never touched and stays at 0 null 0.0.

Fix 1 — rename parameters (quick but changes call-site vocabulary): Account(int a, String n, float am) { acc = a; name = n; amount = am; }

Fix 2 — keep names, qualify fields with this (preferred):

Account(int acc, String name, float amount) {
    this.acc = acc;
    this.name = name;
    this.amount = amount;
}

Now this.acc means the field of the current object (a1.acc when a1 is being constructed) while bare acc on the right means the parameter. Values flow parameter → field. After this fix new Account(832345, "Asha", 5000) followed by display() prints:

Bolded corrected output:

832345 Asha 5000.0

instead of 0 null 0.0. This is the textbook shadowing resolution taught with this. The companion Box example shows the same: Box(double width, ...) { this.width = width; } to resolve width shadowing.

this to invoke current class method — this.display() inside insert

class Account {
    int acc; String name; float amount;
    void insert(int acc, String name, float amount) {
        this.acc = acc; this.name = name; this.amount = amount;
        this.display();
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account();
        a1.insert(111, "Asha", 5000);
    }
}

Execution: a1.insert(111, "Asha", 5000) enters insert with this == a1. After the three this.field assignments, this.display() means a1.display() because this is a1 at that moment. No separate a1.display() appears in main. Output:

Bolded:

111 Asha 5000.0

Rule: this.display() inside a method invoked by a1 is exactly a1.display(). For O2 it would be O2.display(). The self-call avoids hardcoding the variable name inside the class — the class works for any caller.

Constructor chaining with this acc name calling two-parameter constructor from three-parameter constructor

class Account {
    int acc; String name; float amount;
    Account(int acc, String name) {
        this.acc = acc; this.name = name;
    }
    Account(int acc, String name, float amount) {
        this(acc, name); // calls the two-parameter form
        this.amount = amount;
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account(111, "Asha", 5000);
        a1.display(); // 111 Asha 5000.0
    }
}

Steps: new Account(111, "Asha", 5000) enters the three-parameter constructor. First line this(acc, name) is a special this(...) call that invokes the sibling two-parameter constructor Account(int acc, String name) with the same acc and name. That delegate body runs and sets this.acc and this.name. Control returns to the caller, and this.amount = amount; finishes the third field. No repetition of this.acc = acc; this.name = name; is needed.

Constraints: this(...) must be the very first statement in the constructor body, and you cannot mix this(...) and super(...) in the same constructor.

Bolded output: 111 Asha 5000.0. Delegation ensures consistent handling of shared fields regardless of which overload is used.

Passing this as argument display this for a1 Ankit and a2 Showbith and updated a1 — full trace

class Account {
    int acc; String name; float amount;
    Account(int acc, String name) {
        this.acc = acc; this.name = name;
        display(this);
    }
    void update(int acc, String name, float amount) {
        this.acc = acc; this.name = name; this.amount = amount;
        display(this);
    }
    void display(Account obj) {
        System.out.println(obj.acc + " " + obj.name + " " + obj.amount);
    }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account(832345, "Ankit");
        Account a2 = new Account(832346, "Showbith");
        a1.update(999, "AnkitUpdated", 7000);
    }
}

Flow:

1. new Account(832345, "Ankit") creates a1 (832345, "Ankit", 0.0) and calls display(this) where this is a1. display receives that Account as obj and prints obj's fields → 832345 Ankit 0.0.
2. Second construction new Account(832346, "Showbith") does the same for a2 → 832346 Showbith 0.0.
3. a1.update(999, "AnkitUpdated", 7000) runs on a1, overwrites its three fields, then calls display(this) again — still a1 but with updated values → 999 AnkitUpdated 7000.0.

Bolded outputs in order:

832345 Ankit 0.0
832346 Showbith 0.0
999 AnkitUpdated 7000.0

This matches the walkthrough where the constructor displays each new object and the update displays the modified a1. Passing this hands the whole current identity to another routine, useful for callbacks and double-dispatch patterns.

Returning this from update method Account update return this and a1 equals a1.update — chaining pattern

class Account {
    int acc; String name; float amount;
    Account(int acc, String name) {
        this.acc = acc; this.name = name;
    }
    Account update(int acc, String name, float amount) {
        this.acc = acc; this.name = name; this.amount = amount;
        return this;
    }
    void display() { System.out.println(acc + " " + name + " " + amount); }
}
class TestAccount {
    public static void main(String args[]) {
        Account a1 = new Account(111, "Asha");
        a1.display(); // 111 Asha 0.0
        a1 = a1.update(222, "Asha2", 9000);
        a1.display(); // 222 Asha2 9000.0
    }
}

Steps: new Account(111, "Asha") creates a1 with amount still 0.0; first display → 111 Asha 0.0. a1.update(222, "Asha2", 9000) runs on a1, updates its three fields, and executes return this; which evaluates to the same object reference a1. The assignment a1 = a1.update(...) stores that returned reference back into a1 (here it points to the same object; the pattern matters when chaining calls like a1.update(...).display() or fluent APIs). Second display → 222 Asha2 9000.0.

This pattern enables method chaining: return this lets calls be strung together because each call yields the current object for the next dot.

Bolded outputs in order: 111 Asha 0.0 then 222 Asha2 9000.0.

Immutable final class Account with final fields getters only — construction and read

final class Account {
    final int acc;
    final String name;
    final float amount;
    Account(int acc, String name, float amount) {
        this.acc = acc;
        this.name = name;
        this.amount = amount;
    }
    int getAcc() { return acc; }
    String getName() { return name; }
    float getAmount() { return amount; }
}

class Test {
    public static void main(String args[]) {
        Account a = new Account(111, "Asha", 5000);
        System.out.println(a.getAcc() + " " + a.getName() + " " + a.getAmount());
    }
}

Trace:

1. final class Account blocks inheritance — class Sub extends Account would not compile.
2. final int acc; etc., start unassigned; they will be assigned exactly once in the constructor. The final modifier tells the compiler to enforce single assignment.
3. new Account(111, "Asha", 5000) allocates fields, enters constructor, executes this.acc = acc etc. — the sole legal write to each final field. After constructor returns, acc=111, name="Asha", amount=5000.0.
4. Three getters getAcc, getName, getAmount return those frozen values.
5. Test.main creates a and prints via getters:

Bolded output:

111 Asha 5000.0

No setter exists, so the only way to give the object its state is the construction call. Any later attempt to mutate must go through a blocked path.

This also demonstrates why this.acc = acc appears again: shadowing fix and final-field initialization share the same syntax — qualifying the field side with this.

Attempted modification and compiler error the final field Account.amount cannot be assigned

If you add after construction a line that tries to change a final field:

a.amount = 1000;

the compiler rejects it while amount remains final. The lecture reported message similar to:

exception in thread "main" java.lang.Error: unresolved compilation problem:
  the final field Account.amount cannot be assigned

(The exact wording varies by compiler/IDE — some say cannot assign a value to final variable amount — but the key phrase final field ... cannot be assigned is the searchable signal.)

Steps to reproduce:

1. Keep final float amount; and the getters-only class as above.
2. After Account a = new Account(111, "Asha", 5000); write a.amount = 1000; or add a setter void setAmount(float v){ amount = v; } — both fail because amount is already assigned in the constructor.
3. Removing final from the field declaration would let that assignment compile and run, silently breaking immutability. Keeping final preserves the read-only guarantee.

The same fence blocks indirect mutation through a setter, because none is provided by design. If you added one, the assignment inside it would also fail for the same reason — a final field cannot be reassigned.

IRCTC illustration — database Oracle MySQL versus Hadoop MapReduce and Kerberos and Paytm Google Pay UPI and real-time train updates

Context: IRCTC — the Indian Railway Catering and Tourism Corporation ticket booking platform used across the country — was used as the concrete, end-to-end model to show how planning feeds design and design feeds who codes what.

Requirements discovered for a system like IRCTC (from customers, domain experts, market surveys):

• A database in the background that must store huge amounts of data (users, trains, bookings, payments, history).
• Optimization for peak load (festival season spikes, Tatkal windows).
• Customer roles with distinct permissions: admin, regular user, ticket agent, railway staff, ticket-counter staff.
• An application programming interface layer for payment merchants.
• Broad train details: which intermediate stations a train visits, timings, seat maps, live location.

Designing for those requirements — requirement by requirement, weighing platform choices:

• For large database: Designers weigh traditional relational Oracle or MySQL versus distributed options Hadoop or MapReduce or a cloud-native store. Criteria: expected data size, query patterns (transactional bookings need strong consistency; analytics on travel patterns tolerates eventual consistency), latency for a seat-availability check, scalability for thousands of concurrent transactions. Example decision: Oracle for strongly consistent ticket inventory plus Hadoop/MapReduce for nightly analytics.

• For customer roles / authentication: Different actors (railway employees, admin staff, counter staff, end customers) need different access levels. Designers decide authentication and access-control mechanisms; a high-level platform such as Kerberos or a similar role-aware login system was mentioned as a design option for strong, centralized authentication and ticket inspection permissions.

• For APIs / payments: The system must collaborate with many payment partners — Paytm, Google Pay, other UPI handling (Unified Payments Interface), credit cards, debit cards, internet banking and other merchants — so the API design must be compatible with all those choices today. A third-party merchant integration layer (often a payment gateway abstraction) is designed so new wallets can be added without rewriting core booking logic. In textbook terms this is the interface and integration design within architecture.

• For train details — real-time updates: Design must support updates as a train moves from station A to station B through many intermediate stations. Servers used by intermediate station masters and staff must see live positions, delays, and berth availability, which drives choices about data modeling (train as entity with ordered station list), replication (push vs poll), and distribution (edge caches at stations). The same data powers passenger apps and internal control panels; consistency vs freshness is the trade-off.

From decision to coding: Once choices are fixed — say "Oracle for bookings, Hadoop for analytics, Kerberos for auth, gateway for Paytm/Google Pay/UPI, streaming replication for live location" — tasks are assigned: one subteam codes database schema and queries, another builds authentication, another integrates merchant APIs, another handles train-state tracking. Separately developed pieces are integrated into one complete IRCTC-like product, then tested, deployed, and maintained.

Sense-check: If requirement analysis missed that intermediate stations need write access (not only read), the station-update replication design would be wrong and require rework — illustrating why the earlier phases matter before coding.