Троллинг у вас нормальный.
Хотя можете ввести в гугл слова "xml java read file" и "xml java write file" - но вряд ли найдете свои "уроки информатики".
Я страраюсь делать так сказать как во всех ресурсах написано - но тут видимо наткнулся на проблему которую будет трудно разрешить.
Как может у меня корневой элемент совпадать с null если он имеет название FILESYSTEM,
да хоть любою другое.
Использование Element mainRootElement = doc.createElementNS(" http://crunchify.com/CrunchifyCreateXMLDOM",null) не помогает.
Даже System.out.println ("Root element of the doc is " + xmlDoc.getDocumentElement().getNodeName()) выдает эту же ошибку.
Хотя конечно поиск можно делать и после формирование виртуального масива xml типа Document, но для чего тогда стандартная запись и чтение xml...

Вы что мне еще притензии ставите будете.
Вообще то я обратился на форум чтобы побыстрее сделать задание (чтобы мне по-сути что-то подсказали).
Чтение с файла кажется есть вначале.
И я могу считать в текст.ареа как через append (поток с файла) так и напрямую (при передаче String xmlmain1() где использвуется ElementToStream() ).
Только меня удивляет некие "причуды" компилятора который в последнем варианте использует прочтение всего списка файлов на диске С (хотя в методе волк поставлено ограничение на 1000 файлов), выводит только 300.
Так и сейчас - заменил doc.createElementNS на просто doc.createElement -записало 500 свойств файлов xml на диск, отменил валидацию при чтение с файла - и заработало. Но при выводе всех этих xml после чтение на консоли отображается лиш вторая половина (Вот если причина в том что я использую не Эклипс, то действительно создаю себе проблем-но раньше с этим проблем не было).
В любом случае - можно компонировать метод для поиска файла по имени в xml.

golovonometr,
пока еще понятие не имею, чем здесь модель может помочь, и в чем ее суть.
settext() наверное не лутче Append(), и последнее суто детище JtextArea и добавляет в конец, если добавлять по строкам.
У меня есть метод xmlmain который возвращает String и правильно выводить текст--
и в заканчитвается
строками:

- но до появление тесктовой области надо ждать несколь коминут.
Думаю это через то что надо чтобы главный клас наследовал Jframe,
и там уже была бы пустая текстовая область, которая лиш в мейне при вызове метода append
бы заполнила эту текстовую область.
Через FileReader read() работает, но там четко обозначен второй аргумент - имя (обьект) самого файла, а если считывать со второго потока, то второй аргумент нулл или неизвестно что. И самое главное -- почему самая текстовая область не появляется - конструктор создание ее обьекта ведь присущ, даже если read() не работает.

Решилось.
Теперь форматированое XML появляется в Jtextarea за пару секунд (в даном случае 5 тыс. описей файлов с 25 тыс. линеек тескта).
Достаточно было продвинуть метод апенда текста-
textArea.append(CrunchifyCreateXMLDOM1.xmlmain1 ()); -
в самый конец класа GUI, когда сперва появляется пустая текстовая область, а после процесинга она заполняется.
метод использованый из 3-ей страницы (спасибо сайту Java2s) - String xmlmain1 () -
там он з типом возврата ByteArrayOutputStream - но это неправильно ибо апенд берет лиш стринговые аргументы (но главное там использование toByteArray()).
Теперь мне надо компоновать GUI,
но обезпечить non-locking для 4 заданий(4 методов) -что-бы в конкретное время
исполнялся лиш один метод-что-то на подобе sychronized?
Но как это сделать в Свинге понятие не имею.
Как и поставить такие ограничение как невозможность записи в файл и рендеринга до окончание индексации, или невозможность поиска файла по его названию пока не записан xml на диск.

//Petro123, с вашыми советами не соскучишся. Может хватит.
На счет предупреждение, что исполняется (или не выполнено) другое задание - то напримере рендеринга XML надо наверное если исполянется индексация - в ее начале инициализировать некую переменную init в значение false, и если метод рендеринга проверяет ее и выявляет false то выводить сообщение, что надо подождать проведение индексации (и в таком случае через брейк выход из метода). Хотя здесь переменная init может принимать три значение- например, 0-индексация не запущена, 1-проводится индексация, 2-индексация полностью проведена. 0-дефолтное значение, 1-в начале метода индексации, 2- в конце метода индексации.
Проблема потоков здесь наверное не очень актуальна, а вопрос locking может возникнуть если, эта индексация проводится очень долго, хотя вряд ли возможно зависание апликации.
Хотя действительно надо использовать сохранение вектора индексации в виртуальной памяти, или во всех первых 3ех методах вызывать метод Filewalker.walk().
При поиске файла по имени можно уже считывать с записаного файла, если конечно не будет проблем с записую, тем болем всего масива xml.

//Petro123, думаю здесь больше неуместной критики не будет (по-сути пожалуста)
Выявляется если выводить все xml файлов в textarea со всего диска С:\, то появляется уже давно изветсная ошибка
Именно на строке textArea.append(CrunchifyCreateXMLDOM1.xmlmain1 ());
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space.
Если записывать в файл, то отображается лиш 3 тыс. элементов, хотя всего на диске 85 тыс. единиц (xml всего 350 кб весит), и такая проблема при записи постоянна. В конце списка xml –такая ошибка - "Не удается отобразить страницу XML - Не удается просмотреть ввод XML с использованием списка стилей XSL." То есть я так понимаю
Записать весь xml на диск я не смогу?.
Выход наверное сегментация – например несколько textare.append () применить, если нехватка памяти через невозможность апенда передать за раз больше например 5 мб., если текстовая область неможеть выдержать столько мегабайт, то разве Jtree использовать.
Тогда поиск надо разве по вектору обьектов Filewalker использовать.
Если кто не понимает – то таких проблем нету при небольших количествах файлов свойств которые считываются – например при 5 тыс. все нормально вчера работало.
Если ошибки связаны с памятью – то на диск сериализированый файл занимал место около 12 мб., пока что на диске в 2 разы больше (хотя в общем очень мало), и размер xml не больше обьема сериализации.
Памяти 0,5 гиг –может на компе с нормальной памятью - OutOfMemoryError: Java heap space не будет.

Petro123, вас уже должны были заблокировать.
Про БД у меня в начале написано - хотя толку - xml это обычный текстовый файл.
Однако как написано в англоязычном интернете - dom схема - может создать максимум сотни, или тысячи узлов (которые все есть обьектами), а здесь только файлов 85 тыс.
Вот кажется простая альтернатива -stax-
http://tutorials.jenkov.com/java-xml/stax-xmlstreamwriter.html.
Больше того - вот уже пол часа записисывается файл xml - пока что не написано что program finished. А проверяя обьем этого файла - вот такая динамика - 0 - 3.45 мб. - 0 - 1.8 мб - 3.8 мб. То есть что то мешает полностью записать этот файл?

Petro123, дивно что вас не заблокировано, может какая хотя бы автоблокировка сработает. Если я все детально описываю, это через то что мне
надо это как можно быстрее сделать. Будет напутствие другим, да и я сам если надо что-то припомню. То что есть 4 страницы это одно а то что нету дельных советов это очевидно. Вот был же вариант использовать stах writer (ибо dom разве для пару тысяч узлов, не более). Там все очень просто и быстро. Две закавыки --1. Все записывается в одну строку - потому надо какой то эфективный способ размещение перехода на другую строку возле открывающихся и закрывающихся тегов.2. Надо чтобы не было проблем с прочтением кирилицы. Когда указал кодировку в startDocument("utf-8"), то появилась другая проблема. Что так трудно было подсказать о stах? Не думаю что эти две проблемы не решаются. Хотя поиск по тегам с помощью stах rеаdеr вряд ли проведеш.