Matnia Javy - bajzel niemożliwy do ogarnięcia?

0

Naszła mnie nagła frustracja. Po tym jak do głupiego wyklikania dość prymitywnej rzeczy w Swingu okazało się, że przydałby mi się prosty komponent do wyboru katalogu. Najprostsze co mogłem wziąć to coś co zauważyłem na tym forum czyli l2fprod-common-components.
Ponieważ jednak potrzebowałem dokumentacji, a zawarta w pakiecie została wygenerowana w starym stylu bez linkowania do metod dziedziczonych z klas przodków, to postanowiłem je sobie sam na nowo wygenerować.
No i się zaczęło...
Rozpakowałem źródła, stworzyłem w netbeans projekt z użyciem istniejących źródeł. Podłączyłem rzekomo wszystkie niezbędne biblioteki.
Jak się okazało chyba jednak nie wszystkie. Nie zadziałały importy dla
com.toedter.calendar.JDateChooser
net.sf.nachocalendar
org.springframework

Pierwsze dwa jakoś znalazłem, podłączyłem i wydawało się ok. Były to jednak drobiazgi. Ostatnia pozycja to jednak jakaś paranoja. Jak się okazało importy pochodzą ze Spring RPC. Przez kilka godzin próbowałem rozpoznać z czym to się je i dlaczego od słowa Spring zaczyna kilkadziesiąt zupełnie różnych rzeczy, które mają ze sobą tyle wspólnego co kolejne nierozpoznawane importy. Kilka godzin straciłem na rozpoznawaniu kompletnie popieprzonych ścieżek katalogowych do tych pakietów, które udało mi się znaleźć. Z jakiegoś powodu istniają ludzie - zwani "programistami", których życiowym celem jest takie skomplikowanie prostych rzeczy, żeby już nikt poza nimi tego nie rozumiał.
Jak się jednak okazało źródła Spring RPC odwołują się do Spring framework, a po znowu kilku godzinnym rozpoznaniu o jaką wersję może chodzić i ściągnięciu plików znowu okazało się, że 9/10 wszystkich plików znowu wyrzuca błędami importów. Tym razem nie sprowadzało się to do trzech, lecz do kilkudziesięciu.
Zrezygnowałem z szukania źródeł bo prawca wyglądała na tygodniową. Chciałem już jedynie, żeby netbeans przestał podkreślać mi te cholerne importy. Przez następną godzinę metodycznie ładowałem kolejne biblioteki oraz następne od których istnienia zależały te pierwsze. W kilku przypadkach doszedłem do kilkupoziomowego zagnieżdżenia. W kilku przypadkach okazało się, że odwołania do bibliotek tworzą jakby cykl bo małe biblioteki od których zależała kompilacja plików Spring Framework odwoływały się do kolejnych, które z kolei odwoływały się do kolejnych pakietów Spring.
Tego już nie wytrzymałem.
Z niewielkiego drobiazgu do wyklikania problem urósł do cholernej "docentury", której nawet nie podejrzewałem zaczynać.

Wypierniczyłem wszystko co ściągnąłem. Sam sobie napiszę to co potrzebuję. Na pewno nie zajmie mi to tygodnia kompletnie bezsensownej i kompletnie odmóżdżającej pracy. Na pewno nie będzie idealne, wszechstronne i zgodne z mnóstwem użytecznego kodu. Tyle, że co mi po tym użytecznym kodzie, kiedy po próbie jego użycia mam zamiar trzasnąć wszystko i użycie shift-del i rozbijanie monitora to najłagodniejsza reakcja.

Zastanawiam się tylko jaki w tym wszystkim jest sens. Jaki jest sens w założeniu ponownego użycia kodu skoro:

  1. Kolejne wersje bibliotek to zawsze wersje testowe i zawsze zawierające błędy bo zanim usunie się wszystkie to autorzy wprowadzają kolejne nieprzetestowane funkcjonalności.
  2. Znalezienie dowolnie prostego kodu do ponownego użycia powoduje, że ściągamy megabajty zupełnie niepotrzebnego nam kodu, którego rzekomo potrzebujemy. Na dodatek nie czytając megabajtów dokumentacji nie dowiemy się czy naprawdę potrzebujemy.

Czy ktoś widzi w tym jakiś sens? Bo ja już nie.

0

chciałbym kiedys dojsc do takiego poziomu znajomosci javy by miec takie problemy :)

0

Dlatego do kompilacji należy używać narzędzi takich jak maven. Ściągasz sobie kod i pom.xml, a maven sam odnajdzie i ściągnie potrzebne zależności.
Co do pytania 2 to Java ma ten ból, że w przeciwieństwie do np. Cpp nie można kazać kompilatorowi by nie sprawdzał zależności. Taki mały zonk.

0

Dzięki za podpowiedź kwestii mavena. Na pewno ruszę bo zawsze to jakiś krok do przodu.
Co do źródeł, to moja znajomość Javy jest na poziomie przedszkolnym i dlatego zawsze wgłębiam się w źródła. Z tego samego powodu nie dotykałem nawet EJB czy Springa bo są to rzeczy do których jeszcze w tym języku nie dotarłem (tzn. do jawnej potrzeby użycia).
Oglądając jednak liczne źródła dochodzę do wniosku, że większość programistów swoją pracą poszerza tylko informatyczną wieżę Babel. Rzeczy proste komplikowane są do takiego stopnia, że to aż nieprawdopodobne.
Wielu programistów Javy wysłałbym na roczne, przymusowe programowanie w czystym assemblerze bez makr. Może wtedy przestaliby niepotrzebnie komplikować. ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1