public String getSystemDisplayName(File f)

  public String getSystemTypeDescription(File f)

  public javax.swing.Icon getSystemIcon(File f)

Эти методы предназначены для визуального отображения файлов или подкаталогов в виде списка (например, в диалоге выбора файла). Метод getSystemDisplayName позволяет узнать, как операционная система рекомендует именовать данный элемент. Для корня диска C: может быть получено что-то вроде «WINDOWS (C:)», для рабочего стола – «Desktop». Метод getSystemTypeDescription дополняет имя элемента описанием, которое обычно можно увидеть при просмотре каталога в режиме «Details». Например, это может быть «File Folder», «Text Document» для txt-файла, «Application» для exe-файла. Наконец, метод getSystemIcon возвращает иконку, которую операционная система рекомендует использовать для графического представления данного файла или подкаталога.

  public boolean isParent(File folder, File file)

Этот метод не имеет аналогов в классе File. В рамках пакета java.io.* для аналогичных целей должен был бы использоваться примерно такой вызов:

  file.getParent().equals(folder.getPath())

(возможно, с предварительным приведением маршрутов к каноническому виду методами getCanonicalPath). При работе с более сложными современными файловыми системами подобная проверка строк была бы некорректна. Действительно, folder.getPath() может вернуть «My Computer» как для настоящего элемента «My Computer» – родителя каталога «C:», так и для подкаталога с именем «My Computer» в текущем каталоге Windows. Попытка использовать getCanonicalPath не привела бы к успеху – для «My Computer» метод getCanonicalPath порождает исключение, так как никакому осмысленному каталогу подобный элемент файловой системы не соответствует.

На самом деле современная реализация метода isParent (JDK 1.4.1) устроена крайне неэффективно. Если folder – наследник некоего внутреннего класса sun.awt.shell.Shell-Folder (именно такие наследники получаются для всех каталогов, возвращаемых методами FileSystemView), то метод isParent, не мудрствуя лукаво, получает полный список всех «детей» folder (вызовом getFiles) и поочередно сравнивает объект file с каждым из них.

Вот типичный пример скрытой квадратичности, глубоко «закопанной» в исходниках библиотечных модулей. В частности, такая реализация порождает ужасающее «торможение» визуального компонента JFileChooser при попытке просматривать с помощью клавиатуры каталог из сотен или тысяч файлов. Связано это с тем, что любое перемещение курсора по каталогу приводит к вызову метода setSelectedFile, делающему новый файл активным. Этот метод проверяет (вызовом isParent), точно ли текущий выбранный каталог является «родителем» по отношению к новому файлу, и если это не так, изменяет текущий каталог. Действие в данной ситуации, вообще говоря, бессмысленное. (Это издержки общей организации модуля JFileChooser: один и тот же метод setSelectedFile используется и для управления компонентом «снаружи», когда текущий каталог действительно может измениться, и при реакции на стрелки «вверх»/«вниз».) Проверка нового выбранного файла методом isParent требует полного перебора всех файлов текущего каталога, так как каталоги в JFileChooser всегда представлены наследниками File, сгенерированными методами FileSystemView. В результате каждое нажатие на стрелку «вверх»/«вниз» приводит к линейному перебору каталога, а полная прокрутка каталога с помощью стрелок на клавиатуре означает квадратичное число операций.

Аналогичное «скрытое» торможение легко можно получить, легкомысленно пользуясь методами getDefault-Directory() и getHomeDirectory(), которые могут понадобиться и в совершенно «невизуальной» программе. Эти методы тоже возвращают наследников ShellFolder, и для них isParent работает медленно. В моей практике был случай, когда программа начала загружаться в десятки раз медленнее (несколько минут) только из-за того, что в момент старта был добавлен простой анализ содержимого каталога getDefault-Directory(). Причина оказалась именно в методе isParent, превратившего нормальный линейный алгоритм анализа в квадратичный. Самое неприятное, что проблема проявлялась только в случае, когда каталог «My Documents» содержал много элементов – ситуация типичная для рядового пользователя, но сравнительно редкая для хорошо структурированных файловых систем профессионалов.