1. org.jetbrains.annotations.NotNull 2. stream.map

0

1.

import org.jetbrains.annotations.NotNull;
class AClass {

    IColumnDefinition definition;

    public AClass(@NotNull IColumnDefinition definition) {
        this.definition = definition;
    }

Co to jest ta adnotacja? Do daje? Warto się emocjonować, czy olać?
Ma retention = CLASS, czyli nie ujawnia się na runtime ... platforma pewnie ma statyczną analizę - jest wartościowa?
I najważniejsze, nie można użyć "normalnej" @NotNull cokolwiek by to mogło znaczyć?
Stary SO nie rozjaśnia https://stackoverflow.com/que[...]-java-annotation-should-i-use
(nawiasem mówiąc brzmi to jak gorzki dowcip)

2.
Brakuje mi wprawy ze streamami, trzeba mi dokładnie to:

List<A> aList;
List<B> bList;
for(A a : aList) {
   bList.Add( new B(a) );
}

pewnie w pomyśle znajdzie się

aList.stream().map ... collect

ale nie umiem.

1

1) Przeciez jest na stronie Jetbrains Not Null wyjaśnione
2)Jeśli dobrze roumiem to:

var bList = aList.stream().map(a -> new B(a)).collect(Collectors.toList()):
0
scibi92 napisał(a):

1) Przeciez jest na stronie Jetbrains Not Null wyjaśnione
2)Jeśli dobrze roumiem to:

var bList = aList.stream().map(a -> new B(a)).collect(Collectors.toList()):
  1. Scyzoryk mi się otwiera, bo osobiście nie dostrzegam powodów do rozdzielnia adnotacji statycznej i runtimowej ...

  2. Dobrze rozumiesz. Kombinowałem z niepotrzebnymi : lub ::

3

Co do na stronie jetbrains i obsługi notnull.
Rak naprawdę niezły.

klasa skompilowana normalnie (gradlem, mavenem) - oczywiście takich asercji na notnull nie będzie miała (bo i skąd).
Zostaną dodane tylko w kodzie odpalanym bezpośrednio z Intellij.
Można ewentualnie sobie domontowac w buildzie odpowiedni plugin do tego, ale jetbrains nic o tym niuansie nie pisze.

Generalnie adnotacje @Nullable i @NotNull są w javie kompletnie zrypane - przez to, że mamy 15 standardów. (Podobnie zresztą jak loggery).
W zasadzie adnotacji @NotNull nie powinno być. Notnull powinno być opcją domyślną. Inaczej mamy kolejny szum w kodzie (jakby w javie było go mało :/).
Mimo tego, próbowałem w dawnych czasach z tego korzystać i ginąłem w zalewie fałszywych alarmów sonara, który zawsze się w tym gubił. Pewnie przez to, że w jednym projekcie potrafiły się objawić cztery rodzaje tych adnotacji (przez biblioteki).

Scyzoryk mi się otwiera, bo osobiście nie dostrzegam powodów do rozdzielnia adnotacji statycznej i runtimowej ...

nie wiem o czym piszesz. Adnotacje runtimowe to zło szczególne. Choćby dlatego warto je wyróżnić.

0
jarekr000000 napisał(a):

W zasadzie adnotacji @NotNull nie powinno być. Notnull powinno być opcją domyślną.

Nie wiem czy się rozumiemy ale IMO powinna być opcja na oznaczenie, że parametr metody może być nullem (tzn. z domysłu wszystko jest not-null - chyba, że oznaczymy, że coś jest nullable). Wtedy wiadomo, czy się bać czy nie.

Mimo tego, próbowałem w dawnych czasach z tego korzystać i ginąłem w zalewie fałszywych alarmów sonara, który zawsze się w tym gubił. Pewnie przez to, że w jednym projekcie potrafiły się objawić cztery rodzaje tych adnotacji (przez biblioteki).

No tutaj to nie problem bibliotek jako takich tylko JAR hell.
W ogóle to IDE próbujące "przemycić" jakieś feature'y w kodzie to kompletna porażka. Sam się spotkałem z ClassNotFound: NotImplementedException (czy jakoś tak) bo jakiś geniusz pozwolił, żeby NetBeansy pomyślały za niego.

0
AnyKtokolwiek napisał(a):

2)Jeśli dobrze roumiem to:

List<A> aList;
List<B> bList;
for(A a : aList) {
  bList.Add( new B(a) );
}
scibi92 napisał(a):

2)Jeśli dobrze roumiem to:

var bList = aList.stream().map(a -> new B(a)).collect(Collectors.toList()):
  1. Scyzoryk mi się otwiera, bo osobiście nie dostrzegam powodów do rozdzielnia adnotacji statycznej i runtimowej ...

  2. Dobrze rozumiesz. Kombinowałem z niepotrzebnymi : lub ::

Ale te znaczki "::" (tj. method handlery) są jak najbardziej przydatne.

        List<B> result = aList.stream()
                .map(B::new)
                .collect(Collectors.toList());

IMO takie coś jest czytelniejsze trochę od lambdy (tj. niekoniecznie przy konstruktorach, ale już wywoływanie getterów jak najbardziej).
Niskopoziomowo ma to nieistotną w 99% przypadków zaletę taką, że przy lambdzie (zazwyczaj) tworzona jest dodatkowa metoda statyczna w klasie. Przy method handlerze metoda jest wołana bezpośrednio.

0
wartek01 napisał(a):

Nie wiem czy się rozumiemy ale IMO powinna być opcja na oznaczenie, że parametr metody może być nullem (tzn. z domysłu wszystko jest not-null - chyba, że oznaczymy, że coś jest nullable). Wtedy wiadomo, czy się bać czy nie.

Tak, z jednym ale - ale to (non)nullability powinno być zaszyte w samych typach, a nie w adnotacjach które może sobie potem przeprocesować jakiś procesor adnotacji (albo i nie), jakiś analizator kodu z interfejsem krzemowym lub białkowym (albo i nie) lub jeszcze inny runtimowy refleksyjno-adnotacyjny hokus-pokus (albo i nie).

Jak dla mnie to jest chyba największy problem adnotacji jako takich - definiując je tylko mówisz, że istnieją, że można je dodać w określonych miejscach i że mają być widoczne w określonym czasie, poza tym nie robią absolutnie nic. Tymczasem dopisując kod (w tym taki poprzedzony @) chciałoby się myśleć, że dopisuje się pewne zachowanie - a tu niespodzianka. Nie dopisuje się zachowania, tylko informację, że może ewentualnie coś ktoś kiedyś będzie mógł z tym zrobić, potencjalnie na dowolnym etapie od kompilacji po runtime. Na zasadzie się zobaczy :D

W dodatku skoro jakiekolwiek działanie powiązane z adnotacją jest definiowane odrębnie i jak przybywa zależności to już nie masz kontroli co się z nią stanie (ostatnio władowałem się w taki problem - 0 adnotacji X skutkowała brakującym beanem w runtime, 1 adnotacja skutkowała 2 beanami i konfliktem w runtime). Potencjalnie mogę sobie zaszyć gdzieś taki aspekcik, który jak złapie w adnotacjach argumentów jakikolwiek org.jetbrains.annotations.NotNull to coś tam nababra, wywoła crash albo coś :)

0
wartek01 napisał(a):
jarekr000000 napisał(a):

W zasadzie adnotacji @NotNull nie powinno być. Notnull powinno być opcją domyślną.

Nie wiem czy się rozumiemy ale IMO powinna być opcja na oznaczenie, że parametr metody może być nullem (tzn. z domysłu wszystko jest not-null - chyba, że oznaczymy, że coś jest nullable). Wtedy wiadomo, czy się bać czy nie.

a). Ideału nie ma, Java nie ma defaultu NotNull
b). Ale użycie adnotacji od producenta IDE, z tym IDE mocno zespawanego (bardzo utrudnione jest użycie innych `@NotNul') jest ścieżką najgorszą z możliwych

3. Nowy pod-wątek
I tu moja myśl zawędrowała do @NotNul lombokowego, "zobaczmy co się wygeneruje po delombokizacji"
I tu (dla mnie duży) zonk.
Jetbrains IDEA tak mocno spawa ze sobą subset lomboka (pięć adnotacji), że o pełnego lomboka to trzeba na serio wejść na ścieżkę wojenną z IDE, i tę wojnę wygrać lub polec.
Na tym etapie nie mam determinacji zaryzykować wysadzenie funkcjonalności IDE w powietrze.

Mysli o IDE ...
Coraz bardziej doceniam Netbeans, nieco bardziej ubogie, zwłaszcza w analizy i propozycję mikro-usprawnień kodu na alt-enter, ale posłuszne programiście (a nie na odwrót).
Tylko kuźma, szkoda, szkoda, szkoda, że nie ma w NB aktywnego plugina do Kotlina**** (martwy od kilku lat).

1

Są adnotacje w javie, które sa całkiem spoko np:
@Override, jest tylko w żródłach i tylko dla kompilatora - tak powinno być.

@Nullable można wprowadzić w kompilatorze - dając parametr (opt in), że dany moduł kompilujemy z domyślnym brakiem null.

Co do innych adnotacji. Są takie miejsca, że przekraczamy granice języka - serializacja: json, xml, baza danych, czy nawet serwis rest i wtedy adnotacje compile time (ClASS, SOURCE) też mogłyby działać sensownie - poprzez plugin do kompilatora, jakiś tool na poziomie buildu (troche jak w micronaut). To nie jest super rozwiązanie, ale lepsze niż totalnie runtimowe magie, które się upowszechniły.

Co do lomboka to szkoda gadać, ale on jest tak zrobiony, że jakbyś nie miał magii w IDE to by nie dało się w tym pisać - cały kod na czerwono.(btw.... ja i tak nie mogę na to patrzeć).

1

@wartek01: Z nullami powinno być jak w Kotlinie jednym zdaniem pisząc.

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