SCJP, podejście trzecie

Znowu cisza na blogu. Ale poza nim prace wrą – efekty z całą pewnością niedługo opublikuję. Natomiast póki co słów kilka o SCJP i relacja z lektury trzeciego (i nie tylko) rozdziału podręcznika do SCJP.

Chciałem być mądry – kończyłem właśnie 3 rozdział (Assignments), ale że on trochę długi i do powtórzenia więcej, zabrałem się dla relaksu za rozdział ostatni – kompilator, JVM i insze takie techniczne. No i wszystko niby piękne i oczywiste, za to na teście kończącym rozdział poległem bardzo mocno. I nie wynikało to z braku samej wiedzy nabytej w tym konkretnym rozdziale, ale z braku wiedzy zamieszczonej w rozdziałach poprzednich. Kiedy potem zacząłem czytać rozdział 4 (Operators), już w pierwszych kilku zdaniach autorzy zwrócili uwagę na 3 zagadnienia, na których poległem kilka rozdziałów później. Stąd moja uwaga – należy czytać podręcznik rozdział po rozdziale .Natomiast jeśli chodzi o rozdział trzeci to kilka uwag na dole rzecz jasna:

  • UWAGA– tylko tyle. Zanim zaczniesz się wgryzać w zawiłości wątków, wyjątków, przypisań czy czegoś tam jeszcze, zwróć uwagę na to, czy wszystkie zmienne są odpowiednio poinicjalizowane (czy coś nie jest NULLem). Zobacz jak na wykonanie kodu wpłyną operatory inkrementowania czy dekrementowania ułożone w takim, a nie innym miejscu.
  • bloki inicjalizacyjne– są statyczne i instancyjne. Jasne. Statyczne są wywoływane wtedy, kiedy klasa jest ładowana przez JVM. A co to znaczy? Taki przykład:
    class A {}
    class B extends A {}
    class C extends B {
    // tutaj metoda main, konstruktor domyslny
    }

    Pytanie – kiedy załaduje się klasa B, a kiedy A? Założeniem logicznym byłoby to, że skoro klasa C dziedziczy po B (więc ładujemy klasę B), ale to B dziedziczy po A, więc aby w pełni w ogóle skompilować klasę C trzeba załadować do pamięci zarówno klasę B (rodzica), jak i także klasę A (dziadka klasy C). Natomiast odpowiedzi do testu końcowego mówią, że w przypadku tego kodu, na początku zostanie załadowana TYLKO KLASA B. I tym samym wykonają się jej statyczne bloki inicjalizacyjne. Dziwne.
  • Var-argsy – powracają w nowej formie. Ale i znowu są na szarym końcu. Nie zamierzam bliżej tego przedstawiać, ale rzecz w pytaniu jaka przeciążona metoda zostanie wywołana, jeśli parametry metody są do siebie dość zbliżone, a w grę wchodzi AutoBoxing oraz widening (poszerzanie). Należy zapamiętać, że jeśli JVM ma do wyboru metodę z var-argsami jako parametrami lub metodę z np. jedym obiektem klasy Object, to niezależnie od wersji jeśli ma inną możliwość zawsze ją wybierze. Zagmatwałem 🙂 Konkludując: W pytaniach o uruchamiane metody na var-argsy nie patrz. W 99,9% są ostatnie do wywołania, only when all the lights go out.
  • Garbage Collector– za obiekty możliwe do usunięcia (eligible) uznaje się równiez na egzaminie właściwości klas. Czyli jeśli mamy dwa obiekty, do których np. nie ma referencji, wówczas chcąc podsumować ilość obiektów do usunięcia, bieżemy pod uwagę te obiekty, a także ich składowe (tablice dla przkładu).
Advertisements

2 thoughts on “SCJP, podejście trzecie

  1. blbu

    co do blokow inicjalizacyjnych to nie jest tak, ze A nie ma bloku static? 🙂
    A przy GC trzeba tez pamietac o staticach (przynajmniej ja zapomnialem) 🙂

  2. chlebik Post author

    I to jest sluszne spostrzezenie. Po raz kolejny musze sobie powiedziec – pokory i uwagi 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s