Theory
आपके Laptop पर काम करता है, Server पर मर जाता है
BookBridge college server के लिए ready है। आप .class files copy करते हैं, java BookBridge type करते हैं, और यह आपका greet करता है:
NoClassDefFoundError: circulation/IssueRegister
File exist करती है; आप इसे देख सकते हैं। पर JVM वहाँ नहीं देख रहा जहाँ आप सोचते हैं यह देख रहा है।
Trial और error के बजाय इसे calmly fix करने के लिए, आपको package story का आख़िरी piece चाहिए: एक name जैसे circulation.IssueRegister एक file कैसे बनता है जिसे JVM असल में ढूँढता है।
Theory
एक Address को एक City चाहिए
circulation.IssueRegister "Ring Road, Shop 12" जैसा है: एक precise address, पर useless जब तक आप जानें किस city में search करना है।
Classpath JVM की cities की list है: folders और JAR files जहाँ searching शुरू हो सकती है। हर starting point से यह dotted name को folders की तरह walk करता है: circulation/, फिर IssueRegister.class। City के बिना address: NoClassDefFoundError, चाहे file आपके कितनी भी करीब बैठी हो।
Theory
Name से File तक, Formally
Rule के 2 halves हैं:
- Dots Folders बन जाते हैं: package com.bookbridge.util path com/bookbridge/util/ पर map होता है, और package की हर class उस folder में compile होती है।
javac -d .compile time पर आपके लिए tree build करता है। - Classpath Starting Points Supply करता है: directories और .jar archives की एक list (एक JAR एक zipped package tree है)। JVM हर entry को order में try करता है: entry + package path + ClassName.class।
Server fix: java -cp /apps/bookbridge BookBridge, तो search वहाँ शुरू होता है जहाँ tree असल में रहता है।
Theory
Package Object
Packages run time पर भी exist करते हैं, class java.lang.Package के objects की तरह। एक program उस shelf को introspect कर सकता है जहाँ से एक class आई:
Package p = String.class.getPackage();
p.getName() "java.lang" देता है
और एक package paperwork carry करता है: इसकी specification (documented contract: title, version, vendor) और इसकी implementation (shipped code का version)। Methods: getSpecificationTitle(), getSpecificationVersion(), getSpecificationVendor(), और getImplementationVersion()। Values JAR की manifest file से पढ़ी जाती हैं; बिना manifest वाले plain class folders यहाँ null देते हैं।
Practical
एक Package से अपने बारे में पूछना
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
package com.bookbridge.util की तरह declared classes किस folder structure में बैठनी चाहिए?
- com/bookbridge/util/
- com.bookbridge.util/ (एक folder जिसके नाम में dots हैं)
- util/bookbridge/com/ (reversed, naming convention की तरह)
- कोई भी folder, जब तक package statement सही है
Show the answer
com/bookbridge/util/
हर dot एक folder boundary है: com में bookbridge है जिसमें util है, और .class files अंदर बैठती हैं। Option B dotted name को एक single label की तरह treat करता है, जो JVM कभी नहीं करता। Option C reverse-domain NAMING convention को folder layout पर over-apply करता है; folders exactly नाम follow करते हैं जैसे लिखा गया। Option D laptop-to-server trap है hook से: package statement अकेले JVM को नहीं बताता कुछ भी कहाँ है; folder tree plus classpath बताते हैं।
Think first
Specification बनाम Implementation
एक Package object दोनों एक specification version और एक implementation version report करता है। Tap करने से पहले: difference क्या है, और 2 numbers क्यों रखें?
Show the answer
Specification documented contract है: package क्या promise करता है (जैसे, Java platform API, version 17)। Implementation actual code है जो वह promise deliver करता है: एक particular vendor का build, अपने खुद के version के साथ। दो numbers क्योंकि कई implementations एक specification honour कर सकते हैं, और एक program run time पर compatibility check कर सकता है: क्या यह environment कम से कम वह spec version provide करता है जो मुझे चाहिए? वह runtime self-description Package object का पूरा job है।
Watch out
Error को सही से पढ़िए
ClassNotFoundException / NoClassDefFoundError almost कभी इसका मतलब नहीं होता file missing है; इसका मतलब है file वहाँ नहीं है जहाँ CLASSPATH + package path कहता है देखने के लिए। Order में 3 चीज़ें check कीजिए: package statement, folder tree, -cp value।
Null Metadata Normal है: getSpecificationTitle() आपकी खुद की classes के लिए null return करना बस मतलब है कोई manifest नहीं, कोई error नहीं। Exam answer में values invent मत कीजिए; कहिए "JAR manifest से, वरना null।"
Theory
Unit अपना Loop बंद करता है
Unit 4 एक paragraph में: threads एक program को एक साथ 2 paths पर चलने देते हैं, और packages इसके बढ़ते class collection को shelved, access-controlled, findable (classpath) और self-describing (Package object) रखते हैं। BookBridge अब एक छोटा पर honestly organised system है। Unit 5 पूरी तरह gear बदलती है: आप plain Java classes से hand-build linked lists बनाते हैं, वह data-structures bridge जिस पर हर बाद का DS course खड़ा है।
Summary
Key takeaways
- Dotted package names folder paths पर map होते हैं: com.bookbridge.util com/bookbridge/util/ में रहता है।
- Classpath starting points list करता है (folders, JARs) जिन्हें JVM search करता है; javac -d tree build करता है।
- NoClassDefFoundError का मतलब आमतौर पर wrong classpath या folder है, missing file नहीं।
- java.lang.Package run time पर एक loaded package describe करता है: getClass().getPackage(), getName()।
- Specification = documented contract (title, version, vendor); implementation = shipped code का version।
- Metadata JAR manifest से आता है और bare folders के लिए null है: यही कहिए, values invent मत कीजिए।
- Memory hook: classpath city name देता है, package name streets walk करता है।