Вопрос состоит в следующем: мне необходимо сохранять много текстовой инфрмации (ну это своего рода различные настройки приложения ) так как луче сделать сохранять их в XML или обычном текстовом файле. Дело в том что эти настройки в дальнеёшем можно будет открывать и использовать в 2-ом приложении (это приложение может быть написано на 2-ом языке). ?

И на этой почве ещё один вопрос как в Java обстоит работа с XML и файлами?

Ну это по вкусу.  

С XML в Java обстоит хорошо. Единственно, ИМХО, не стоит использовать dom классы, которые она предлагает по умолчанию. Лучше взять jar с dom4 (У меня dom4j-1.6.1.jar но может есть версия и новее). Но это, естественно, если собираетесь работать с DOM.

_Y_, а где есть документация желательно на русском по работе JAVA + XML 



где можно скачать эту библиотеку.



Не совсем понял а без Dom это что имеется ввиду?

java.util.Properties

SAX, например.

Не знаю. Доки, но они на английском. Может Googl поможет?


http://www.dom4j.org


XML может обрабатываться как единый документ (модель DOM), а может - посредством генерации событий (модель SAX).  В поледнем случае можно работать с документами любого размера - в памяти все равно они не остаются. Это не только в Java, но и в других языках - две модели на выбор. Но я работал только с DOM.

Добавлено @ 16:30

Вряд-ли годиться, т.к. ему надо использовать те же установки программами, написанными на других языках.

Это сообщение отредактировал(а) _Y_ - 12.9.2007, 16:31

Ну и всётаки что луче по вашему DOM или SAX?

Что лучше, кошка или собака? Я бы сказал, что для небольших количеств информации удобнее DOM, но если ее столько, что памяти жалко, то только SAX.

а вот если я поработал с DOM забрал все данные которые мне необходимы то память почле этого же освобождается?

Со временем gc очистит память.

Мы пробуем сейчас сохранять свойства программы в xml с помощью java.bean.XMLEncoder/Decoder. При закрытии программы создается обьект, хранящий текущие параметры программы. С помощью анкодера предполагаем получать xml, который сохраняется на сервере. При старте программы xml загружается в программу и с помощью декодера восстанавливается обьект установок. XML предпочли потому, что параметров очень много. В использованием Preferences не устроило то, что свойства пишутся в регистр и приложение (JNLP) должно иметь соответствующие права. Такой подход годится только для использования одним приложением.

Это сообщение отредактировал(а) COVD - 12.9.2007, 18:31

классы XMLEncoder i XMLDecoder из java.util.   

точнее, в java.beans

А если с SAX работать то память не gc освобождает? также со временем?

Добавлено через 2 минуты и 56 секунд


Tony,  у меня JDK 1.5 и в java.util нет етих классов. Но зато они есть в java.beans 

DOM загружает в память сразу весь xml документ, потом начинает его парсировать. Может так случиться, что памяти не хватит, чтобы весь документ загрузить. 

SAX загружает кусочек документа, парсирует его и освобождает, потом загружает следующий кусочек, снова парсирует и освобождает, ...

В обоих случаях gc будет чистить память, но легче ему будет с SAX, т.к. загружаемые порции более мелкие.

если надо редактировать дерево в коде - DOM.
если нет - то SAX.
все просто...

Может, тогда проще писать в файл пропертей?
Зачем генерить xml, затем ее читать, когда можно просто просетать нужные свойства и сохранить в файл?
И, кстати, класс ResourceBundle может сохранять как properties файл, так и xml.

Кошка однозначно 

А можно какието примеры по работе с настройками ну или как работать с XML создавать его редактировать, открывать и читать с него? И как его подключить себе? 

Проперти - это просто список параметр=значение. Удобно для простых случаев. Теперь представьте, что пользователь открывает в приложении несколько окон. При закрытии программы надо сохранить, например, текущие размеры, позицию каждого окна и состояния чекбоксов. Список свойств становится динамическим (количество параметров)  и принимает вид окно.параметр=значение . Если внутри окна есть вложенные компоненты , то окно.компонент.параметр=значение.  И это надо программировать очевидно вручную. А использование xml позволяет автоматизировать этот процесс благодаря наличию парсеров.

Абсолютно согласен.
Я имею в виду, что для простых случаев можно воспользоваться простыми решениями 

Да у меня как раз сложный случай всё как писал COVD, подскажите пожалуста доки на русском или готовые хорошие примеры по работе с XML

кхе, эта, ключик для бандла сформировать на основе типа, имени компонента и его иерархии сложно? По-моему гораздо сложнее в данном случае писать DOM модель, т.к. данные, очевидно, придется сохранять. DOM модель, суть - дерево, иерархия компонентов - дерево. Дерево будем строить, типо, второй раз? Удобство лично для меня сомнительно... проперти проще. К тому же проперти можно (и удобно) разнести на разные бандлы для различных целей, а если надо разнести XML-ник, придется писать парсеры и домифайеры на каждый формат... Сейчас вы мне скажете про универсальный формат, угу, непомерных размеров, в котором без XML Spy не разберешься... да и весить он будет в 3 раза больше пропертей по причине избыточной информации...

ПыСы
кстати, если задуматься о записи, если предположить, что у нас пропертисы, ну, или , там, XML-ник запакован в jar либо в war/ear, то встает законный вопрос, куда писать.... советую глянуть в сторону http://java.sun.com/javase/6/docs/api/java...ge-summary.html
http://java.sun.com/javase/6/docs/api/java...references.html

Это сообщение отредактировал(а) y3u - 13.9.2007, 20:12

Preferences мы откинули по причине того, что у нас webstart клиент и не хочется его подписывать, а иначе у него нет необходимых прав куда-то писать. Он вступает в диалог с пользователем, а нам этого не надо. Кроме того еще неизвестно, поможет ли подписка пользователям, которые работают из офиса и не имеют административных прав на своем служебном компьютере (всеобщая озабоченность безопасностью). Поэтому мы будем писать только на сервер. А вообще конечно это удобно.



Про ключик я не знаю как и что. Буду благодарен, если намекнете. Но и Дом модель писать тоже вроде не надо. Предполагаем, что каждый компонент вернет обьект - java bean (тут уж вручную, наверное, только нужные свойства), и этот бин через  java.beans.XMLEncoder/Decoder будем превращать в xml и обратно.

to Reptor

у вас требование, чтобы свойства можно было восстановить в другой программе и возможно написанной на другом языке, поэтому использование java.beans.XMLEncoder/Decoder возможно не лучший для вас вариант (для нас возможно тоже    ).


Это сообщение отредактировал(а) COVD - 13.9.2007, 21:37

а куда на сервер? Если в FS, тогда вопрос: а если клентов хотя бы 1000 и каждому по метру на настройки - это уже гиг, квотировать, таки, придется иначе со временем сожрется вся память. Рулить квотами кто будет? А мониторинг неиспользуемых настроек тоже придется писать... А если в БД, ну, в принципе, если бабла не жалко, можно организовать под эту, в общем-то, бесполезную информацию, отдельный сервак, тогда да, согласен... 
Эта, может, таки, подписать?


и что? Виндовз тоже вступает с пользователем в диалог, когда юзер пытается удалить файл, Аутпост Файерволл или какой-нить Зоналарм, тоже вступают с пользователем в диалог, когда находятся в режие обучения. Я вас умоляю, на дворе 21 век, все умеют пользоваться компам, даже дети малые, чего такого страшного в диалоге? Это же нормально...

Добавлено через 7 минут и 35 секунд
кстати, впомнил, что у апачча в коммонсах видел полезную тулу, думаю, всех спасет 

http://commons.apache.org/configuration/

Это сообщение отредактировал(а) y3u - 14.9.2007, 08:39

FS - это file system? Что такое гиг. 21 век . В БД будем писать. Опять же это мобильность для клиента - утром соединился из офиса, вечером из дома.  



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





Вот именно. Дети как раз лучше умеют. Ничего не боясь жмут на кнопку Ok. А публика по другую сторону экватора - не всегда. Вы тоже считаете, что установить java-плагин на компьютер проще пареной репы? 

Конечно, проблема видится не в диалоге, а в том, что он просит дать доступ и т.д. Но вы правы, прогресс не остановить .


Добавлено @ 08:44
кстати, впомнил, что у апачча в коммонсах видел полезную тулу, думаю, всех спасет 

http://commons.apache.org/configuration/

Спасибо!