Już pora na v 14 ?

1

Jak jest z rzeczywistym przygotowaniem szerokiego rynku do Javy 14?
Frameworki, serwery, już się dotestowało, czy jeszcze nie?

Czy operować na 11 ?
Interesuje mnie ogólny wybór wersji, na development i produkcję

2

Na produkcje z Javą 14? :D A jakie biblioteki/frameworki z nią wspołpracują? Jakos slabo to widze. Chyba, ze piszesz w "czystej" Javie, wtedy mozna próbować.
Z mojego doświadczenia wynika, że jak ktos uzywa Javy 11 na produkcji to jest "na czasie" ;)

1

Java 14 to nie LTS. LTSy to 11, 17, 23, 29, +6, +6, +6, +6, itd

6

Pora na Kotlina 🔥🔥🔥

3
p_agon napisał(a):

Dlaczego ostatnio powstaje tyle wersji? Gonią C# czy jak?

Wydają wersję co pół roku choćby nie wiem co się działo. I IHMO jest to dobra decyzja. Dzięki temu nie musimy czekać na rekordy jeszcze półtora roku. A jak już wejdą w wersji 17 to będą przetestowane

0
KamilAdam napisał(a):
p_agon napisał(a):

Dlaczego ostatnio powstaje tyle wersji? Gonią C# czy jak?

Wydają wersję co pół roku choćby nie wiem co się działo. I IHMO jest to dobra decyzja. Dzięki temu nie musimy czekać na rekordy jeszcze półtora roku. A jak już wejdą w wersji 17 to będą przetestowane

Po co czekać? To bez nowej funkcji języka nie umiesz czegoś zrobić?

2
PerlMonk napisał(a):

Po co czekać? To bez nowej funkcji języka nie umiesz czegoś zrobić?

Java 1.4 wystarczy każdemu.
/s

Rozwijając odpowiedź @KamilAdam:
Wydawanie wersji co pół roku sprawia, że łatwo jest przetestować nowe ficzery w wersji poglądowej (preview, incubator, experimental, zwał jak zwał) i przesłać opinię do autorów Javy, by poprawili tego ficzera zanim zostanie wypuszczona jego wersja stabilna.

2
PerlMonk napisał(a):
KamilAdam napisał(a):
p_agon napisał(a):

Dlaczego ostatnio powstaje tyle wersji? Gonią C# czy jak?

Wydają wersję co pół roku choćby nie wiem co się działo. I IHMO jest to dobra decyzja. Dzięki temu nie musimy czekać na rekordy jeszcze półtora roku. A jak już wejdą w wersji 17 to będą przetestowane

Po co czekać? To bez nowej funkcji języka nie umiesz czegoś zrobić?

Oczywiście że umiem. Java od dawna jest językiem kompletnym w sensie Turinga. Chodzi o to żeby było łatwiej pisać kod lub o to żeby był wydajniejszy. Rekordy pozwolą akurat pisać wydajniejszy kod w mniejszej ilości linii. win-win po prostu. Teraz tylko czekać aż klasy danych z Kotlina i klasy przypadków z Scali będą przerabiać by pod spodem używały rekordów

0

@KamilAdam: Jak znam bezwładność projektów w jakkolwiek większej firmie, aktualizacja Javy będzie przeskokiem o kilka wersji.

2

@PerlMonk:
Skoro jeszcze nie dotarło to może dorzucę jeszcze rys historyczny. Do tej pory było tak, że nowe wersje Javy były co kilka lat i wszystkie nowe ficzery w nich były wyłącznie w wersjach stabilnych (czyli wstecznie niekompatybilne zmiany były niedozwolone). Takie podejście powodowało paraliż, Java zamiast się dynamicznie rozwijać to była hamowana przez katastroficzne wizje krytyków nowych rozwiązań, którzy mieli zupełnie inną wizję niż autorzy Javy i uważali, że tylko ich podejście jest słuszne. Obecnie zamiast takiego modelu wydawniczego mamy nową wersję Javy co pół roku, kontrowersyjne ficzery są wydawane początkowo w wersjach niestabilnych, są łatwe do przetestowania (bo mamy nowe pełne wydania Javy, a nie jakieś alpha buildy), a paniki jest mniej, bo zamiast czytać katastroficzne wizje każdy zainteresowany może sobie potestować na luzie nową wersję Javy i wydać własną opinię.

0

@Wibowit: A miej sobie własną opinię. W tej chwili mam ją gdzieś :D

5

Nie rozumiem dlaczego ktoś zdrowy na umyśle miałby niepokoić się szybko zmieniającym się głównym numerem wersji? To jakiś rodzaj fobii? Jak widzisz zmieniające się wersje Chrome'a, Firefoksa, Edgium, Opery, itp to masz jakieś negatywne reakcje?

1

Java 14 to nie LTS. LTSy to 11, 17, 23, 29, +6, +6, +6, +6, itd

To jest jakiś zakaz używania nie-LTSów na prodzie? Nikt na 12 na przykład nie operuje? ;)

0
Wibowit napisał(a):

Jak widzisz zmieniające się wersje Chrome'a, Firefoksa, Edgium, Opery, itp to masz jakieś negatywne reakcje?

Tak.

1

Arytmofobia

0
Wibowit napisał(a):

Nie rozumiem dlaczego ktoś zdrowy na umyśle miałby niepokoić się szybko zmieniającym się głównym numerem wersji? To jakiś rodzaj fobii? Jak widzisz zmieniające się wersje Chrome'a, Firefoksa, Edgium, Opery, itp to masz jakieś negatywne reakcje?

Szczerze mówiąc nie rozumiem, co tak szybkie zmienianie numerów wersji wnosi. Już dawno nauczyłem się te numerki olewać. Nie wiem, którą wersję FF mam, w każdym razie jest najnowsza bo się ff sam aktualizuje.

O ile pamiętam to miał być jakiś zabieg marketingowy, czy się mylę? Jeśli tak, to co wnosi do marketingu uczenie ludzi ignorowania numerków?

2

Nie zabieg marketingowy a implementacja https://en.wikipedia.org/wiki/Release_early,_release_often Już w tym temacie napisałem, że taka zmiana ma po prostu ułatwić życie autorom Javy - zamiast przeciągać release w nieskończoność, bo implementacja jakiegoś tam ficzera długo zajmuje to ustawia się sztywne ramy czasowe, a jak ktoś się z ficzerem spóźni to nie ma tragedii bo kolejny release już za pół roku. Dodatkowo są ficzery w postaci rozwojowej (preview/ incubator/ experimental/ etc) w publicznych wersjach Javy co ułatwia ich testowanie przez społeczność Javową i zbieranie opinii.

Linux też ma time-based releases tylko zamiast 51, 52, 53, 54 mamy 5.1, 5.2, 5.3, 5.4. Linux w wersji X.0 jest po prostu kolejną wersją po X-1.<najwyższy numerek>, nic szczególnego nie wnosi. Dla przykładu Linus stwierdził, że w wersji głównej 4.x będzie 21 mniejszych wersji (od 4.0 do 4.20) bo na palcach jest w stanie policzyć od 0 do 20 i zrobił to pod koniec jej istnienia. Jest to niezbyt poważne podejście i dlatego numerowanie dużymi wersjami jest chyba najlepsze.

6

Java 8 forever.

0

System który nie jest 100% kompatybilny w przód, i nie może sobie pozwolić na update do takiej 14, ciężko nazwać "na czasie".

Każda taka funkcjonalność która wymaga większej zmiany, dokłada się do bezwładności aplikacji w ramach ruchu w przód, w kierunku nowszych technologii.

Niemniej, mało kto nie ma wyjeb*ne na kompatybilność w przód :D

3

Kiedyś miałem nadzieję, że Java 9 i w górę są robione szybko i bezwględnie aby urypać Springa i Java EE.
Z JavaEE się udało, ale Spring wręcz zyskał, dostosowują go super szybko do nowych wersji.

1

Musicie rozumieć ze szybkie wydawanie małych nowych wersji to nie zabieg marketingowy

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