RiaChoi Text Logo.
Method Order in Java VS JavaScript

Java

JavaScript

Method Order in Java VS JavaScript

Small discovery while switching from JavaScript to Java

Ria ChoiAugust 28th, 2026

Why Java Doesn't Care About Method Order (But JavaScript Sometimes Does)

I learned JavaScript first. So when I started writing Java, I had a habit.

I always defined a function before I used it.

Then one day, while working on an order processing class in Java, I called a private method near the top of my class, even though I hadn't written that method yet.

I expected an error. Instead, the code compiled fine and ran perfectly.

That small surprise sent me down a rabbit hole.

Why does Java allow this, while JavaScript sometimes punishes you for the exact same thing?

Java Reads the Whole Class First

When you compile a Java file, the compiler doesn't read your code line by line like a story. It scans the entire class first, builds a map of every method that exists, and only then translates everything into bytecode.

 

✏️ Side note:

I added the cards below to explain, step by step, how Java compiles code. It's not too technical, so anyone should be able to follow along.

java_compiler
How Java Works

The reason I included these cards is that I wanted to pin down exactly when method mapping happens: it happens at the beginning of symbol table construction.

 

This means that by the time your code actually runs, Java already knows every method in the class. It doesn't matter if a method is defined above or below where it's called.

public class OrderSagaOrchestrator {
    public void executeOrderSaga() {
        compensateOrder(1L); // calling a method defined below. Totally fine.
    }

    private void compensateOrder(Long orderId) {
        // implementation here
    }
}

To the compiler, this class has two methods. Their order on the page is irrelevant.

 

JavaScript Is a Little More Complicated

JavaScript doesn’t work the same way, and the answer actually depends on how you write your function.

Function Declarations Get Hoisted

If you use a regular function declaration, JavaScript moves it to the top of its scope before running anything.
This is called hoisting.

I was taught that the concept of hoisting is very important when first learning JavaScript. I still do memorize the concept in one to two sentences just in case an interviewer might ask me the question.

sayHello(); // works fine, prints "Hello"

function sayHello() {
    console.log("Hello");
}

So in this case, order really doesn’t matter either.

 

Function Expressions Do Not

But if you write the same function using const and an arrow function, the behavior changes completely.

sayHello(); // ReferenceError: Cannot access 'sayHello' before initialization

const sayHello = () => {
    console.log("Hello");
};

The variable name is hoisted, but its value isn’t assigned until the line actually runs. Call it too early, and JavaScript throws an error.

This is actually a very important part of understanding hoisting.

 

The Difference

Java’s compiler builds something like a table of contents before touching your logic. JavaScript, on the other hand, mostly just starts reading your file from top to bottom, with a few special exceptions.

 

The Convention: Putting Public Methods First

Let’s see this code example.

I used this code to demonstrate the Orchestrated Saga pattern from my previous post.

public class OrderSagaOrchestrator {

    public void executeOrderSaga() {

        compensateOrder(1L); 

    }

    private void compensateOrder(Long orderId) {

        // ...

    }

}

The answer has nothing to do with compilation.

It’s about readability.

When someone opens your class, they usually want to understand what it does before they care about how it does it.

Public methods represent your class’s API, the part other developers actually interact with.

Private methods are implementation details, the kind of thing you only dig into when you need to.

 

This pattern even has a name.

It’s called the “Step Down Rule”, popularized by Robert Martin’s Clean Code.

The idea is simple:

As you read down the file, the level of abstraction should get lower.

High level logic first, detailed implementation later.

 

So placing compensateOrder below executeOrderSaga isn’t a technical requirement.

It’s a courtesy to whoever reads your code next, including future you.

 

Takeaway

If you’re coming from JavaScript like I was, it’s easy to assume every language treats function order the same way.

Once you understand that Java compiles the entire class before running anything, the mystery disappears.

And once you understand hoisting in JavaScript, you’ll stop getting surprised by the opposite problem too.

 

Share

Related contents