7:45 Też mnie to wpienia z tymi break'ami w switch'u (także w C/C++). W Pascalu już co najmniej 30 lat temu potrafili obyć się bez tego nieszczęsnego break'a (w "case"). Po kilkunastu latach kodzenia w Delphi i przejściu na C++, a potem na Javę, często zapominałem o tym break'u. W tym nowym "odkrywczym" rozwiązaniu switch'a w Javie wykorzystuje zapis jakby wyrażenia lambda, choć zapewne nim nie jest. Lepiej późno, niż wcale. 😁 Dzięki za ciekawy film o nowościach Javy👍, kiedyś pewnie się przydadzą, bo narazie kodzę na wersji 13-tej.
Ja do testowania API zamiast rekordów używam Data Lombok, łatwiej jest wtedy utworzyć data model jakiegoś endpointa, zwłaszcza, ze gettery i settery są wbudowane. Tym bardziej jest to wygodne w przypadku kiedy mamy więcej pól niż w podanym przez Kamila przykładzie.
Wszystko zależy od problemu, bo rekordy i adnotacja @Data z Lomboka - choć występują między nimi podobieństwa - mają jednak inne zastosowania. Fajnie tłumaczy to jeden z architektów Javy, Brian Goetz, w tym poście: stackoverflow.com/a/61325018/1159338
Siema, na pewno gdzieś z tyłu głowy mam taki pomysł, ale póki co - ze względu na to, że inne rzeczy mają wyższy priorytet - musi on jeszcze poczekać na realizację. Nie chcę obiecywać czegoś, czego nie uda mi się zrealizować, więc na pewno taki poradnik nie pojawi się w ciągu najbliższych kilku miesięcy, ale co będzie później, na przykład w drugiej połowie przyszłego roku, zobaczymy :) Będę na pewno pamiętał o tym temacie i w jakiejś formie postaram się go zrealizować :)
(komentarz piszę po obejrzeniu pierwszej części filmu, przed switchem, jeśli odpowiedź pojawia się później to przepraszam) Dlaczego wersje LTS wychodzą tak rzadko (mniej więcej co trzecia, bo 8 w 2014, 11 w 2018, a przed obejrzeniem tego filmu dałbym sobie rękę uciąć że 14 też jest dłużej wspierana), natomiast częściej są wrzucane krócej wspierane wersje, skoro i tak w praktyce ludzie korzystają tylko z LTSów? Dlaczego po prostu nie ma tak jak w C++, że nowy (wyróżniony nowym numerem) standard pojawia się co 3 lata, a między tym są tylko jakieś wersje beta czy też snapshotowe? Jest w tym jakaś logika, czy po prostu taki kaprys osób zajmujących się utrzymaniem Javy?
Częstsze wydania sprawiają, że łatwiej jest przystosować się do zmian. Jeżeli pracujemy nad własnymi projektami, co pół roku możemy aktualizować Javę i wykorzystywać nowe rozwiązania. Również twórcy zewnętrznych narzędzi są zmuszeni do regularnego dbania o kompatybilność - a łatwiej jest dopasować bibliotekę do nowej wersji Javy raz na pół roku niż raz na trzy lata. To jak w pracy z Gitem - im częściej robimy commity, im częściej robimy rebase z masterem, tym mniej konfiliktów i praca idzie sprawniej :) Swoją drogą widzę teraz, że LTS-y będą częściej - co dwa lata zamiast co trzy. Tak to wyglądało jeszcze w sierpniu: web.archive.org/web/20210823214935/www.oracle.com/java/technologies/java-se-support-roadmap.html "For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release." A tak to wygląda obecnie: www.oracle.com/java/technologies/java-se-support-roadmap.html "Oracle intends to make future LTS releases every two years meaning the next planned LTS release is Java 21 in September 2023."
Możemy zdefiniować taki konstruktor w następujący sposób: public record PersonRecord(String name, int age) { public PersonRecord() { this("default", -1); } } Możemy też zdefiniować konstruktory przyjmujące inne argumenty niż domyślny (w przypadku rekordów nazywany kanonicznym) konstruktor, który przyjmuje argumenty dla każdego pola: public record PersonRecord(String name, int age) { public PersonRecord(String name) { this(name, -1); } public PersonRecord() { this("default", -1); } } Ale pozostaje jeszcze pytanie o sens takiego rozwiązania. Rekordy są niemutowalne (niezmienne), więc po utworzeniu rekordu z użyciem konstruktora bezargumentowego, pola otrzymują domyślne, zdefiniowane przez Ciebie w tym konstruktorze, wartości i nie da się ich już w żaden sposób zmienić.
Fajnie zobaczyć wszystkie zebrane nowości w jednym miejscu :)
7:45 Też mnie to wpienia z tymi break'ami w switch'u (także w C/C++). W Pascalu już co najmniej 30 lat temu potrafili obyć się bez tego nieszczęsnego break'a (w "case"). Po kilkunastu latach kodzenia w Delphi i przejściu na C++, a potem na Javę, często zapominałem o tym break'u. W tym nowym "odkrywczym" rozwiązaniu switch'a w Javie wykorzystuje zapis jakby wyrażenia lambda, choć zapewne nim nie jest. Lepiej późno, niż wcale. 😁 Dzięki za ciekawy film o nowościach Javy👍, kiedyś pewnie się przydadzą, bo narazie kodzę na wersji 13-tej.
8:00
"Me oczy ujrzały kod, a serce rzekło piekne()"
Wielkie dzięki za materiał!
Fajnie wyjaśnione. Dzięki za materiał! 😁
dzieki za material!
Fajne, podobać się. Sąsiadki bym nie odmówił za taki materiał, pozdrawiam!
Ja do testowania API zamiast rekordów używam Data Lombok, łatwiej jest wtedy utworzyć data model jakiegoś endpointa, zwłaszcza, ze gettery i settery są wbudowane.
Tym bardziej jest to wygodne w przypadku kiedy mamy więcej pól niż w podanym przez Kamila przykładzie.
Wszystko zależy od problemu, bo rekordy i adnotacja @Data z Lomboka - choć występują między nimi podobieństwa - mają jednak inne zastosowania. Fajnie tłumaczy to jeden z architektów Javy, Brian Goetz, w tym poście: stackoverflow.com/a/61325018/1159338
Witam. Czy jest szansa na to że pojawia się poradniki do języka C# w przyszłości. Patrząc na jakość tych poradników wyszłoby by to świetnie
Siema, na pewno gdzieś z tyłu głowy mam taki pomysł, ale póki co - ze względu na to, że inne rzeczy mają wyższy priorytet - musi on jeszcze poczekać na realizację. Nie chcę obiecywać czegoś, czego nie uda mi się zrealizować, więc na pewno taki poradnik nie pojawi się w ciągu najbliższych kilku miesięcy, ale co będzie później, na przykład w drugiej połowie przyszłego roku, zobaczymy :) Będę na pewno pamiętał o tym temacie i w jakiejś formie postaram się go zrealizować :)
(komentarz piszę po obejrzeniu pierwszej części filmu, przed switchem, jeśli odpowiedź pojawia się później to przepraszam)
Dlaczego wersje LTS wychodzą tak rzadko (mniej więcej co trzecia, bo 8 w 2014, 11 w 2018, a przed obejrzeniem tego filmu dałbym sobie rękę uciąć że 14 też jest dłużej wspierana), natomiast częściej są wrzucane krócej wspierane wersje, skoro i tak w praktyce ludzie korzystają tylko z LTSów? Dlaczego po prostu nie ma tak jak w C++, że nowy (wyróżniony nowym numerem) standard pojawia się co 3 lata, a między tym są tylko jakieś wersje beta czy też snapshotowe? Jest w tym jakaś logika, czy po prostu taki kaprys osób zajmujących się utrzymaniem Javy?
Częstsze wydania sprawiają, że łatwiej jest przystosować się do zmian. Jeżeli pracujemy nad własnymi projektami, co pół roku możemy aktualizować Javę i wykorzystywać nowe rozwiązania. Również twórcy zewnętrznych narzędzi są zmuszeni do regularnego dbania o kompatybilność - a łatwiej jest dopasować bibliotekę do nowej wersji Javy raz na pół roku niż raz na trzy lata. To jak w pracy z Gitem - im częściej robimy commity, im częściej robimy rebase z masterem, tym mniej konfiliktów i praca idzie sprawniej :)
Swoją drogą widzę teraz, że LTS-y będą częściej - co dwa lata zamiast co trzy. Tak to wyglądało jeszcze w sierpniu: web.archive.org/web/20210823214935/www.oracle.com/java/technologies/java-se-support-roadmap.html
"For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release."
A tak to wygląda obecnie: www.oracle.com/java/technologies/java-se-support-roadmap.html
"Oracle intends to make future LTS releases every two years meaning the next planned LTS release is Java 21 in September 2023."
a co jak w rekordzie chcemy użyć bezparametrowego konstruktora?
Możemy zdefiniować taki konstruktor w następujący sposób:
public record PersonRecord(String name, int age) {
public PersonRecord() {
this("default", -1);
}
}
Możemy też zdefiniować konstruktory przyjmujące inne argumenty niż domyślny (w przypadku rekordów nazywany kanonicznym) konstruktor, który przyjmuje argumenty dla każdego pola:
public record PersonRecord(String name, int age) {
public PersonRecord(String name) {
this(name, -1);
}
public PersonRecord() {
this("default", -1);
}
}
Ale pozostaje jeszcze pytanie o sens takiego rozwiązania. Rekordy są niemutowalne (niezmienne), więc po utworzeniu rekordu z użyciem konstruktora bezargumentowego, pola otrzymują domyślne, zdefiniowane przez Ciebie w tym konstruktorze, wartości i nie da się ich już w żaden sposób zmienić.
Rok 2088 a my używamy javy 8
Ten nowy switch da się przecież używać juz w 16
Nawet wcześniej, bo już w Javie 13 :) Odcinek jest o funkcjonalnościach, które pojawiły się od Javy 9 do Javy 17.
@@JakNauczycSieProgramowania ok. Po prostu myslalem ze chodzi tylko o 17, a odcinke fajny