Tak oto dochodzimy do ostatniego artykułu z długiego cyklu na temat języka Java. W przyszłości mogą pojawić się jeszcze jakieś, ale będą to pojedyncze wpisy. Na dzisiaj mam dla Was coś specjalnego na odejście od tematu. Czy zdajecie sobie sprawę, że mogliście wielokrotnie źle korzystać z łańcucha znaków od czasu utworzenia instancji? Dowiedzieliśmy się już znacznie wcześniej, że łańcuch znaków sprawia trudności w języku C, aczkolwiek w Javie też jest pewna pułapka i to o wiele bardziej perfidna, bo niedająca po sobie niczego poznać. Zapraszam serdecznie, to jest bardzo ważny wątek!
Kontynuujemy wczorajszy wątek dotyczący pakietów, aby traktować go jako drugi krok do tego, jak należy PRAWIDŁOWO ręcznie kompilować kod źródłowy w języku Java. Proszę o cofnięcie się wstecz jeśli nie przerobiliście tamtego etapu, jest on kluczowy, żeby zrozumieć, a także utworzyć własny archiwum JAR. Zapraszam.
Korzystając z pakietów w Javie kompilując to wszystko ręcznie przy użyciu jedynie wiersza poleceń, na pewno niejeden z Was zastanawiał się czemu znowu coś nie działa. Dzisiaj nikogo nie będzie dziwić korzystanie z dowolnego IDE, aczkolwiek warto chociaż parę razy w życiu skompilować swój kod manualnie od początku do końca, aby się dowiedzieć jak to działa w rzeczywistości. Pakiety w języku Java mocno komplikują proces ręcznej kompilacji i tym się teraz zajmiemy w ramach odejścia od tematu kolekcji.
Poruszymy dzisiaj podsumowanie wszystkich trzech typów kolekcji występujących w języku Java: List vs. Set vs. Map. Dosyć sporo się już napisało o niektórych konkretnych kolekcjach więc warto teraz skonfrontować te trzy typy, pokazać ich najlepsze zastosowania oraz zalety i wady. Zapraszam bardzo serdecznie!
Przechodzimy do części praktycznej "równości" obiektów w Javie. Trzymamy się kolekcji "HashSet" i rzucam następującymi hasłami: "hashCode" (zwany "kodem mieszającym") i "equals". Jesteście zaciekawieni znaczeń tych słów kluczowych i w jaki sposób mogą pomóc nam przy ustalaniu czy dwa obiekty są sobie równe? Nie pozostaje Wam nic innego jak wchodzić do środka artykułu!
Jesteście zainteresowani jakie inne kolekcje występują w Javie? OK, zdecydowana większość problemów może zostać rozwiązana za pomocą "ArrayList", natomiast są też takie, które okażą się o wiele skuteczniejsze albo chociaż zaoszczędzą trochę pisania ze względu na ich niektóre działania wykonywane automatycznie. A skoro o automatycznych działania mowa, to obejrzymy sobie kolekcję "TreeSet" i porównamy sobie z poprzednim "książkowym" przykładem.
Zakończyłem jak na razie temat typów generycznych w Javie. Te trzy części tłumaczenia zastosowania typów ogólnych były potrzebne po to, abyśmy mogli teraz spokojnie wrócić do poprzedniego rozdziału na którym stanęliśmy. Możemy w końcu porównać sobie interfejs "Comparable" do poprzedniego i zobaczyć jak daleko idą te różnice.
Javy nie ma końca. Kontynuujemy temat typów ogólnych. Poprzednio wspomniałem o słowie kluczowym "extends", które nie tylko jest wykorzystywane podczas dziedziczenia przez klasy, ale także przez typy generyczne. Jeśli nie przeczytaliście fragmentu o metodach uogólnionych, to przerwijcie czytanie w tym miejscu i wróćcie do tamtego artykułu, bo to będzie kontynuacja. Poznajcie tajemnicę drugiego znaczenia "rozszerzania", bo przy programowaniu uogólnionym ma to dwojakie zastosowanie.
Przejdziemy teraz do drugiej części trudnego do przyswojenia tematu jakim są typy generyczne. Java posiada szerokie pole do popisu jeśli chodzi o programowanie uogólnione, bo tak to się elegancko nazywa. Kolejnym krokiem w ich prawidłowym rozumieniu są metody generyczne. Jak je tworzyć, jak je rozumieć a co najważniejsze, jakie dają korzyści. Wszyscy zainteresowani niech zaglądają do środka!
Wczoraj poruszyłem kwestią związaną z sortowaniem kolekcji. Nie możemy iść dalej z kontynuacją tego tematu bez podstawowego rozumienia typów generycznych. Typy generyczne stanowią kręgosłup wszystkich wykorzystywanych kolekcji w Javie i nie tylko w tym języku. Zrobię teraz do tego wstęp na taki sam kształt jak wtedy z wątkami.
Czy już wiecie jak możemy posortować dowolną kolekcję w języku Java, która przyjmuje obiekty typu klasowego? Mamy dwie drogi: interfejs "Comparator" lub interfejs "Comparable" (drugi będzie przedstawiony później). Dzięki nim, jesteśmy w stanie ustalić kryterium w jaki sposób mają być sortowane obiekty o którym pisałem w pierwszej części.
Póki co, postanowiłem uznać serię artykułów na temat wątków w Java za zakończoną. Gdyby trzeba było coś jeszcze dodać, to z pewnością później wprowadzę. Rzućmy teraz okiem na kolekcje. "ArrayList" nie trzeba nikomu przedstawiać, aczkolwiek co byście powiedzieli gdyby konieczne było sortowanie "ArrayList"? Jest możliwość posortowania najbardziej powszechnie stosowanej kolekcji bez stosowania żadnych skomplikowanych sztuczek (jak się później okaże, zależy jakiego typu są argumenty). Zapraszam do środka artykułu.
Dobra. Dotychczas temat wątków opierał się o same podstawowe zagadnienia. Uprzedzam, że od tej pory będziemy wchodzić w szczegóły, które mogą spowodować zrobienie sobie dłuższego "przystanku". Jak dobrze pamiętają ci, którzy czytali samą teorię, wątek w Java musi być opatrzony serią niezbędnych zabezpieczeń celem eliminacji wszelkich kolizji. Tematem na dziś będzie spójność danych, czyli jak sprawić, żeby modyfikacja pewnej danej przez jeden wątek obowiązywała w innych obecnie działających wątkach. Java dysponuje pewnymi sposobami wdrażania takiego zabezpieczenia.
Programując wątki w języku Java, każdy z Was bez wyjątku musi pojąć jedną bardzo ważną rzecz dotyczącą samego ich usypiania. OK, wiemy już, że za pomocą statycznej metody "sleep" klasy "Thread", możemy oddziaływać na przebieg działania wątku po prostu go opóźniając o podaną liczbę milisekund. Natomiast jest jeden niuans domagający się wyjaśnień. Uśpienie wątku też coś przed nami ukrywa. Serdecznie zapraszam do środka artykułu.
Lecimy dalej naprzód z wątkami w Javie! Dzisiaj skonfrontujemy oba sposoby tworzenia wątków. Jest możliwość zrobienia tego od strony dziedziczenia klasy "Thread", ale mamy również do dyspozycji implementację interfejsu "Runnable". Którą drogę wybrać? Czy są jakieś różnice w działaniu? A może w efektywności? Przekonajcie się już teraz. Wątek w Java tworzony na dwa sposoby zapisu.
Oto przed Wami część druga rozdziału poświęconego wątkom w języku Java. Wczoraj opisałem dosyć rozlegle jak to wygląda teoretycznie. Programowanie współbieżne przeznaczone jest tylko dla nieco bardziej "kumatych" w tej dziedzinie i z pewnością amatorzy się w tym nie odnajdą. Dzisiaj uzupełnimy sobie tę wiedzę o drugą "połowę", czyli praktykę. Utworzymy sobie własny pierwszy nowy wątek w Java!
Przesuwamy się ku coraz trudniejszym tematom języka Java i tym razem rozpocznę serię artykułów dotyczących wątków. Wątek w Java jest już zaawansowanym rozdziałem w programowaniu i nawet doczekał się własnego działu naukowego, "programowanie współbieżne". Bez względu na wszystko, trzeba zacząć od samego początku i najpierw wyjaśnić sobie teorię zanim przejdziemy do części praktycznej. Zapraszam serdecznie do wpisu.
Kontynuujemy rozpoczęty temat połączenia sieciowego w języku Java, aczkolwiek dzisiaj będzie więcej teorii niż praktyki z wklejanymi paskami z kodami źródłowymi celem przybliżenia Wam pewnych faktów dotyczących wprowadzanych portów do obiektów klasy "Socket". Temat niniejszego artykułu: port protokołu i pewne zasady jakie trzeba przestrzegać.
Zmęczeni już tą biblioteką Swing? Spokojnie, zmieniamy temat na całkiem inny i przejdziemy teraz do zagadnień związanych z połączeniem sieciowym. Java pozwala na łatwe tworzenie połączenia sieciowego na podstawie architektury klient-serwer. Przedstawiam Wam klasę "Socket" - to od niej zaczyna się cała historia.