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ę
- Rejestracja:około 11 lat
- Ostatnio:około rok
- Postów:45
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" ;)
edytowany 1x, ostatnio: xxxmateusz00xxx
- Rejestracja:prawie 20 lat
- Ostatnio:około 7 godzin
1
Java 14 to nie LTS. LTSy to 11, 17, 23, 29, +6, +6, +6, +6, itd
Zobacz pozostały 1 komentarz
Wibowit
LTS są co 3 lata, a nie co 3 release'y. Są 2 release'y na rok, a więc jak to pomnożysz to dostajesz LTS co 6 release'ów.
Wibowit
Jak chcesz się uczyć Javy od podstaw to możesz poszukać czegoś do Javy 11, bo to ostatni LTS. Sprawdziłem przed chwilą i książki Caya Horstmanna do Javy zostały uzupełnione o Javę 11, więc możesz je brać. W korpo natomiast pewnie nadal często spotykana będzie Java 8.
Wibowit
No to się naucz. Po co w kółko książki do wszystkiego? Przecież pisanie książki trwa dłużej niż cykl wydawniczy Javy to jak mają autorzy książek nadążać? Są 3 miesiące od zamrożenia listy ficzerów do wydania Javy. Czy w 3 miesiące autor książki zdąży poznać nowe funkcje, wyrobić sobie na ich temat opinię, napisać o tym rozbudowany materiał, przejrzeć w poszukiwaniu błędów i rozesłać książki do księgarni na całym świecie?
Wibowit
Nie wiem, nie czytam. Zamiast czekać na książki czytam opisy nowości od razu u źródła i testuję jak mam ochotę. Po co czekać? :)
Wibowit
Ja robię tak, że wchodzę sobie na listę ficzerów dla danej wersji Javy, np http://openjdk.java.net/projects/jdk/14/ i czytam co tam jest w JEPach napisane.
- Rejestracja:około 17 lat
- Ostatnio:około 9 godzin
- Postów:1873
6
Pora na Kotlina 
Zobacz pozostałe 10 komentarzy
Koniec wsparcia dla Kotlina byłby absurdalny, Kotlin zdobywa fejm, możesz mieszać Springa i Kotlina (czego nie da się za bardzo ze Scalą), coraz wiecej firm wprowadza Kotlina. Ale nikt nie zmusza żebyś z tego języka korzystał, dla mnie spoko, więcej "konserw" to będzie mniejszy bój o pracę z Kotlinem :D :D :D
- Rejestracja:ponad 6 lat
- Ostatnio:7 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
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
edytowany 1x, ostatnio: KamilAdam
- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
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ć?
- Rejestracja:prawie 20 lat
- Ostatnio:około 7 godzin
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.
- Rejestracja:ponad 6 lat
- Ostatnio:7 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
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
Zgadzam się, ale co twój komentarz ma wspólnego z moim postem?
- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
0
@KamilAdam: Jak znam bezwładność projektów w jakkolwiek większej firmie, aktualizacja Javy będzie przeskokiem o kilka wersji.
- Rejestracja:prawie 20 lat
- Ostatnio:około 7 godzin
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ę.
edytowany 1x, ostatnio: Wibowit
- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
0
@Wibowit: A miej sobie własną opinię. W tej chwili mam ją gdzieś :D
Zobacz pozostałe 5 komentarzy
Jak to "w końcu"? W którym miejscu sugerowałem, że trzeba się spieszyć? Kuleje u ciebie czytanie ze zrozumieniem.
Dobra, to napiszę inaczej: w ogóle nie sugerowałem, że trzeba się spieszyć. Jedynie ty napisałeś z czapy jakieś
Szybciej! Szybciej, bo nie zdążycie!!! Deadliny was gonią. Jak dogonią, to będzie fuckup.
Swoją drogą artykuł jednej osoby z Allegro o tym jak wrócili z Kotlina na Jave, wzbudził bardzo dużą kontrowersje. Nie sam fakt, ale argumentacja. Bardzo szybko samo allegro odcielo się, że dotyczy to opinii jednego zespołu, a nie wszystkich ich zespołów.
- Rejestracja:prawie 20 lat
- Ostatnio:około 7 godzin
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?
- Rejestracja:ponad 5 lat
- Ostatnio:około 4 lata
- Postów:239
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? ;)
Zobacz pozostałe 4 komentarze
Słyszysz jakieś głosy w swojej głowie i mówisz, że to moje.
Wszystkie twoje posty w tym temacie to czysty trolling.
- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
0
Wibowit napisał(a):
Jak widzisz zmieniające się wersje Chrome'a, Firefoksa, Edgium, Opery, itp to masz jakieś negatywne reakcje?
Tak.
Polecam się tym nie przejmować.
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
- Rejestracja:ponad 10 lat
- Ostatnio:prawie 4 lata
- Postów:473
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?
- Rejestracja:prawie 20 lat
- Ostatnio:około 7 godzin
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.
edytowany 1x, ostatnio: Wibowit
Częste wydawanie nowych wersji pozwala szybciej integrować się z nowymi zmianami, szybciej wyłapywać błędy, unikać ich propagacji, szybszy feedback od użytkownika końcowego oraz pozwala uniknąć wielkich problematycznych zmian. Małe aktualizacje wersji są najs. To jest zgodne z podejściami typu divide and conquer, CI, CD, Agile. Zgadzam się ze wszystkim co napisałeś oprócz ‚to niezbyt poważne podejście i dlatego‚ - możesz policzyć na palcach to prosty i mądry argument. Nie zajmuj się powagą podejścia, mądrość człowieka rozjaśnia jego oblicze
To liczenie na palcach Linus sobie wymyślił dopiero, gdy nadał numer wersji 5.0 po 4.20. Wcześniej nikt nie wiedział co Linusowi przyjdzie do głowy.
- Rejestracja:ponad 21 lat
- Ostatnio:około 2 godziny
6
Java 8 forever.
Fakt, jedna z najistotniejszych wersji. Moze 5 była podobnie epokowa.
- Rejestracja:prawie 15 lat
- Ostatnio:około 4 godziny
- Lokalizacja:Laska, z Polski
- Postów:10056
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
a potrafisz przewidzieć co uwalą albo zepsują za lat kilka, by cały projekt był kompatybilny bez zmian z Javą 20? ;D
Chciałem po prostu zaznaczyć jakie kryteria musiałby spełniać projekt żeby nazwać go "na czasie".
Java ma wysoką kompatybilność dopóki nie kombinuje się z unsafe, classloaderami czy głęboką refleksją. Unsafe jest deprecated od samego początku i to jest tak jakby polegać na undefined behavior w C czy C++. Classloadery się pozmieniały w Javie 9 przy okazji modularyzacji - wszystkie programy nadal chodzą oprócz tych, które polegały na nieudokumentowanych wnętrznościach standardowych classloaderów. Glęboka refleksja od zawsze była problemem - jeśli jest jakiś magiczny framework, który musi analizować wszystko w runtime to sypie się przy nowych ficzerach, bo ich nie zna.
No jeśli ktoś korzysta z takich framework ów to siłą rzeczy jego projekt nie jest kompatybilny w przód :)
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
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.
- Rejestracja:prawie 12 lat
- Ostatnio:prawie 5 lat
- Lokalizacja:Warszawa
- Postów:1683
1
Musicie rozumieć ze szybkie wydawanie małych nowych wersji to nie zabieg marketingowy