Javaの新しいキーワード

近い将来、Java言語で新しい機能が登場します。これらの機能は、現在Valhalla、Panama、およびLoomのプロジェクトで取り組んでいます。 言語の拡張は簡単な作業ではありません。特に下位互換性に重点を置いている言語ではありません。 したがって、言語アーキテクトは、Javaへの統合を円滑に進めるために、蓄積された基本的な問題を解決する必要があります。



昨日（1月8日）、Java言語アーキテクトとしてOracleで働いていたBrian Goetzは、 「キーワードがもっと必要だ、キャプテン！」という手紙を Project Amberメーリングリストに公開しました。これは、新しいキーワードを言語に追加する問題を解決する方法を提案しました。 その結果、キーワードは非ヌル 、 非ファイナル 、 最終ファイナル 、 このリターンなどの言語で表示される場合があります （投稿の最後の切り抜きの下に完全なリストが待っています）。



過去にはこの問題はめったに言語で発生しなかったので、彼らは通常それについてあまり考えず、「できるだけ早く首を下ろそうとした」。 将来の既存のアプローチの欠点により、それらのアプリケーションには問題があり、この点で、事前に機能することが決定されました。 提案された解決策：キーワードとして使用できる字句形式の範囲を拡大してみてください。1つ（または複数）の既存のキーワードまたは予約済み識別子を使用するハイフンで区切られたキーワードを許可します。



重要なメモ：Brownは、新しいキーワードは説明のための例としてのみ提供されており、それらに焦点を合わせるべきではないことに注意します。 しかし、私たちの前に、言語の構文が将来どのように変化する可能性があるかについてよく考えられたデモンストレーションがあることは明らかです-手紙では、著者はこのアイデアが多くの望ましい欠落した言語コンストラクトをJavaに追加するのに役立つと述べています。

「古い」メソッド

ご存じのとおり、今日のJava言語には50個のキーワード（ keyword ）があり、変数の識別子として使用することは禁じられています。 完全なリストは、3.9節のJLS言語仕様に記載されています。 このリストは、言語の最初のバージョンからあまり変更されていません-バージョン4でアサートのみが追加され、5で列挙 、9で_に加えて、キーワードと同様に動作する「予約済み識別子」（ true 、 false 、 null ）もあります方法。



開発者が言語に新しいキーワードを追加する必要がある場合、次のいずれかの方法を使用する必要があります。

• 所有権の強制譲渡：以前は識別子であった単語をキーワードに変換します（例： assert ）。
• 廃棄：既存のキーワードは、使用される予定がなかった方法で使用され始めます（例は、注釈値またはデフォルトメソッドのデフォルトの使用です）。
• それなしで：新しいキーワードを必要としない構文を使用する方法を見つけます-たとえば、注釈の代わりに注釈用のインターフェイスを使用するか、機能を完全に放棄します。
• 可視性の作成：英雄的な言語の成果（ 制限されたキーワード、予約されたタイプ名 ）を使用して、状況依存キーワードの錯覚を作成します。

原則として、これらの方法はいずれも通常適用できますが、それぞれに欠点があり、言語の本格的な本格的な拡張のためには、これらの方法だけでは明らかに十分ではありません-将来のイノベーションのために、言語構文の完全な拡張の不可能性を排除する必要があります。

新しいキーワードを追加する

新しい単語を「ただ」取り、追加することに対して、次の議論があります。

• 選択したキーワードがより便利で人気があるほど、プログラムのソースコードで頻繁に出会うため、言語に非互換性が追加されます（たとえば、Java SE 1.4でassertという単語が登場すると、すべてのテストフレームワークが機能しなくなりました）。
• 開発者がこのようなコードの非互換性を排除するコストは、小規模（ローカル変数の名前変更）から致命的な（インターフェイスメソッドまたはパブリックタイプが無効化された場合）まで大きく異なります。
• 言語開発者が使用する可能性が最も高い単語は、一般的な識別子です（たとえば、 value 、 var 、またはmethod ）。
• ソースコードでめったに使用されず、衝突が少ない単語を選択する場合、 通常は言語で回避することが望ましいと思われる通常はbut_not_always_finalのような構造を使用する必要があります。
• それでもめったに使用されない単語を選択することに頼る場合、この方法をあまり頻繁に使用しても機能しません。互換性を損なうことはよくありません。

「古い」キーワードの再利用

これらの言葉とともに生き続ける「ただ」については、いくつかの考慮事項があります。

• さまざまなコンテキストでキーワードを再利用するための前例は、多くのプログラミング言語に見られます（Javaの例は、「変更不可」、「再定義不可」、「拡張不可」の指定に（ （ab）use ） finalを使用しています ）。
• このアプローチは理にかなっており、単独で実行される場合もありますが、通常は優先事項ではありません。
• 時間が経つにつれて、キーワードのセットに対する要件のセットが拡大し、おかしな点に達する可能性があります。コードでnull finalを使用したい人はいません。
• 後者が誇張であると思われる場合は、 JEP 325で作業している間、 新しいスイッチ構成を使用して異なるセマンティクスでスイッチを記述することを真剣に提案したことに留意してください。 新しい新しいスイッチ 。

新しいキーワードなしで生きる方法は？ おそらく、一部の人が示唆するように、言語の進化への対処を完全にやめることができます。 しかし、これは深刻ではなく、開発者からの言語の新しい機能に健全な関心があるため、他の人の意見には適合しません。

コンテキストキーワード

コードで特定の意味を提供するために使用されるが、一見予約語（ C＃で使用 ）ではないコンテキストキーワードは、同じ「魔法の杖」のように見えますが、ここでは、ブライアンは練習に基づいてその使用について独自の見解を示しています（たとえば、Java 10のvar実装はキーワードではなく、 予約された型名です ）。 既存のプログラムを「壊す」ことなく新しいキーワードを追加するという幻想と引き換えに、言語の複雑さと歪みが増大します。



コンテキストのキーワードは、仕様の作成者、コンパイラ、およびIDEにとって困難です。 1つまたは2つの特殊なケースに関しては、これは問題を引き起こしませんが、それらがどこでも使用され始めると、コードまたはバグからのテールをサポートするためのはるかに高いコストに変換されます。



これを却下することができます-彼らは、これは言語ユーザーの問題ではなく、その作成者とコンパイラとIDEを書く人々の問題だと言います。 しかし実際には、誰もが苦しんでいます。 IDEにとって、これは重大な問題になる可能性があります。開発者が入力している内容（コンテキストキーワードまたは識別子）を推測するには、より多くの入力が必要になります。 その結果、ユーザーは構文の強調表示、オートコンプリート、およびリファクタリング機能の機能が低下します。



このツールを使用できますが、慎重に行ってください。

舌の歪み

これらのアプローチが引き起こす問題-不器用な構文、生活とバグの不必要な複雑さ-原則として、私たちは妥協することができるようです。 しかし、最も明白な問題ではない別の問題があります。キーワードを使用することのニュアンスは、言語自体のデザインが歪められるという事実につながります。



Java開発者にとって、 アノテーションの代わりにインターフェースを記述することは今日ではありふれていますが、@と "old"キーワードの組み合わせの代わりにフレンドリーな用語アノテーションを使用する方がはるかに論理的であることに全員が同意するでしょう。



別の例：使用可能な修飾子のセット（public、private、static、finalなど）をcompleteと呼ぶことはできません-finalでもstaticでもないものは言えません 。 これは、この修飾子を放棄することを示す方法がないため、デフォルトでは変数またはクラスが最終的な 、またはデフォルトでメンバーが静的な機能を作成できないことを意味します。



この問題は、言語を使用する人にとってはそれほど明白ではありませんが、言語自体の作成者は、言語をさらに開発したいという要望のために、絶えず遭遇し、私たち全員がそのような決定にお金を払わなければなりません（明示的に、暗黙的に）。



上記のすべてからの結論は、それ自体を示唆しています：キーワードの別のソースが必要です。

提案されたソリューション

この言語の実験的な機能では、構文を使用して新しいキーワードを事前に指定します。この場合、新しいキーワード自体の前に2つのアンダースコアが付きます（たとえば、プロトタイプProject Valhallaでは__ByValueです ）。 この決定の理由は理解できます-これは一時的な置換であり、将来的には最終的な構文について決定する必要があり、同時に既存のコードとの競合を簡単に回避できることを指摘する必要があります。 1つまたは2つのアンダースコアで始まる新しいキーワードに同様の形式を使用することをお勧めしますが、このソリューションは美しいとは言えません。この場合、通常の新しいキーワードと混同されるためです。



したがって、1つ以上の「古い」キーワードまたは予約済み識別子を使用するハイフンを使用して作成されたキーワードを使用することをお勧めします。



制限されたキーワードとは異なり、このアプローチでは構文解析の問題がはるかに少なくなります。これは（以下-例） not-nullを減算式と混同することができず、レクサーはabが 3トークンか1トークンかを常に判断できるためです。 これにより、既存のソースコードまたは互いに競合する可能性がはるかに低いキーワードを作成するための新しい機会が開かれています。 さらに、言語の作成者がJavaに追加したいものの多くは、その中の既存の言語構成要素（たとえば、 非null ）に基づいているため、意味のある名前を持つ可能性がはるかに高くなります 。



新しいキーワードの例として、新しいキーワードの場所の候補が挙げられます（著者によると、現時点ではこのリストは純粋に例示的なものです）。



- 非ヌル ;

- 非最終 ;

-package-private （デフォルトではクラスのメンバーへのアクセスレベルの修飾子。現在どのような方法でも示されていません）。

- パブリックリード （パブリックリード、プライベートレコーディング）;

-nullチェック済み ;

-type -static （ Valhallaに必要な概念。クラス自体ではなく、クラスの特定の特殊化に関連した静的を示します）;

- デフォルト値 ;

- 最終的に最終 （現在は安定した注釈を使用して行われることになっているもの）、

- 準決勝 （ シールドの代わりとして）;

- 網羅的スイッチ ;

-enum-class 、 annotation-class 、 record-class （言語の作成者は、 enumおよびinterfaceの代わりにこれらのキーワードを使用できます（そうした機会がある場合）。

-this-class （現在のクラスのクラスリテラルを記述するため）;

-this-return （多くの場合、setter / method-builderが受信者を返すようにマークする方法を追加するように要求されます）。



確かに字句体系には他の変形があり、それに従って、すでにソースコードに書かれているものと最小限に重複するようにキーワードを構成することが可能です。 提案されたハイフンは、車と人間の両方にとって十分に読みやすいです。



このアプローチは、以前に使用されたものと一緒に使用する可能性を決して排除しないが、それらと一緒に使用されることが理解される。