Jedna z rzeczy, która mnie bardzo irytuje w Javie to toporność interakcji z systemem operacyjnym. Rozumiem, że JVM jest przenośne i tak dalej, ale ile trzeba się naszarpać, żeby wywołać coś z biblioteki SO/DLL przekracza ludzie pojęcie. Mam nadzieję, że zmiany z FFI (foreign function interface) do użycia i wywołanie funkcji z bibliotek systemowych przestanie być udręką.
Dla jasności programiści JVM mają do dyspozycji JNI, które wymaga kompilacji kodu natywnego, żeby ten można było wowłać z poziomu JVM. Z mniej topornych opcji mam JNA (oparte o libffi), które jest dość wolne, oraz nieoficjalne api jnr-ffi.
Dla zainteresowanych https://openjdk.org/jeps/424 i https://github.com/jnr

Programujesz? Nie wiesz o co chodzi z tym "Log4j"?
Próbuję to wyjaśnić w najnowszym filmie pokazując podatność CVE-2021-44228 na prostym kawałku kodu.
• Dowiesz się jak użyć Canary Tokens do wykrycia podatności w swoich aplikacjach.
• Zobaczysz, że można wykraść zmienne środowiskowe korzystając z interactsh
• Pokazuję, że podatne mogą być wszystkie wersję Javy - te nowsze i te starsze.
• Zmienna "LOG4JFORMATMSGNOLOOKUPS" nie zawsze rozwiązuje problem.
• Wersja 2.15.0 nie jest najlepszym rozwiązaniem
Masz znajomych programistów? Podeślij im ten film - może ich zainteresuje
https://www.youtube.com/watch?v=sPa83lM7YJs

Java 17 będzie lepiej generować liczby losowe
https://www.infoworld.com/article/3606833/jdk-17-whats-in-store-for-java-17.html

Dlaczego samochody są złe, czyli po jakiego grzyba tutoriale robią nam wodę z mózgu?
W końcu się zmotywowałem, a poniżej efekt Zapraszam też do obserwowania tagu #luznegatkiprzyjavie <- tu będę wrzucał swoje wypociny.
Jeśli ktoś z Was uczył się jakiegoś obiektowego języka programowania to mógł się przed chwilą uśmiechnąć pod nosem. Samochody. Wszędzie te samochody. Oczywiście, samochody posiadają markę, kolor, silnik. To już musi brzmieć znajomo. Ale od początku.
Obiekt. Podstawowa jednostka czasu i przestrzeni w obiektowych językach programowania. A może to jednak klasa jest tą jednostką? Prawda jest taka że w przypadku obiektów i klas nie ma dylematu kury i jajka - tu wszystko jest jasne. Klasa jest "projektem" obiektu, a obiekt instancją klasy. I choć w Javie wszystko dziedziczy po klasie Object, to jednak nie ma obiektu bez klasy.
Część z Was już wie, a część z Was zaraz się dowie, że klasa będąc "projektem" obiektu, jego definicją, w swoim najprostszym ujęciu może posiadać pola oraz metody. Pola służą do przechowywania danych, z kolei metody, w dużym uproszczeniu, coś z tymi danymi przechowywanymi w polach robią.
No ale dziki! Co z tymi samochodami, bo się niecierpliwimy!
Już odpowiadam. Jeśli ktoś miał okazję robić jakiś tutorial z Javy albo uczestniczył w bootcampie to prawie na sto procent widział public class Samochod. Taki Samochod miał pola: private String kolor, private String marka i obowiązkowo private Silnik silnik. Posiada też metody. I tu się zaczyna cały problem jaki widzę. Bo czy logicznym z punktu widzenia początkującego programisty jest to że Samochod posiada metody uruchom() czy zahamuj()? Ano tak. A czy z perspektywy programowania obiektowego ma to sens? Ano nie. Paradoksalnie, często w tutorialu samochód jest jeszcze dalej eksploatowany, i w pewnym momencie służy do wytłumaczenia czym jest odwrócenie zależności, i wtedy (najczęściej) jest to zrobione poprawnie. Ale o tym kiedy indziej.
To co z tym samochodem jest nie tak że jest on złym przykładem? Bo samochód sam w sobie jest tworem zbyt skomplikowanym żeby móc go opisać za pomocą jednej klasy która będzie zawierała absolutnie wszystkie jego elementy składowe, metody, enumeracje, i co tylko sobie można jeszcze tam wyobrazić.
Dlaczego nikt nie używa jako przykładu czegoś prostszego? Weźmy takiego buta. But ma kolor, but ma markę, składa się z kilku różnych materiałów które zostały użyte do jego produkcji, ma sznurówki, rzepy czy zamek. No but. Chyba każdy z Was widział kiedyś buta.
Jedyne metody jakie może mieć nasz but to tak zwane gettery i settery - metody które służą do ustawiania wartości pól. Przykładowo - but ma kolor, więc setterem do ustawienia koloru będzie setColor() a getterem do pobrania wartości koloru będzie getColor(). Bez żadnych skomplikowanych powiązań między wewnętrznymi elementami buta. Jest on też doskonałym przykładem do tego by pokazać kilka rodzajów pól jakie może mieć klasa. Kolor - ciąg znaków, rozmiar - wartość liczbowa, sposób wiązania - enumeracja (sznurówki, rzepy, zamek), a rodzaj materiału może być osobnym obiektem o nazwie Material, który będzie miał w środku przykładowo rodzaj materiału i wartość prawda/fałsz odnosząca się do jego nieprzemakalności. Proste? Proste.
But nie będzie miał metod takich jak załóż() czy zawiąż() - bo każdy chyba się zgodzi że but się sam nie zakłada ani sam się nie zawiązuje (no dobra, wiem że istnieją Nike Adapt :P) - wiadomym jest że za zakładanie buta odpowiedzialny jest inny obiekt - Człowiek.
Odpowiedzialność to też ważne słowo w programowaniu obiektowym. Dziś rozpisywać się o tym nie będę, ale chciałem napomknąć jedynie że w programowaniu obiektowym mamy wprowadzony zestaw założeń opisywany skrótem SOLID - gdzie rozwinięciem pierwszej literki jest "Single responsibility principle" mówiąca o tym że klasa powinna mieć tylko jedną odpowiedzialność. W przypadku klas służących do przechowywania danych - tą odpowiedzialnością jest... przechowywanie danych. Ot, niespodzianka. Umieszczanie metody uruchom() w klasie Samochód łamie tę zasadę. "Czepiasz się, dziki" - ano czepiam się, bo osobiście uważam że złym pomysłem jest rozpoczynanie uczenia innych ludzi programowania od zrobienia tego na złym przykładzie.
Uff. Przebrnąłem. Jeśli doczytaliście aż do tego miejsca to dajcie znać jak bardzo powinienem przestać pisać o programowaniu

Chcecie jakieś w miarę quality wpisy o programowaniu w #java i #kotlin po stronie backendowej, trochę o szynach ESB, testach jednostkowych i takich tam? Próbuję się zabrać za pisanie od pewnego czasu i szukam motywacji

Kurła, dawno nie wykonałem takiej ilości pracy jak dzisiaj. Jestem z siebie zadowolony. Choć przede mną jeszcze masa pracy.