Theory
Works on your laptop, dies on the server
BookBridge is ready for the college server. You copy the .class files, type java BookBridge, and are greeted by:
NoClassDefFoundError: circulation/IssueRegister
The file exists; you can see it. But the JVM is not looking where you think it is looking.
To fix this calmly instead of by trial and error, you need the last piece of the package story: how a name like circulation.IssueRegister becomes a file the JVM actually finds.
Theory
An address needs a city
circulation.IssueRegister is like "Ring Road, Shop 12": a precise address, but useless until you know which city to search in.
The classpath is the JVM's list of cities: folders and JAR files where searching may begin. From each starting point it walks the dotted name as folders: circulation/, then IssueRegister.class. Address without city: NoClassDefFoundError, however close the file sits to you.
Theory
Name to file, formally
The rule has 2 halves:
- Dots become folders: package com.bookbridge.util maps to the path com/bookbridge/util/, and every class of the package compiles into that folder.
javac -d .builds the tree for you at compile time. - The classpath supplies starting points: a list of directories and .jar archives (a JAR is a zipped package tree). The JVM tries each entry in order: entry + package path + ClassName.class.
Server fix: java -cp /apps/bookbridge BookBridge, so the search starts where the tree really lives.
Theory
The Package object
Packages also exist at run time, as objects of class java.lang.Package. A program can introspect the shelf a class came from:
Package p = String.class.getPackage();
p.getName() gives "java.lang"
And a package carries paperwork: its specification (the documented contract: title, version, vendor) and its implementation (the shipped code's version). Methods: getSpecificationTitle(), getSpecificationVersion(), getSpecificationVendor(), and getImplementationVersion(). The values are read from the JAR's manifest file; plain class folders without a manifest give null.
Practical
Asking a package about itself
public class PackageInfo {
public static void main(String[] args) {
Package p = String.class.getPackage();
System.out.println(p.getName()); // java.lang
System.out.println(p.getSpecificationVersion()); // the platform's spec version
System.out.println(p.getImplementationVersion()); // the JDK build you run
// For your own packages: values come from the JAR manifest;
// classes loaded from bare folders report null here.
}
}
Quiz
Classes declared as package com.bookbridge.util must sit in which folder structure?
- com/bookbridge/util/
- com.bookbridge.util/ (one folder with dots in its name)
- util/bookbridge/com/ (reversed, like the naming convention)
- Any folder, as long as the package statement is correct
Show the answer
com/bookbridge/util/
Each dot is a folder boundary: com contains bookbridge contains util, and the .class files sit inside. Option B treats the dotted name as a single label, which the JVM never does. Option C over-applies the reverse-domain NAMING convention to the folder layout; the folders follow the name exactly as written. Option D is the laptop-to-server trap from the hook: the package statement alone does not tell the JVM where anything is; the folder tree plus classpath do.
Think first
Specification vs implementation
A Package object reports both a specification version and an implementation version. Before tapping: what is the difference, and why keep 2 numbers?
Show the answer
The specification is the documented contract: what the package promises (say, the Java platform API, version 17). The implementation is the actual code delivering that promise: a particular vendor's build, with its own version. Two numbers because many implementations can honour one specification, and a program can check compatibility at run time: does this environment provide at least the spec version I need? That runtime self-description is the Package object's whole job.
Watch out
Read the error correctly
ClassNotFoundException / NoClassDefFoundError almost never means the file is missing; it means the file is not where the CLASSPATH + package path says to look. Check 3 things in order: the package statement, the folder tree, the -cp value.
Null metadata is normal: getSpecificationTitle() returning null for your own classes just means no manifest, not an error. Do not invent values in an exam answer; say "from the JAR manifest, else null".
Theory
The unit closes its loop
Unit 4 in one paragraph: threads let one program walk 2 paths at once, and packages keep its growing class collection shelved, access-controlled, findable (classpath) and self-describing (Package object). BookBridge is now a small but honestly organised system. Unit 5 changes gear completely: you hand-build linked lists out of plain Java classes, the data-structures bridge every later DS course stands on.
Summary
Key takeaways
- Dotted package names map to folder paths: com.bookbridge.util lives in com/bookbridge/util/.
- The classpath lists the starting points (folders, JARs) the JVM searches; javac -d builds the tree.
- NoClassDefFoundError usually means wrong classpath or folder, not a missing file.
- java.lang.Package describes a loaded package at run time: getClass().getPackage(), getName().
- Specification = the documented contract (title, version, vendor); implementation = the shipped code's version.
- Metadata comes from the JAR manifest and is null for bare folders: say so, do not invent values.
- Memory hook: the classpath names the city, the package name walks the streets.