Można już ściągać Javę 10 i pobawić się varami :P
http://openjdk.java.net/jeps/286

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Z tego co zrozumiałem, to var nadal będzie można użyć jako nazwy zmiennej, a samo słówko kluczowe jest wrażliwe na wielkość liter, czyli dalej będzie się kompilował taki kod:

int var = 5;

class Var {
}

ale taki już nie:

class var {
}

Biada temu kto tak nazywa klasy :]

var będzie można używać jeśli typ będzie można wywnioskować z typu po prawej stronie np.: var napis = "Napis";

Ja jestem jeszcze za mały w te klocki, ale dla Intelli to ciągle chyba beta <<< nie zabijać posłańca, jak coś namieszał :)

No najwidoczniej IntelliJ nie ma jeszcze oficjalnego wsparcia dla vara, ale to kwestia czasu.

BEGIN STARY DZIAD NARZEKA
Fajnie, fajnie. Ale tam gdzie mógłbym użyć javy 10 to już i tak od dawna mam Kotlina, albo jeszcze fajniejszą Scale. Gdzie jest val(!) i do tego spójny z resztą języka ( a nie tylko łatka na lokalne zmienne).
Tam gdzie muszę używać Javy to niestety projekty, gdzie wielce się cieszę, że udało się (nie tak dawno temu) przewalczyć Javę 8.
Szansa, na zmigorwanie do javy 10 będzie za 5-6 lat, a i tak połowa magicznych tooli rozszerzających magię Springa (bo sam spring ma za mało) będzie się walić (jak zwykle).
Btw. wczoraj miałem mini spór z developerem - 20 lat w javie, który pierwszy raz zobaczył map i flatMap na Streamach w javie 8 (mocne). Ło panie jakie to nieczytelne.... na ifach i list.add to by było.
Skończyło sie tak, że zaproponowałem, że jak chce to sam przepisuje na ify.
END STARY DZIAD NARZEKA

szkoda że nie ma Javy 10 w Oracle PPA, ale napisałem emaila może coś sie dowiem ;]

Nawet Javę 11 da się już ściągnąć ;) http://jdk.java.net/11/

Oczywiście early access preview.

Na 9 ledwo rzuciłem okiem, nie zdążyłem się porządnie pobawić, a tu 10. Duże zmiany? Poza var oczywiście :P

Co 6 miesięcy teraz są nowe wersje, więc wiele nie zdążyli wstawić. W języku żadnych innych zmian już chyba nie ma, ale jest poprawione domyślne GC: http://openjdk.java.net/jeps/307

A tak oprócz tego można juz dociągnąć bazę oracle 18c;)

var list = new ArrayList<String>(); // infers ArrayList<String>

hurraa, 10 lat po C#.

I 20 lat po JavaScript.
Teraz to dopiero będzie dramat - jak przez var jeszcze wiecej ludzi będzie pisać skrypty javy.

Azarien napisał(a):

var list = new ArrayList<String>(); // infers ArrayList<String>

hurraa, 10 lat po C#.

</flame>

Mimo wszystko jest coraz mniej znaczących różnic między typowym kodem w C#, a w Javie. Składnia jest oczywiście trochę inna, ale to już powoli kosmetyka.

Warto przypomnieć, że wielkimi krokami nadchodzi możliwość zrobienia m.in. listy od małego inta ( http://jdk.java.net/valhalla/ ), więc w kulawych porównaniach wydajności C# vs Java, które do tej pory testują narzut boxowania w Javie ta zacznie wychodzić na prowadzenie.

Przykro mi, ale widzę, że czas przesiadać się na Kotlina / Scalę. A szkoda, bo mogło to mieć ręce i nogi. Teraz jedynie nauswa się pytanie - Scala czy Kotlin.
Scala troche trudniejsza i potworek w niektórych sprawach - Kotlin hmm..... ciężko mi się do czegoś przyczepić - te componentX() przy data class jest kompletnie idiotyczne, ale dobra.

Jeju jeszcze nie zdążyłem zostać programistą java a już trzeba sie przesiadać na kotlin/scala? Czy bootcampy nadążą za zmianami ?

Szczerze mówiąc nie rozumiem narzekania na var. Nie było - źle, bo nie ma. Jest - źle, bo jest. Tak to wychodzi.

Brak val spowodowany jest tym, że Java idzie w kierunku zmiennych "effectively final" - pisząc z użyciem lambd, i tak kompilator nie skompiluje kodu, który będzie zmieniał wartość zmiennej var, jeśli ta jest używana w lambdach. W kolejnych wersjach języka var będzie rozszerzany (w Javie 11 - możliwość używania w argumentach lambd).

Dalej nie rozumiem dlaczego ograniczyli sie do var i nie dali val, zaden argument nie wydaje mi sie tu sensowny.
Scala czeka; Gdyby tylko nie te biblioteki naszpikowane implicitami... Same implicity i jezyk bardzo lubie, ale jak patrze na te biblioteki, ktore sa tym nafaszerowane do pozygu i zamiast annotation-hell mamy implicit-hell to sie odechciewa, chociaz i tak lepiej niech to dziala w compile-time niz run-time.

@Edit
btw. z tego co czytam tak luzno (moge sie mylic) ale niedlugo (2020?...) w 'Project Valhalla' generyki maja byc 'reified'. Czy to czasem nie zboostuje Scala'owego type system'u, ktory aktualnie przez to cierpi, jeszcze mocniej? :) Z tego co sie orientuje nie da sie tego zaimplementowac w jezyku, tylko w JVM wiec Scala tez podlapie.

btw. z tego co czytam tak luzno (moge sie mylic) ale niedlugo (2020?...) w 'Project Valhalla' generyki maja byc 'reified'.

Właśnie mają nie być 'reified'. Jak na razie jedynym językiem z 'reified generics' jest C# (i inne z .NETu). To co jest w miarę potwierdzone to:

• możliwość tworzenia klas wartościowych (value classes)
• możliwość parametryzowania generyków prymitywami i klasami wartościowymi

Reified generics nie są potrzebne do parametryzowania generyków klasami wartościowymi. To mit powtarzany przez C#-owców. Reified generics są głównie po to, by mieć jeszcze bardziej szalone zabawy z refleksją. Natomiast klasy wartościowe, tablice takich klas i generyki korzystające z takich klas służą polepszeniu wydajności i oszczędności pamięci.

@karolinaa Java tymi zmianami w stylu JavaScript co pół roku dla mnie umarła, teraz będę uczył się Rust, język najbardziej lubiany na Stackover. W przyszłości zapewne będą w nim pisane sterowniki i programy pod przyszłe nowoczesne systemy RedoxOS, FuschiaOS.

Jak dla mnie brak vara był największą bolączką Javy. Tak więc cieszę się, że Oracle jest ze mną.

To pewnie gettery i settery już są? Czy dalej lombkm albo pisanie metod

Jakie gettery i settery? To chyba tylko w starych projektach. _.copy(...) i value class nadal bardzo brakuje.

No takie jak w C# są. Głupie pytanie, wiesz co to getter i setter?

Tak. Tylko w javie nie są za bardzo potrzebne. No chyba, że ktoś w starych frameworkach sie grzebie.

W sumie taką samą konwencją jak metody get i set mogłoby być poprzedzanie publicznych pól np przedrostkiem "attr".

Skoro jest Lombok to po co dalej coś kombinować? Można by co najwyżej dać osobną kontrolę nad zapisem i odczytem gołego pola, tzn z zewnątrz tylko do odczytu, a z wewnątrz można robic cokolwiek.

Co do setterów i getterów to ma być nowy pojemnik danych datum, którego będzie można używać w zamian za klasę. Przykładowo

datum Punkt(
  int x;
  int y;
}

równoważne jest z tym

public class Point {
    private int x;
    private int y;
     
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    public int getX() {
        return x;
    }
    public void setX(int x) {
        this.x = x;
    }
    public int getY() {
        return y;
    }
    public void setY(int y) {
        this.y = y;
    }
}

Kolejne zmiany to np. instrukcja swich będzie mogła przyjmować obiekty, a nawet zwracać wartość. Więcej do poczytania tutaj https://javastart.pl/b/java/co-nowego-w-javie/.

Wibowit napisał(a):

Skoro jest Lombok to po co dalej coś kombinować? Można by co najwyżej dać osobną kontrolę nad zapisem i odczytem gołego pola, tzn z zewnątrz tylko do odczytu, a z wewnątrz można robic cokolwiek.

Jest dokładnie odwrotnie. Trzeba kombinować z Lombokiem, bo sama Java jest ułomna. Poprzestawiało ci się coś.

Boisz się używać bibliotek?

Dla mnie jako fana @Value pattern to te settery są ułomne. Generalnie nie przepadam za mutowalnymi DTO ;)