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

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

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

Стандарт Юникод изначально разрабатывался как кодировка символов с фиксированной шириной 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, в основном в классе Character, используют 32-битовые целые числа для представления кодовых точек как отдельных сущностей. Платформа Java SE предоставляет методы для преобразования между 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) иногда запрещает определённые идентификаторы, определяя производство, принимающее только подмножество идентификаторов. Подмножества следующие:

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

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

51 последовательность символов, сформированных из ASCII-символов, зарезервированы для использования в качестве ключевых слов и не могут использоваться в качестве идентификаторов (§3.8). Ещё 17 последовательностей символов, также сформированных из 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   yield
module       permits    sealed       var         
non-sealed   provides   to           when        
open         record     transitive   with        

Ключевые слова 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-символов, являются операторами.

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