Theory
તમારા laptop પર Works, server પર dies
BookBridge college server માટે ready છે. તમે .class files ને copy કરો છો, java BookBridge type કરો છો, અને greet થાઓ છો સાથે:
NoClassDefFoundError: circulation/IssueRegister
file exist કરે છે; તમે એને જોઈ શકો છો. પણ JVM તમે think કરો છો ત્યાં look નથી કરી રહ્યું.
આને trial and error દ્વારા calmly fix કરવાને બદલે, તમારે package story નો last piece જોઈએ છે: કેવી રીતે circulation.IssueRegister જેવું name એ file બને છે જે JVM actually find કરે છે.
Theory
Address ને city ની જરૂર છે
circulation.IssueRegister એ "Ring Road, Shop 12" જેવું છે: precise address, પણ useless જ્યાં સુધી તમે જાણો નહીં કે કઈ city માં search કરવું.
classpath એ JVM ની cities ની list છે: folders અને JAR files જ્યાં searching begin થઈ શકે છે. દરેક starting point થી એ dotted name ને folders તરીકે walk કરે છે: circulation/, પછી IssueRegister.class. Address without city: NoClassDefFoundError, file તમારી પાસે કેટલી પણ close હોય.
Theory
Name થી file, ઔપચારિક રીતે
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 ત્યાં start થાય છે જ્યાં tree really lives કરે છે.
Theory
Package object
Packages run time પર પણ exist કરે છે, class java.lang.Package ના objects તરીકે. program class કઈ shelf થી આવી છે એ introspect કરી શકે છે:
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 માંથી read થાય છે; plain class folders manifest વગરના 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()); // platform ની spec version
System.out.println(p.getImplementationVersion()); // JDK build જે તમે run કરો છો
// તમારા પોતાના packages માટે: values JAR manifest માંથી આવે છે;
// bare folders માંથી loaded classes અહીં null report કરે છે.
}
}
Quiz
package com.bookbridge.util તરીકે declared classes કયા folder structure માં sit કરવી જોઈએ?
- com/bookbridge/util/
- com.bookbridge.util/ (dots ધરાવતો એક folder)
- util/bookbridge/com/ (reversed, naming convention જેવું)
- કોઈપણ folder, જો package statement correct હોય તો
Show the answer
com/bookbridge/util/
દરેક dot એ folder boundary છે: com એ bookbridge ને contain કરે છે જે util ને contain કરે છે, અને .class files અંદર sit કરે છે. Option B dotted name ને single label તરીકે treat કરે છે, જે JVM ક્યારેય કરતું નથી. Option C reverse-domain NAMING convention ને folder layout પર over-apply કરે છે; folders name ને exactly as written follow કરે છે. Option D એ laptop-to-server trap છે hook થી: package statement alone JVM ને કંઈ ક્યાં છે એ નથી કહેતું; folder tree plus classpath એ કરે છે.
Think first
Specification vs implementation
Package object બંને specification version અને implementation version ને report કરે છે. tap કરતા પહેલા: difference શું છે, અને 2 numbers શા માટે keep કરવા?
Show the answer
specification એ documented contract છે: package શું promise કરે છે (say, Java platform API, version 17). implementation એ actual code છે જે એ promise ને deliver કરે છે: particular vendor નું build, તેની own version સાથે. બે numbers કારણ કે many implementations એક specification ને honour કરી શકે છે, અને program run time પર compatibility ને check કરી શકે છે: શું આ environment ને ઓછામાં ઓછી spec version આપે છે જે મારે જોઈએ છે? એ runtime self-description એ Package object નું whole job છે.
Watch out
error ને correctly read કરો
ClassNotFoundException / NoClassDefFoundError almost never એટલે કે file missing છે; એટલે કે file ત્યાં નથી જ્યાં CLASSPATH + package path look કરવા કહે છે. 3 things ને order માં check કરો: package statement, folder tree, -cp value.
Null metadata normal છે: તમારા own classes માટે getSpecificationTitle() null return કરે છે એટલે manifest નથી, error નહીં. exam answer માં values ને invent ન કરો; કહો "from the JAR manifest, else null".
Theory
unit તેનો loop close કરે છે
Unit 4 એક paragraph માં: threads એક program ને 2 paths એક સાથે walk કરવા દે છે, અને packages તેના growing class collection ને shelved, access-controlled, findable (classpath) અને self-describing (Package object) રાખે છે. BookBridge હવે small પણ honestly organised system છે. Unit 5 gear completely change કરે છે: તમે plain Java classes થી linked lists ને hand-build કરો છો, data-structures bridge જેના પર દરેક later DS course stands કરે છે.
Summary
Key takeaways
- Dotted package names folder paths માં map થાય છે: com.bookbridge.util com/bookbridge/util/ માં lives કરે છે.
- classpath starting points ની list કરે છે (folders, JARs) જે JVM search કરે છે; javac -d tree build કરે છે.
- NoClassDefFoundError usually wrong classpath અથવા folder નો અર્થ છે, missing file નહીં.
- java.lang.Package loaded package ને run time પર describe કરે છે: getClass().getPackage(), getName().
- Specification = documented contract (title, version, vendor); implementation = shipped code ની version.
- Metadata JAR manifest માંથી આવે છે અને bare folders માટે null છે: say so, values invent ન કરો.
- Memory hook: classpath city ને names કરે છે, package name streets ને walk કરે છે.