Strona główna > Java > Trik z ładowniem klas

Trik z ładowniem klas

Wprowadzenie
Ostatnio udało mi się zrobić ciekawy użytek z tego jak java ładuje klasy w trakcie życia aplikacji. Proces ten nawet zwięźle jest opisany tutaj. Dotychczas mogłem przypominać sobie o tym kiedy musiałem walczyć z tym. Na przykład kiedy na serwerze aplikacyjnym zaplątały się dwie takie same biblioteki, ale w różnych wersjach. Dobrze było kiedy coś takiego objawiało się wyjątkiem, w gorszym wydaniu mogło otrzymywać się informacje o tym, że coś nie działa tak jak powinno i kombinuj co jest nie tak, zwykłe „u mnie działa” nie pomagało.

Opis problemu
Jednak znalazły się okoliczności kiedy można wykorzystać te „specyficzne” właściwości aby ułatwić sobie życie. Miałem problem z wykorzystaniem zewnętrznej biblioteki. W trakcie działania aplikacja sypała warning_ami. No i z faktu pojawiania się tego mogłem wiedzieć tylko tyle że coś tą zewnętrzną bibliotekę boli, ale co jest przyczyną tego to już nie bardzo.

Dochodzenie do rozwiązania
Więc na początek google i szukanie czy komuś coś takiego już się objawiło. W idealnym świecie powinien być to post o potędze internetu i poprawnym poszukiwaniu informacji w nim, ale tą drogą nie wiele znalazłem. Dowiedziałem się, że inni też spotykają się z czymś takim, a jedyne znalezione rozwiązanie tego problemu, to odpowiednia zabawa z poziomem logowania i zamiatanie tego pod dywan😉
No, ale można się oprzeć na idei wolnego oprogramowania. Jako, że zewnętrzna biblioteka miała dostępne źródła, to pobrało i podłączyło się je pod projekt w eclipsie. Tak więc teraz znalazłem tą linijkę, w zewnętrznym kodzie, gdzie występował warning. Uruchamiając aplikację w trybu debug mogłem widzieć więcej co jest nie tak.
I to w zasadzie wystarczało do rozwiązania konkretnego przypadku. Jednak ja takich przypadków miałem wiele i rozwiązanie każdego z nich wymagało zmiany w różnych miejscach. Tak więc praca w trybie debug wyglądała by męcząco, gdybym chciał rozwiązać każdy przypadek w taki sposób. Jak na razie dowiedziałem się o klasie występujących problemów, teraz potrzebowałem tylko pozyskiwania zwięzłych informacji w każdym przypadku. Idealnie byłoby gdyby warning_i, od których to wszystko się zaczęło, niosły te informacje. Jednak budowanie ze źródeł feralnego jara z rozszerzonymi informacjami w logach wydawało mi się przesadą, dlatego postanowiłem użyć triku z ładowaniem klas.
Miałem źródła zewnętrznej klasy, w której chciałem rozszerzyć logowanie. Więc w ramach kodu projektu nad którym pracowałem stworzyłem odpowiedni pakiet i w nim kopie tej klasy ze zmianami jakie chciałem. Dzięki temu teraz kiedy uruchamiałem aplikacje „moja zewnętrzna” klasa była ładowana przed oryginałem i mój kod był wykonywany dostarczając mi dodatkowych informacji, które musiałbym pozyskiwać w czasochłonnym trybie debug🙂.

Wnioski
Co z tego można wyciągnąć na przyszłość?:

  • Czasem to co nam uprzykrza życie, w innych przypadkach może ułatwiać;
  • Jest to rozwiązanie, które polegało na dodaniu tymczasowego nieprodukcyjnego kodu aby ułatwić sobie pracę. Robiąc podmianę klas jako stałe rozwiązanie, zastanowiłbym się dobrze czy na pewno nie mogę zrobić tego samego w bardziej czysty sposób, tak aby nie zaszkodzić samemu sobie w przyszłości.

Jeszcze na koniec o samej istocie rozwiązywanego tu problemu. Był on związany z logowanie, ostatnio ukazała się seria ciekawych artykułów związanych z tym zagadnieniem, a opisany przypadek pasuje zwłaszcza do tego.

Kategorie:Java Tags: ,
  1. Brak komentarzy.
  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: