- Which statement best describes the command and the required correction?
Answer: Only app is searched; use java -cp app:/shared/classes demo.App.
When working with Java's classpath, the most important rule to internalize is this: **-cp (or -classpath) completely replaces CLASSPATH** — it does not add to it. The JVM searches only the locations you explicitly provide to the running command.
In this scenario, java -cp app demo.App tells the JVM to search only the app directory. Even though CLASSPATH=/shared/classes is set in the environment, that variable is entirely ignored once -cp is specified. So demo.App will be found in app/demo/App.class, but when the JVM tries to load common.Helper, it won't look in /shared/classes — and the program will fail with a ClassNotFoundException. The fix is to include both locations explicitly: java -cp app:/shared/classes demo.App (colon-separated on Unix). That makes D correct.
A is wrong because it describes behavior that doesn't exist — -cp never appends to or merges with CLASSPATH. They are mutually exclusive. B is wrong because one location is searched (app), and copying everything into the current directory is neither the only fix nor a good practice. C has the logic completely backwards — removing -cp app would restore CLASSPATH as the source, meaning only /shared/classes would be searched, which would then lose access to demo.App. That's the opposite of solving the problem.
A reliable study tip: whenever you see -cp on the command line, mentally cross out any CLASSPATH environment variable — it's as if it doesn't exist. You must list every directory or JAR the application needs, separated by : on Unix or ; on Windows.
- Which change most directly allows the application to find both
App and Service at runtime? Answer: Launch with java -cp out:lib/api.jar client.App.
When running a Java application, the JVM needs to locate every class referenced at runtime — not just your main class, but every dependency it uses. The -cp (classpath) flag tells the JVM where to look, and on Unix-like systems, you separate multiple locations with a colon (:).
In this scenario, App.class lives in out/, and api.Service lives inside lib/api.jar. The original launch command java -cp out client.App only tells the JVM to look in out/, so when App immediately tries to use api.Service, the JVM can't find it and throws a ClassNotFoundException. The fix is to include both locations in the classpath.
A is correct because java -cp out:lib/api.jar client.App gives the JVM both search locations — out/ for App.class and lib/api.jar for api.Service. This directly solves the runtime resolution problem.
B fails because it only includes lib/api.jar in the classpath, dropping out/ entirely. Now the JVM can find api.Service but can't find client.App itself — you've just swapped which class is missing.
C is nonsensical: -d specifies the output directory for compiled .class files. You can't use a .jar file as a compilation output directory; javac would reject this. Also, recompilation doesn't affect runtime classpath issues.
D doesn't help because classpath resolution depends on the -cp flag, not physical file proximity. Placing App.class next to api.jar changes nothing unless the classpath is also corrected.
Remember: always audit your runtime -cp separately from your compile-time -cp — they must both include every dependency your code touches.
- What does the application print when launched with
java -cp app:old:new demo.App? Answer: It prints old because the first matching classpath entry supplies the class.
When a question involves duplicate classes on the classpath, the key concept to focus on is how Java's bootstrap class-loading mechanism resolves conflicts: it uses a first-found wins strategy.
The URLClassLoader (which backs the application class loader) iterates through classpath entries in the exact order they appear after -cp. The moment it locates a class that matches the requested binary name, it loads that version and stops searching. In this case, old appears before new in app:old:new, so config/Version.class is found under old first, and "old" is printed. A is correct.
B is wrong because Java does not behave like a linker that lets later entries override earlier ones. Once a class is loaded and cached in the class loader, the same binary name is never resolved again. The new directory is simply never consulted for config.Version.
C is wrong because duplicate binary names on the classpath are not prohibited. Java silently ignores the shadowed copies — no exception is thrown, no warning is issued. This is a deliberate (if sometimes dangerous) design decision.
D is wrong because the classpath is an ordered list, not a set of equal-priority entries. There is nothing unpredictable here; the result is fully deterministic based on declaration order.
A useful study tip: whenever you see a -cp or CLASSPATH question involving duplicate classes, mentally scan left-to-right and mark the first entry containing the class — that is always the winner under the standard application class loader.
- Which command uses a classpath wildcard while still including all required class locations?
Answer: java -cp "app:lib/*:lib/classes" demo.Main
When working with the Java -cp (classpath) flag, you need to understand exactly what each path notation does. A wildcard (*) in Java classpaths matches JAR files only within a directory — it does not recursively include subdirectories or loose .class files in subdirectories.
In this scenario, you have two distinct locations that must be on the classpath: lib/alpha.jar (a JAR inside lib/) and lib/classes (a directory of .class files). You also need app/ for Main.class. The challenge is including all three efficiently.
Option D, java -cp "app:lib/*:lib/classes" demo.Main, is the correct answer. lib/* expands to match all JARs in lib/ (picking up alpha.jar), and lib/classes explicitly adds the class directory. Together, all three required locations are covered.
Option A (app:lib/*) fails because lib/* only matches JARs directly inside lib/ — it does not descend into lib/classes to pick up .class files there. The wildcard is not recursive.
Option B (app:lib/classes/*) makes the opposite mistake: it applies the wildcard to lib/classes, looking for JARs there, but completely misses lib/alpha.jar in the parent lib/ directory.
Option C (app:lib) adds lib as a plain directory, which tells the JVM to look for .class files directly in lib/ — it does not load JARs or traverse into lib/classes. Both alpha.jar and the classes directory would be missed.
A useful rule of thumb: when you see a wildcard question, ask yourself "does this cover JARs and loose class directories separately?" If either is missing, the classpath is incomplete.
- Which command correctly launches
Tool? Answer: java -cp libs/tools.jar p.q.Tool
When launching a Java class from the command line, the two most important things to get right are: (1) how you specify the classpath, and (2) how you name the class. These details trip up many developers, so let's break them down carefully.
The -cp flag tells the JVM where to look for compiled classes. When your class lives inside a JAR file, you must point -cp directly at the JAR file itself — not at the folder containing it. Once the classpath is set, you identify the class using its fully qualified binary name, which uses dots as separators (matching the package declaration), not slashes. So the correct invocation is java -cp libs/tools.jar p.q.Tool — option C.
Option A fails because -cp libs points to the directory, not the JAR inside it. The JVM scans directories for .class files directly, but won't automatically open JAR files sitting inside them — you must name the JAR explicitly.
Option B uses -jar, which tells the JVM to run a self-executable JAR and ignores any additional arguments as class names. More importantly, -jar requires a Main-Class entry in the manifest — which the passage explicitly says is missing — so this would throw an error.
Option D has the right classpath but names the class as p/q/Tool, using slashes instead of dots. The JVM expects the canonical class name with dot notation; the slash style is a filesystem path, not a class identifier.
A handy rule: **JAR on classpath → dot-separated class name. No manifest → no -jar.**
- What is the result of running
javac -d out src/misc/Report.java? Answer: Compilation succeeds and writes out/org/audit/Report.class based on the package.
When you see a question about javac and output directories, the key concept to focus on is: **the -d flag controls where .class files land, and the package declaration — not the source file's location — determines the subdirectory structure created inside that destination.**
When you run javac -d out src/misc/Report.java, the compiler reads the package org.audit; declaration inside the source file. It then creates the directory hierarchy org/audit/ under out automatically, placing the compiled bytecode at out/org/audit/Report.class. The compiler doesn't care that your source file lives under src/misc/ — it uses the package name to build the output path. This is answer C, the correct choice.
A is wrong because javac does not require your source file to mirror the package structure in its path. That convention matters for tools like java when finding source, and is a best practice, but it is not enforced by the compiler itself — the file will still compile successfully.
B is wrong because the -d flag never mirrors the source directory tree into the output. It mirrors the package structure. Writing to out/misc/Report.class would ignore the package org.audit; declaration entirely.
D is wrong because -d out anchors output at out/, not alongside the source file. Nothing is written into src/ as a result of -d.
As a study tip, remember: **-d = destination root, package = subdirectory path**. The source file's folder is irrelevant to where the .class file ends up.
- Which action correctly makes the class launchable from the
classes classpath root? Answer: Move it to classes/tools/Widget.class and run java -cp classes tools.Widget.
Whenever you see a question about running Java programs, remember two rules that must both be satisfied: the class file must live in a directory structure that mirrors its package, and you must reference the class by its fully-qualified binary name on the command line.
Here's why C is the only option that works. The class declares package tools;, giving it the binary name tools.Widget. The JVM resolves this by looking for a file at [classpath root]/tools/Widget.class. When you set -cp classes, the JVM expects the file at classes/tools/Widget.class. Moving the file there and running java -cp classes tools.Widget satisfies both requirements perfectly — the file is in the right place, and you're using the correct fully-qualified name.
A fails on two counts: the file is in the wrong location (classes/Widget.class instead of classes/tools/Widget.class), and the class name Widget omits the package prefix. Even if one were fixed, both must be correct simultaneously.
B uses the correct binary name tools.Widget, but the file is still misplaced at classes/Widget.class. The JVM will look for classes/tools/Widget.class and throw a ClassNotFoundException — the name and the file path must agree.
D moves the file to the right location, but then sets the classpath to classes/tools instead of classes. This means the JVM looks for classes/tools/Widget.class under classes/tools/, translating to classes/tools/Widget.class — actually this could seem to work, but the binary name Widget without the package prefix won't match the declared package, causing a runtime error.
Think of it as a contract: package declaration → directory structure → fully-qualified class name — all three must align.
- Which command uses a relative classpath that correctly launches
Runner? Answer: java -cp ../classes demo.Runner
When launching a Java program with java -cp, you need to understand two things: how classpath resolution works, and how relative paths are calculated from the current working directory (CWD).
The classpath must point to the root of the package hierarchy, not to the class file itself. Since Runner declares package demo;, Java expects to find it at [classpath]/demo/Runner.class. Your CWD is /work/project/scripts, so any relative path starts from there.
B is correct because ../classes navigates one directory up from scripts to project, then into classes — resolving to /work/project/classes. From there, Java looks for demo/Runner.class, which exists exactly at /work/project/classes/demo/Runner.class. The fully qualified class name demo.Runner completes the picture correctly.
A uses classes as a relative path, which resolves to /work/project/scripts/classes — a path that doesn't exist. This is the classic trap of forgetting to navigate up out of the current directory first.
C points the classpath to ../classes/demo, which resolves to /work/project/classes/demo. Java would then look for Runner.class directly inside that folder using the class name Runner (no package prefix). But since you passed demo.Runner, Java searches for demo/Runner.class inside /work/project/classes/demo, which doesn't exist.
D uses an absolute path (/work/project), so it isn't a relative classpath at all — the question explicitly asks for a relative one.
Study tip: Always calculate the classpath as the directory above the top-level package folder, and trace your relative path step-by-step from the CWD.
- What is the most likely result, assuming the JAR does not contain
Main.class? Answer: Main is not found because the explicit classpath does not include the current directory.
When you provide an explicit classpath using -cp or -classpath, Java uses exactly and only what you specify — it does not silently add the current directory (.) as a fallback. This is a critical distinction from the default behavior, where the current directory is the implicit classpath when no -cp flag and no CLASSPATH variable are set.
In this scenario, java -cp lib/helper.jar Main tells the JVM to search for classes exclusively inside lib/helper.jar. Since Main.class lives in the current directory (not inside that JAR), the JVM cannot find it and throws a ClassNotFoundException or NoClassDefFoundError at startup. The correct fix would be java -cp lib/helper.jar:. Main (Unix) or java -cp lib/helper.jar;. Main (Windows), explicitly including the current directory with ..
A is wrong because it describes behavior that simply does not exist. Java never automatically appends the current directory when an explicit classpath is given — that's the exact trap this question is testing. C is wrong because unnamed-package classes are not treated specially by the classloader; they still must be reachable via the classpath like any other class. D is wrong because combining JAR files and directory entries in a single classpath is perfectly legal and very common practice — that's not the problem here.
The study tip to remember: **explicit -cp overrides everything, including the current directory**. Whenever you see a -cp flag in an exam question, ask yourself whether . is included. If it's missing and a class lives in the current directory, that class won't load.
- Which command correctly launches the class?
Answer: java -cp classes com.acme.Main
When running a Java program from the command line, you need to understand two distinct concepts: the classpath and the fully qualified class name. The classpath tells the JVM where to start looking for .class files, and the class name tells it which class to load — expressed as a dot-separated package path, never a file path.
Given that the file lives at /opt/app/classes/com/acme/Main.class and your working directory is /opt/app, the classpath root should be classes — the directory that sits directly above the com/acme/ package structure. From that root, the JVM can resolve any class by converting dots to directory separators internally. The class must be referenced by its fully qualified name: com.acme.Main. That makes B (java -cp classes com.acme.Main) the correct command.
A is wrong because classes/com/acme points too deep into the directory tree. The classpath root must be above the package hierarchy, not inside it, so the JVM can no longer reconstruct the package structure correctly.
C fails because com/acme/Main.class is a file path, not a class name. Java expects a dot-separated class name after the classpath — it does not accept slashes or the .class extension on the command line.
D uses classes/com as the classpath, which again digs one level too deep, and then lists acme.Main — dropping the com segment of the package, making the fully qualified name incomplete.
A reliable rule of thumb: the -cp directory should be the parent of your top-level package folder. The class argument is always package.ClassName, never a path.
