na początek zarzucę powiedzeniem, którego często używała moja babcia: https://pl.wiktionary.org/wiki/jeszcze_si%C4%99_taki_nie_urodzi%C5%82,_co_by_wszystkim_dogodzi%C5%82
nie ma języków, które wszystkim robią dobrze. każdy obrywa krytyką, więc i rozsądnym autorom nie zależy na tym, by wszystkim zrobić dobrze naraz.
Czy tylko ja mam wrażenie, że nowe ficzery w Java są wrzucane kompletnie z d...?
z d... czy po prostu powoli?
Class property. Cały świat używa raka pod tytułem @Lombok bo skoro nasi dziadowie pisali get i set, to my tez tak będziemy. Co stoi na przeszkodzie umożliwienia takiej składni:
public String imie;
@ Override get{
return "";
}
Gdzie do każdego publicznego pola klasy jest generowany "wewnętrznie" getter, jak pole nie jest final to również setter, które w razie czego można sobie z ręki nadpisać?
automatyczne gettery masz przy rekordach, ale takie bez przedrostka get, więc w sumie nie wpisują się w tę starożytną konwencję.
z tego co czytałem jeszcze niedawno na listach dyskusyjnych openjdk to autorzy javy traktują brak properties jako pożądaną prostotę i zaletę javy, tzn. kod typu obiekt.pole zawsze oznacza samo wyodrębnienie wartości pola z obiektu, a nie dowolną logikę, która może być ukryta pod getterem z propertiesa.
Albo dlaczego do kolekcji nie da się dodać MultiMap, tylko jak pojawia się potrzeba użycia, to trzeba rozkminiać, czy opłaca się załadować Guavę do projektu, czy to jeszcze nie ten moment i jednak rzeźbić "coś" samodzielnie. Dlaczego ogólnie ~80% Guavy nie jest w standardowych bibliotekach?
ile języków ma wbudowane multimapy?
Rozwój switch...case w ciągu 30 lat to:
- można jedynie po prymitywach
- po 20 latach, no dobra, robimy rewolucję, można po String
- Kurde, wiedziałem, żeby nie wprowadzać tych enumów.... no dobra, po enumach też można...
- TDD!!! robimy sealed class, wrzućmy ją do switcha
Czemu nie można tego zrobić od razu po czymkolwiek, dokładając od razu możliwość zastąpienia ciągów if else i wpisywania warunków?
to jest zażalenie typu: czemu zaczęli od javy 1.0, a nie od javy 15 od razu? przypominają mi się żale jakiejś panny w internecie. (ironicznie) pytała czemu faceci nie rodzą się od razu po 30-tce, tylko na początku są niedojrzałymi dupkami (to jej opinia). cóż, każdy język dojrzewa i obrasta w nowe bajery z czasem.
Wprowadzenie null safety... no kurczę jak można wprowadzać null safety opcjonalnie?! Ok, rozumiem, legacy, ale przecież można zwyczajnie wprowadzić opcję kompliatora -wantAppCrashOnNulls. Braki Either itd. pominę milczeniem.
jak masz jakiś świetny pomysł to możesz zarzucić na liście dyskusyjnej, np. tu https://mail.openjdk.java.net/pipermail/discuss/ albo tu https://mail.openjdk.java.net/pipermail/amber-dev/2022-May/007333.html (jak widać, nawet dość niedawno ktoś zarzucił pomysł o null-safety i się wywiązała dyskusja)
Modularyzacja... od daaaawna wiadomo, że w Javie brakuje dobrym możliwości zdefiniowania zewnętrznego interface'u pakietu. Po 20 latach wchodzą moduły, ale tak, żeby nie dało się ich używać. Pod hasłem "Java 8 forever".
modularyzacja działa, ale problemem jest wszędobylska (w świecie javy) skłonność do refleksji, by dostać się do szczegółów implementacyjnych (co jest przecież blokowane przed modularyzację) i grzebać nie tam gdzie powinno się grzebać (np. w implementacji classloaderów). można jednak mieć program częściowo zmodularyzowany i częściowo nie.
moim zdaniem trend na mikroserwisy osłabił motywację do ścisłej modularyzacji. w przypadku "modularnych monolitów" wsparcie w modularyzacji od jvma byłoby bardzo pomocne, ale mikroserwisy mają tak czy siak mocną izolację kodu z definicji.
I ja rozumiem, kompatybilność wsteczna. Tylko skoro powstają języki Java interoperable, które tych wad nie mają, to może i w Java by się dało?
hm, tych języków kompatybilność wsteczna (z różnych powodów) mniej dotyczy (np. po prostu mniej się tym przejmują), więc to jednak inny kaliber problemu.
w konkretnej wersji, w której działa plugin :-) Java 8 i konkretna wersja tomcata to oczywista oczywistoć.