Глава 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 устарело и не должно использоваться в новом коде.

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

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

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