Java 11 - dostępna od jutra

Jedyne co mnie na razie cieszy w tej wersji, to http client wbudowany w SDK i LTS.
Nie zaglebialem sie co prawda jeszcze czy ma przyjazne i wygodne API i na co pozwala, ale ciesze sie na sama mysl ze byc moze bede mogl (i moze nawet chcial) zaczac wyp* te rakowe 'apache http client' i nie bede musial sie tlumaczyc. Teraz bedzie 'jest w SDK wiec jest infinite support i awesome'.

Na epsilona nie mam zadnych przypadkow uzycia.
Local-Variable Syntax for Lambda Parameters (JEP 323) to tylko przymiarka do zmian wprowadzajacych pattern matching i enhanced switch statement.
Dynamic Class-File Constants (JEP 309) za nisko dla smiertelnikow.
Remove the Java EE and CORBA Modules (JEP 320) whatever, kto tego jeszcze uzywa

Na epsilona nie mam zadnych przypadkow uzycia.

Benchmarki :)

Local-Variable Syntax for Lambda Parameters (JEP 323) to tylko przymiarka do zmian wprowadzajacych pattern matching i enhanced switch statement.

Eee, że niby w jaki sposób? Jedyne ciekawe przykłady pokazane w JEPie to możliwość dodania adnotacji dla parametrów lambdy z niejawnym typem, czego nie można zrobić w Javie 8. Tzn w Javie 11 możesz zrobić (@Nonnull var x, @Nullable var y) -> x.process(y) ale (@Nonnull x, @Nullable y) -> x.process(y) już nie.

Wibowit napisał(a):

Na epsilona nie mam zadnych przypadkow uzycia.

Benchmarki :)

1. Toole command line, krótko żyjące, gdzie dzieki olaniu GC można jeszcze przyspieszyć działanie (dodac to tego AOT compilation i nabiera sensu java w tym zastosowaniu).
2. Systemy low / no gc, soft real time. Gdzie obecnie nie mamy faktycznie allokacji, bo wyszystko jest allokowane po inicjalizacji systemu. Dzięki epsilon moga nieznacznie wydajniej działać bo odpadnie zupełnie niepotrzebna, dodatkowa komplikacja związana ze startowaniem gc, dodatkowymi wątkami gc itp. Dodatkowo, a może głównie, upraszcza się konfiguracja. Wcześniej trzeba było wydumać parametry gc takie żeby prawie nigdy się nie odpalił (a i tak nie było gwarancji).

Epsilona to ja chętnie przytulę w testach wydajnościowych "wielokskalowych" tzn. gdzie testujemy z poziomu np. SOAPowego API. Odpadnie problem niestabilności pomiarów.

Poza tym teaki noop gc jest fajny wszędzie tam gdzie potrafimy policzyć ile tej pamięci potrzeba. Krótko żyjące usługi raportowe, mikroserwisy w kontenerach, które po prostu się restartują jak poleci OoME, usługi obliczeniowe na prymitywach. Wszelkiej maści małe urządzenia o niekrytycznym znaczeniu np. zarządzanie oświetleniem w domu. Zresztą lepiej niech się wywali, ale wiem o tym, że się wywali, a nie user manual i "pamiętaj by co 248 dni zrestartować swojego Dreamlinera".

Gość napisał sporo prawdy o Javie 11, a pracuje w niej od 20 lat.
przemelek.blogspot.com/2018/10/czas-porzucic-javae.html

Przemek mocno uprościł problem. OpenJDK będzie budowane na bieżącą (jak to ma miejsce obecnie). Kolejne wersje javy będą zawierały różne usprawnienia i nowe API, ale raz na pewien czas będzie wydawany LTS i to właśnie LTSy będą istotne z punktu widzenia produkcji. Poprawki bezpieczeństwa jak były wdrażane tak i będą wdrażane na bieżąco. BTW, dzisiaj też nie aktualizuje się JRE na produkcji wraz z każdą zmianą, bo nie ma takiej potrzeby (bo serwery zazwyczaj żyją w sieci wewnętrznej).

Zresztą cały system modułów wprowadzony w Javie 9 miał za zadanie umożliwienie wydawania JRE w krótkich cyklach. Kolejna rzecz to profile, które żyły sobie w Javie EE, a dzięki modułom wejdą do JSE. Oznacza to, że duże firmy będą używać nie tyle co JSE w wersji X, ale będą tworzyć własne deskryptory, które będą zawierać listę modułów dostępnych na środowisku produkcyjnym.

Ale jaki to będzie miało wpływ na trudność nauki Javy, będzie trudniejsza, ponieważ szybciej będą wprowadzane zmiany jak to ma miejsce w Scali?

Nie. Kolejne wersje będą zawierać kolejne moduły i API, które dodawać będą pewne funkcjonalności. Jednak na początku i tak z nich nie korzystasz w trakcie nauki. Względnie są one "oczywiste" jak switch ze stringami czy multiline string.

BTW, Przemka post z 2010 roku https://przemelek.blogspot.com/2010/12/szkoda-javay.html

Intellij jest napisane w Swing nie w JavaFX :o

Znany antypattern:

Wołanie przodka (ang. CallSuper): W programowaniu obiektowym możliwe jest dziedziczenie właściwości i zachowania klas bazowych i przedefiniowywanie ich. Często metoda, która przedefiniowuje metodę bazową musi się i tak odwołać do metody bazowej w środku, aby skorzystać z jej funkcjonalności – dużo lepszym pomysłem w takim przypadku jest stworzenie czysto abstrakcyjnej metody w klasie bazowej.

Java ma na to nawet podobnie nazywające się słowo kluczowe: super. Mogłoby być CallSuper ps dodam, że w w Androidzie wiele przeciążonych metod, gdzie dodajemy własną implementację i tak musi na końcu lub początku zawierać wywołanie z super, zwykle jako return metody. Mają swoją implementację w klasie bazowej i w dodatku koniecznie trzeba jej użyć.

W Scali jest https://www.artima.com/scalazine/articles/stackable_trait_pattern.html i jest używany np ScalaTeście i (rzadziej) w aktorach Akkowych. Wołanie super jest tam konieczne by wzorzec zadziałał.

Używanie antywzorca żeby wzorzec zadziałał. Hmhh

Stackable Traits działają świetnie w ScalaTeście. Nie widzę przeciwwskazań do ich stosowania w tym przypadku. Zauważ, że zarówno wzorce jak i antywzorce mają sens w pewnym kontekście.

Czy to prawda, że Java jest dalego w tyle za C# ?

W ilości słów kluczowych na pewno.

Niestety C# jest daleko w tyle za Kotlin i Scala. JVM to nie tylko Java, Google odchodzi od Javy na rzecz Kotlina, Go i Dart.

To ciekawe bo jak społeczność zapytała, czy kotlin będzie portowany na net to twórcy stwierdzili, że c# jest znacznie nowocześniejszy i lepiej zaprojektowany niż Java więc nie ma takiej potrzeby.

To piszesz o maszynie wirtualnej C# i JVM, nie o samym języku, może o to im chodziło?

W C# jest ten problem, że jak chcesz coś zrobić w MSbuild bez IDE to przeżyjesz horror. .Net Core .Net 45 .NetStandard, który wymaga .Net 4.6.1. To nie jest tak jak w JVM, że weźniesz sobie kodzik z Windowsa i go po prostu odpalisz na Linuksie.

Cały czas zwracacie uwagę na toole oraz vm. Tutaj chodzi o sam język który jest obecnie w wersji 7.3 :-)

Jeżeli to prawda, że developerzy Kotlina z Rosji wybrali JVM do swojego języka, tylko dlatego, że CLR od Microsoftu był lepszy i nie opłacało się go ulepszać nowym językiem programowania. To co można powiedzieć o kompilatorach powstałych dużo później? Powinny przodować takie nowości jak Go, Swift, Crystal, Rust :)

Sporą zaletą Kotlina jest to, że działa bez problemu na Androidzie, gdzie nowe wersje Javy wchodzą powoli.

Na .NETa jest parę języków spoza MS, ale się nie wybiły: https://en.wikipedia.org/wiki/List_of_CLI_languages
Jeden z języków który się pojawiał na tym forum to pochodzący z Polski https://en.wikipedia.org/wiki/Nemerle - nota bene, wg Wiki w Nemerle inwestowali JetBrains, czyli twórcy Kotlina

Goście z JetBrains zauważyli, że poza C# reszta języków praktycznie nie istnieje w świecie .NETa, więc nie ma sensu się za niego brać:
Kotlin on .NET platform https://discuss.kotlinlang.org/t/kotlin-on-net-platform/2142

Hello,
do you plan to port kotlin on .net platform?

At the moment there are no such plans.

Given that previous attempts to build alternative languages on the CLR (Boo, Nemerle, Scala.NET, even F#) saw extemely limited adoption, the “hell yeah” doesn’t actually sound believable. And C# is a much more modern, full-featured and nicely designed language than Java 8.

Następnym razem zanim ktoś zapyta czemu firma X (inna niż Microsoft) nie przeportuje swojego języka na .NETa to niech sprawdzi jak takie inwestycje wypadały w przeszłości. Skoro nigdy to nie wypalało to po co próbować dalej?

Mam wrażenie, że Kotlin nie zyskałby żadnej popularności, gdyby nie to, że Google uznał go jako oficjalny język dla Androida. A dlaczego? Bo łatwiej było użyć nowego języka, niż adaptować wszystkie ficzery Javy na tej platformie. Java powoli staje się kulą u nogi, widać to po tym, jak duże ma tyły na Androidzie, nawet nie wszystko z Javy8 jest obsługiwane.

I poprawcie mnie jeśli się mylę, nie wydaje mi się żeby Kotlin był szeroko stosowany gdziekolwiek poza Androidem

Ja korzystam z Kotlina na backendzie.
Spring wspiera kotlina na równiz javą, a promują chyba bardziej niż javę (na backend).
Nawet jednym w banku, gdzie pracuje, ruszyły pierwsze projekty w kotlinie (na backend).

W porównaniu do Javy, to fatycznie szeroko nie jest używany. Ale porównanie do Javy jest trochę nie na miejscu. Fakt, że na Androidzie była szybka adopcja wynika po pierwsze z życia w świecie Javy 6.5 i pewnie też z chęci ucieczki od sporów z Oraclem. Natomiast udział Kotlina poza Androidem jest widoczny.

Gradle wspiera, promuje i zachęca do używania Kotlina. N26 pisze głównie w Kotlnie nowe rzeczy. W Allegro korzysta się z Kotlina. Wewnętrzne projekty Googla nierzadko korzystają z Kotlina (zewnętrzne też, ale to głównie Android). Square korzysta z Kotlina nie tylko na Androidzie. Jitpack nowe rzeczy robi w Kotlinie. Pivotal robi dużo dla adopcji Kotlina. Trochę tego jest.

Ok, ale czy poza Androidem nie lepszym wyborem jest Scala?

Jeśli patrzeć na samą moc języka, to pewnie jest. Nie znam Scali na tyle, żeby mieć dobrze wyrobione zdanie, ale na pewno Scala wymaga dużo więcej restrykcji od programistów, bo na więcej pozwala. Dla mnie Kotlin jest bardziej pragmatyczny i można w nim też pisać elegancki i zgrabny kod + ma trochę własnych fajnych mechanizów, które nie są przesadzone. Myślę, że @jarekr000000 miałby więcej do powiedzenia w temacie Scala vs Kotlin.

Natomiast w przypadku wieloplatformowego kodu, to myślę, że Kotlin tak za 2 lata będzie naprawdę solidny pod tym względem i będzie jednym z najlepszych wyborów.

Scala ma 2 wady:
1)Długi czas kompilacji
2)No i składniowo jest dosyć trudna IMO

Nie - lepszym wyborem jest Kotlin.

Kotlin jest trudniejszy od TypeScript, ponieważ stoję przed trudnym wyborem języka. TS przypomina Jave i C# i chyba się na nich wzoruje.