JDK, JRE, JVM & the main Method — Interview Questions

How to use this lesson

These are the questions that open almost every Java interview. They sound easy, which is exactly why interviewers use them: a vague answer here sets a weak tone for the rest of the conversation. For each question, lead with the short answer, then add the key points if the interviewer wants more. The Learn it in depth links go to the full lessons on each topic.

Q1. What is Java?

Short answer (say this first): Java is a high-level, class-based, object-oriented programming language. Its source code compiles to platform-neutral bytecode, which runs on any machine that has a Java Virtual Machine. That is the "write once, run anywhere" promise.

Key points to cover:

• It's statically typed, and memory is managed automatically by a garbage collector.
• It's used for backend services (Spring Boot), Android apps, big-data tools (Kafka, Spark, Hadoop), and desktop and enterprise systems.
• Java is both a language and a platform: the JVM, plus a large standard library.
• It's designed to have as few implementation dependencies as possible. Your code depends on the JVM, not on the operating system.

Learn it in depth → Classes and Objects

Q2. What are the main features of Java?

Short answer: Platform independence, object orientation, automatic memory management, strong type safety and security, built-in multithreading, and a rich standard library.

Key points to cover:

• Platform independent: compiled once to bytecode, and run on any JVM.
• Object-oriented: classes, inheritance, polymorphism, encapsulation and abstraction.
• Robust: garbage collection (no manual free), no raw pointer arithmetic, checked exceptions, and array bounds checks.
• Secure: bytecode verification, no direct memory access, and a strong type system.
• Multithreaded: threads and concurrency utilities are part of the core library.
• High performance for a managed language: the JIT compiler turns hot bytecode into optimised machine code at runtime.
• Simple (relative to C++): no operator overloading, no multiple class inheritance, and no header files.

Common trap: calling Java "interpreted". Modern JVMs interpret bytecode at first, then JIT-compile frequently used code to native code. That's why long-running Java services perform well.

Q3. What is the JVM, and why is it important?

Short answer: The Java Virtual Machine is the runtime engine that loads, verifies and executes Java bytecode. It's what makes Java platform independent: the bytecode is the same everywhere, and each operating system gets its own JVM implementation.

Key points to cover:

• The JVM provides memory management (heap, stacks, garbage collection), security checks, and the JIT compiler.
• The JVM itself is platform dependent. There are different builds for Windows, Linux and macOS. Your bytecode is not platform dependent.
• It runs other JVM languages too: Kotlin, Scala and Groovy all compile to the same bytecode.

Learn it in depth → JVM Memory Areas

Q4. What is the difference between JDK, JRE and JVM?

Short answer: The JVM runs bytecode. The JRE is the JVM plus the standard class libraries, which is everything needed to run Java programs. The JDK is the JRE plus development tools (javac, jar, javadoc, jdb, jshell), which is everything needed to build them.

Key points to cover:

• A useful picture: JDK ⊃ JRE ⊃ JVM.

Common trap: saying you still download a separate JRE. Since Java 11, Oracle and most vendors ship only the JDK. For deployment, you create a trimmed runtime with jlink, or use a JRE-style base image from a vendor such as Eclipse Temurin.

Learn it in depth → JVM Memory Areas

Q5. What are the key components of the JVM architecture?

Short answer: Three main parts: the class loader subsystem, the runtime data areas, and the execution engine.

Key points to cover:

• Class loader subsystem: loads .class files. It has three phases:
  • Loading: the bootstrap, platform and application class loaders find the class.
  • Linking: the bytecode is verified, memory is prepared for static fields, and references are resolved.
  • Initialisation: static initialisers run.
• Runtime data areas:
  • Heap: objects, shared by all threads.
  • Method area / Metaspace: class metadata and the runtime constant pool.
  • Per-thread Java stacks: frames holding local variables.
  • PC registers.
  • Native method stacks.
• Execution engine:
  • The interpreter.
  • The JIT compiler (C1/C2 in HotSpot), which compiles hot methods to native code.
  • The garbage collector.
• The Java Native Interface (JNI) and native libraries let Java call C/C++ code.

Common trap: saying "the heap is per thread". The heap and method area are shared. Stacks, PC registers and native stacks are per thread.

Learn it in depth → JVM Memory Areas

Q6. Can a Java application run without a JRE installed?

Short answer: It always needs a Java runtime, but that runtime doesn't have to be installed system-wide. You can bundle a runtime with the application.

Key points to cover:

• jlink (Java 9+) builds a custom, trimmed runtime that contains only the modules your app uses. It's often a fraction of the full JDK's size.
• jpackage (Java 14+) wraps the app and its runtime into a native installer (.msi, .dmg, .deb).
• GraalVM Native Image compiles the app ahead of time into a standalone native executable. It needs no JVM at runtime, at the cost of some dynamic features such as unrestricted reflection.
• In containers, the runtime ships inside the image, so the host needs nothing.

Q7. Is it possible to have a JDK installed without a JRE?

Short answer: No. Every JDK includes a full Java runtime, because the development tools themselves (javac, for example) are Java programs that need it.

Key points to cover:

• Up to Java 8, the JDK contained a visible jre/ folder.
• Since Java 9's module system, the JDK has no separate jre directory. The runtime is built into the JDK's modules, but it's still there.
• The reverse is possible: a runtime-only installation, or a jlink image, has no compiler.

Q8. Explain public static void main(String[] args).

Short answer: It's the entry point the JVM looks for when you launch a class. Each keyword has a reason:

• public: the JVM launcher must be able to call it from outside the class.
• static: the JVM can call it without creating an object first.
• void: it returns nothing. To report an exit status, use System.exit(code).
• main: the name the launcher searches for.
• String[] args: the command-line arguments. String... args (varargs) is also accepted.

public class Greeter {
    public static void main(String[] args) {
        String name = args.length > 0 ? args[0] : "world";
        System.out.println("Hello, " + name);   // java Greeter Asha → Hello, Asha
    }
}

Key points to cover:

• The order of modifiers can vary (static public void main is legal).
• final and synchronized are allowed on it too.
• The parameter name doesn't matter: String[] argv works.
• Java 25 (JEP 512) made instance main methods and compact source files standard. A simple program can now be just void main() { IO.println("Hi"); }. The launcher still prefers the classic static main(String[]) when it exists.

Learn it in depth → Classes and Objects

Q9. What happens if main is not declared static?

Short answer: Up to Java 20, the class compiles, but launching it fails with the error "Main method is not static in class X, please define the main method as: public static void main(String[] args)". The JVM had no object to call a non-static method on.

Key points to cover:

• It's a runtime (launch) error, not a compile error. A non-static method called main is perfectly legal Java.
• Java 21–24 allowed instance main methods as a preview feature, and Java 25 made them standard. The launcher creates an instance, using a non-private no-argument constructor, and calls main() on it.
• In an interview, give the classic answer first, then mention the Java 25 change. It shows you track the language.

Q10. Can we override the main method?

Short answer: Not in the true sense, because static methods aren't overridden. A subclass can declare its own static main, but that hides the parent's method; it doesn't override it.

Key points to cover:

• Overriding means runtime dispatch based on the object's type. Static methods are resolved at compile time by the class name, so there's no dynamic dispatch.
• If you launch java Child, the JVM runs Child.main. If you launch java Parent, it runs Parent.main. Each class's main is independent.
• The @Override annotation on a static method is a compile error. That's a quick way to prove the point.

Learn it in depth → Inheritance and Polymorphism

Q11. Can we overload the main method?

Short answer: Yes. main is an ordinary static method, so you can declare other main methods with different parameter lists.

public class App {
    public static void main(String[] args) {
        System.out.println("launcher entry point");
        main(42);                               // call the overload yourself
    }
    public static void main(int code) {
        System.out.println("overload called with " + code);
    }
}

Q12. Will the JVM execute an overloaded main method?

Short answer: No. The launcher calls only the entry-point signature, main(String[] args). The overloads run only if your code calls them.

Key points to cover:

• With Java 25's launch protocol, a main() with no parameters is also a valid entry point. If both main(String[]) and main() exist, the launcher picks main(String[]).

Q13. Can we print something to the console without a main method?

Short answer: Not in modern Java. Up to Java 6, you could print from a static initialiser block, which ran when the class loaded, before the launcher complained about the missing main. Since Java 7, the launcher checks for main before initialising the class, so the program fails with "Main method not found" and the static block never runs.

public class NoMain {
    static {
        System.out.println("printed on Java 6 only");
        // Java 6: printed, then an error unless you call System.exit(0) here
        // Java 7+: "Error: Main method not found in class NoMain" and nothing is printed
    }
}

Common trap: the widely repeated answer "it worked until Java 8" is wrong. The change came in Java 7. And since Java 25, the honest modern answer is that you don't need the classic main at all: a compact source file with void main() does the job.

Follow-up questions this topic invites — and their answers

Q: If bytecode is platform independent, why do we need different JDK downloads per OS? A: The JVM, and the native parts of the runtime, are written for a specific operating system and CPU. The bytecode is the same everywhere; the program that runs it isn't.

Q: What's the difference between the JIT compiler and javac? A: javac compiles .java source to bytecode ahead of time. The JIT compiler runs inside the JVM, and turns frequently executed bytecode into optimised native machine code while the program runs, using runtime profiling information that javac never has.

Q: What does the bytecode verifier protect against? A: It checks that loaded bytecode is well formed and type safe before it runs. That means no stack overflows or underflows within a frame, no treating an int as an object reference, and no jumping into the middle of an instruction. This matters because class files can come from untrusted sources.

Q: Which class loaders exist, and what is parent delegation? A: The bootstrap loader (core classes), the platform loader (other Java SE modules), and the application loader (your classpath). A loader first asks its parent to load a class, and only loads it itself if the parent can't. That stops application code from replacing core classes such as java.lang.String.

Q: How do you pass arguments to main in an IDE or with Maven? A: From the command line: java MyApp a b c. In an IDE, set them in the run configuration's "Program arguments". With Maven's exec plugin: mvn exec:java -Dexec.args="a b c". With Spring Boot: mvn spring-boot:run -Dspring-boot.run.arguments="--port=9000".