Каковы относительные преимущества XMLEncoder и XStream?

Мне действительно нравится библиотека XStream. Это делает действительно хорошее задание вывода довольно простого xml в результате обеспеченного объекта Java. Это работает отлично для репродуцирования объекта назад от xml также. И, одна из наших сторонних библиотек уже зависела от него так или иначе.

• Мы приняли решение использовать его, потому что мы хотели, чтобы наш xml был человекочитаем. Используя псевдоним функция делает это намного более хорошим.

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

Двухминутное учебное руководство подводит итог основного использования, но в интересах того, чтобы хранить информацию в одном месте, я попытаюсь подвести итог его здесь, просто немного короче.

// define your classes
public class Person {
  private String firstname;
  private PhoneNumber phone;
  // ... constructors and methods
}

public class PhoneNumber {
  private int code;
  private String number;
  // ... constructors and methods
}

Затем пользуйтесь библиотекой для, выписывают xml.

// initial the libray
XStream xstream = new XStream();
xstream.alias("person", Person.class); // elementName, Class
xstream.alias("phone", PhoneNumber.class); 

// make your objects
Person joe = new Person("Joe");
joe.setPhone(new PhoneNumber(123, "1234-456"));

// convert xml
String xml = xstream.toXML(joe);

Вы производите, будет похож на это:

<person>
  <firstname>Joe</firstname>
  <phone>
    <code>123</code>
    <number>1234-456</number>
  </phone>
</person>

Возвратиться:

Person newJoe = (Person)xstream.fromXML(xml);

XMLEncoder обеспечивается для бобовой сериализации Java. В прошлый раз, когда я использовал его, файл выглядел довольно противным. Если действительно не заботятся о том, на что похож файл, он мог работать на Вас, и Вы добираетесь для предотвращения сторонней зависимости, которая также хороша. Я ожидал бы, что возможность создания более симпатичной сериализации будет больше проблемой с XMLEncoder также.

XStream производит полное имя класса, если Вы не искажаете имя. Если класс Человека выше имел

package example;

Другое предложение: рассмотрите использование JAXB (http://jaxb.dev.java.net). При использовании JDK 1.6 он прибывает связанный, выезд "javax.xml.bind" для получения дополнительной информации таким образом, никакая потребность в дополнительных внешних банках.

JAXB довольно быстр. Мне нравится XStream также, но это - бит медленнее. Кроме того, XMLEncoder является битом игрушки (по сравнению с другими опциями)..., но если это работает, нет никакого вреда в использовании его.

Также: одно преимущество JAXB - то, что можно также связать частичный документ (поддеревья) с ним; никакая потребность создать объект (объекты) для целого файла. Для этого необходимо использовать Stax (XMLStreamReader) для указания на корневой элемент поддерева, затем связать. Никакая потребность использовать SAX, даже для самых больших файлов, пока это может быть обработано блок блоком.

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

Если использование памяти будет беспокойством (то файл, содержащий XML, будет очень большим), я рекомендую SAX.

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

Я также предпочел бы XStream, поскольку это действительно просто в использовании и расширяться. Можно быстро запустить, если Вы идете с установкой по умолчанию. Если необходимо настроить поведение, оно имеет очень чистый API и много точек расширения, таким образом, Вы имеете действительно мелкомодульный контроль над вещами, Вы хотите настроить, не вмешиваясь в другие части процесса маршалинга.

Поскольку XML, который создается XStream, выглядит хорошим, ручное редактирование также просто. Если вывод не выполняет Ваши потребности, и длинный список доступных Преобразователей не содержит тот, в котором Вы нуждаетесь, довольно просто записать Ваше собственное.

Большой плюс является также хорошая документация относительно их домашней страницы.

В Java также есть новый служебный класс, предназначенный для хранения парных наборов ключей и значений, типичных для конфигураций. Это старый стиль, но очень простой и удобный. Это делается с помощью класса java.util.Properties , объекта Map с параметрами сериализации. Это может быть все, что вам нужно, если вы не храните целые объекты.

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

В результате я обычно переключаюсь на JAXB. Он намного более надежен, почти не содержит ошибок и более гибкий, чем XStream.

Вам следует избегать использования XMLEncoder / XMLDecoder как чумы, если вы собираетесь сохранять нетривиальное количество объектов или ваша система должна быть многопоточной. См. Ужасающие подробности http://matthew.mceachen.us/blog/do-not-want-xmlencoder-129.html .

Если вам необходимо использовать XML, XStream отлично подойдет. Но спросите себя, действительно ли вам нужно использовать XML. Вот тестовый проект сериализации, который может помочь вам найти лучшие решения:

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking