Dlaczego „końcowe” jest niedozwolone w metodach interfejsu Java 8?

Jedną z najbardziej przydatnych funkcji Java 8 są nowe defaultmetody interfejsów. Istnieją zasadniczo dwa powody (mogą być inne), dlaczego zostały wprowadzone:

• Zapewnienie rzeczywistych domyślnych implementacji. Przykład:Iterator.remove()
• Zezwolenie na ewolucję API JDK. Przykład:Iterable.forEach()

Z punktu widzenia projektanta API chciałbym móc korzystać z innych modyfikatorów metod interfejsu, np final. Przydałoby się to podczas dodawania metod wygody, zapobiegając „przypadkowym” zastąpieniom przy wdrażaniu klas:

interface Sender {

    // Convenience method to send an empty message
    default final void send() {
        send(null);
    }

    // Implementations should only implement this method
    void send(String message);
}

Powyższe jest już powszechną praktyką, gdyby Senderbyły klasą:

abstract class Sender {

    // Convenience method to send an empty message
    final void send() {
        send(null);
    }

    // Implementations should only implement this method
    abstract void send(String message);
}

Teraz defaulti finaloczywiście są oczywiście sprzeczne słowa kluczowe, ale samo domyślne słowo kluczowe nie byłoby ściśle wymagane , więc zakładam, że ta sprzeczność jest umyślna, aby odzwierciedlić subtelne różnice między „metodami klasy z ciałem” (tylko metody) a „interfejsem” metody z ciałem ” (metody domyślne), tj. różnice, których jeszcze nie rozumiałem.

W pewnym momencie obsługa modyfikatorów takich jak statici finalmetod interfejsu nie została jeszcze w pełni zbadana, powołując się na Briana Goetza :

Drugą częścią jest to, jak daleko posuniemy się do wspierania narzędzi do budowania klas w interfejsach, takich jak metody końcowe, metody prywatne, metody chronione, metody statyczne itp. Odpowiedź brzmi: jeszcze nie wiemy

Od tego czasu pod koniec 2011 roku staticdodano oczywiście obsługę metod w interfejsach. Najwyraźniej dodało to wiele wartości do samych bibliotek JDK, takich jak with Comparator.comparing().

Pytanie:

Jaki jest powód final(i także static final), że nigdy nie dotarł do interfejsów Java 8?

To pytanie jest w pewnym stopniu związane z tym, z jakiego powodu „synchronizacja” jest niedozwolona w metodach interfejsu Java 8?

Kluczową rzeczą do zrozumienia w przypadku metod domyślnych jest to, że głównym celem projektowania jest ewolucja interfejsu , a nie „przekształcanie interfejsów w (mierne) cechy”. Chociaż oba te elementy nakładają się na siebie, a my staraliśmy się dostosować do tych drugich, gdzie nie przeszkadzało to w pierwszym, te pytania najlepiej zrozumieć, patrząc w tym świetle. (Uwaga też, że metody klasy są będzie różna od metod interfejsu, bez względu na zamiar, z racji faktu, że metody interfejsu można mnożyć dziedziczone.)

Podstawową ideą metody domyślnej jest: jest to metoda interfejsu z domyślną implementacją, a klasa pochodna może zapewnić bardziej szczegółową implementację. A ponieważ ośrodek konstrukcja była ewolucja interfejsu, to był krytyczny cel projektu, że metody domyślne mógł być dodany do interfejsów po fakcie , w sposób zgodny źródłowej i binarnej kompatybilne.

Zbyt prosta odpowiedź na pytanie „dlaczego nie ostateczne domyślne metody” jest taka, że ​​wtedy ciało nie byłoby po prostu domyślną implementacją, byłoby jedyną implementacją. Chociaż jest to nieco zbyt prosta odpowiedź, daje nam wskazówkę, że pytanie zmierza już w wątpliwym kierunku.

Innym powodem, dla którego końcowe metody interfejsu są wątpliwe, jest to, że stwarzają one niemożliwe problemy dla implementatorów. Załóżmy na przykład, że masz:

interface A { 
    default void foo() { ... }
}

interface B { 
}

class C implements A, B { 
}

Tutaj wszystko jest dobrze; Cdziedziczy foo()po A. Teraz załóżmy, że Bzmieniono na foometodę z domyślną:

interface B { 
    default void foo() { ... }
}

Teraz, gdy przejdziemy do ponownej kompilacji C, kompilator powie nam, że nie wie, dla jakiego zachowania powinien dziedziczyć foo(), więc Cmusi go zastąpić (i może zdecydować o delegowaniu, A.super.foo()jeśli chce zachować to samo zachowanie). Ale co, jeśli Bzrobił swoje domyślne finali Anie jest pod kontrolą autora C? Teraz Cjest bezpowrotnie zepsuty; nie można go skompilować bez foo()przesłonięcia, ale nie można go przesłonić, foo()jeśli był końcowy w B.

To tylko jeden przykład, ale chodzi o to, że ostateczność metod jest tak naprawdę narzędziem, które ma sens w świecie klas z pojedynczym dziedzictwem (generalnie, które łączą stan z zachowaniem), niż z interfejsami, które jedynie przyczyniają się do zachowania i mogą być mnożone dziedziczny. Zbyt trudno jest uzasadnić, „jakie inne interfejsy mogłyby zostać zmieszane z ostatecznym implementatorem”, a zezwolenie na ostateczną metodę interfejsu prawdopodobnie spowodowałoby te problemy (i wybuchłyby nie na osobie, która napisała interfejs, ale na słaby użytkownik, który próbuje to zaimplementować).

Innym powodem, dla którego należy ich zabronić, jest to, że nie mieliby na myśli tego, co myślisz. Domyślna implementacja jest brana pod uwagę tylko wtedy, gdy klasa (lub jej nadklasy) nie zapewnia deklaracji (konkretnej lub abstrakcyjnej) metody. Gdyby domyślna metoda była ostateczna, ale nadklasa już ją zaimplementowała, domyślna byłaby zignorowana, co prawdopodobnie nie jest tym, czego oczekiwał autor domyślny, deklarując ją jako ostateczną. (To zachowanie dziedziczenia jest odzwierciedleniem centrum projektowania metod domyślnych - ewolucji interfejsu. Powinna istnieć możliwość dodania metody domyślnej (lub domyślnej implementacji do istniejącej metody interfejsu) do istniejących interfejsów, które już mają implementacje, bez zmiany zachowanie istniejących klas, które implementują interfejs,

Na liście mailingowej lambda jest wiele dyskusji na ten temat . Jednym z tych, które wydają się zawierać wiele dyskusji na temat tego wszystkiego, jest: Widoczność metody zróżnicowanego interfejsu (była Final Defenders) .

W tej dyskusji Talden, autor oryginalnego pytania, zadaje pytanie bardzo podobne do twojego pytania:

Decyzja o upublicznieniu wszystkich członków interfejsu była rzeczywiście niefortunną decyzją. To, że każde użycie interfejsu w projekcie wewnętrznym ujawnia prywatne szczegóły implementacji, jest duże.

Jest to trudny do naprawienia bez dodawania do języka pewnych niejasnych lub łamliwych kompatybilności niuansów. Taka przerwa w kompatybilności i potencjalna subtelność byłyby nie do przyjęcia, więc musi istnieć rozwiązanie, które nie zepsuje istniejącego kodu.

Można ponownie wprowadzić słowo kluczowe „pakiet” jako specyfikator dostępu. Brak specyfikatora w interfejsie oznaczałby dostęp publiczny, a brak specyfikatora w klasie oznacza dostęp do pakietu. To, które specyfikatory mają sens w interfejsie, jest niejasne - szczególnie jeśli, aby zminimalizować obciążenie wiedzy programistów, musimy upewnić się, że specyfikatory dostępu oznaczają to samo w klasie i interfejsie, jeśli są obecne.

W przypadku braku domyślnych metod spekulowałbym, że specyfikator elementu w interfejsie musi być co najmniej tak samo widoczny jak sam interfejs (aby interfejs mógł faktycznie zostać wdrożony we wszystkich widocznych kontekstach) - przy użyciu domyślnych metod, które nie są tak pewny.

Czy była jakaś jasna informacja, czy jest to w ogóle możliwa dyskusja w terenie? Jeśli nie, czy powinno się to odbyć gdzie indziej.

Ostatecznie odpowiedź Briana Goetza brzmiała :

Tak, to już jest badane.

Pozwólcie jednak, że ustalę pewne realistyczne oczekiwania - funkcje języka / VM mają długi czas realizacji, nawet takie trywialne. Minął już czas na proponowanie nowych pomysłów na funkcje językowe dla Java SE 8.

Najprawdopodobniej nigdy nie został wdrożony, ponieważ nigdy nie był objęty zakresem. Nigdy nie zaproponowano jej na czas do rozważenia.

W kolejnej gorącej dyskusji na temat ostatecznych metod obrony na ten temat Brian powiedział ponownie :

I masz dokładnie to, czego sobie życzyłeś. Właśnie to dodaje ta funkcja - wielokrotne dziedziczenie zachowania. Oczywiście rozumiemy, że ludzie będą wykorzystywać je jako cechy. I ciężko pracowaliśmy, aby zapewnić, że oferowany przez nich model dziedziczenia jest prosty i wystarczająco czysty, aby ludzie mogli uzyskać dobre wyniki w różnych sytuacjach. Jednocześnie postanowiliśmy nie wypychać ich poza granice tego, co działa prosto i czysto, co prowadzi do reakcji „aw, nie posunąłeś się wystarczająco daleko” w niektórych przypadkach. Ale tak naprawdę większość tego wątku wydaje się narzekać, że szkło jest wypełnione w 98%. Wezmę 98% i dam radę!

To umacnia moją teorię, że po prostu nie była częścią zakresu ani części ich projektu. Udało im się zapewnić wystarczającą funkcjonalność, aby poradzić sobie z zagadnieniami ewolucji API.

Trudno będzie znaleźć i zidentyfikować „the” odpowiedź, dla przyczyn niezależnych wymienionych w komentarzach z @EJP: Istnieje około 2 (+/- 2) ludzi na świecie, którzy mogą dają jednoznacznej odpowiedzi na wszystko . Wątpliwości może być po prostu coś w rodzaju: „Wspieranie ostatecznych domyślnych metod nie wydawało się warte wysiłku polegającego na restrukturyzacji wewnętrznych mechanizmów rozstrzygania połączeń”. Jest to oczywiście spekulacja, ale jest ona poparta przynajmniej subtelnymi dowodami, takimi jak to Oświadczenie (jednej z dwóch osób) z listy mailingowej OpenJDK :

„Przypuszczam, że jeśli dozwolone byłyby metody„ ostateczne domyślne ”, mogą wymagać przepisania z wewnętrznego wywołania specjalnego na widoczny interfejs użytkownika.”

i trywialne fakty, takie jak ta, metoda po prostu nie jest uważana za (naprawdę) ostateczną metodę, gdy jest to defaultmetoda, jak obecnie zaimplementowana w metodzie Method :: is_final_method w OpenJDK.

Trudno znaleźć dalsze naprawdę „autorytatywne” informacje, nawet przy nadmiernej liczbie wyszukiwań internetowych i czytaniu dzienników zatwierdzeń. Pomyślałem, że może to być związane z potencjalnymi niejednoznacznościami podczas rozwiązywania wywołań metod interfejsu z invokeinterfaceinstrukcją i wywołaniami metod klasy, odpowiadającymi invokevirtualinstrukcji: W przypadku invokevirtualinstrukcji może istnieć proste wyszukiwanie vtable , ponieważ metoda musi być albo dziedziczona z nadklasy lub zaimplementowane bezpośrednio przez klasę. W przeciwieństwie do tego, invokeinterfacepołączenie musi zbadać odpowiednią stronę wywoływania, aby dowiedzieć się, do którego interfejsu to połączenie faktycznie się odnosi (wyjaśniono to bardziej szczegółowo na stronie InterfaceCalls na HotSpot Wiki). Jednak,finalmetody albo w ogóle nie są wstawiane do vtable , albo zastępują istniejące wpisy w vtable (patrz klassVtable.cpp. Linia 333 ), i podobnie, domyślne metody zastępują istniejące wpisy w vtable (patrz klassVtable.cpp, wiersz 202 ) . Tak więc faktyczny powód (a zatem odpowiedź) musi być ukryty głębiej w (raczej złożonym) mechanizmie rozstrzygania wywołań metody, ale być może te odniesienia będą mimo to uważane za pomocne, czy tylko dla innych, którym uda się uzyskać rzeczywistą odpowiedź z tego.

Nie sądzę, że konieczne jest określenie finalmetody interfejsu konwergencji. Mogę się zgodzić, że może to być pomocne, ale najwyraźniej koszty przeważają nad korzyściami.

Niezależnie od tego, co powinieneś zrobić, to napisać odpowiedni javadoc dla domyślnej metody, pokazując dokładnie, czym jest ta metoda i czego nie wolno robić. W ten sposób klasy implementujące interfejs „nie mogą” zmieniać implementacji, chociaż nie ma gwarancji.

Każdy może napisać Collectiontekst, który jest zgodny z interfejsem, a następnie robi rzeczy metodami absolutnie sprzecznymi z intuicją, nie ma innego sposobu, aby się przed tym uchronić, niż napisanie obszernych testów jednostkowych.

Dodajemy defaultsłowo kluczowe do naszej metody, interfacegdy wiemy, że klasa rozszerzająca naszą implementację interfacemoże, ale nie musi override. Ale co, jeśli chcemy dodać metodę, której nie chcemy przesłonić żadną klasą implementacyjną? Cóż, dwie opcje były dla nas dostępne:

1. Dodaj default finalmetodę.
2. Dodaj staticmetodę.

Teraz Java mówi, że jeśli mamy classimplementację dwóch lub więcej interfacestakich, że mają one defaultmetodę o dokładnie takiej samej nazwie i podpisie, tj. Są duplikaty, wówczas musimy zapewnić implementację tej metody w naszej klasie. Teraz w przypadku default finalmetod nie możemy zapewnić implementacji i utknęliśmy. I dlatego finalsłowo kluczowe nie jest używane w interfejsach.