Neue Schlüsselwörter in Java

In naher Zukunft werden neue Funktionen in der Java-Sprache erscheinen, an denen derzeit im Rahmen der Projekte von Valhalla, Panama und Loom gearbeitet wird. Das Erweitern einer Sprache ist keine leichte Aufgabe, insbesondere keine Sprache, bei der der Schwerpunkt auf der Abwärtskompatibilität liegt. Daher müssen Spracharchitekten akkumulierte grundlegende Probleme lösen, damit ihre Integration in Java reibungslos verläuft.

Gestern (8. Januar) veröffentlichte Brian Goetz, der als Java Language Architect für Oracle arbeitete, einen Brief mit dem Titel „Wir brauchen mehr Schlüsselwörter, Captain!“ An die Mailingliste von Project Amber . in dem er einen Weg vorschlug, um das Problem des Hinzufügens neuer Schlüsselwörter zur Sprache zu lösen. Infolgedessen werden Schlüsselwörter möglicherweise in der Sprache angezeigt, z. B. " Nicht null" , " Nicht endgültig" , " Endlich endgültig" und " Diese Rückgabe" (eine vollständige Liste wartet unter dem Ausschnitt am Ende des Beitrags auf Sie).

Da dieses Problem in der Vergangenheit nur selten in der Sprache auftrat, haben sie normalerweise nicht viel darüber nachgedacht und „versucht, so schnell wie möglich vom Hals zu kommen“; Aufgrund der Unzulänglichkeiten bestehender Ansätze in der Zukunft wird ihre Anwendung problematisch sein, und diesbezüglich wurde beschlossen, im Voraus zu arbeiten. Vorgeschlagene Lösung: Versuchen Sie, den Satz lexikalischer Formulare zu erweitern, die als Schlüsselwörter verwendet werden können. Lassen Sie Schlüsselwörter zu, die durch einen Bindestrich getrennt sind, wobei ein (oder mehrere) vorhandene Schlüsselwörter oder eine reservierte Kennung verwendet werden.

Wichtiger Hinweis: Brown weist darauf hin, dass die neuen Schlüsselwörter nur als veranschaulichendes Beispiel dienen und dass Sie sich nicht auf sie konzentrieren sollten. Es ist jedoch offensichtlich, dass wir eine gut durchdachte Demonstration vor uns haben, wie sich die Syntax der Sprache in Zukunft ändern könnte. In dem Brief erwähnt der Autor, dass diese Idee dazu beitragen wird, Java viele wünschenswerte fehlende Sprachkonstrukte hinzuzufügen.

"Alte" Methoden

Wie Sie wissen, gibt es heute in der Java-Sprache 50 Schlüsselwörter ( Schlüsselwörter ), deren Verwendung als Bezeichner von Variablen verboten ist. Eine vollständige Liste finden Sie in der JLS-Sprachspezifikation in Abschnitt 3.9 . Diese Liste hat sich seit der ersten Version der Sprache nicht wesentlich geändert - nur Assert wurde in Version 4 hinzugefügt, Enum in 5 und _ in 9. Zusätzlich zu ihnen gibt es auch "reservierte Bezeichner" - true , false und null -, die sich ähnlich wie Schlüsselwörter verhalten Weg.

Wenn Entwickler der Sprache ein neues Schlüsselwort hinzufügen müssen, müssen sie auf eine der folgenden Methoden zurückgreifen.

• Zwangsübertragung des Eigentums: Wir nehmen die Wörter, die zuvor Bezeichner waren, und wandeln sie in Schlüsselwörter um (z. B. Assert ).
• Entsorgung: Ein vorhandenes Schlüsselwort wird so verwendet, dass es nie verwendet werden sollte (ein Beispiel ist die Verwendung von Standard für Anmerkungswerte oder Standardmethoden).
• Verzichten Sie darauf: Finden Sie eine Möglichkeit, die Syntax zu verwenden, für die kein neues Schlüsselwort erforderlich ist. Verwenden Sie beispielsweise die Schnittstelle für Anmerkungen anstelle von Anmerkungen, oder geben Sie die Funktion vollständig auf.
• Sichtbarkeit schaffen: Erstellen Sie die Illusion kontextsensitiver Schlüsselwörter mithilfe heldenhafter sprachlicher Errungenschaften ( eingeschränkte Schlüsselwörter, reservierte Typnamen ).

Im Prinzip kann jede dieser Methoden normalerweise angewendet werden, aber jede von ihnen hat ihre Nachteile, und für eine ernsthafte vollständige Erweiterung der Sprache reichen diese Methoden eindeutig nicht aus - für zukünftige Innovationen muss die Unfähigkeit beseitigt werden, die Sprachsyntax vollständig zu erweitern.

Hinzufügen neuer Schlüsselwörter

Es gibt die folgenden Argumente gegen das „gerechte“ Nehmen und Hinzufügen neuer Wörter.

• Je bequemer und beliebter das ausgewählte Schlüsselwort ist, desto häufiger wird es im Quellcode von Programmen angezeigt, wodurch die Sprache inkompatibel wird (wenn beispielsweise das Wort assert in Java SE 1.4 angezeigt wird, funktionieren alle Test-Frameworks nicht mehr).
• Die Kosten für die Beseitigung einer solchen Inkompatibilität des Codes durch den Entwickler variieren stark von klein (Umbenennen einer lokalen Variablen) bis schwerwiegend (wenn die Schnittstellenmethode oder der öffentliche Typ ungültig ist).
• Wörter, die Sprachentwickler am wahrscheinlichsten verwenden, sind beliebte Bezeichner (z. B. value , var oder method ).
• Wenn Sie Wörter auswählen, die im Quellcode selten verwendet werden und bei denen es weniger Kollisionen gibt, müssen Sie Konstrukte wie gewöhnlich_but_not_always_final verwenden , die in der Sprache natürlich zu vermeiden wären.
• Wenn Sie jedoch auf die Verwendung selten verwendeter Wörter zurückgreifen, funktioniert die zu häufige Verwendung dieser Methode nicht - die Kompatibilität ist nicht gut, und es gibt nicht so viele erfolgreichere Kombinationen.

Wiederverwendung "alter" Schlüsselwörter

Es gibt Überlegungen, wie man „nur“ weiterhin mit diesen Worten leben kann.

• Präzedenzfälle für die Wiederverwendung von Schlüsselwörtern in verschiedenen Kontexten finden sich in vielen Programmiersprachen (ein Beispiel aus Java ist die Verwendung von ( (ab) use ) final für die Bezeichnungen "nicht veränderlich", "nicht neu definiert" und "nicht erweiterbar").
• Manchmal ist dieser Ansatz sinnvoll und kommt von selbst, aber normalerweise hat er keine Priorität.
• Mit der Zeit erweitern sich die Anforderungen an eine Reihe von Schlüsselwörtern, und es kann zu einem lustigen Punkt kommen - niemand möchte null final in seinem Code verwenden.
• Wenn Ihnen letzteres übertrieben vorkam, denken Sie daran, dass sie bei der Arbeit an JEP 325 ernsthaft vorgeschlagen haben, das neue Switch- Konstrukt zu verwenden, um den Switch mit unterschiedlicher Semantik zu beschreiben - wenn Sie in der gleichen Richtung fortfahren, können wir nach zehn Jahren erreichen neuer neuer Schalter .

Wie lebe ich ohne neue Schlüsselwörter? Es ist möglich, die Entwicklung der Sprache vollständig einzustellen, wie einige vorgeschlagen haben. Dies ist jedoch nicht ernst und passt nicht zur Meinung der übrigen, da die Entwickler ein gesundes Interesse an den neuen Funktionen der Sprache haben.

Kontextbezogene Schlüsselwörter

Kontext-Schlüsselwörter, die verwendet werden, um eine bestimmte Bedeutung im Code bereitzustellen, aber keine reservierten Wörter sind ( in C # verwendet ), scheinen auf den ersten Blick der gleiche „Zauberstab“ zu sein, aber hier gibt Brian seine eigene Sicht auf ihre Verwendung, basierend auf der Praxis ( Zum Beispiel var- Implementierungen in Java 10 (kein Schlüsselwort, sondern ein reservierter Typname ). Als Gegenleistung für die Illusion, neue Schlüsselwörter hinzuzufügen, ohne vorhandene Programme „brechen“ zu müssen, wird die Sprache komplexer und verzerrter.

Kontextbezogene Schlüsselwörter sind für Spezifikationsschreiber, Compiler und IDEs schwierig. Wenn es um ein oder zwei Sonderfälle geht, verursacht dies keine Probleme, aber wenn sie überall verwendet werden, führt dies zu viel höheren Kosten für die Unterstützung des Codes oder des Endes von Fehlern.

Man könnte dies ablehnen - sie sagen, dies sei kein Problem der Sprachbenutzer, sondern ihrer Schöpfer und derer, die Compiler und IDEs schreiben. Aber in Wirklichkeit leidet jeder. Für die IDE kann dies ein erhebliches Problem sein: Es sind weitere Eingaben erforderlich, um zu erraten, was der Entwickler eingibt - ein kontextbezogenes Schlüsselwort oder eine Kennung. Infolgedessen verschlechtern sich die Funktionen zur Hervorhebung der Syntax, zur automatischen Vervollständigung und zum Refactoring.

Sie können dieses Tool verwenden, tun Sie dies jedoch mit Vorsicht.

Zungenverzerrung

Es scheint, dass wir uns mit den Problemen, die diese Ansätze verursachen - ungeschickte Syntax, unnötige Komplikationen des Lebens und Fehler - im Prinzip abfinden könnten. Aber es gibt noch ein anderes, nicht das offensichtlichste Problem - die Nuancen der Verwendung von Schlüsselwörtern führen dazu, dass das Design der Sprache selbst verzerrt ist.

Für Java-Entwickler ist das Schreiben einer Benutzeroberfläche anstelle von Anmerkungen heutzutage üblich, aber jeder wird zustimmen, dass die Verwendung des benutzerfreundlichen Begriffs " Anmerkung" anstelle einer Kombination aus @ und dem "alten" Schlüsselwort viel logischer wäre.

Ein weiteres Beispiel: Der Satz verfügbarer Modifikatoren (öffentlich, privat, statisch, endgültig usw.) kann nicht als vollständig bezeichnet werden - wir können nichts sagen, was nicht endgültig oder nicht statisch ist . Dies bedeutet wiederum, dass Sie keine Features erstellen können, in denen Variablen oder Klassen standardmäßig endgültig oder Mitglieder standardmäßig statisch sind, da nicht angegeben werden kann, dass wir diesen Modifikator aufgeben möchten.

Dieses Problem ist für diejenigen, die die Sprache verwenden, nicht so offensichtlich - aber die Autoren der Sprache selbst begegnen ihr aufgrund ihres Wunsches, sie weiterzuentwickeln, ständig, und wir alle müssen für solche Entscheidungen bezahlen (wenn explizit, wenn implizit).

Die Schlussfolgerung aus all dem oben Genannten bietet sich an: Wir brauchen eine andere Quelle von Schlüsselwörtern.

Vorgeschlagene Lösung

In den experimentellen Funktionen der Sprache wird eine Syntax verwendet, um neue Schlüsselwörter vorab festzulegen, wobei den neuen Schlüsselwörtern selbst zwei Unterstriche vorangestellt werden (im Prototyp Project Valhalla ist dies beispielsweise __ByValue ). Der Grund für diese Entscheidung ist verständlich - Sie müssen darauf hinweisen, dass dies ein vorübergehender Ersatz ist, für den Sie in Zukunft eine Entscheidung über die endgültige Syntax treffen müssen, und gleichzeitig Konflikte mit vorhandenem Code leicht vermeiden können. Man könnte vorschlagen, ein ähnliches Format für neue Schlüsselwörter zu verwenden - beginnend mit einem oder zwei Unterstrichen -, aber diese Lösung kann nicht als schön bezeichnet werden, da in diesem Fall normale und neue Schlüsselwörter Verwirrung stiften.

Daher wird vorgeschlagen, Schlüsselwörter zu verwenden, die unter Verwendung eines Bindestrichs erstellt wurden und ein oder mehrere "alte" Schlüsselwörter oder reservierte Bezeichner verwenden.

Im Gegensatz zu eingeschränkten Schlüsselwörtern verursacht dieser Ansatz viel weniger Probleme beim Parsen, da (im Folgenden - ein Beispiel) not-null nicht mit einem Subtraktionsausdruck verwechselt werden kann und ein Lexer immer bestimmen kann, ob ab drei oder eins Token ist. Dank dessen eröffnen sich uns neue Möglichkeiten, Schlüsselwörter zu erstellen, bei denen es weniger wahrscheinlich ist, dass sie mit dem vorhandenen Quellcode oder untereinander in Konflikt stehen. Darüber hinaus haben sie mit größerer Wahrscheinlichkeit aussagekräftige Namen, da ein Großteil dessen, was die Ersteller der Sprache zu Java hinzufügen möchten, auf vorhandenen Sprachkonstrukten basiert - beispielsweise nicht null .

Als Beispiele für neue Schlüsselwörter werden mögliche Kandidaten für den Platz neuer Schlüsselwörter angegeben (ich erinnere mich, dass diese Liste laut Autor derzeit nur zur Veranschaulichung dient):

- nicht null ;
- nicht endgültig ;
- package-private (standardmäßig Modifikator der Zugriffsebene für Mitglieder der Klasse, der derzeit in keiner Weise angegeben ist);
- öffentlich gelesen (öffentlich gelesen, privat aufgezeichnet);
- null geprüft ;
- Typ-statisch (das für Valhalla notwendige Konzept; bezeichnet statisch in Bezug auf die spezifische Spezialisierung der Klasse und nicht die Klasse selbst);
- Standardwert ;
- schließlich endgültig (was jetzt mit der Annotation " Stabil" geschehen soll),
- Halbfinale (als Alternative zu versiegelt );
- erschöpfender Schalter ;
- Aufzählungsklasse , Anmerkungsklasse , Datensatzklasse (Sprachautoren könnten diese Schlüsselwörter als Alternative zu Aufzählung und Schnittstelle verwenden , wenn sie eine solche Gelegenheit hätten);
- diese Klasse (um das Klassenliteral für die aktuelle Klasse zu beschreiben);
- this-return (wird häufig gebeten, eine Möglichkeit hinzuzufügen, um den Setter / Methoden-Builder als Rückgabe seines Empfängers zu markieren).

Sicherlich gibt es andere Varianten von lexikalischen Schemata, nach denen es möglich wäre, Schlüsselwörter so zusammenzustellen, dass sie sich minimal mit denen überschneiden, die bereits vom Quellcode geschrieben wurden. Der vorgeschlagene Bindestrich ist sowohl für Autos als auch für Menschen lesbar genug.

Es versteht sich, dass dieser Ansatz in keiner Weise die Möglichkeit ausschließt, ihn zusammen mit den zuvor verwendeten zu verwenden, sondern zusammen mit ihnen verwendet wird.