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

Предположим, я хочу хранить много небольших объектов конфигурации в XML, и мне не очень-то нравится формат. XMLDecoder класс, встроенный в JDK будет работать, и из того, что я слышу, XStream работает аналогичным образом.

В чем преимущества каждой библиотеки?

0
добавлено отредактировано
Просмотры: 25

8 ответы

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

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

0
добавлено
Какие ошибки есть в XStream?
добавлено автор Marcus Leon, источник

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

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

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

0
добавлено
Спасибо за предложение. Я делаю различие между привязкой и сериализацией, и этот вопрос ориентирован на сериализацию. Однако вы отмечаете, что XMLEncoder является игрушкой по сравнению с другими. Не могли бы вы привести некоторые специфические особенности XStream, которые отсутствуют в XMLEncoder?
добавлено автор erickson, источник
Справедливо. Просто в большинстве случаев сериализация, основанная на привязке к данным, работает нормально. И я не видел ничего, что указывало бы, что JAXB не будет работать. Жесткая игрушка: отсутствует конфигурируемость, только пишет beans (без полей), xml-интеграция (XE использует строку concat, а не xml writer), производительность.
добавлено автор StaxMan, источник

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

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

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

0
добавлено
Все дело в том, чтобы загрузить объекты в память. Это механизм десериализации. Я хотел бы избежать создания DOM, а затем прокрутить его для создания параллельного графа объектов, потому что тогда у меня бы были два копии в памяти, без необходимости. XMLDecoder, по крайней мере, основан на SAX.
добавлено автор erickson, источник

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

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

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

0
добавлено

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

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

http://code.google.com/p/thrift-protobuf- сравнить/вики/Бенчмаркинг

0
добавлено

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

0
добавлено

Мне очень нравится 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);

Вы будете выглядеть следующим образом:


  Joe
  
    123
    1234-456
  

Вернуться назад:

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

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

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

package example;
the xml would have "example.Person" instead of just "person".
0
добавлено
«Отвратительный» аспект вывода XMLEncoder - это в основном полностью квалифицированные имена классов. Если я предпочитаю не создавать псевдонимы, что делает XStream с именами пакетов? У меня много типов; класс-код должен быть сведен к минимуму. Как мне написать общий XSLT для преобразования любого XStreamed типа, скажем, в JSON?
добавлено автор erickson, источник
Это хорошая часть. JSON уже выводит на JSON . Это то, что вы хотите?
добавлено автор Jorge Ferreira, источник
Я не уверен, как вы должны написать XSLT, чтобы перейти от вывода XStream к JSON? Вы можете задать новый вопрос о SO. :)
добавлено автор Jay R., источник

Дополнение к @jay ответом на пример:

Код:

PortfolioAlternateIdentifier identifier = new PortfolioAlternateIdentifier();
identifier.setEffectiveDate(new Date());
identifier.setSchemeCode("AAA");
identifier.setIdentifier("123456");

Выход с использованием XStream:


 2014-05-02 20:14:15.961 IST
 AAA
 123456
   

Выход с использованием XMLEncoder:

<?xml version="1.0" encoding="UTF-8"?> 
  
    
      1399041855961    123456   AAA   
 
0
добавлено