Wyjaśnij cechy pracy z pakietami (packages) w Javie, do czego są potrzebne, jaka jest ich rola w organizacji kodu i jakie mogą wystąpić błędy przy ich użyciu.

Odpowiedź.

Pakiety (packages) w Javie są używane do logicznej grupowania klas, interfejsów i pod-pakietów. Pomaga to w strukturyzacji dużych projektów, poprawia czytelność i ponowne wykorzystanie kodu.

Główne funkcje pakietów:

• Zapobiegają konfliktom nazw (na przykład, dwie klasy o tej samej nazwie mogą znajdować się w różnych pakietach).
• Organizują dostępność klas (modyfikator dostępu package-private).
• Zapewniają łatwiejsze zarządzanie zależnościami i wdrożeniem.

Tworzenie i używanie pakietu:

package com.example.utils;

public class MathUtils {
    public static int sum(int a, int b) {
        return a + b;
    }
}

Aby użyć klasy z innego pakietu:

import com.example.utils.MathUtils;

public class Test {
    public static void main(String[] args) {
        System.out.println(MathUtils.sum(5, 7));
    }
}

Pytanie z pułapką.

Czy można zdefiniować pakiet w środku pliku klasy Java lub nie w pierwszej linii?

Odpowiedź: Nie, dyrektywa package musi być pierwszą (niepustą) linią w źródłowym pliku Java.

// Niepoprawne!
import java.util.*;
package com.example; // Błąd kompilacji
public class MyClass {}

Przykłady rzeczywistych błędów z powodu braku znajomości szczegółów tematu.

---

Historia

W rzeczywistym projekcie zapomniano wskazać dyrektywę package na początku pliku. Po kompilacji klasa znalazła się w pakiecie domyślnym, co doprowadziło do konfliktów z klasami o tej samej nazwie z innych bibliotek. W rezultacie wystąpiły błędy typowania i problemy z budowaniem pliku JAR.

---

Historia

W dużym zespole, pracując z wieloma pakietami (na przykład, com.example i com.Example) wystąpił problem z niezgodnością między Linuxem a Windowsem – Windows ignoruje wielkość liter w ścieżkach, Linux – nie. Spowodowało to niespodziewane błędy na produkcji po wdrożeniu na serwerze z Linuxem.

---

Historia

Programista przypadkowo nadał klasie dostęp protected do ważnych metod, sądząc, że nie będą one widoczne z zewnątrz, ale nie uwzględnił, że klasy wewnątrz jednego pakietu mogą odwoływać się do tych członków. Spowodowało to wyciek wewnętrznej logiki biznesowej przez API, które nie było przeznaczone do użytku zewnętrznego.