Следующее замечание касается начальной емкости StringBuffer (необязательный параметр конструктора). Можно было бы попытаться оценить требуемую емкость, исходя из длины файла и заказанной кодировки. Но для сложных кодировок здесь легко ошибиться, заказав слишком много памяти, особенно учитывая возможное появление новых кодировок в будущем. А это чревато возникновением ошибки «Out of memory», даже когда на самом деле виртуальной памяти Java достаточно для размещения файла. Ускорение же, которого можно добиться таким способом, крайне незначительно и теряется на фоне «расшифровки» сложных кодировок и дисковых операций чтения файла.

Описанную функцию loadFileAsString можно дополнить версиями, читающими файл в виде массива символов, а также работающими с именем файла вместо объекта File:

  public static String loadFileAsString(

    String fileName, String encoding)

    throws IOException

  {

    return loadFileAsString(

      new File(fileName),encoding);

  }

  public static char[] loadFileAsChars(

    String fileName, String encoding)

    throws IOException

  {

    return loadFileAsChars(

      new File(fileName),encoding);

  }

  public static char[] loadFileAsChars(

    File file, String encoding)

    throws IOException

  {

    String buf= loadFileAsString(file,encoding);

    char[] result= new char[buf.length()];

    buf.getChars(0,result.length,result,0);