DEV Community: Adesola

Reading Input in Java

Adesola — Sat, 03 Oct 2026 18:17:11 +0000

System.in, BufferedReader, and Scanner

Every Java beginner eventually asks the same question: "Okay, I can print output — how do I actually read something the user types?" Java gives you a few ways to do this, each with trade-offs. Let's go through them in the order most people discover them.

A quick trivia detour: what is println, really?

Before we get to input, a fun fact that doubles as a common interview question: what class does println actually belong to?

The answer is PrintStream. When you write System.out.println(...), you're calling println on System.out — an object of type PrintStream. And System.out itself is declared inside the System class as:

public static final PrintStream out = null;

Yes, literally initialized to null in the source — it only becomes a working object because native code inside the JVM reassigns it during startup, before your program ever runs. It's a nice example of how much setup happens before main even starts.

The most basic way: System.in.read()

The lowest-level way to read input is System.in.read(), which reads a single byte and returns it as an int:

public class StoreApplication {
    public static void main(String[] args) throws IOException {
        System.out.println("Enter a Number: ");
        int number = System.in.read();
        System.out.println("You entered: " + (number - 48));
    }
}

The - 48 looks strange until you remember that read() returns the ASCII value of the character typed, not the number itself. The ASCII value of the character '0' is 48, '1' is 49, and so on — so subtracting 48 converts the character code back into the actual digit.

This only works because the example assumes a single-digit number. read() reads one byte at a time, so the moment a user types 42, this approach breaks — you'd read '4' and stop, never seeing the 2. For anything beyond a single digit, you need something better.

A more practical option: BufferedReader

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class StoreApplication {
    public static void main(String[] args) throws IOException {
        System.out.println("Enter a Number: ");

        InputStreamReader reader = new InputStreamReader(System.in);
        BufferedReader bfNumber = new BufferedReader(reader);
        int num = Integer.parseInt(bfNumber.readLine());

        System.out.println("You entered: " + num);
    }
}

BufferedReader reads a full line of text at once via readLine(), which you then convert to the type you actually need (Integer.parseInt for an int, in this case). It's not limited to console input either — the same BufferedReader can read from a file, a network connection, or anything else wrapped in a Reader.

Don't forget to close it

BufferedReader is a resource — like a file handle or a database connection — and it's the developer's responsibility to close it once you're done, or you risk leaking it:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class StoreApplication {
    public static void main(String[] args) throws IOException {
        System.out.println("Enter a Number: ");

        InputStreamReader reader = new InputStreamReader(System.in);
        BufferedReader bfNumber = new BufferedReader(reader);
        int num = Integer.parseInt(bfNumber.readLine());

        System.out.println("You entered: " + num);
        bfNumber.close();
    }
}

Manually calling close() like this works, but it has a sharp edge: if an exception happens between opening the reader and this close() call, the resource never gets released. That's exactly the problem try-with-resources was introduced to solve — I covered that in detail in my try-with-resources article, which is worth reading right after this one.

The newer option: Scanner

Before Java 5, BufferedReader was really the only practical option for reading console input. Java 5 introduced the Scanner class, which is friendlier for simple cases:

import java.util.Scanner;

public class StoreApplication {
    public static void main(String[] args) {
        System.out.println("Enter a Number: ");

        Scanner reader = new Scanner(System.in);
        int num = reader.nextInt();
        System.out.println("You entered: " + num);
        reader.close();
    }
}

No manual parsing needed — nextInt() reads and converts in one step. Scanner has similar methods for other types too: nextLine(), nextDouble(), nextBoolean(), and so on.

So which one should you actually use?

System.in.read() — essentially never, outside of understanding how input works at a low level. Too limited for real use.

Scanner — great for quick scripts, small programs, and competitive-programming-style input where convenience matters more than raw performance.

BufferedReader — generally faster for reading large volumes of input, and more flexible since it isn't tied to parsing specific types the way Scanner is. It is a common choice in performance-sensitive code and when reading from files.

Both are resources and both need closing — and in both cases, try-with-resources is the safer way to do that instead of a manual close() call.

Wrapping up

Reading input in Java looks trivial once you've done it a few times, but each option — System.in.read(), BufferedReader, Scanner — represents a different point on the trade-off between low-level control, performance, and convenience. Knowing all three (and why Scanner eventually replaced BufferedReader for a lot of everyday use cases) is a small thing that signals you understand more than just the syntax.

Which one do you reach for by default — Scanner or BufferedReader? Let me know in the comments.

Try-With-Resources In Java

Adesola — Sat, 03 Oct 2026 18:04:50 +0000

Try-With-Resources in Java, Explained

If you've worked with files, streams, or database connections in Java, you've probably written something like this at some point:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class StoreApplication {
    public static void main(String[] args) throws IOException {
        int num = 0;
        BufferedReader br = null;
        try {
            System.out.println("Enter a Number: ");
            br = new BufferedReader(new InputStreamReader(System.in));
            num = Integer.parseInt(br.readLine());
            System.out.println("Number entered is " + num);
        } finally {
            if (br != null) {
                br.close();
            }
        }
    }
}

This works, but notice the ceremony required just to close a reader safely:

Declare the variable outside the try so it's visible in finally
Null-check it before closing (because the try might fail before br is ever assigned),
Remember to do this every single time you open a resource. Forget the null check, or forget close() altogether, and you've got a resource leak.

Java 7 introduced a cleaner way to handle exactly this pattern.

Try-with-resources

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class StoreApplication {
    public static void main(String[] args) throws IOException {
        int num = 0;

        try (BufferedReader br = new BufferedReader(new InputStreamReader(System.in))) {
            System.out.println("Enter a Number: ");
            num = Integer.parseInt(br.readLine());
            System.out.println("Number entered is " + num);
        }
    }
}

The resource is declared directly in the parentheses after try, and Java closes it automatically once the block finishes — whether it finishes normally or because an exception was thrown. No finally, no null check, no manual close() call.

Why this works: AutoCloseable

Try-with-resources isn't magic — it only works with types that implement the AutoCloseable interface (or its more specific subtype, Closeable, used by most I/O classes).

AutoCloseable defines a single method, close(), and the compiler generates the equivalent of the old try/finally pattern for you behind the scenes.

This also means you can make your own classes work with try-with-resources by implementing AutoCloseable yourself:

class Connection implements AutoCloseable {
    public void query(String sql) {
        System.out.println("Running: " + sql);
    }

    @Override
    public void close() {
        System.out.println("Connection closed.");
    }
}

public class StoreApplication {
    public static void main(String[] args) {
        try (Connection conn = new Connection()) {
            conn.query("SELECT * FROM users");
        }
        // "Connection closed." is printed automatically here
    }
}

Multiple resources

You can open more than one resource in the same try-with-resources statement, separated by semicolons:

try (
    BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
    Connection conn = new Connection()
) {
    // use both resources
}

Java closes them in reverse order of declaration — so in the example above, conn closes before reader. This matters when resources depend on each other (e.g., a statement that depends on a connection should close before the connection does).

The suppressed-exception problem it quietly fixes

Here's a subtle bug the manual finally pattern has: if the code inside try throws an exception, and close() in finally also throws, the exception from close() overwrites the original one — the real cause of the failure gets silently lost.

Try-with-resources handles this correctly: if both the resource body and close() throw, the body's exception is treated as the primary one, and the exception from close() is attached to it as a suppressed exception, retrievable via getSuppressed(). You don't lose either piece of information.

Java 9+: using an already-declared resource

If a resource variable is already declared and effectively final (never reassigned), you don't have to redeclare it inside the parentheses — you can just reference it:

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
try (br) {
    System.out.println("Number entered is " + br.readLine());
}

This is purely a convenience for cases where the resource is created earlier in the method.

Wrapping up

Try-with-resources is one of those features that looks like minor syntax sugar but actually removes a whole category of bugs: forgotten close() calls, missed null checks, and swallowed exceptions. If you're opening anything that needs closing — files, streams, sockets, database connections — reaching for try-with-resources by default is the safer habit.

Do you have a resource-leak war story from before you knew about this? Share it in the comments.

Exceptions in Java

Adesola — Sat, 03 Oct 2026 16:46:49 +0000

Exceptions in Java, Explained

Before we get to exceptions specifically, it helps to zoom out and look at the three kinds of errors you'll run into as a Java developer.

Three kinds of errors

Compile-time errors — usually caused by bad syntax. The code won't even build.
Logical errors — the code compiles and runs fine, but produces the wrong result because the logic is flawed, not the syntax.
Runtime errors — the code compiles fine, but something goes wrong while it's actually running, and execution breaks.

A classic example of a runtime problem: your application depends on a file, the file gets deleted from the server, and the moment your code tries to read it — crash. This is exactly the kind of situation exceptions exist to handle, so your application can respond gracefully instead of dying mid-execution.

Handling exceptions with try/catch

Arithmetic exception

public class StoreApplication {
    public static void main(String[] args) {
        int i = 45;
        int j = 0;

        try {
            int output = i / j;
            System.out.println("The result of the division: " + output);
        } catch (Exception e) {
            System.out.println("Execution could have stopped here due to this error: \"" + e.getMessage() + "\"");
        }

        System.out.println("Execution continues.");
    }
}

Array index out of bounds

public class StoreApplication {
    public static void main(String[] args) {
        int[] nums = new int[5]; // valid indices: 0 to 4

        try {
            System.out.println("array value at position one: " + nums[1]);
            System.out.println("array value at position five: " + nums[5]); // out of bounds
        } catch (Exception e) {
            System.out.println("Execution could have stopped here due to this error: \"" + e.getMessage() + "\"");
        }

        System.out.println("Execution continues.");
    }
}

Multiple catch blocks

You can catch different exception types separately, which lets you respond differently depending on what actually went wrong:

public class StoreApplication {
    public static void main(String[] args) {
        int i = 45;
        int j = 4;
        int[] nums = new int[5];

        try {
            int output = i / j;
            System.out.println("array value at position one: " + nums[1]);
            System.out.println("array value at position five: " + nums[5]);
            System.out.println("The result of the division: " + output);
        } catch (ArithmeticException e) {
            System.out.println("Arithmetic exception caught: \"" + e.getMessage() + "\"");
        } catch (IndexOutOfBoundsException e) {
            System.out.println("Index out of bounds exception caught: \"" + e.getMessage() + "\"");
        } catch (Exception e) {
            System.out.println("Some other exception caught: \"" + e.getMessage() + "\"");
        }

        System.out.println("Execution continues.");
    }
}

Important ordering rule: catch blocks are checked top to bottom, and only the first match runs. If you put the general Exception catch before the more specific ones, the specific catch blocks become unreachable — the compiler will actually flag this as an error, because Exception would already catch everything below it:

This won't compile — unreachable catch blocks

try {
    // ...
} catch (Exception e) {
    // this catches everything first
} catch (ArithmeticException e) {
    // unreachable
} catch (IndexOutOfBoundsException e) {
    // unreachable
}

The rule of thumb: most specific exception first, most general last.

Multi-catch shorthand

If two exception types should be handled identically, you don't need two blocks — Java lets you combine them with |:

try {
    // risky code
} catch (ArithmeticException | IndexOutOfBoundsException e) {
    System.out.println("Caught a numeric or bounds error: " + e.getMessage());
}

The Throwable hierarchy

Every error and exception in Java is a subclass of Throwable, which sits directly under Object. Throwable is a class, not an interface — it's unrelated to marker/functional interfaces like Cloneable, Runnable, or Serializable, even though the naming pattern looks similar at a glance.

Object
  └── Throwable
        ├── Error
        │     ├── IOError
        │     ├── ThreadDeath
        │     └── VirtualMachineError (e.g. OutOfMemoryError)
        │
        └── Exception
              ├── RuntimeException
              │     ├── ArithmeticException
              │     ├── IndexOutOfBoundsException
              │     │     └── ArrayIndexOutOfBoundsException
              │     └── NullPointerException
              │
              ├── SQLException
              └── IOException

Two branches matter most in day-to-day code:

Errors — things you generally can't recover from (like running out of memory). You typically don't catch these; when they happen, execution simply stops.
Exceptions — things you can and should handle, so your program keeps running.

Checked vs. unchecked exceptions

Unchecked exceptions are RuntimeException and everything under it (ArithmeticException, NullPointerException, etc.). The compiler doesn't force you to catch or declare them.

Checked exceptions are everything else under Exception (IOException, SQLException, etc.). The compiler does force you to either catch them or declare them with throws.

This leads us into a keyword distinction that's easy to mix up.

throw vs. throws

These look similar but do completely different jobs:

throw actually throws an exception instance, at the point where something goes wrong:

if (balance < amount) {
    throw new IllegalArgumentException("Insufficient balance");
}

throws goes in a method signature to declare that the method might throw a checked exception, so callers know they need to handle it:

public void readFile(String path) throws IOException {
    // ...
}

The finally block

A finally block runs whether or not an exception was thrown — it's the place for cleanup code (closing a connection, releasing a resource) that absolutely must happen either way:

try {
    int output = 45 / 0;
} catch (ArithmeticException e) {
    System.out.println("Caught: " + e.getMessage());
} finally {
    System.out.println("This always runs, exception or not.");
}

try-with-resources

For anything that needs closing (files, streams, connections), modern Java offers try-with-resources, which closes the resource automatically — no finally block needed:

try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"))) {
    System.out.println(reader.readLine());
} catch (IOException e) {
    System.out.println("Could not read file: " + e.getMessage());
}

Custom exceptions

Sometimes the built-in exceptions don't describe your problem well enough, and a custom exception communicates intent much more clearly than a generic one. To create one, extend Exception (for a checked exception) and pass the message up to the parent via super:

class InsufficientBalanceException extends Exception {
    public InsufficientBalanceException(String message) {
        super(message);
    }
}


public class BankAccount {
    private double balance = 100.0;

    public void withdraw(double amount) throws InsufficientBalanceException {
        if (amount > balance) {
            throw new InsufficientBalanceException("Cannot withdraw " + amount + ", balance is only " + balance);
        }
        balance -= amount;
    }

    public static void main(String[] args) {
        BankAccount account = new BankAccount();
        try {
            account.withdraw(150.0);
        } catch (InsufficientBalanceException e) {
            System.out.println("Transaction failed: " + e.getMessage());
        }
    }
}

If you want an unchecked custom exception instead — the one callers aren't forced to catch — extend RuntimeException instead of Exception, following the same pattern.

Wrapping up

Exceptions exist so your program can fail safely instead of failing silently or crashing outright. The real skill isn't just wrapping code in try/catch — it's knowing which exceptions are worth catching specifically, which ones should bubble up, and when a custom exception communicates your intent better than a generic one.

What's a tricky exception-handling bug you've run into? Share it in the comments.

Annotations, Functional Interfaces, and Lambdas in Java

Adesola — Mon, 28 Sep 2026 11:31:43 +0000

These three concepts build on each other more than they seem to at first glance: annotations give the compiler metadata to act on, one specific annotation (@FunctionalInterface) marks a particular kind of interface, and that kind of interface is exactly what makes lambda expressions possible. This post walks through all three, in that order.

Annotations

Metadata(s) for the compiler.

An annotation in Java is metadata attached to code — a class, method, field, or interface — that doesn't change what the code does, but gives instructions to the compiler, a tool, or the JVM about how to treat it. You've probably already used a few without thinking about it: @override, @deprecated, @SuppressWarnings.

@Override
public String toString() {
    return "example";
}

@override doesn't add behavior — it just tells the compiler "check that this method actually overrides something in the superclass, and fail if it doesn't." That's the general pattern: annotations are instructions about the code, not part of its logic.

One of the most useful annotations for modern Java is @FunctionalInterface, which brings us to the next concept.

Functional interfaces

A functional interface is an interface with exactly one abstract method. This single-method shape is also called a SAM interface — Single Abstract Method.

interface A {
    void show();
}

To make Java enforce that an interface stays this way, you annotate it:

@FunctionalInterface
interface A {
    void show();
}

Now, if a second abstract method sneaks in, it's going to give a compile-time error instead of a bug which you will see later:

@FunctionalInterface
interface A {
    void show();
    void play(); // compile error: not a functional interface anymore
}

Note that this restriction only applies to abstract methods. A functional interface can still have any number of default or static methods, since those already have a body and don't count toward the "single abstract method" rule:

@FunctionalInterface
interface A {
    void show();

    default void log() {
        System.out.println("Logging from A");
    }
}

Implementing a functional interface with an anonymous class

Before lambdas, this is what implementing a small interface inline looked like:

public class StoreApplication {
    public static void main(String[] args) {
        A obj = new A() {
            @Override
            public void show() {
                System.out.println("implementing interface directly....");
            }
        };

        obj.show();
    }
}

It works, but it's verbose for something this simple — which is exactly the problem lambda expressions were introduced to solve.

Lambda expressions

Functional interfaces are what make lambda expressions possible in Java 8+: since a functional interface guarantees there's exactly one method to implement, Java can let you skip the class name, the method name, and the boilerplate, and just write the method body.

Implementing a functional interface with a lambda

@FunctionalInterface
interface A {
    void show();
}

public class StoreApplication {
    public static void main(String[] args) {
        A obj = () -> System.out.println("implementing interface using lambda....");
        obj.show();
    }
}

Passing an argument via lambda

@FunctionalInterface
interface A {
    void show(int i);
}

public class StoreApplication {
    public static void main(String[] args) {
        A obj = (i) -> System.out.println("implementing interface using lambda...." + i);
        obj.show(45);
    }
}

A functional interface that returns a value


@FunctionalInterface
interface A {
    int add(int a, int b);
}

public class StoreApplication {
    public static void main(String[] args) {
        A calculator = (i, j) -> {
            System.out.println("Performing addition of numbers " + i + " and " + j);
            return i + j;
        };

        System.out.println("The sum is equal to " + calculator.add(45, 30));
    }
}

Same contract, same enforcement from @FunctionalInterface — just far less ceremony to implement it.

Types of interfaces, at a glance

Now that we've covered the functional/SAM interface in depth, it's worth placing it alongside the other interface types you'll run into:

Normal interface — two or more methods, no restrictions on count.

Functional / SAM interface — exactly one abstract method; can be
implemented with a lambda.

Marker interface — has no methods at all. It exists purely to "tag" a class with metadata that other code can check via instanceof, so the JVM or a framework can treat tagged classes differently. Serializable and Cloneable are the classic examples — implementing Serializable doesn't add any methods, but it tells the JVM "this object is allowed to be serialized."

That last one brings things full circle: marker interfaces were Java's original way of attaching metadata to a class before annotations existed. Today, annotations have largely taken over that role — which is exactly where this post started.

Wrapping up

Annotations give the compiler instructions, @FunctionalInterface uses that mechanism to enforce a single-method contract, and lambdas exist to make implementing that contract painless. Once you see the chain connecting them, a lot of modern Java code (streams, Comparator, Runnable, custom callbacks) starts making a lot more sense.

Got a favorite use of lambdas or functional interfaces in your own code? Drop it in the comments.

Enums in Java Explained

Adesola — Sat, 26 Sep 2026 17:17:20 +0000

Enums

When you create an enum in Java, the compiler treats it as a special kind of class. Each constant you define inside it is actually an object — an instance — of that class. In plain terms: enums are named constants with the full power of a class behind them.

enum Status {
    RUNNING, PENDING, FAILED, SUCCESS
}

Convention note: enum constants are conventionally written in UPPER_SNAKE_CASE (like RUNNING, not Running). It's not required by the compiler, but it's the style you'll see in almost all Java codebases and libraries.

How do we get the enum's position?
Short Answer: We get an enum constant's position with ordinal() method that the standard java library has made available.

Every enum constant knows its own position (starting at 0) in the order it was declared. You get that position with ordinal():

public class ApplicationController {
    public static void main(String[] args) {
        Status s = Status.RUNNING;
        System.out.println(s.ordinal()); // 0
    }
}

How do we access all the enum constants?

Short Answer: By Looping over every constant with values() method that the standard java library provides.

If you want all the constants defined in an enum, values() returns them as an array:

public class ApplicationController {
    public static void main(String[] args) {
        Status[] states = Status.values();
        for (Status state : states) {
            System.out.println("Status " + state + ": rank " + state.ordinal());
        }
    }
}

There's also a valueOf(String) method that does the reverse — it looks up a constant by its exact name:

Status s = Status.valueOf("RUNNING"); // Status.RUNNING

This throws an IllegalArgumentException if the string doesn't match any constant, so it's worth wrapping in a try/catch if the input is coming from outside your program (like user input or a config file).

Using enums in a switch

Enums work naturally with switch statements — note that you don't repeat the enum name in each case:

public class ApplicationController {
    public static void main(String[] args) {
        Status s = Status.RUNNING;
        switch (s) {
            case RUNNING:
                System.out.println("All Good");
                break;
            case PENDING:
                System.out.println("Please Wait");
                break;
            case FAILED:
                System.out.println("Try Again");
                break;
            default:
                System.out.println("Done");
        }
    }
}

Enums are classes — with limits

Since enums are compiled as classes, you can give them constructors, fields, and methods, just like any other class. The catch: every enum implicitly extends java.lang.Enum, and Java doesn't support multiple class inheritance. That means:

An enum can't extend any other class (it's already extending Enum).
No other class can extend an enum (enums are implicitly final).

Enums can, however, implement interfaces — that's the workaround when you need enum-like polymorphism.

Enum constructors in practice

enum Laptop {
    MAC(2000), LENOVO(1800), HEWLETT_PACKARD(1500), XPS(1200);

    private int price;

    Laptop(int price) {
        this.price = price;
    }

    public int getPrice() {
        return price;
    }

    public void setPrice(int price) {
        this.price = price;
    }
}

public class StoreApplication {
    public static void main(String[] args) {
        Laptop laptop = Laptop.MAC;
        System.out.println(laptop + " goes for N" + laptop.getPrice());

        for (Laptop eachLaptop : Laptop.values()) {
            System.out.println("This brand of laptop called " + eachLaptop
                    + " costs about " + eachLaptop.getPrice()
                    + ", and its name is " + eachLaptop.name());
        }
    }
}

One detail worth calling out: enum constructors are implicitly private. That's not optional — you'll never see public Laptop(int price) compile. It's exactly why you can write Laptop.MAC but can never write new Laptop(999) from outside the enum itself; the only instances that will ever exist are the ones declared in the enum body.

Wrapping up

Enums give you type-safe constants that can carry their own data and behavior — a big step up from using plain int or String constants scattered across a codebase. Once you start attaching fields and methods to them, they stop feeling like "just a list of options" and start feeling like proper domain objects.

Got a favorite enum trick or gotcha? Drop it in the comments.

Interfaces in Java, Explained

Adesola — Wed, 23 Sep 2026 14:36:43 +0000

An interface in Java is a blueprint of behavior — a contract that any implementing class agrees to fulfill. Interfaces are often used as an alternative (or complement) to abstract classes, especially since Java doesn't support multiple inheritance with classes but does allow a class to implement multiple interfaces.

In this post, we'll cover:

How fields behave inside an interface
How to implement an interface
Default and static methods (Java 8+)
When to reach for an interface vs. an abstract class

Fields in an interface

Any variable declared inside an interface is implicitly public, static, and final — effectively a constant. Because final variables must be initialized where they're declared, this won't compile:

interface A {
    String talk;
    int age;
    void show();
    void config();
}

This will:

interface A {
    String talk = "show me the way";
    int age = 90;
    void show();
    void config();
}

Implementing an interface

A class that implements an interface must provide concrete bodies for all of its abstract methods:

class B implements A {
    public void show() {
        System.out.println("Inside show method");
    }

    public void config() {
        System.out.println("Inside config method");
    }
}

Putting it together

public class ApplicationWorker {
    public static void main(String[] args) {
        A obj = new B();   // program to the interface
        obj.show();
        obj.config();
        System.out.println(obj.age); // 90 — inherited constant
    }
}

Notice obj is declared as type A but holds a B instance. That's the real payoff of interfaces: your code can depend on the contract (A) rather than a specific implementation (B), which makes it easy to swap implementations later without touching the calling code.

Default and static methods (Java 8+)

Older Java versions required every interface method to be abstract. Since Java 8, interfaces can also define default and static methods with actual bodies:

interface A {
    String talk = "show me the way";
    int age = 90;

    void show();
    void config();

    default void greet() {
        System.out.println("Hello from interface A");
    }

    static void info() {
        System.out.println("A is an interface with default behavior");
    }
}

A default method gives implementing classes a working fallback they can optionally override — useful for adding new methods to an interface without breaking every class that already implements it. A static method belongs to the interface itself and is called as A.info(), not through an instance.

Interface vs. abstract class: which one to use?

A quick decision rule:

Use an interface when you're defining a capability or contract that unrelated classes might share (e.g., Comparable, Runnable) — especially if a class might need to implement more than one.
Use an abstract class when you're modeling a clear "is-a" relationship and want to share common state (fields) or partially implemented behavior among closely related subclasses.

In practice, many modern Java designs favor interfaces for flexibility, using default methods to share common behavior when needed.

Wrapping up

Interfaces let you separate what something does from how it does it. That separation is what makes code built around interfaces easier to test, extend, and swap out over time.

If you found this useful, let me know in the comments — and feel free to share other Java interface gotchas you've run into!

I started working on a trading application using Java. There are things that i started picking up along the way. I hope to start sharing them as i journey further... Java beginnings

Adesola — Tue, 15 Sep 2026 09:13:35 +0000