Krótko

ExecutorService posiada zarówno metody submit(Callable) jak i submit(Runnable).

1. w pierwszym przypadku (z while (true)) oba submit(Callable) i submit(Runnable) pasują, więc kompilator musi wybrać pomiędzy nimi
   • submit(Callable) jest wybierane przez submit(Runnable) Ponieważ Callable jest bardziej szczegółowe niż Runnable
   • Callable mA throws Exception W call(), więc nie jest konieczne przechwytywanie wyjątku wewnątrz
2. w drugim przypadku (z while (tasksObserving)) Tylko submit(Runnable) pasuje, więc kompilator wybiera Informatyka
   • Runnable nie posiada deklaracji throws dotyczącej swojej metody run(), więc błędem kompilacji jest nie przechwycenie wyjątku wewnątrz metody run().

Pełna historia

Specyfikacja języka Java opisuje sposób wyboru metody podczas kompilacji programu w $15.2.2 :

1. określić potencjalnie stosowane metody ($15.12.2.1) który odbywa się w 3 fazach dla ścisłej, luźnej i zmiennej arytmetyki inwokacja
2. wybierz najbardziej konkretną metodę ($15.12.2.5) z metod znalezionych na pierwszym kroku.

Przeanalizujmy sytuację za pomocą 2 metod submit() w dwóch fragmentach kodu dostarczonych przez OP:

ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.submit(() -> {
        while(true)
        {
            //DO SOMETHING
            Thread.sleep(5000);
        }
    });

I

ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.submit(() -> {
        while(tasksObserving)
        {
            //DO SOMETHING
            Thread.sleep(5000);
        }
    });

(gdzie tasksObserving nie jest zmienną końcową).

Identyfikacja Potencjalnie Stosowanych Metod

Najpierw kompilator musi zidentyfikować potencjalnie stosowane metody: $15.12.2.1

Jeśli element jest stałą arytmetyką metody z arytmetyką n, arytmetyka wywołania metody jest równa n i dla wszystkich i (1 ≤ i ≤ n), i argument wywołania metody jest potencjalnie zgodny , jak określono poniżej, z typem i ' - tego parametru metody.

I nieco dalej w tej samej sekcji

Wyrażenie jest potencjalnie kompatybilne z typem docelowym zgodnie z następującymi zasadami:

Wyrażenie lambda (§15.27) jest potencjalnie kompatybilny z funkcjonalnym typem interfejsu (§9.8), jeśli wszystkie z poniższych są prawdziwe:

Arytmetyka funkcji typu docelowego jest taka sama jak arytmetyka wyrażenia lambda.

Jeśli typ funkcji typu docelowego ma zwrot void, to ciało lambda jest wyrażeniem instrukcji (§14.8) lub blokiem zgodnym z void (§15.27.2).

Jeśli typ funkcji typu docelowego ma typ zwracany (non-void), to ciało lambda jest albo wyrażenie lub blok zgodny z wartością (§15.27.2).

Zauważmy, że w obu przypadkach lambda jest blokiem lambda.

Zauważmy również, że Runnable mA typ zwracania void, więc aby być potencjalnie kompatybilnym z Runnable, blok lambda musi być blokiem kompatybilnym z void. W tym samym czasie Callable mA typ non-void return, więc aby być potencjalnie comtatible z Callable, blok lambda musi być zgodny z wartością blok .

$15.27.2 definiuje czym są Void-compatible-block i value-compatible-block .

Blok lambda body jest kompatybilny z void, jeśli każde polecenie return w bloku ma postać return;.

Blok lambda jest zgodny z wartością, jeśli nie może normalnie się wypełnić (§14.21), a każda instrukcja return w bloku ma postać return Expression;.

Spójrzmy na $14.21, paragraf o while pętli:

A while twierdzenie może być wypełnione normalnie iff co najmniej jedna z następujących wartości jest prawdziwa:

Twierdzenie while jest osiągalne, a wyrażenie warunkowe nie jest wyrażeniem stałym (§15.28) o wartości true.

Istnieje osiągalna instrukcja break, która kończy instrukcję while.

W pierwszym przypadku, jak widać, istnieje while pętla ze stałym wyrażeniem o wartości true (BEZ break poleceń), więc nie może wypełnić normalnie (o $14.21); nie ma też poleceń return, stąd pierwsza lambda jest zgodna z wartością.

W tym samym czasie, nie ma return w ogóle, więc jest równieżVoid-compatible . W pierwszym przypadku lambda jest kompatybilna zarówno z void, jak i z wartością.

W drugim przypadku pętla while może zakończyć się normalnie z punktu widzenia kompilatora (ponieważ pętla wyrażenie nie jest już wyrażeniem stałym), więc lambda w całości może zakończyć się normalnie, więc jest nie a blok zgodny z wartością . Ale nadal jest blokiem kompatybilnym z void , ponieważ nie zawiera return instrukcji.

Przypominając to, co zauważyliśmy wcześniej, oznacza to, że w pierwszym przypadku lambda będzie potencjalnie kompatybilna zarówno z Callable, jak i Runnable; w drugim przypadku lambda będzie tylko potencjalnie kompatybilna z Runnable.

Wybierz najbardziej konkretną metodę

W pierwszym przypadku kompilator musi wybrać pomiędzy tymi dwoma metodami, ponieważ obie są potencjalnie odpowiednie . Robi to za pomocą procedura o nazwie "wybierz najbardziej konkretną metodę" i opisana w $15.12.2.5. Oto fragment:

Interfejs funkcjonalny typu S jest bardziej specyficzny niż interfejs funkcjonalny typu T dla wyrażenia e, Jeśli T nie jest podtypem S i jedno z poniższych jest prawdziwe (gdzie U1 ... Uk i R1 to typy parametrów i typ powrotu funkcji typu przechwytywania S, A V1 ... Vk i R2 są typami parametrów i typami zwrotnymi funkcji typu T):

Jeśli e jest wyrażenie lambda (§15.27.1), wtedy jedno z poniższych jest prawdziwe:

R2 jest nieważny.

Po pierwsze,

Wyrażenie lambda z zerowymi parametrami jest jawnie typowane.

Również żadne z Runnable i Callable nie jest podklasą siebie, a Runnable typem zwracanym jest void, więc mamy dopasowanie: Callable jest bardziej szczegółowy niż Runnable. Oznacza to, że pomiędzy submit(Callable) A submit(Runnable) w pierwszym przypadku metoda z Callable zostanie wybrany.

Jeśli chodzi o drugi przypadek, mamy tylko jedną potencjalnie stosowaną metodę, submit(Runnable), więc jest ona wybrana.

Więc dlaczego zmienia się powierzchnia?

W końcu widzimy, że w tych przypadkach kompilator wybiera różne metody. W pierwszym przypadku wnioskuje się, że lambda jest Callable, która ma {[13] } na swojej metodzie call(), tak że sleep() kompiluje wywołania. W drugim przypadku, to Runnable, który run() nie deklaruje żadnego throwable wyjątki, więc kompilator skarży się, że wyjątek nie zostanie złapany.