discoStar
2017-11-22 08:59
jarekr000000

Jak zwykle nie widziałem tego postu (przeoczyłem). Ale dzięki - ciekawe linkii w komentarzach. To podejście widziałem w Scali, ale dopiero się przyzwyczajam.

rubaszny_karp
2017-10-26 12:07

G1 i Shenandoah GC to dużo ? Widać na horyzoncie nowy GC dla Javy http://mail.openjdk.java.net/[...]unce/2017-October/000237.html
P.S CMS będzie deprecated http://openjdk.java.net/jeps/291 :) - chociaż ciekawe, bo Google proponował przejęcie.

#java #jvm #makejavagreatagain

vpiotr

GC jest dla ludzi z demencja. Niech zyje sprytne i unikalne zwalnianie! 😄

zyxist
2017-10-12 21:06

Zainspirowany wpisem @scibi92, postanowiłem napisać trochę więcej na temat przyszłości Javy, tej bliższej, i tej nieco dalszej oraz o tym, dlaczego nie będzie Javy 10 :).

https://www.zyxist.com/blog/przyszlosc-javy-blizsza-i-dalsza

#java

Hispano-Suiza

@zyxist: jakiś czas temu dodałem ten blog do ulubionych, a tu proszę trafiłem i na autora :-)

Shalom
2017-10-10 22:42

Dzisiaj mały rant na "magię" a w sumie może bardziej na jakiś taki cargo cult i bezmyślne używanie rzeczy, ktorych się nie rozumie.

Jestem juz przyzwyczajony że co jakiś czas ktoś z temu prosi mnie o pomoc w zdebugowaniu jakiegoś problemu z serii przeciez to niemożliwe, java się zepsuła!!11.
Tak też było i dziś. Jedna osoba stawiała sobie środowisko do pracy nad jakimś nowym modułem i potrzebowała setup trochę mniej typowy niż u innych. Sam projekt generalnie jest upchany do granic możliwości rozwiązaniami z serii hype driven development i @jarekr000000 dostałby pewnie zawału ;) Niestety jest to jednocześnie tak zrobione, że rekord postawienia tego lokalnie u developera wynosi jakieś 2 dni... Sugerowałem nawet, żeby następnym razem ktos po prostu zrobił VMkę z gotowym środowiskiem, no ale nie mam "mocy sprawczej" więc bawią się dalej :D

Wracając do tematu, odbywała się dziś (tzn już pewnie od wczoraj jak nie dłużej) próba kolejnego setupu i pojawił się problem nie do przejścia -> w trakcie startu aplikacji leci wyjątek z JMSa że nie da się połącyć do jakiejśtam kolejki o podanym URLu. Niby nic wiekiego, niemniej to jest aplikacja z pluginami i nie do końca wiadomo kto i gdzie te JMSa próbuje postawić i skąd bierze adres. Adres pewnie z propertisów, ale tych jak sie dorzuci pluginy jest trochę, no ale nic, grepujemy sobie po nich i nie ma tego adresu który szukamy. Po drodze wyszło jeszcze trochę potencjalnych baboli w konfiguracji więc poprawiamy, no ale czas wrócić do tego JMSa. Pomyślałem nawet, że może gdzieś ktoś na lewo coś dorzuca do jara, więc rozpakowałem i sprawdziłem tam no i nadal nic.

Przy okazji miałem pokaz "permutation driven development", bo zanim zostałem wezwany do pomocy to już pewne desperackie próby zostały podjętę. Pliki properties były powrzucane w każde możliwe miejsce w strukturze projektu i musiałem poświęcić kilka minut na wyjaśnienie, że nie ma sensu, bo tylko te z src/main/resources będą brane pod uwagę. Musiałem też co jakiś czas stopować genialne pomysły z serii zmieńmy tutaj to property i przebudujmy projekt!, kiedy ewidentnie widać że nijak nie ma to związku z naszym problemem.

No więc czas jednak użyć debugera i zobaczyć co tam się generalnie dzieje. A tu niestety kłody pod nogi. Ten JMS to oczywiście startuje oczywiście z jakiegoś Springowego beana, na podstawie 7 krotnie powstrzykiwanych obiektów a na koniec wstrzykniętych properties. Istniała też szansa że może ta wartość jest gdzieś "w kodzie" ustawiana setterem - no to można by się breakować tam. A tu niestety Lombok :D Dobrze że IntelliJ dekompiluje klasy w locie i pozwala postawić breakpointy w tym zdekompilowanym bajtkodzie, który już ma te dodane lombokiem konstruktory i metody. Debuger potwierdza że faktycznie property jest ewidentnie z jakiegoś wstrzyknięcia, więc wskakujemy sobie w property resolver i patrzymy co za propertisy Spring sobie znalazł. Jest ich tam trochę, ale po chwili trafiamy na "winnego". Jest on o tyle dziwny, że to nie jest plik z classpath, tylko... URL! Moja pierwsza myśl jest taka, że ktoś sprytnie zrobił sobie property które przechowuje URLa do innych property i się to tak sprytnie rekurencyjnie ładuje. Powtarzamy więc sesje grepowania, szukając teraz już nie naszego JMSowego endpointa (tego który nie działał na samym początku), tylko szukając URLa do tych lewych propertisów i znów nic. Nauczony doświadczeniem sprawdziłem na wszelki wypadek czy springowy property resolver gdzieś tego nie widzi wśród załadowych propertisów, ale też nie!

Przyszło mi wtedy do głowy, że cudów tutaj nie ma, skoro nie ma tego w kodzie ani w properties ani w jarze, to jedyna możliwość, która pozostaje, to oczywiście parametry wywołania programu, które oczywiście też są automatycznie obsługiwane przez Spinga. Otwieram "run configuration" i widzę tam już znajomy URL do rypniętych properties... Myśle że moja mina to było klasyczne szok, niedowierzanie i tysiące pytań bez odpowiedzi. Pytam więc grzecznie WTF?! Jak się okazuje parametry zostały dodane zupełnie bezmyślnie bo tak było w developer's guidzie i bez jakiejś refleksji nad tym do czego one służą i czy nie należy ich jakoś zmodyfikować. Usuwamy parametr, wszystko startuje od kopa. Kurtyna.

#dailywtf #magic #ihavenoideawhatimdoing #java

Koziołek

@karolinaa: właśnie pracuję nad taką standaryzacją w nowej firmie. Docelowo ma to wyglądać tak, że bazę danych wraz z JMSem odpalamy w kontenerach, a główna apka chodzi na hoście. Rzecz w tym, że nikt nie wiem jak prawidłowo skonfigurować apkę. Nawet najdłużej pracujący w projekcie nie wiedzą jak to zrobić...

vpiotr

@Shalom: witaj w swiecie korpo-flag. Ja takie bzdety robie na codzien.

zyxist
2017-10-07 21:51

Właśnie wypuściłem w świat wtyczkę do Gradle'a o nazwie Chainsaw. Dodaje ona sensowną obsługę modułów JDK9 do Gradle'a i jest mocno zmodyfikowaną wersję eksperymentalnej wtyczki experimental-jigsaw autorstwa twórców Gradle'a, która okazała się być mocno wybrakowana i nierozwijana. Po moich modyfikacjach wtyczka nadaje się już do sensownego użytku:

  • budowanie projektu z deskryptorem modułu module-info.java,
  • obsługa testów jednostkowych:
    • automatycznie wykrywa JUnit 4/5
  • możliwość dodania dodatkowych testowych modułów (np. Mockito),
  • weryfikacja poprawności nazwy modułu (czy jest zgodna z nazwą głównego pakietu w projekcie).

Strona projektu oraz instrukcja użycia: https://github.com/zyxist/chainsaw

Kolejną funkcjonalnością, którą planuję dodać, jest możliwość patchowania krzywych JAR-ów, jak np. jsr305, która może się przydać przy dodawaniu niektórych zależności.

#java #java9 #gradle

zyxist

Właśnie wypuściłem nową wersję wtyczki. Pojawiło się patchowanie modułów oraz współpraca z procesorami adnotacji, dzięki czemu można już poradzić sobie np. z Guavą oraz Daggerem. Jeśli wtyczka Wam się podoba, to dajcie jej gwiazdkę na Githubie :).

wiciu

@zyxist: Dzięki za odpowiedź. Sprawdzę to.

zyxist
2017-09-24 16:03

Kolejna porcja wieści z frontu Java 9 + Jigsaw.

Wygląda na to, że jeszcze trochę wody w Wiśle upłynie, zanim moduły będzie można wykorzystać w kodzie produkcyjnym. Wsparcie ze strony narzędzi oraz najpopularniejszych bibliotek jest obecnie średnie, ale myślę, że to tylko kwestia czasu, by usunąć niedoróbki.

Przez weekend udało mi się poprawić kod Daggera, zdefiniować stabilne nazwy modułów w bibliotece Netty oraz rozbudować wtyczkę experimental-jigsaw do Gradle'a o wsparcie dla JUnit 5 oraz możliwość używania w testach dodatkowych bibliotek takich, jak Mockito.

I to jest chyba najlepszy sposób na utorowanie modułom drogi. Spróbujcie napisać jakąś niewielką, przykładową aplikację z użyciem modułów oraz ulubionych bibliotek. Jeśli widzicie, że coś nie działa, szturchajcie autorów, wystawiajcie Pull Requesty i działajcie! Samo się nie zrobi :).

#java

zyxist

Jeśli chodzi o samo JDK, to moduły pełnią tam dwie funkcje. Pierwsza, to pochlastanie ogromnego monolitu pt. "biblioteka standardowa" na mniejsze klocki, aby ułatwić rozwój kolejnych wersji języka. Drugi, to zwiększenie bezpieczeństwa - moduły pozwalają łatwo zablokować dostęp do "prywatnych" rzeczy, które do tej pory wyciekały.

W aplikacjach widzę przede wszystkim ukrycie bebechów przed innymi modułami - sam często czegoś takiego potrzebowałem i trzeba to było robić naokoło poprzez np. Mavena (dwa moduły - api oraz implementacja), albo zaprzęgając ciężkie kombajny w stylu OSGi. Najprostszy przykład to Guava, którą wiele aplikacji przepakowuje do pakietów o innej nazwie (np. Jersey wrzuca wszystko do jersey.repackaged), tyle że obecnie te przepakowane rzeczy są widoczne razem z właściwą Guavą i powoduje to czasami mnóstwo problemów, jak ktoś zaimportuje nie to, co trzeba i tego nie zauważy.

Twórcom bibliotek czy frameworków moduły pozwalają zdefiniować jasny kontrakt, z czego może korzystać aplikacja. Dla nowych osób w projekcie jest to duża pomoc, bo wiadomo od razu, gdzie trzeba dbać o kompatybilność i ścieżki migracji, a gdzie nie. Miałem okazję pracować w takim projekcie, gdzie nie było jasnego podziału na wewnętrzne klasy i publiczne API. Od strony utrzymania to był koszmar - ciągle coś "wyciekało", albo ktoś użył czegoś niedozwolonego "bo mógł" i traciliśmy dużo czasu na pomoc przy migracjach do nowych wersji.

Burdzi0

@zyxist: Dzięki, jakiś porządny konkret ;)

zyxist
2017-09-22 18:50

Java 9 już jest i dlatego postanowiłem dzisiaj spróbować dodać moduły do jednego z projektów. Sam projekt od strony designu był już przygotowany pod dodanie plików module-info.java, lecz niestety życie nie okazało się tak piękne, a wszystko przez zewnętrzne biblioteki.

Po pierwsze - Dagger 2 i generowanie kodu. Okazało się, że z powodu zostawienia w kodzie Daggera jednego nieużywanego importu adnotacji javax.annotation.Generated, wsiąkłem na kilka godzin, próbując rozplątać sajgon spowodowany przez paskudnego potworka znanego szerzej jako JSR-305 JAR. W dużym skrócie - rzecz polega na tym, że dwa moduły nie mogą być właścicielami tego samego pakietu. W Javie 6 wprowadzono 5 adnotacji w pakiecie javax.annotation, a potem grupa developerów zaproponowała dołożenie jeszcze ~20 innych w postaci JSR-305. JSR nie został przyjęty, ale JAR-ki z "referencyjną" implementacją w kilku mutacjach zaczęły krążyć po Internecie i infekować projekty typu Guava, Apache Spark itd. Anotacja Generated trafiła do tego pakietu trochę przez pomyłkę, bowiem pozostałe 4 adnotacje związane były z Javą EE. Niestety, obecność zarówno modułu JDK, jak i luźnej JAR-ki sprawia problemy, jeśli mamy je w jednym projekcie.

Ostatecznie Daggera udało się uruchomić dzięki kilku hackom, które opisałem w krzaku wystawionym twórcom Daggera: https://github.com/google/dagger/issues/880 i tam też odsyłam osoby, które trafią na podobny problem.

Po drugie - Ratpack. Ten gość jest praktycznie nieużywalny w świecie modułów, ponieważ autorzy poumieszczali te same pakiety w kilku JAR-kach (sytuacja podobna do powyższej - niedopuszczalny, tzw. package split). Problemy są podobne do powyższych, ale już ich skala zaczęła robić się zbyt duża i odpuściłem. Aby to obejść, trzeba bowiem w skryptach buildowych zaszywać ścieżki do plików JAR.

Pomijam już fakt, że projekt stosuje niekonwencjonalne zasady nazewnictwa pakietów i stąd biorą się jego obecne problemy. Dlatego przestroga dla wszystkich, nie tylko programujących w Javie: można łamać idiomy języka, można używać niestandardowych bibliotek, prywatnych API... ale jeśli łamiesz konwencje nazewnictwa lub zostawiasz śmieci w importach, to ludzie umierają :).

#java