Почему Closure Compiler настаивает на добавлении дополнительных байтов?

Я думаю, что происходит, но я ни в коем случае не уверен...

Код, вызывающий вставку запятых, tryMinimizeStringArrayLiteral в PeeholeSubstituteAlternateSyntax.java.

Этот метод содержит список символов, которые, вероятно, имеют низкое кодирование Хаффмана и поэтому предпочтительны. разделить на чем другие символы. Вы можете увидеть результат этого, если попробуете что-то вроде этого:

"a b c d e f g".split(" "); //Uncompiled, split on spaces
"a,b,c,d,e,f,g".split(","); //Compiled, split on commas (same size)

Компилятор заменит символ, который вы пытаетесь разбить, на тот, который он считает благоприятным. Он делает это, перебирая символы строки и находя наиболее подходящий символ разделения, который не встречается в строке:

// These delimiters are chars that appears a lot in the program therefore
// probably have a small Huffman encoding.
NEXT_DELIMITER: for (char delimiter : new char[]{',', ' ', ';', '{', '}'}) {
  for (String cur : strings) {
    if (cur.indexOf(delimiter) != -1) {
      continue NEXT_DELIMITER;
    }
  }
  String template = Joiner.on(delimiter).join(strings);
  //...
}

В приведенном выше фрагменте вы можете увидеть массив символов, который компилятор считает оптимальным для разбиения. Запятая стоит первой (поэтому в моем примере с пространством выше пробелы заменены запятыми).

Я считаю, что вставка запятых в случае, когда строка для разделения является пустой строкой, может быть просто недосмотром. По-видимому, для этого случая не существует какой-либо специальной обработки, поэтому он обрабатывается как любой другой вызов split, и каждый символ соединяется с первым подходящим символом из массива, показанного в приведенном выше фрагменте.

Еще один пример того, как компилятор работает с методом split:

"a,;b;c;d;e;f;g".split(";"); //Uncompiled, split on semi-colons
"a, b c d e f g".split(" "); //Compiled, split on spaces

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

Обновить

После некоторых дальнейших исследований этого, это определенно не ошибка. Такое поведение на самом деле предусмотрено дизайном, и, на мой взгляд, это очень умная маленькая оптимизация, если учесть, что компилятор Closure предпочитает скорость скомпилированного кода размеру.

Выше я пару раз упомянул кодировку Хаффмана. Алгоритм кодирования Хаффмана, объясняемый очень просто, присваивает вес каждому символу, появляющемуся в кодируемом тексте. Вес основан на частоте появления каждого символа. Эти частоты используются для построения бинарного дерева с наиболее распространенным символом в корне. Это означает, что наиболее распространенные символы декодируются быстрее, поскольку они находятся ближе к корню дерева.

И поскольку алгоритм Хаффмана является значительной частью алгоритма DEFLATE, используемого gzip. Поэтому, если ваш веб-сервер настроен на использование gzip, ваши пользователи получат выгоду от этой умной оптимизации.

Эта проблема была исправлена ​​20 апреля 2012 г. См. редакцию: https://code.google.com/p/closure-compiler/source/detail?r=1267364f742588a835d78808d0eef8c9f8ba8161

По иронии судьбы, split в скомпилированном коде не имеет ничего общего с split в исходном коде. Рассмотреть возможность:

Source  : a = ["0","1","2","3","4","5"]
Compiled: a="0,1,2,3,4,5".split(",")

Здесь split - это просто способ представления длинных массивов (достаточно длинных, чтобы сумма всех кавычек + запятых была длиннее split(","") ). Итак, что происходит в вашем примере? Во-первых, компилятор видит строковую функцию, примененную к константе, и сразу ее вычисляет:

'0123456789'.split('') => ["0","1","2","3","4","5","6","7","8","9"]

В какой-то момент при формировании вывода компилятор считает этот массив «длинным» и записывает его в приведенной выше «разделенной» форме:

["0","1","2","3","4","5","6","7","8","9"] => "0,1,2,3,4,5,6,7,8,9".split(",")

Обратите внимание, что вся информация о split('') в источнике к этому моменту уже потеряна.

Если бы исходная строка была короче, она была бы сгенерирована в виде массива массива без дополнительного разбиения:

Source  : a = '0123'.split('')
Compiled: a=["0","1","2","3"]