არის Java-ს ავტომატური კონვერტაცია (, ) და მათი (, ) შორის. ეს მოსახერხებელია, მაგრამ აქვს დახვეწილი ხარვეზები — ფუნქციონირების დაკლება, გასაკვირი ქცევა და რისკი.
intdoubleIntegerDouble==NullPointerExceptionInteger boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42))
int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue())
List<Integer> nums = new ArrayList<>();
nums.add(5); // autoboxes int 5 → Integer (collections need objects)
int x = nums.get(0); // auto-unboxes Integer → int
ეს ხდება ავტომატურად, რადგან კოლექციები და generics მოითხოვენ ობიექტებს (თქვენ არ შეგიძლიათ გქონდეთ List<int>), ამიტომ Java-ს primitives გამჭვირვალედ აკოვებს.
Integer a = 1000;
Integer b = 1000;
a == b; // ❌ FALSE — different Integer OBJECTS (reference comparison)
a.equals(b); // ✅ true — value comparison
// the WORSE trap — the Integer cache makes small values seem to work:
Integer c = 100, d = 100;
c == d; // TRUE — Java CACHES Integers from -128 to 127 (same object)
Integer e = 200, f = 200;
e == f; // FALSE — outside the cache range → different objects
ეს მახალისებელი აღმოჩნდება: == Integer-ზე მუშაობს მცირე მნიშვნელობებისთვის (კეშირებული), მაგრამ ჩავარდება დიდი მნიშვნელობებისთვის — კოდი, რომელიც სწორი ჩანს ტესტირებაში, წარუმატებელი ხდება პროდუქციაში. ყოველთვის გამოიყენეთ .equals() wrapper მნიშვნელობის შედარებისთვის, ან ჯერ unbox primitive-ებში.
Integer value = null; // a wrapper can be null
int x = value; // 💥 NullPointerException — unboxing null calls null.intValue()
Map<String, Integer> map = new HashMap<>();
int count = map.get("missing"); // 💥 NPE — get() returns null, then unboxing fails
Null wrapper-ის unboxing ყრის NPE — ჩვეულებრივი, გასაკვირი crash, განსაკუთრებით მცირე სიაში ძიებით, რომელიც ბრუნდება null.
// ❌ autoboxing in a hot loop — creates millions of Integer objects (GC pressure, slow)
Long sum = 0L; // WRONG type — wrapper
for (long i = 0; i < 1_000_000; i++) {
sum += i; // unbox, add, re-box → new Long each iteration!
}
// ✅ use primitives in hot paths
long sum = 0L; // primitive — no boxing
მეორდებადი boxing/unboxing ქმნის ზედმეტ ობიექტებს, რომელიც ზიანს აყენებს ფუნქციონირებას მჭიდროდ მიმოწერილ ციკლებში.
Autoboxing მოსახერხებელი და ყველგან გავრცელებული (კოლექციები, generics ყველა უთხრის მას), მაგრამ მისი ხარვეზები იწვევენ რეალურ, რთულად დიაგნოსტიკაზე bugs-ებს.
== ხაფანგი განსაკუთრებით საშიშია: Integer-ების შედარება ==-ით მუშაობს კეშირებული მცირე მნიშვნელობებისთვის (-128 დან 127-მდე), მაგრამ ჩუმად ჩავარდება მეტი ერთეულების — bug, რომელიც გლეჯის ტესტებს და წარუმატებელი პროდუქციაში — შეაყრანი .equals() (ან unboxing) აუცილებელი wrapper შედარებისთვის. NullPointerExceptions null wrapper-ის unboxing-ის (საერთო მცირე სიაში ძიებით) მეორე ხშირი crash.
და boxing hot ციკლებში ქმნის არასაჭირო ობიექტებს, რომელიც ზიანს აყენებს ფუნქციონირებას.
გაჩნდება, როდის ხდება boxing, მნიშვნელობა-ვერსუსი-ჩვენება შედარების საკითხი, null-unboxing რისკი და primitive-ების გამოყენება ფუნქციონირების-კრიტიკული კოდი მნიშვნელოვანია სწორი, ეფექტური Java-ს დაწერის — და Integer-cache == ქცევა კლასიკური ინტერვიუს შეკითხვაა, რომელიც აჩენს ღრმა გაგებას.