- Which explanation is most consistent with all of the facts?
Answer: The IDE uses its bundled JDK for compilation, while the terminal finds only a runtime or lacks the JDK path
Whenever you see a question mixing IDE behavior with command-line Java tools, think about the distinction between a JDK (Java Development Kit, which includes the compiler javac) and a JRE (Java Runtime Environment, which only runs compiled bytecode). IDEs often ship with their own bundled JDK, completely independent of whatever your system's PATH variable points to.
That's exactly what's happening here. The IDE succeeds because it uses its own internal JDK for both compilation and execution — no system PATH needed. In the terminal, java works because a JRE (or a JDK's runtime component) is accessible on the system PATH, but javac fails because the full JDK's bin directory isn't included in that PATH. This makes B the explanation that fits every clue in the passage without contradiction.
A has it backwards. The IDE isn't outsourcing compilation to the system — the passage explicitly says the IDE operates independently of system environment variables. Suggesting the IDE uses the system JRE for compiling misreads both how IDEs work and what the passage states.
C is a fundamental misconception. Java always compiles source code into bytecode (.class files) first, then the JVM interprets or JIT-compiles that bytecode. No mainstream Java IDE skips javac to produce native machine code directly.
D describes a fictional behavior. There is no mechanism by which an IDE opening on your machine disables javac in a separate terminal. These processes are entirely independent.
As a study tip: remember that java ≠ javac. If only java works, you have a runtime but likely no compiler on your PATH — a classic JRE-vs-JDK distinction question.
- Which conclusion is best supported by this observation?
Answer: The current command environment can find a Java runtime but cannot find the Java compiler
When troubleshooting a Java environment, the key distinction to keep in mind is between the JRE (Java Runtime Environment) and the JDK (Java Development Kit). The JRE contains the java launcher, which runs compiled bytecode. The JDK contains both the runtime and javac, the compiler that turns .java source files into bytecode. They are separate tools, and a system can have one without the other.
Here, java -version works but javac -version fails. This tells you exactly one thing with certainty: the current shell's PATH can locate a Java runtime but cannot locate the compiler. That's precisely what B states, making it the best-supported conclusion — it describes only what the evidence shows, nothing more.
A is too absolute. While a JDK does include javac, it's possible a JDK is installed but its bin directory simply isn't on the PATH. You can't conclude from a missing command that the program doesn't exist on the machine at all.
C is factually wrong. java and javac are entirely separate executables with different purposes — one runs programs, the other compiles them.
D is also wrong. A JRE with no compiler is not defective — it's designed that way. End-users only need the runtime; developers need the full JDK. Lacking javac is expected in a JRE-only install.
A useful rule of thumb: command-not-found errors tell you about PATH visibility, not necessarily about what's physically installed. On the exam, watch for questions that conflate "not on PATH" with "not installed."
- Which statement best describes the roles of the JDK and the generated image?
Answer: The JDK is needed to create the image, while the target system can execute the application using only the resulting runtime image
When you see a question about Java module system tooling and deployment, think about the jlink tool and how Java's module system separates build-time concerns from runtime concerns.
The jlink tool, bundled with the JDK, lets you assemble a custom runtime image containing only the modules your application actually needs — including a functional, stripped-down JVM. This image is entirely self-contained: it can launch and execute your application on a target system without any additional Java installation. That's exactly what D describes — the JDK is required on the developer/build machine to run jlink and produce the image, but the target machine only needs the resulting image to run the application.
A is wrong because image-building tools like jlink are not bundled with standard runtime environments (JREs) — they live in the JDK. You can't create a custom runtime image without the JDK's tooling.
B is wrong on two counts: the generated image is not a source compiler, and the target does not need a separate JRE. The image already includes its own JVM, so bytecode execution is handled internally by the image itself.
C is wrong because it contradicts the core purpose of jlink. The generated runtime image does include a functional JVM component — that's the whole point. Requiring the full JDK on the target would defeat the purpose of creating a reduced image in the first place.
As a study tip, remember: JDK builds, image runs. The JDK is a build-time tool; jlink images are self-sufficient deployment artifacts.
- Why can the second computer execute the application without installing the original developer's JDK?
Answer: The first JDK produced platform-oriented bytecode that a compatible runtime on the second computer can interpret or compile
When you see a question about Java portability, you should immediately think about the "write once, run anywhere" principle — the cornerstone of Java's design. The key is understanding what a JDK actually produces and what happens at runtime on another machine.
Java source code is compiled into bytecode, stored in .class files. Bytecode is not native machine code for any specific operating system — it's a neutral, intermediate instruction set designed for the Java Virtual Machine (JVM). When the second computer runs those class files, its JVM (part of the JRE or JDK) either interprets or JIT-compiles that bytecode into the native instructions its own OS understands. This is exactly what A describes, making it correct: the first JDK produced platform-neutral bytecode, and a compatible runtime on the second machine handles execution.
B is wrong because JDKs do not embed a compiler inside each class file. Class files contain bytecode, not a compiler. Compilation already happened — the .class file is the result of compilation, not a self-compiling artifact.
C is wrong because class files are not converted back into source code. Decompilation is theoretically possible but is not how Java execution works, and the OS itself has no built-in Java source compiler.
D is wrong because the two operating systems do not share identical native instructions — that's precisely the problem Java's bytecode model solves. A JVM is absolutely required.
Study tip: Remember the two-step model: JDK compiles source → bytecode; JVM executes bytecode. Questions about Java portability almost always hinge on the role of bytecode as the platform-independent middle layer.
- Which assessment of the proposal is most accurate?
Answer: It is unlikely to solve the failure because a JDK adds development tools, not arbitrary application dependencies
When you see a question about JDKs, JREs, and runtime failures, anchor yourself to one key distinction: what each component actually provides. A JRE (Java Runtime Environment) executes compiled Java programs. A JDK (Java Development Kit) bundles a JRE plus development tools like the compiler (javac), debugger, and documentation generator. Neither package includes third-party libraries — those are external dependencies that developers must supply separately, typically through build tools like Maven or Gradle.
That's why B is correct. The missing database driver is a third-party dependency (think JDBC drivers like MySQL Connector or PostgreSQL's driver). Swapping the runtime for a JDK adds javac and other dev tools, but it does absolutely nothing to supply that missing driver. The root cause — an absent JAR on the classpath — remains completely unaddressed.
A reflects a common misconception: the JDK is a curated toolkit for Java development, not a repository for every library ever written in Java. It ships with the Java standard library, not third-party packages. C describes something that simply doesn't exist — the Java compiler has no mechanism to automatically download missing classes at runtime; that's not how the JVM classloading or compilation model works. D is the opposite trap — it overcorrects by claiming a JDK has no runtime capabilities, when in fact a JDK includes a full JRE and absolutely can run programs.
As a study tip, remember: JDK = JRE + dev tools. Any question about missing dependencies points to classpath/build configuration issues, not which Java environment variant you're running.
- Which installation is the minimum conceptual requirement for the deployment machine?
Answer: A compatible JRE, because execution requires the JVM and runtime libraries but not compilation tools
When you see a question about Java deployment requirements, focus on the distinction between the three core Java components: the JDK, JRE, and JVM. Ask yourself what tasks actually need to happen on that machine.
Running a pre-compiled JAR file requires two things: a virtual machine to interpret and execute bytecode, and the standard runtime libraries (like java.lang, java.io, etc.) that the application's classes depend on at runtime. Together, the JVM plus those libraries is exactly what a JRE (Java Runtime Environment) provides — making C the correct minimum requirement for a deployment-only machine.
A is wrong because the JDK (Java Development Kit) is a superset that includes the JRE plus development tools like the compiler (javac), javadoc, and jar. The scenario explicitly states the machine will never compile, document, or package anything, so installing a JDK would provide unnecessary tools — it satisfies the requirement, but it is not the minimum.
B is tempting but subtly incorrect. A bare JVM alone cannot run most real-world Java applications because those apps rely on the standard library classes bundled with the JRE. Without those runtime libraries, even a simple System.out.println() call would fail. The JVM executes bytecode; it doesn't bundle the libraries itself.
D is a fundamental misconception. The JVM executes bytecode (.class files), not source code. Java source is not recompiled at startup — that's not how the platform works at all.
A handy mental hierarchy to memorize: JDK ⊃ JRE ⊃ JVM. On exam questions, match the minimum component to the minimum task required.
- Which allocation of Java software best matches the responsibilities of the two servers?
Answer: Install a JDK on the integration server and a compatible runtime environment on the production server
When you see a question about Java deployment environments, the key distinction to understand is the difference between the JDK (Java Development Kit) and the JRE/JVM (Java Runtime Environment/Virtual Machine). The JDK bundles everything in the JRE plus development tools like the javac compiler, debugger, and profiler. The JRE contains only what's needed to run already-compiled bytecode.
Answer D is correct because it maps each server's responsibilities to the right toolset. The integration server compiles source code (needs javac) and runs tests (needs a full JDK). The production server only launches the pre-built artifact — compiled .class files or a JAR/WAR — so a runtime environment (JRE or a modern JDK used as a runtime) is all it needs. This approach also follows the security principle of minimal footprint: don't install tools on production that aren't required.
Answer A gets it exactly backwards — putting a JRE on the server that must compile code means javac won't be available, and the integration server would immediately fail at its core task.
Answer B is wrong because a standalone JVM cannot run Java applications without the supporting class libraries that the JRE provides. The artifact itself doesn't bundle the entire Java standard library.
Answer C reflects a common misconception: once source code is compiled, the resulting bytecode has **no dependency on javac**. The compiler is a build-time tool, not a runtime requirement.
A handy rule of thumb: "Build with JDK, run with JRE." Whenever a server's only job is executing code, a runtime environment is sufficient — reserve the full JDK for wherever compilation happens.
- Which correction most accurately explains their conceptual relationship?
Answer: The JVM executes bytecode; the JRE adds runtime libraries and support; the JDK adds development tools on top of that
When working with Java infrastructure questions, think in layers: each component builds on the previous one, forming a clear hierarchy rather than interchangeable synonyms.
At the foundation sits the JVM (Java Virtual Machine) — its sole job is executing bytecode at runtime, abstracting away the underlying operating system. On top of that, the JRE (Java Runtime Environment) packages the JVM together with the standard class libraries and other files needed to run Java applications. Finally, the JDK (Java Development Kit) wraps everything in the JRE and adds development-specific tools: the javac compiler, debugger, and documentation utilities. This nesting is exactly what answer A describes, making it correct.
Answer B scrambles the roles entirely — the JRE does not compile source code (that's the JDK's javac compiler), and the JVM has nothing to do with packaging archives or managing OS updates. Answer C inverts reality: the JDK does not execute bytecode (the JVM does), and no component "generates source files from class files" as a standard function — that would be decompilation, which isn't part of any of these tools' core purposes. Answer D is wrong on both counts: the JVM and JDK are not interchangeable runtime options (the JDK is a superset for developers), and the JRE is used for running programs, not compiling them.
A helpful memory trick: JVM ⊂ JRE ⊂ JDK — each symbol represents containment. If you need to only run Java, install the JRE; if you need to develop Java, install the JDK and you get everything automatically.
- Which statement correctly distinguishes the software needed on the two machines?
Answer: The first machine needs a JDK for development tools, while the second needs only a compatible runtime
When you see a question about Java development environments, anchor your thinking around this hierarchy: the JVM runs bytecode, the JRE bundles the JVM with core libraries for execution, and the JDK bundles everything in the JRE plus development tools like javac (compiler), javadoc (documentation generator), and jar (packaging utility).
The first machine in this scenario does three things: compiles source files, generates API docs, and packages a JAR — all tasks requiring JDK-specific tools. The second machine only runs the finished JAR, which requires nothing beyond a compatible runtime environment (a JRE or modern JDK acting as one). That makes C correct: the first machine needs a JDK for its development tools, and the second needs only a compatible runtime.
A is wrong because executing a JAR does not invoke the compiler or documentation generator — those tools are only used during development, not at runtime. This confuses the build phase with the execution phase.
B reverses the requirements entirely. The first machine (doing development) needs the JDK, not just a JRE. The second machine needs a runtime to run the JAR — it has no need to "unpack" it with a JDK, which isn't even what a JDK does anyway.
D is wrong because compilation, documentation generation, and packaging are not JVM instructions. The JVM only interprets or JIT-compiles bytecode at runtime; javac, javadoc, and jar are separate command-line tools that live in the JDK.
A useful mental shortcut: develop → JDK, deploy → JRE. If a machine's job involves writing or building code, it needs a JDK.
- Which change most directly addresses the failure without changing the project source?
Answer: Point the build tool to the installed JDK so it can access both runtime support and compilation tools
When troubleshooting Java build failures, the key distinction to understand is the difference between a JRE (Java Runtime Environment) and a JDK (Java Development Kit). A JRE contains only what's needed to run compiled Java bytecode — the java launcher, libraries, and the JVM. A JDK includes everything in the JRE plus the compiler (javac) and other development tools. Build tools like Maven or Gradle need the JDK specifically because they must compile .java source files into bytecode before execution.
In this scenario, JAVA_HOME points to a JRE, so the build tool finds a valid runtime but no javac compiler — exactly the reported failure. The fix is straightforward: redirect JAVA_HOME to the JDK installation. That's why A is correct. It gives the build tool access to both the runtime and the compilation tools it needs, resolving the issue without touching any source code.
B is dangerously wrong — renaming java to javac doesn't add compiler functionality; it just mislabels the launcher. The binary itself cannot compile source code regardless of its name. C is a misconception: multiple Java installations coexist peacefully on a system and do not interfere with each other's execution. The JVM reads bytecode independently of other installations. D misunderstands the compilation pipeline — a JAR typically contains compiled .class files, not raw source. You can't skip compilation by packaging source files into a JAR and expect a runtime to execute them.
As a study tip, whenever you see Java environment questions, immediately ask yourself: does this task require the JDK or just a JRE? Compilation always requires the JDK.
