Perché "final" non è consentito nei metodi di interfaccia Java 8?

Una delle funzionalità più utili di Java 8 sono i nuovi defaultmetodi sulle interfacce. Ci sono essenzialmente due ragioni (potrebbero essercene altre) per cui sono state introdotte:

• Fornire implementazioni predefinite effettive. Esempio:Iterator.remove()
• Consentire l'evoluzione dell'API JDK. Esempio:Iterable.forEach()

Dal punto di vista di un progettista API, mi sarebbe piaciuto poter usare altri modificatori su metodi di interfaccia, ad es final. Ciò sarebbe utile quando si aggiungono metodi di praticità, evitando sostituzioni "accidentali" nelle classi di implementazione:

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);
}

Quanto sopra è già una pratica comune se Senderfosse una classe:

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);
}

Ora, defaulte finalsono ovviamente in contraddizione con le parole chiave, ma la parola chiave predefinita stessa non sarebbe stata strettamente richiesta , quindi presumo che questa contraddizione sia intenzionale, per riflettere le sottili differenze tra "metodi di classe con body" (solo metodi) e "interfaccia" metodi con corpo " (metodi predefiniti), cioè differenze che non ho ancora capito.

Ad un certo punto, il supporto per modificatori come statice finalsui metodi di interfaccia non è stato ancora completamente esplorato, citando Brian Goetz :

L'altra parte è fino a che punto andremo a supportare gli strumenti di costruzione di classi nelle interfacce, come metodi finali, metodi privati, metodi protetti, metodi statici, ecc. La risposta è: non lo sappiamo ancora

Da quel momento alla fine del 2011, ovviamente, è staticstato aggiunto il supporto per i metodi nelle interfacce. Chiaramente, questo ha aggiunto molto valore alle librerie JDK stesse, come ad esempio con Comparator.comparing().

Domanda:

Qual è il motivo final(e anche static final) mai raggiunto le interfacce Java 8?

Questa domanda è, in una certa misura, correlata a Qual è il motivo per cui la "sincronizzazione" non è consentita nei metodi di interfaccia Java 8?

La cosa chiave da capire sui metodi predefiniti è che l'obiettivo principale del progetto è l' evoluzione dell'interfaccia , non "trasformare le interfacce in tratti (mediocri)". Sebbene ci sia una certa sovrapposizione tra i due, e abbiamo cercato di essere accomodanti verso il secondo in cui non si è ostacolato il primo, queste domande sono meglio comprese se viste in questa luce. (Nota anche che i metodi di classe stanno andando essere diverso da metodi di interfaccia, indipendentemente l'intento, in virtù del fatto che i metodi di interfaccia possono essere moltiplicano ereditate.)

L'idea di base di un metodo predefinito è: si tratta di un metodo di interfaccia con un'implementazione predefinita e una classe derivata può fornire un'implementazione più specifica. E poiché il centro di progettazione era l'evoluzione dell'interfaccia, era un obiettivo di progettazione fondamentale che i metodi predefiniti potessero essere aggiunti alle interfacce dopo il fatto in modo compatibile con la sorgente e binaria.

La risposta troppo semplice al "perché non i metodi predefiniti finali" è che allora il corpo non sarebbe semplicemente l'implementazione predefinita, sarebbe l'unica implementazione. Anche se questa è una risposta un po 'troppo semplice, ci dà un indizio che la domanda sta già andando in una direzione discutibile.

Un altro motivo per cui i metodi di interfaccia finali sono discutibili è che creano problemi impossibili per gli implementatori. Ad esempio, supponiamo di avere:

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

interface B { 
}

class C implements A, B { 
}

Qui va tutto bene; Ceredita foo()da A. Ora supponiamo che Bsia cambiato per avere un foometodo, con un valore predefinito:

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

Ora, quando andremo a ricompilare C, il compilatore ci dirà che non sa per quale comportamento ereditare foo(), quindi Cdeve sovrascriverlo (e potrebbe scegliere di delegare A.super.foo()se voleva mantenere lo stesso comportamento). Baveva fatto il suo default finale Anon è sotto il controllo dell'autore di C? Ora Cè irrimediabilmente rotto; non può essere compilato senza foo()eseguire l' override , ma non può eseguire l'override foo()se è stato finalizzato B.

Questo è solo un esempio, ma il punto è che la finalità dei metodi è in realtà uno strumento che ha più senso nel mondo delle classi a eredità singola (generalmente quali coppie dichiarano al comportamento), piuttosto che alle interfacce che semplicemente contribuiscono al comportamento e possono essere moltiplicate ereditato. È troppo difficile ragionare su "quali altre interfacce potrebbero essere mescolate nell'eventuale implementatore", e consentire che un metodo di interfaccia sia definitivo causerebbe probabilmente questi problemi (e si farebbero saltare in aria non sulla persona che ha scritto l'interfaccia, ma sulla povero utente che cerca di implementarlo.)

Un altro motivo per non consentire loro è che non significhino ciò che pensi che significhino. Un'implementazione predefinita viene considerata solo se la classe (o le sue superclassi) non forniscono una dichiarazione (concreta o astratta) del metodo. Se un metodo predefinito fosse definitivo, ma una superclasse già implementasse il metodo, il valore predefinito verrebbe ignorato, il che probabilmente non è quello che l'autore predefinito si aspettava quando lo avesse dichiarato definitivo. (Questo comportamento di ereditarietà riflette il centro di progettazione per i metodi predefiniti - evoluzione dell'interfaccia. Dovrebbe essere possibile aggiungere un metodo predefinito (o un'implementazione predefinita a un metodo di interfaccia esistente) alle interfacce esistenti che dispongono già di implementazioni, senza modificare comportamento delle classi esistenti che implementano l'interfaccia,

Nella mailing list lambda ci sono molte discussioni al riguardo . Uno di quelli che sembrano contenere molte discussioni su tutto ciò è il seguente: Sulla visibilità del metodo dell'interfaccia variegata (erano i difensori finali) .

In questa discussione, Talden, l'autore della domanda originale pone qualcosa di molto simile alla tua domanda:

La decisione di rendere pubblici tutti i membri dell'interfaccia è stata davvero una decisione sfortunata. Che qualsiasi uso dell'interfaccia nella progettazione interna esponga dettagli privati ​​dell'implementazione è un aspetto importante.

È difficile da correggere senza aggiungere sfumature oscure o di compatibilità alla lingua. Un'interruzione della compatibilità di tale entità e potenziale sottigliezza sarebbe inconcepibile, quindi deve esistere una soluzione che non violi il codice esistente.

Potrebbe essere possibile reintrodurre la parola chiave "pacchetto" come specificatore di accesso. L'assenza di uno specificatore in un'interfaccia implicherebbe l'accesso del pubblico e l'assenza di uno specificatore in una classe implica l'accesso al pacchetto. Quali specificatori abbiano senso in un'interfaccia non sono chiari, specialmente se, per ridurre al minimo l'onere della conoscenza per gli sviluppatori, dobbiamo assicurarci che gli specificatori di accesso significino la stessa cosa sia in classe che in interfaccia se sono presenti.

In assenza di metodi predefiniti avrei ipotizzato che l'identificatore di un membro in un'interfaccia deve essere almeno visibile come l'interfaccia stessa (quindi l'interfaccia può essere effettivamente implementata in tutti i contesti visibili) - con metodi predefiniti che non sono così certo.

C'è stata qualche chiara comunicazione sul fatto che si tratti di una possibile discussione nell'ambito? In caso contrario, dovrebbe essere tenuto altrove.

Alla fine la risposta di Brian Goetz è stata:

Sì, questo è già stato esplorato.

Tuttavia, lasciatemi impostare alcune aspettative realistiche: le funzionalità di linguaggio / VM hanno tempi di consegna lunghi, anche se apparentemente banali come questo. Il tempo per proporre idee per nuove funzionalità linguistiche per Java SE 8 è praticamente passato.

Quindi, molto probabilmente non è mai stato implementato perché non faceva mai parte del campo di applicazione. Non è mai stato proposto in tempo per essere considerato.

In un'altra accesa discussione sui metodi di difensore finale sull'argomento, Brian ha ripetuto :

E hai ottenuto esattamente quello che desideravi. Questo è esattamente ciò che aggiunge questa funzionalità: l'ereditarietà multipla del comportamento. Naturalmente capiamo che le persone li useranno come tratti. E abbiamo lavorato duramente per garantire che il modello di eredità che offrono sia abbastanza semplice e pulito da consentire alle persone di ottenere buoni risultati in un'ampia varietà di situazioni. Allo stesso tempo, abbiamo scelto di non spingerli oltre il limite di ciò che funziona in modo semplice e pulito, e ciò porta in alcuni casi a reazioni "aw, non sei andato abbastanza lontano". Ma in realtà, la maggior parte di questo filo sembra lamentarsi del fatto che il vetro è solo pieno al 98%. Prenderò quel 98% e andrò avanti!

Quindi questo rafforza la mia teoria che semplicemente non faceva parte dello scopo o parte del loro design. Quello che hanno fatto è stato fornire funzionalità sufficienti per affrontare i problemi dell'evoluzione delle API.

Sarà difficile da trovare e identificare "la" risposta, per le resons menzionati nelle osservazioni di @EJP: Ci sono circa 2 (+/- 2) di persone nel mondo che possono dare la risposta definitiva a tutti . E nel dubbio, la risposta potrebbe essere qualcosa del tipo "Supportare i metodi predefiniti finali non sembra valere lo sforzo di ristrutturare i meccanismi interni di risoluzione delle chiamate". Questa è una speculazione, ovviamente, ma è almeno supportata da evidenti prove, come questa Dichiarazione (di una delle due persone) nella mailing list di OpenJDK :

"Suppongo che se fossero consentiti metodi" final default ", potrebbe essere necessario riscriverli dall'interfaccia interna all'invocazione visibile dall'utente."

e fatti banali come il fatto che un metodo non è semplicemente considerato un metodo (veramente) finale quando è un defaultmetodo, come attualmente implementato nel metodo Method :: is_final_method in OpenJDK.

Ulteriori informazioni veramente "autorevoli" sono davvero difficili da trovare, anche con ricerche web eccessive e leggendo i log di commit. Ho pensato che potrebbe essere correlato a potenziali ambiguità durante la risoluzione delle chiamate del metodo di interfaccia con l' invokeinterfaceistruzione e le chiamate al metodo di classe, corrispondenti invokevirtualall'istruzione: Per l' invokevirtualistruzione, potrebbe esserci una semplice ricerca vtable , poiché il metodo deve essere ereditato da una superclasse o implementato direttamente dalla classe. Al contrario, una invokeinterfacechiamata deve esaminare il rispettivo sito di chiamata per scoprire a quale interfaccia si riferisce effettivamente questa chiamata (questo è spiegato più dettagliatamente nella pagina InterfaceCalls del Wiki di HotSpot). Però,finali metodi non vengono affatto inseriti nella vtable , o sostituiscono le voci esistenti nella vtable (vedere klassVtable.cpp. Riga 333 ) e allo stesso modo, i metodi predefiniti sostituiscono le voci esistenti nella vtable (vedi klassVtable.cpp, Riga 202 ) . Quindi la ragione reale (e quindi la risposta) deve essere nascosta più in profondità all'interno dei (piuttosto complessi) meccanismi di risoluzione delle chiamate del metodo, ma forse questi riferimenti saranno comunque considerati utili, sia solo per gli altri che riescono a ricavare la risposta effettiva da quello.

Non credo che sia necessario specificare finalun metodo di interfaccia di convivialità, posso concordare sul fatto che può essere utile, ma a quanto pare i costi hanno superato i benefici.

Ciò che dovresti fare, in entrambi i casi, è scrivere javadoc corretto per il metodo predefinito, mostrando esattamente quale sia il metodo e non è consentito farlo. In questo modo le classi che implementano l'interfaccia "non sono autorizzate" a cambiare l'implementazione, sebbene non ci siano garanzie.

Chiunque potrebbe scrivere un oggetto Collectionche aderisce all'interfaccia e quindi fare cose con metodi assolutamente controintuitivi, non c'è modo di proteggersi da questo, se non quello di scrivere test unitari approfonditi.

Aggiungiamo una defaultparola chiave al nostro metodo all'interno di un interfacequando sappiamo che la classe che estende interfaceo meno la overridenostra implementazione. E se volessimo aggiungere un metodo che non vogliamo che nessuna classe di implementazione abbia la precedenza? Bene, due opzioni erano disponibili per noi:

1. Aggiungi un default finalmetodo
2. Aggiungi un staticmetodo

Ora, Java afferma che se abbiamo classdue o più implementazioni interfacestali da avere un defaultmetodo con esattamente lo stesso nome e firma del metodo, cioè che sono duplicati, allora dobbiamo fornire un'implementazione di quel metodo nella nostra classe. Ora, nel caso dei default finalmetodi, non possiamo fornire un'implementazione e siamo bloccati. Ed è per questo che la finalparola chiave non viene utilizzata nelle interfacce.