Глава 3. Лексическая структура

Программы написаны с использованием набора символов Юникод (§1.7). Информацию об этом наборе символов и связанных с ним кодировках можно найти на сайте https://www.unicode.org/.

Java SE Platform отслеживает стандарт Юникод по мере его развития. Точная версия Юникода, используемая данным выпуском, указана в документации класса Character.

Версии языка программирования Java до JDK 1.1 использовали Юникод 1.1.5. Обновления до более новых версий стандарта Юникод происходили в JDK 1.1 (до Юникода 2.0), JDK 1.1.7 (до Юникода 2.1), Java SE 1.4 (до Юникода 3.0), Java SE 5.0 (до Юникода 4.0), Java SE 7 (до Юникода 6.0), Java SE 8 (до Юникода 6.2), Java SE 9 (до Юникода 8.0), Java SE 11 (до Юникода 10.0), Java SE 12 (до Юникода 11.0), Java SE 13 (до Юникода 12.1) и Java SE 15 (до Юникода 13.0).

Стандарт Юникод изначально был разработан как кодировка символов с фиксированной шириной 16 бит. С тех пор он был изменен, чтобы позволить символы, представление которых требует более 16 бит. Диапазон допустимых кодовых точек теперь U+0000 до U+10FFFF, используя шестнадцатеричную запись U+n. Символы, кодовые точки которых больше U+FFFF, называются дополнительными символами. Для представления всего диапазона символов с помощью только 16-битных единиц стандарт Юникод определяет кодировку UTF-16. В этой кодировке дополнительные символы представлены парами 16-битных кодовых единиц, первая из которых принадлежит диапазону верхних суррогатов (U+D800 до U+DBFF), а вторая — диапазону нижних суррогатов (U+DC00 до U+DFFF). Для символов в диапазоне U+0000 до U+FFFF значения кодовых точек и кодовых единиц UTF-16 совпадают.

Язык программирования Java представляет текст в последовательностях 16-битных кодовых единиц, используя кодировку UTF-16.

Некоторые API Java SE Platform, в основном в классе Character, используют 32-битные целые числа для представления кодовых точек как отдельных сущностей. Java SE Platform предоставляет методы для преобразования между 16-битными и 32-битными представлениями.

В этом документе используются термины кодовая точка и кодовая единица UTF-16, где представление актуально, и общий термин символ, где представление не имеет значения для обсуждения.

За исключением комментариев (§3.7), идентификаторов (§3.8) и содержимого символьных литералов, строковых литералов и текстовых блоков (§3.10.4, §3.10.5, §3.10.6), все элементы ввода (§3.5) в программе формируются только из символов ASCII (или экранирований Юникода (§3.3), которые приводят к символам ASCII).

ASCII (ANSI X3.4) — это американский стандартный код для обмена информацией. Первые 128 символов кодировки Unicode UTF-16 — это символы ASCII.

Поток исходных символов Юникода преобразуется в последовательность токенов с использованием следующих трех лексических шагов, которые применяются поочерёдно:

На каждом шаге используется самое длинное возможное преобразование, даже если результат в итоге не формирует корректную программу, в то время как другое лексическое преобразование было бы таковым. Существует два исключения, чтобы учесть ситуации, требующие более тонкого преобразования: на шаге 1, для обработки последовательных \ символов (§3.3), и на шаге 3, для обработки контекстных ключевых слов и смежных > символов (§3.5).

Символы ввода a--b распознаются как a, -- и b, что не является частью какой-либо грамматически корректной программы, даже если распознавание a, -, -, b могло бы быть частью грамматически корректной программы. Распознавание a, -, -, b может быть реализовано с помощью символов ввода a- -b (с символом ASCII SP между двумя - символами).

Можно предположить, что исходный ввод \\u1234 преобразуется в символ \ и (в соответствии с правилом «самое длинное возможное») в экранирование Юникода вида \u1234. На самом деле, ведущий символ \ заставляет этот исходный ввод преобразовываться в семь различных символов: \ \ u 1 2 3 4.

Компилятор языка программирования Java ("компилятор Java") сначала распознаёт экранирования Юникода в своём исходном коде, преобразуя ASCII-символы \u, за которыми следуют четыре шестнадцатеричных цифры, в символ исходного кода, обозначающий единицу кодировки UTF-16 (§3.1) для указанного шестнадцатеричного значения. Одно экранирование Юникода может представлять символы в диапазоне U+0000 до U+FFFF; для представления дополнительных символов в диапазоне U+010000 до U+10FFFF требуется два последовательных экранирования Юникода. Все другие символы в исходном коде компилятора распознаются как символы исходного кода и передаются без изменений.

Этот этап преобразования приводит к последовательности символов ввода Юникода, все из которых являются символами исходного кода (любые экранирования Юникода были преобразованы в символы исходного кода).

\, u и шестнадцатеричные цифры здесь — все ASCII-символы.

Производство СимволВводаЮникода неоднозначно, потому что ASCII-символ \ в исходном коде компилятора может быть преобразован либо в СимволИсходногоКода, либо в \ ЭкранированияЮникода (за которым следует ASCII-символ u). Чтобы избежать неоднозначности, при обработке каждого ASCII-символа \ в исходном коде компилятора необходимо учитывать последние символы исходного кода, полученные на данном этапе преобразования:

Если допустимый \ не следует за u, то он обрабатывается как СимволИсходногоКода и остаётся частью потока экранированного Юникода.

Если допустимый \ следует за u, или если за ним следует более одной u, и последняя u не следует за четырьмя шестнадцатеричными цифрами, то возникает ошибка времени компиляции.

Символ, полученный с помощью экранирования Юникода, не участвует в дальнейших экранированиях Юникода.

Язык программирования Java определяет стандартный способ преобразования программы, написанной на языке Юникод, в ASCII, который преобразует программу в форму, которую могут обработать инструменты, основанные на ASCII. Преобразование включает в себя преобразование всех экранирований Юникода в исходном тексте программы в ASCII путём добавления дополнительной u — например, \uxxxx становится \uuxxxx — и одновременного преобразования символов в исходном тексте, не являющихся ASCII, в экранирования Юникода, содержащие по одному u.

Эта преобразованная версия так же приемлема для компилятора Java и представляет точно такую же программу. Точный исходный текст Юникода может быть восстановлен из этой ASCII-формы путём преобразования каждой последовательности экранирования, где присутствует несколько u, в последовательность символов Юникода с одной u меньше, и одновременного преобразования каждой последовательности экранирования с одной u в соответствующий единственный символ Юникода.

Компилятор Java должен использовать обозначение \uxxxx в качестве формата вывода для отображения символов Юникода, когда подходящий шрифт недоступен.

Компилятор Java затем разделяет последовательность символов ввода Юникод на строки, распознавая разделители строк.

Строки завершаются символами ASCII CR, или LF, или CR LF. Два символа CR, непосредственно за которыми следует LF, считаются одним разделителем строк, а не двумя.

Разделитель строк указывает на завершение формы комментария // (§3.7).

Строки, определяемые разделителями строк, могут определять номера строк, создаваемые компилятором Java.

Результат — последовательность разделителей строк и символов ввода, которые являются терминальными символами для третьего шага процесса токенизации.

Символы ввода и разделители строк, которые получаются после обработки символов Юникод (§3.3) и затем распознавания строк (§3.4), сводятся к последовательности элементов ввода.

Те элементы ввода, которые не являются пробелами или комментариями, являются токенами. Токены — терминальные символы синтаксической грамматики (§2.3).

Пробелы (§3.6) и комментарии (§3.7) могут служить для разделения токенов, которые, если будут рядом, могли бы быть токенизированы другим способом.

Например, символы ввода - и = могут образовывать операторный токен -= (§3.12) только в том случае, если между ними нет пробелов или комментариев. В качестве другого примера, десять символов ввода staticvoid образуют один токен идентификатора, в то время как одиннадцать символов ввода static void (с символом ASCII SP между c и v) образуют пару токенов ключевых слов, static и void, разделенных пробелами.

В качестве особой уступки для совместимости с некоторыми операционными системами символ ASCII SUB (\u001a, или управляющий символ Z) игнорируется, если он является последним символом в потоке экранированного ввода.

Производство Вход является неоднозначным, что означает, что для некоторых последовательностей символов ввода существует более одного способа уменьшения символов ввода до элементов ввода (то есть, токенизировать символы ввода). Неопределенности разрешаются следующим образом:

Рассмотрим два токена x и y в результирующем потоке ввода. Если x предшествует y, то мы говорим, что x находится слева от y и что y находится справа от x.

class Empty {
}

Пробелы определяются как символ ASCII пробела, символ горизонтальной табуляции, символ подачи страницы и символы разделителей строк (§3.4).

Существуют два вида комментариев:

Эти правила подразумевают все следующие свойства:

/* this comment /* // /** ends here: */

Лексическая грамматика подразумевает, что комментарии не встречаются внутри символьных литералов, строковых литералов или текстовых блоков (§3.10.4, §3.10.5, §3.10.6).

Идентификатор — это последовательность неограниченной длины символов Java и цифр Java, первый из которых должен быть символом Java.

"Символ Java" — это символ, для которого метод Character.isJavaIdentifierStart(int) возвращает true.

"Символ Java или цифра" — это символ, для которого метод Character.isJavaIdentifierPart(int) возвращает true.

"Символы Java" включают заглавные и строчные латинские буквы ASCII A-Z (\u0041-\u005a), а также a-z (\u0061-\u007a), и, по историческим причинам, символ доллара ASCII ($, или \u0024) и знак подчеркивания (_, или \u005f). Символ доллара следует использовать только в автоматически генерируемом исходном коде или, в редких случаях, для доступа к имеющимся именам в legacy-системах. Знак подчеркивания может использоваться в идентификаторах, состоящих из двух или более символов, но не может использоваться в качестве идентификатора из одного символа, так как является ключевым словом.

"Цифры Java" включают цифры ASCII 0-9 (\u0030-\u0039).

Символы и цифры могут быть взяты из всего набора символов Unicode, который поддерживает большинство письменных систем, используемых в мире сегодня, включая большие наборы для китайского, японского и корейского языков. Это позволяет программистам использовать идентификаторы в своих программах, написанных на родном языке.

Два идентификатора совпадают только тогда, когда, после игнорирования игнорируемых символов, идентификаторы имеют одинаковый символ Unicode для каждой буквы или цифры. Игнорируемый символ — это символ, для которого метод Character.isIdentifierIgnorable(int) возвращает true. Идентификаторы, имеющие одинаковый внешний вид, могут быть различными.

Идентификатор никогда не имеет такого же написания (последовательности символов Unicode), как зарезервированное ключевое слово (§3.9), булево значение (§3.10.3) или значение null (§3.10.8), из-за правил токенизации (§3.5). Однако идентификатор может иметь такое же написание, как контекстное ключевое слово, поскольку токенизация последовательности входных символов как идентификатора или контекстного ключевого слова зависит от того, где эта последовательность встречается в программе.

Для облегчения распознавания контекстных ключевых слов синтаксическая грамматика (§2.3) иногда запрещает определённые идентификаторы, определяя производство, которое принимает только подмножество идентификаторов. Подмножества следующие:

ТипИдентификатор используется при объявлении классов, интерфейсов и параметров типа (§8.1, §9.1, §4.4), и при ссылке на типы (§6.5). Например, имя класса должно быть ТипИдентификатор, поэтому недопустимо объявлять класс с именем permits, record, sealed, var или yield.

НеквалифицированныйИдентификаторМетода используется, когда выражение вызова метода ссылается на метод по его простому имени (§6.5.7.1). Поскольку термин yield исключён из НеквалифицированныйИдентификаторМетода, любой вызов метода с именем yield должен быть квалифицирован, тем самым отличая вызов от оператора yield (§14.21).

51 последовательность символов, образованных из символов ASCII, зарезервированы для использования в качестве ключевых слов и не могут использоваться в качестве идентификаторов (§3.8). Ещё 16 последовательностей символов, также образованных из символов ASCII, могут интерпретироваться как ключевые слова или другие токены, в зависимости от контекста, в котором они появляются.

abstract   continue   for          new         switch
assert     default    if           package     synchronized
boolean    do         goto         private     this
break      double     implements   protected   throw
byte       else       import       public      throws
case       enum       instanceof   return      transient
catch      extends    int          short       try
char       final      interface    static      void
class      finally    long         strictfp    volatile
const      float      native       super       while
_ (underscore)

exports      opens      requires     uses
module       permits    sealed       var
non-sealed   provides   to           with
open         record     transitive   yield

Ключевые слова const и goto зарезервированы, даже если они в настоящее время не используются. Это может позволить компилятору Java создавать более информативные сообщения об ошибках, если эти ключевые слова C++ некорректно появятся в программах.

Ключевое слово strictfp устарело и не должно использоваться в новом коде.

Ключевое слово _ (подчеркивание) зарезервировано для возможного будущего использования в объявлениях параметров.

true и false не являются ключевыми словами, а являются булевыми литералами (§3.10.3).

null не является ключевым словом, а является литералом null (§3.10.8).

Во время сокращения входных символов до входных элементов (§3.5), последовательность входных символов, которая по смыслу соответствует контекстному ключевому слову, сокращается до контекстного ключевого слова только в том случае, если выполняются оба следующих условия:

В общем случае, случайное пропущение пробелов в исходном коде приведет к тому, что последовательность входных символов будет распознана как идентификатор из-за правила «наиболее длинного возможного перевода» (§3.2). Например, последовательность из двенадцати входных символов p u b l i c s t a t i c всегда распознается как идентификатор publicstatic, а не как зарезервированные ключевые слова public и static. Если предполагается два токена, их необходимо разделить пробелами или комментарием.

Указанное выше правило работает совместно с правилом «наиболее длинного возможного перевода», чтобы получить интуитивный результат в контекстах, где могут появляться контекстные ключевые слова. Например, последовательность из одиннадцати входных символов v a r f i l e n a m e обычно распознается как идентификатор varfilename, но в объявлении локальной переменной первые три входных символа предварительно распознаются как контекстное ключевое слово var по первому условию правила выше. Однако было бы запутанно пропустить отсутствие пробелов при распознавании следующих восьми входных символов как идентификатора filename. (Это означало бы, что последовательность подвергается различной лексемизации в различных контекстах: идентификатор в большинстве контекстов, но контекстное ключевое слово и идентификатор в объявлениях локальных переменных.) Соответственно, второе условие предотвращает распознавание контекстного ключевого слова var по той причине, что непосредственно следующий входной символ f является JavaLetterOrDigit. Последовательность v a r f i l e n a m e поэтому распознается как идентификатор varfilename в объявлении локальной переменной.

В качестве ещё одного примера внимательного распознавания контекстных ключевых слов рассмотрим последовательность из 15 входных символов n o n - s e a l e d c l a s s. Эта последовательность обычно преобразуется в три токена — идентификатор non, оператор - и идентификатор sealedclass — но в объявлении обычного класса, где выполняется первое условие, первые десять входных символов предварительно распознаются как контекстное ключевое слово non-sealed. Чтобы избежать преобразования последовательности в два ключевых слова (non-sealed и class) вместо трёх неключевых токенов, и чтобы избежать вознаграждения программиста за пропуск пробелов перед class, второе условие предотвращает распознавание контекстного ключевого слова. Последовательность n o n - s e a l e d c l a s s поэтому распознаётся как три токена в объявлении класса.

В приведенном выше правиле первое условие зависит от деталей синтаксической грамматики, но компилятор языка программирования Java может реализовать это правило без полного разбора входной программы. Например, можно использовать эвристику для отслеживания контекстного состояния токенизатора, при условии, что эвристика гарантирует, что допустимые использования контекстных ключевых слов токенизируются как ключевые слова, а допустимые использования идентификаторов — как идентификаторы. В качестве альтернативы компилятор может всегда токенизировать контекстное ключевое слово как идентификатор, оставив позднее определение особых применений этих идентификаторов.

Двенадцать лексем, образованных из ASCII-символов, являются разделителями (пунктуаторами).

(   )   {   }   [   ]   ;   ,   .   ...   @   ::

38 лексем, образованных из ASCII-символов, являются операторами.

=   >   <   !   ~   ?   :   ->
==  >=  <=  !=  &&  ||  ++  --
+   -   *   /   &   |   ^   %   <<   >>   >>>
+=  -=  *=  /=  &=  |=  ^=  %=  <<=  >>=  >>>=