Introduction to Java and Object-Oriented Programming Foundations

This lecture introduces Java as both a language and a platform, traces the bytecode execution path that gives Java its portability, inventories the JDK, JRE, JVM, and JIT layers, surveys where Java runs across billions of devices, and builds the core object model — classes as blueprints, objects as filled instances, the structure of a first program, manual command-line build steps, Eclipse project flow, and the three organizing principles and code organization tools of encapsulation, inheritance, polymorphism, and packages.

16.1 Java as a Language and as a Platform

16.1.1 Course Setup and the Flipped Approach

This course is offered through the work integrated learning program and it uses a flipped mode. Recorded lectures, slides, and course material are shared on the portal before the live session. The live session assumes you have gone through that material. The focus is on discussion, problem solving, and interactive examples rather than repeating slides. The course handout on the portal lists the exact pattern. A programming background in C or C++ is helpful, because you will recognise variables, control flow, and functions, yet the course is built so that even without that background you can follow the Java material from the start. The first session therefore spends extra time on what object oriented programming is, what Java is, what editors exist, how to debug, and how to write and run your very first program.

Flipped learning here means you first watch the pre-contact video and read the slides that cover vocabulary like class, object, and platform, then you use the live hour to debug a real Hello World together and to argue about what "platform" really means. This order moves memorisation outside class and leaves class time for the mistakes you learn most from, such as mistyping System.out.println and reading the compiler error.

16.1.2 What a Platform Means

When you hear platform, you might think of several things. In the discussion, responses included a place to develop, a software layer, a user interface that builds on a particular technology, an operating system, and an application level interface. All of these point toward the same central idea.

Visual intuition: Picture a vertical stack. At the bottom is raw hardware — processor, memory, disk. Just above it is the operating system that drives the hardware. At the top is your application. A platform is the whole slab you stand on when you run the application — sometimes that slab is "hardware + operating system", sometimes it is "hardware + operating system + Java runtime". The one-sentence takeaway: without the slab, the application has nowhere to stand.

16.1.3 Why Java Is Called Both a Language and a Platform

Java is a programming language you use to write source code in files ending with .java. At the same time, Java is called a platform because it brings its own runtime environment.

Comparison — Java versus C on platforms: In C, you ship source and rely on a separate compiler for each target, and the resulting executable is tied to one operating system and processor. In Java, you ship bytecode and rely on a port of the JRE for each target, and the same bytecode runs wherever that port exists. Pick C-style native compilation when you need maximal startup speed or direct hardware access without any virtual machine. Pick Java's platform approach when you need "build once, run many places" and automatic services like memory management and standard libraries.

Real-world: this is why the same Java code base can be used on many kinds of devices while only the JRE port for that device changes. A bank's account service, for example, can be built once on a developer laptop and then run on a Linux server, a Windows test machine, and a container in the cloud, because each target offers the same Java platform on top of different hardware.

16.2 Bytecode and the Way a Java Program Executes

16.2.1 The Execution Path With an Intermediate Step

A Java program does not go directly from source file to executable file. The intermediate step is what gives Java its portability.

The source file, for example First.java, contains the text you write. You compile it. The output of the compiler is not a native .exe but a .class file that holds bytecode. That bytecode is then handled by an interpreter to reach a form that the underlying machine can run. The chain is:

First.java (source text you write)
  -- compile with javac --> First.class (bytecode)
  -- interpret with java --> output ready to run

Bytecode is described as highly optimized instructions that the Java runtime system can execute. It is not tied to Windows or Unix or Mac by itself. This is the core of Java's "write once, run anywhere" promise — the compiler's output is neutral.

16.2.2 Java's Magic and Portability

Bytecode is often called Java's magic. You write and compile on one system, for example Windows, and produce First.class. You can then take that same .class file to a Unix system, a Mac, or any other system and run it, provided the target system has a JRE available. You do not recompile the source. You carry the error-free compiled form and execute it directly.

Contrast this with a direct native compilation where you would generate a platform-specific .exe. Different platforms have different configurations, so a single native executable cannot run everywhere. That is the gap that the C tool chain faces without a dedicated compiler per platform.

With Java, your own system provides the compiler, you generate bytecode, and the bytecode travels. Each target provides the matching Java Virtual Machine (JVM) inside its JRE to interpret the bytecode.

Real-world: this portability is the reason the same backend service JAR can be built once and deployed on Linux servers, developer laptops, and cloud containers without rebuilding. The build server produces a JAR of .class files; each deployment target only needs the correct Java runtime.

Visual intuition: Draw a horizontal pipeline with three boxes and two arrows. Box 1 is First.java (text, human-readable, .java extension). Arrow 1 labeled javac points to Box 2 First.class (bytecode, compact, portable). Arrow 2 labeled java + JVM points to Box 3 "native execution + Hello World output". The key landmark is that Box 2 is portable; it can branch to many Box 3 instances on different operating systems. One-sentence takeaway: one compilation fans out to many executions.

16.2.3 How to Describe the Process in Words

When you write notes on this flow, keep the spoken description alongside the steps: source file First.java is the program you have written; after compilation you get a First.class file; that file is the bytecode; bytecode with the help of an interpreter becomes the final executable form ready to run. Saying it in order — "I wrote First dot java, I compiled it with javac to First dot class bytecode, I then interpreted it with the java launcher on a JVM" — cements the chain better than memorizing arrows alone. In an exam, that ordered sentence is what shows you understand the intermediate step.

16.3 Components of the Java Execution Environment — JDK, JRE, JVM and JIT

16.3.1 The Nested Diagram

The environment is best seen as nested boxes. The innermost rectangle is the Java Virtual Machine (JVM). Around it is the Java Runtime Environment (JRE), often shown as a green box. Around both is the Java Development Kit (JDK). A fourth label, JIT, is an optimization layer that improves interpretation and final execution time.

Visual intuition: Picture three concentric rectangles. The smallest inner rectangle is labeled JVM — the engine. The middle rectangle, often colored green in slides, is labeled JRE — engine plus fuel and libraries. The outer rectangle is labeled JDK — the full workshop that contains the engine, the fuel, and all the tools to build engines. A floating badge labeled JIT sits on the JVM boundary, with an arrow saying "makes hot code faster while running". The one-sentence takeaway: each outer box adds capability, but only the inner JVM actually executes bytecode.

16.3.2 JVM — What It Does

A JVM is the interpreter for bytecode. Where First.class is the result of compilation, the JVM provides the runtime for executing that .class file. It loads the bytecode, verifies it, and executes it. Without a JVM, the .class file is just data. With a JVM, it becomes a running program.

16.3.3 JRE — What It Adds

The JRE is the runtime environment for bytecode execution. It contains the JVM plus the libraries and files that the JVM uses. If the JVM is the engine, the JRE is the engine plus the supporting libraries, resources, and runtime files that make the engine usable. Running programs requires a JRE, not just a JVM in isolation.

16.3.4 JDK — The Full Development Kit

The JDK contains everything needed to develop Java applications. It includes the JRE and the JVM, plus the Java compiler (javac), the Java interpreter (java), and the Java documentation and tools. The outer rectangle in the diagram represents this complete system. If you are only running programs, a JRE is enough. If you are writing, compiling, and building programs, you need the JDK.

16.3.5 JIT — The Optimizer

JIT stands for Just-In-Time compilation. It optimizes interpretation and improves execution time. The model is simple: first, make the code correct — both syntax and meaning — so it compiles without errors. Then, make it fast and storage-efficient. JIT works at that second stage, tuning the way bytecode is turned into native instructions while the program runs.

Real-world: in production servers, JIT is a reason long-running Java services gain speed after a warm-up period, as the optimizer learns hot paths. A Spring web service may serve the first few hundred requests a bit slower, then stabilize at higher throughput once hot methods have been JIT-compiled. That is why benchmarks usually discard the first seconds as warm-up.

16.4 Where Java Is Used

16.4.1 Scale of Adoption

According to Sun Microsystems, 3 billion devices run Java. That number is used to stress how widely the language and its runtime have spread.

The figure is from Sun Microsystems, the original creator of Java, and it counted servers, desktops, phones, smart cards, and embedded controllers that shipped with a Java runtime. Even if you update the number today — Oracle now cites higher counts — the point remains: learning Java's class and object model gives you a skill that transfers across hardware families, not just one product line. That reach is the reason the course invests the first lecture in platform and bytecode before any sophisticated object design.

16.4.2 Domains

Java appears across many domains:

• desktop applications
• enterprise applications
• mobile systems — Android itself uses Java
• embedded systems and micro devices, including IoT devices
• smart cards
• robotics
• games
• web systems

The language provides separate modules for desktop, web, and mobile development, so the same core ideas carry across subdomains. Whether you look at a transactional backend, a desktop tool, a web service, or a device controller, you are likely to meet Java.

Visual intuition: Imagine a fan chart with "core Java (classes, objects, packages)" at the center. Spokes radiate to desktop, web, mobile, embedded, smart card, robotics, games. The fan shows that the center is identical — you write a Student class the same way — while only the outer spoke libraries change. The one-sentence takeaway: master the center once, then pick a spoke for your job.

Real-world: a single team can move between a desktop Swing tool, a Spring web service, and an Android app while staying inside the broader Java ecosystem. The Swing tool might let an analyst edit account records, the Spring service might expose POST /accounts over HTTP, and the Android app might let a field agent view those same accounts on a phone — all three share the Account class and its withdraw and deposit methods without rewriting business rules.

16.4.3 Significance for This Course

Before starting object oriented ideas, this breadth matters because it explains why you learn classes, objects, and packages in a way that transfers directly to many job roles. If Java only powered one kind of device, you could afford to learn a device-specific shortcut. Because it powers many, the course insists on the portable foundation — blueprint thinking with classes, controlled access with encapsulation, reuse with inheritance, flexibility with polymorphism, and organization with packages — that is identical everywhere Java runs.

16.5 Classes — The Blueprint Idea

16.5.1 Starting From Examples Before a Formal Definition

A class is introduced through examples first, then given a formal shape. An attribute is a named data item held by the class. An operation or method is a piece of code that works on those attributes. A class groups attributes and operations into one unit. It is a blueprint from which individual examples are created by supplying concrete values.

That one description is the class. It says what data every member will carry and what actions every member can perform. The individual copies then differ only in the values they hold.

16.5.2 Fruit Example

Take a class called Fruit. Within Fruit, there is an attribute name, an attribute color, and an operation cost. Two examples from that blueprint:

• Left example: name = apple, color = red, cost = 10 dollars
• Right example: name = mango, color = yellow, cost = 5 dollars

Both apple and mango belong to the same class Fruit, yet you can tell them apart because their attribute values differ. The class name tells you the kind; the attribute values tell you the specific case.

16.5.3 Person, Account, Student and Circle Examples

A Person class may hold attributes name, age, gender and operations speak, listen, walk. From that blueprint you can create many persons by varying name, age, and gender, while the operations remain the shared capability of any person.

An Account class may hold attributes accountName, accountBalance with a blue-ink label for data and a separate mark for operations such as withdraw, deposit, determineBalance. Each individual account is produced by giving accountName and accountBalance concrete values.

A Student class may hold attributes name, studentID, age with operations getName, getID. Even if two students share the same name and age, their studentID differs, so they remain distinct objects from the same blueprint.

A Circle class may hold attributes center, radius and operations area, circumference, move. A Rectangle class may hold center, height, width with its own area and circumference. The move idea returns later under inheritance because moving only needs a new center.

Visual intuition: Imagine a table where columns are attributes and each row is an instance. The column headers come from the class (name, color, cost for Fruit; center, radius for Circle). Filling a row creates one object. The one-sentence takeaway: the class is the header row; objects are the filled data rows.

16.5.4 Formal View

A class binds data and the code that manipulates it into one unit. Members of a class are its attributes and its member functions. Different sources may call attributes by several names: attributes, member variables, data members, or fields. Operations may be called methods, member functions, or operations — they refer to the same idea. You combine attributes and operations to form the single unit you use as a blueprint.

16.5.5 Why Classes Matter

Real-world: in large Java projects, a class like Student or Account appears as a single file that many parts of the program reuse. Fixing a method in the class fixes the behavior everywhere that class is used. If Account.withdraw once allowed an overdraft bug, correcting that one method repairs every account object in the system without hunting through dozens of copies of procedural code. That single-point fix is the practical payoff of blueprint thinking.

16.6 Objects and Instances — Concrete Values From a Blueprint

16.6.1 How Objects Are Created

An object is a concrete instance produced from a class by giving all its attributes specific values. The class is the blueprint; the object is the house built from it. Other terms you will see: an instance of a class. They mean the same thing.

Take a class Student whose blueprint holds name, age, ID and the associated operations. To create instances:

• instance one: name = Mike, age = 25, ID = 1000
• instance two: name = George, age = 23, ID = 2000

You can keep going and create hundreds or thousands of instances from the same blueprint, as long as the attributes and operations are defined.

16.6.2 State, Behavior and Identity

An entity has state and behavior. State is the current attribute values for that object. Behavior is the operations you can invoke on it. Each object has an address and takes up memory when it is created and given values.

Objects can communicate without knowing each other's internal code or data. The name of the object is enough. If instance1 and instance2 exist, you can write code that refers to one or the other by name, and they can interact through their public operations without exposing private details. This is the client-server view from the crash-course texts: client code requests a service by invoking a method on an object, and the object provides that service.

Visual intuition: Draw two boxes labeled s1 and s2. Each box points with an arrow to its own blob in memory that contains three slots (name, age, ID). The blobs look identical in shape but hold different fill values. The arrows are the references; the blobs are the objects. The one-sentence takeaway: the variable is the arrow, not the blob — copying the arrow copies the pointer, not the contents.

16.6.3 A Small Class Sketch

Consider a class Dog. It may list attributes for its state and operations for its behavior. Creating an object d1 from Dog means supplying values for those attributes. That d1 then occupies memory and carries its own state distinct from any other Dog object you create. The same pattern repeats for Fruit, Person, Account, and any other class you design. For Dog, think of attributes breed, age, color and behavior bark(), eat(). Doing Dog d1 = new Dog(); d1.breed = "Labrador"; d1.bark(); creates one dog that barks as a Labrador, separate from Dog d2 = new Dog(); d2.breed = "Pug";.

Real-world: in a banking system, each Account object holds a different balance and owner name, yet all of them answer to withdraw and deposit. Creating a new account is just creating a new object from the Account blueprint. A clerk might create Account a1 for one customer with balance 8000 and Account a2 for another with balance 500, and the same withdraw code correctly updates only the targeted object's balance because each object carries its own state.

16.7 First Java Program — Structure and Syntax

16.7.1 The Full Program

The first program is intentionally small. You create a file whose name matches the class name. For a class called First, you save the file as First.java. The structure is:

class First {
    public static void main(String args[]) {
        System.out.println("Hello World");
    }
}

When the program is called, class First is invoked. Execution always starts from main. Inside main, the line System.out.println("Hello World"); directs the program to print Hello World on the console.

16.7.2 What Each Word Means

• class is a keyword that declares a class in Java.
• public is an access modifier that represents visibility. Making a class or method public makes it visible to all. Java also allows private and protected as other visibility levels. The full role of each modifier is explored later with objects.
• static is a keyword whose core advantage is that a static method can be invoked without creating an object of its class. How to create objects and when static matters is learned right after you can create objects comfortably.
• void is the return type of the method. For main, the return type is fixed by the language designers. If you try to change the return type of main itself, you will get an error. For methods you write yourself, you can choose the return type.
• main represents the starting point of the program. It is invoked by the Java Virtual Machine.
• String args[] written as String args is used for command line arguments. It appears in every program's main signature and is used when you want to take arguments at the moment you interpret the program. That use is shown in later sessions.
• System.out.println is a combination of three names: System is the name of a class, out is a field within that class, and println is the method that prints a line. Together they send Hello World to standard output.

Visual intuition: Draw a call chain from top to bottom. At the top is the command java First. An arrow drops to First.main (the doorway). Inside main, a horizontal arrow points to System.out.println. The console on the right then shows Hello World with a downward arrow for the newline. The one-sentence takeaway: the JVM knocks on one fixed door, and that door delegates to the printing service.

16.7.3 How to Save and Name

The class holds the entire program. After writing the code inside main, close the method bracket and the class bracket. Save the file as First.java — the class name plus .java. Execution always starts from main, so the JVM looks there first. Use a plain text editor with UTF-8 encoding and ensure the editor does not silently add a double extension like First.java.txt. Check the file manager — the type should be JAVA file, not text file.

16.8 Compiling, Running and Debugging From the Command Line

16.8.1 Two Steps to Run

After saving First.java, you need exactly two commands:

• Compile: javac First.java
• Interpret the bytecode: java First

javac is the name of the Java compiler. When it succeeds, it generates First.class, which is the bytecode. In the file manager, that file appears with type class file. Starting from an empty folder, you see only First.java. After compilation you see First.class added automatically. Then java First uses the interpreter named java to run that bytecode and you see Hello World on the screen.

The folder state matters. Before compiling, the folder holds just the source text. After compiling, it holds both the source and the generated bytecode. That visible appearance of a new .class file helps you confirm that compilation succeeded even before you run. Keep source and class files together in the same working directory while learning; packages will later teach you a nested layout.

Visual intuition: Picture the file manager with a before and after snapshot. Before: one icon First.java (text). After javac: two icons — the original plus First.class (class file, binary). After java First: the console window shows the third artifact — the output line Hello World. The one-sentence takeaway: text in, class file out, console out.

16.8.2 Live Correction While Compiling

In the demonstration, the file is written in notepad, saved as First.java, then compiled from the command prompt after moving to the directory with cd to the folder that holds the file. The first javac First.java reports an error because System was typed as sysdem with outgroup and println misspelled. Reopening the file, fixing to System.out.println, and running javac First.java again produces no error, which means the file compiled successfully. Going back to the folder then shows First.class has been created. Running java First then prints Hello World.

This sequence shows the edit-compile-observe loop that you will use throughout the course. Every Java fix follows the same cycle: edit the .java text, recompile with javac, confirm the .class updated, rerun with java, observe.

16.8.3 Fixing the Path When JDK Is Not Detected

If you installed Java for the first time, your system may not determine the JDK. The symptom is that javac is not recognized. The fix is to set the path.

Go to My Computer, then Properties, then Advanced system settings, then Environment variables, then System variables, then Path. Add the path to your JDK installation. An example path shown is for JDK 9.0, but you use whatever recent installer you have, for example Java 17 or Java 18 from Oracle. Whichever version you installed, add its bin path to the environment variable so the system can find javac and java.

Real-world: this manual path step is only needed when you run from the command line with notepad. Eclipse hides it, which is why many beginners first run fails in the prompt but succeeds in Eclipse. Knowing the manual step still matters for servers and containers where no IDE is present and you must set PATH or JAVA_HOME yourself.

16.9 Eclipse IDE — Integrated Development Environment

16.9.1 What an IDE Provides

Eclipse is a well known Integrated Development Environment (IDE) for writing Java programs. Compared with notepad, where you handle everything manually, Eclipse brings built-in compiler support, project organization, and on-the-fly analysis. Once installed, you do not need to set the path separately. For good practice, you should know both paths: manual notepad with path handling and Eclipse with its integrated tooling.

An IDE is a single program that bundles the editor, compiler, launcher, debugger, and project view. In notepad, you are the build system — you decide where to save, when to run javac, and how to read raw compiler text. In Eclipse, the IDE does that plumbing: it compiles as you type, organizes sources into projects and packages, links the correct JDK, and shows problems inline. The Eclipse console also keeps Hello World output in the same window as your code, so the edit-compile-observe loop stays in one place.

16.9.2 Creating a Project and a Class

The flow inside Eclipse is:

• You see the overall Eclipse console.
• Go to File, then New, then Java Project. In the field that appears, provide the name of the Java project, for example firstProject. The IDE may suggest starting with a lower case letter. Press Finish. The new project appears on the left side.
• To add a class, go to File, then New, then Class. Provide the class name First. By default, Eclipse includes a package named demo and prepares the class structure public class First. In notepad you must type all of that yourself.
• Inside main, write System.out.println("Hello World"); and save. The name of the class is First.

16.9.3 Running and Fixing Inside Eclipse

To execute, click Run and then Run First.java. Hello World appears in the output area below.

Eclipse also helps when you make a small mistake. If you write man instead of main, or pri instead of println, it immediately shows a marker. The message might read that the method print is undefined for the type PrintStream and offers a quick fix: change to print or println. Selecting the fix repairs the error in place. In notepad you would only discover such a typo after trying to compile; in Eclipse you see it while typing.

Real-world: teams use Eclipse, IntelliJ, or similar IDEs precisely for this tight feedback, plus built-in build, search, and refactor support. Refactoring a class name in Eclipse renames the file, the class line, and all references together, something a manual notepad edit cannot do safely.

16.10 Encapsulation — Binding Data With the Code That Manipulates It

16.10.1 Core Idea and Access Control

Encapsulation is binding the data with the code that manipulates it. The attributes and operations of a class live together in one unit rather than as disconnected pieces.

Two statements capture the intent:

• The variables or data of a class are hidden from any other class and can be accessed only through member functions of the same class where they are declared.
• Encapsulation can be achieved by declaring all variables in the class as private and writing public methods in the class to set and get values of those variables.

An access modifier controls how widely a member can be seen. Common choices are private for restricted access and public for visible-to-all access. If you give a getter or setter no explicit modifier, its access is default or package level, which means every class present in the same folder or package can call that method. That fact matters because the getter and setter are meant to sit between an outside caller and the private data.

Visual intuition: Picture the Student object as a safe. The private fields id and name are inside the safe. The public or package methods setId, getId, setName, getName are the keypad on the door. Outside code cannot reach inside the safe; it can only press the keypad. The one-sentence takeaway: the safe wall is private, the keypad is the controlled method path.

16.10.2 The Student Example in Full

Consider a class named Student with two members, id and name. To enforce encapsulation, both are declared with private:

class Student {
    private int id;
    private String name;

    void setId(int x) { id = x; }
    int getId() { return id; }

    void setName(String s) { name = s; }
    String getName() { return name; }
}

In spoken form: setId receives one argument and assigns that argument's value to id. It is setting the value, so its return type is void. getId takes no assignment argument; it returns the current value of id, so its return type is int, the type of the variable itself. The same pattern repeats for name: setName receives a String argument and assigns it to name; getName returns a String. Initially getName was typed with return type int by mistake; the correction is that it should be String because name is a String.

By default, setId, getId, setName, and getName have no modifier written before them, so they are accessible to other classes in the same package. What they reach for, however, is private. Another class in the same package cannot write s1.id directly because id is private, but it can call s1.setId(5) and s1.getId() to work with the value through the method layer. That indirection is the whole point: the data stays hidden, while controlled methods provide the path to read or write it.

16.10.3 Using the Encapsulated Class From Another Class

Create a second class in the same package or folder named TestStudent with public static void main. Inside it:

class TestStudent {
    public static void main(String args[]) {
        Student s1 = new Student();
        s1.setId(5);
        System.out.println(s1.getId());
        s1.setName("Satish");
        System.out.println(s1.getName());
    }
}

In an earlier non-encapsulated version, you might have written s1.id = 253 and s1.name = "Satish" using the dot operator, then printed with System.out.println(s1.id) or s1.name. That style gave the same numeric result but left the fields exposed. With private fields, that direct assignment is no longer possible outside Student. You must call setId with a value such as 5, and that value is assigned to id inside Student. Similarly you assign a name string and later retrieve it with a getter.

A separate note made during the session: if you create an object s1 that is an instance of Student itself, then inside the Student class you can reach s1.id directly, because an object of a class can access private members of that same class. If you instead create an object t1 of TestStudent, you cannot write t1.id to reach a student's id — t1 is not a Student. The rule is not about the name after the dot but about which class the object belongs to. Private means "inside this class definition", not "inside this object name".

16.10.4 Read-Only and Write-Only Choices

Whether you provide both getter and setter is a design decision.

• If you want a read-only variable, provide getId as public and omit setId. Whatever value is initialized will then never be modified through the public path.
• If you want a write-only variable, provide setId and omit getId. Callers can modify the value, but cannot read it back through the class where it lives.

The earlier example showed the full combination with both accessors for both fields. In practice you choose based on the need of the program.

Real-world: many Java beans expose every field with both get and set to let frameworks read and write freely, while domain objects for security or configuration expose only getters to keep values immutable after construction. A BankAccount that holds a ledger balance might expose getBalance but no setBalance — the only way to change the balance is through deposit and withdraw methods that preserve invariants such as non-negative balance.

16.10.5 Worked Use With Multiple Objects

Continuing the Student story to show many objects from the same blueprint:

Student s1 = new Student();
s1.setId(253);
s1.setName("Satish");

Student s2 = new Student();
s2.setId(300);
s2.setName("Mike");

// s3, s4, and so on can be added in the same way
System.out.println(s1.getId() + " " + s1.getName());
System.out.println(s2.getId() + " " + s2.getName());

Each object carries its own copy of id and name. The dot operator reaches either the accessor method or the field depending on the access rules, but the encapsulated form replaces s1.id = 253 with s1.setId(253) for code outside Student.

16.11 Inheritance — One Class Acquiring Properties of Another

16.11.1 The Intuition From a Classroom Image

A picture is used to make the idea memorable: an examination is in progress with three students. The student in the blue t-shirt is writing the answer independently. The student in the middle tries to copy something from the student on the left or right. The student on the far side then tries to copy from the middle student. The information available with the parent flows to the child, and an intermediate child can then pass it further. That copying is the everyday image for inheritance: existing capability is reused rather than rewritten.

About 75 minutes into the session, a short five minute break is taken before starting these three principles, which is why the encapsulation, inheritance, and polymorphism material appears as a distinct second block. That break is a useful landmark: if you recall "before the break was classes and Hello World, after the break was the three pillars", you will never mix the order.

16.11.2 Definition and Roles

Inheritance is the property by which one class acquires the properties of another. The source is called the parent class, superclass, or base class. The receiver is called the child class, subclass, or derived class. The child inherits certain capabilities from the parent, shown in diagrams with one color for inherited features and another for its own local features. If a parent class has ten features, a child might inherit two of them and add several of its own. The relationship is that the child is a usable extension of the parent.

Visual intuition: Imagine a vertical tree where Person sits at the top with four slots: name, age, gender, address. Branching down left is Student and down right is Lecturer. Each child box shows the same top four slots in one color (inherited) plus its own slots — rollNumber, year for Student and staffID, department for Lecturer — in a second color (local). The one-sentence takeaway: write the shared slots once at the parent, and every child automatically carries them in the same color.

16.11.3 Person Example — Sharing Common Attributes

Take a Person class that holds attributes common to many people: name, age, gender, and address. A Student class needs those four plus its own local attributes such as rollNumber and year. A Lecturer class needs the same four plus staffID and department. Instead of writing name, age, gender, and address repeatedly in Student and Lecturer, you place them once in Person and let both children inherit them. You then add only the local fields to each child.

The hierarchy can be extended: Student and Lecturer are children of Person, and further specializations can inherit from them. For example, ResearchStudent could extend Student and inherit both Person and Student traits while adding thesis fields, forming a chain where information flows parent → child → grandchild just like the three students in the picture.

16.11.4 Shape Example — Sharing a Common Method

A Shape class holds an attribute center and a method moveTo(newCenter). A Circle subclass holds center, radius, and methods area, circumference, plus inherited movement. A Rectangle subclass holds center, height, width, and its own area, circumference. The way area and circumference are calculated differs between circle and rectangle. The way moveTo works is the same in both: take the new coordinates and assign them as the center. Instead of writing moveTo twice, you move that method out of Circle and Rectangle and keep it once in Shape. Both children then simply inherit it. The advantage is reuse: write once, use in many children.

Real-world: in a graphics toolkit, Shape.moveTo written once fixes movement for every shape that inherits from Shape, so a bug fix in one place repairs all derived shapes. The same holds for a UI toolkit where Component.setVisible sits in the superclass and Button and Label simply inherit visibility control.

16.12 Polymorphism — Many Forms

16.12.1 Meaning and the Everyday Image

Polymorphism means many forms. The parts poly meaning many and morph meaning form come from Greek. The idea is that a single name can have many forms of use.

A vivid image is used: a character known as Ben10 who has multiple alien forms. Selecting a different form changes what the character can do, yet it remains the same character. In code, the same method name can be written in several forms, and the system picks the right one based on how it is called. That many-forms idea is polymorphism.

Visual intuition: Draw a single label initialize at the top, with two arrows down to two boxes. The left box is labeled initialize(int k) and the right box initialize(int k, int l). Call arrows come from two objects both labeled S1 but carrying one versus two arguments, and each arrow lands on exactly one box. The one-sentence takeaway: one name fans out to many implementations, chosen by call shape.

16.12.2 Method Overloading as a Form of Polymorphism

A straightforward form is method overloading. Consider a method named initialize:

void initialize(int k) { /* method one */ }
void initialize(int k, int l) { /* method two */ }

If you create an object S1 of the class and write S1.initialize(k) with a single argument, the one-argument version (method one) is called. If you write S1.initialize(k, l) with two arguments, the two-argument version (method two) is called. The name initialize stays the same; the choice of definition is made automatically from the number of arguments you supply. That automatic selection based on call shape is what we call method overloading, a form of polymorphism. Types, counts, or orders of arguments can drive the selection, but the session focuses on count.

Real-world: Java libraries overload constructors and utility methods so callers need to remember only one name, such as println for many argument shapes. System.out.println() has overloads for int, double, String, Object, and others. You call the same println whether you have println(42) or println("Hello") or println(3.14), and the compiler routes each to the matching body.

16.13 Packages — Organizing Code With Folders and Import

16.13.1 What Packages Are

A package is broadly a directory or folder that organizes classes and files. On a computer, you might create a folder on D drive called firstProject, and inside it another folder called demo. In Java terminology that inner folder is a package. It holds various classes and files that you may want to call from your program.

In Eclipse you create that same structure by choosing File, then New, then Package, giving it a name. The name you give is the package name you will use in code. The crash-course texts put it this way: large programs consist of many classes in multiple packages, and the class files must live in subdirectories whose names match the package names. Writing package demo; as the first line of First.java places First inside demo, and the compiler expects the file to sit at src/demo/First.java inside project firstProject.

Visual intuition: Draw a file tree with firstProject at the top, branching to src/demo/First.java and src/classOne/HelloWorld.java and src/classroom/HelloWorld.java. Next to each file, write its full name: demo.First, classOne.HelloWorld, classroom.HelloWorld. An arrow from demo.First points to an import line import classOne.*; showing the link. The one-sentence takeaway: the folder path is the package name, written in dots for code and slashes for the file system.

16.13.2 Importing All Classes From a Package

Suppose a class named HelloWorld is available inside a package named classOne (a folder classOne). Your program lives in a different package, say classTwo. To use the earlier code you need to import it.

To bring every class from classOne into your program, write:

import classOne.*;

import is the keyword that provides the name of the folder or package plus .*. The * means all classes available in that folder become importable. After that line you can write ordinary code that uses those classes if they are public:

HelloWorld H = new HelloWorld();
H.show();

You created an object of HelloWorld and called its method show through the object H.

This was demonstrated in Eclipse by showing how to create a package and how it appears as a folder structure in the project explorer. In the Package Explorer, classOne appears as a expandable folder that reveals its classes; writing the import then turns a red unknown-type marker into a resolved reference.

16.13.3 Importing a Single Class From a Package

If you only need one class, you can import that class specifically instead of *.

With a folder named classroom that holds a class named HelloWorld:

import classroom.HelloWorld;

The rest stays the same: you create an object of that class in the normal way and access its methods through the object.

You can have multiple packages in your Java environment, in your working folder or working directory, and import the respective classes into your program using import for each package you want to use. The order of import lines does not affect execution, but keeping them sorted helps readers see dependencies at a glance.

Real-world: large applications group classes into packages such as com.company.model, com.company.service, and com.company.util so that import com.company.model.* or specific imports keep code organized and collisions low. A model package might hold User, Account, and Transaction; a service package holds the logic that operates on them; a utility package holds helpers. Import lines then document which layer reaches into which.

16.13.4 How Eclipse Shows Packages

Eclipse makes packages visible as folder trees. Creating a package with File, New, Package places a directory under the project. Writing import classOne.*; or import classroom.HelloWorld; then resolves against that directory view. The IDE marks missing imports as errors, which is another advantage over notepad where a missing import is only seen at compilation. The Package Explorer shows a chain firstProject > src > classOne > HelloWorld.java; the editor underlines an unknown type in red until you add the matching import, then the underline clears immediately. You also get an organizer: Source → Organize Imports will add needed imports and remove unused ones automatically.

Exam Guidance Summary

The session does not announce distribution of marks or question patterns for a final exam. Instead it gives practice guidance that directly affects how you should study from the first class.

• The pre-contact and post-contact session material covers the foundation. Go through that material and the recordings to stay ready before each live session.
• From the very first class, build a strong connection with program structure. Practicing the small Hello World program and the encapsulation example with getters and setters pays off when later, higher topics are added.
• Practice both ways: first on the Eclipse IDE, then also by executing the same programs on notepad with the command line. That pair gives you an understanding of how a program is created, how it compiles, how bytecode is generated, and how it is interpreted.
• Practice material is readily available: searching for Java examples gives many exercises, and an additional document with practice problems may be provided to work from.
• A good connect with the program structure early makes it quick to grab new material in coming sessions as the course moves toward higher topics.

Exam note: while no specific marks are stated, the emphasis is that the more you practice, the more you enjoy the programming work. Treat bytecode steps, JDK versus JRE versus JVM, class versus object, encapsulation with getter and setter, inheritance with Person and Shape examples, polymorphism with method overloading, and packages with import as the core checklist to be able to write and explain.

Key Industry Applications

• Java platform in products: Java's own runtime environment together with its API is the reason Java is described as a platform, not just a language. Any hardware or software environment that lets code run is a platform; Java supplies its own. Vendors port the JRE to servers, laptops, and devices so the same bytecode can ship everywhere.

• Portable bytecode delivery: Bytecode portability lets a compiled class file built on Windows run on Unix or Mac wherever the JVM is available. The interpreter in the JVM turns bytecode into native actions on each target. Build systems produce JARs once and deploy them unchanged to test, staging, and production.

• Environment layers in operations: The JDK includes the compiler, interpreter, documentation, JVM, and JRE; the JRE includes the JVM plus libraries; the JVM loads, verifies, and executes bytecode. JIT optimization during interpretation improves speed in long-running applications, which is why teams benchmark after warm-up.

• Scale and domains: Sun Microsystems' figure of 3 billion devices running Java spans desktop applications, enterprise applications, mobile including Android, embedded systems, smart cards, robotics, games, IoT and web systems. Separate Java modules exist for desktop, web, and mobile work, yet the core class and object model is identical across them.

• Classes and objects in codebases: Classes as blueprints appear everywhere: Fruit with apple 10 dollars red and mango 5 dollars yellow, Person with name age gender and speak listen walk, Account with accountName accountBalance and withdraw deposit, Student with name studentID and getName getID, Circle with center radius and area circumference. Each object such as Mike 25 ID 1000 or George 23 ID 2000 or Satish 253 shows a distinct state with shared behavior, created with new and reached through references.

• First program and toolchain: The First program class First { public static void main(String args[]) { System.out.println("Hello World"); } } saved as First.java compiled with javac First.java to First.class and run with java First is the same start that real developers use for the smallest deployable service and the same path that fails when the JDK path is not set.

• IDE feedback: Eclipse lets you create a Java Project firstProject and a class First in package demo with default structure already filled in, run it to see Hello World, and get immediate yellow warnings or red errors such as method print is undefined for type PrintStream with a one-click fix. Notepad lacks that.

• Encapsulation as a bean pattern: Encapsulation with private id and name plus public setId, getId, setName, getName is the standard Java bean pattern for hiding data and exposing controlled read or write paths, including read-only by omitting a setter or write-only by omitting a getter. Teams use it with constructors to make identity fields stable after construction.

• Inheritance for reuse: Inheritance reuse is shown by moving shared attributes like name age gender address into Person for reuse in Student and Lecturer, and by moving moveTo(newCenter) into Shape for reuse in Circle and Rectangle instead of duplicating it. A single bug fix in the parent then repairs every child.

• Polymorphism via overloading: Polymorphism through method overloading lets a single name initialize with one argument or two arguments dispatch to the matching definition, the same idea that lets Java's own libraries overload constructors and print methods such as println so callers remember one name.

• Packages at team scale: Packages as directories let you organize firstProject/demo and import with import classOne.* for all classes or import classroom.HelloWorld for one class, a habit that scales to com.company.model and similar namespaces in production code. Explicit single-class imports reduce collisions when two packages share a short name.