¿Cuáles son las ventajas relativas de XMLEncoder y XStream?

Supongamos que quiero almacenar muchos pequeños objetos de configuración en XML, y no me importa demasiado el formato. La clase XMLDecoder integrada en el JDK funcionaría, y por lo que escuché, XStream funciona de manera similar.

¿Cuáles son las ventajas para cada biblioteca?

0
agregado editado
Puntos de vista: 4

8 Respuestas

Siempre encuentro XStream muy tentador, porque es muy fácil ponerse en marcha. Sin embargo, invariablemente termino reemplazándolo. Es bastante complicado, y su manejo de la colección podría requerir mucho trabajo.

Como resultado, generalmente cambio a JAXB. Es mucho más robusto, está libre de errores y es más flexible que XStream.

0
agregado
¿Qué errores hay en XStream?
agregado el autor Marcus Leon, fuente

Otra sugerencia: considere usar JAXB ( http://jaxb.dev.java.net ). Si está utilizando JDK 1.6, viene incluido, consulte "javax.xml.bind" para obtener más información, por lo que no es necesario utilizar jar adicionales externos.

JAXB es bastante rápido. También me gusta XStream, pero es un poco más lento. Además, XMLEncoder es un poco de juguete (en comparación con otras opciones) ... pero si funciona, no hay daño al usarlo.

Además, uno de los beneficios de JAXB es que también puede enlazar un documento parcial (subárboles) con él; no es necesario crear objetos para todo el archivo. Para esto, necesita usar Stax (XMLStreamReader) para apuntar al elemento raíz del subárbol y luego vincular. No es necesario usar SAX, incluso para la mayoría de los archivos de gran tamaño, siempre que se pueda procesar por partes.

0
agregado
Gracias por la sugerencia. Estoy haciendo una distinción entre unión y serialización, y esta pregunta está orientada a la serialización. Sin embargo, mencionas que XMLEncoder es un juguete en comparación con los demás. ¿Podrían citar algunas características específicas de XStream que faltan en XMLEncoder?
agregado el autor erickson, fuente
Lo suficientemente justo. Es solo que en la mayoría de los casos la serialización basada en el enlace de datos funciona bien. Y no vi nada que indicara que JAXB no funcionaría. Wrt toy: falta de configurabilidad, solo escribe beans (sin campo), integración xml (XE usa string concat, no xml writer), rendimiento.
agregado el autor StaxMan, fuente

Si planea almacenar todos esos objetos de configuración en un único archivo, y ese archivo será bastante grande, las dos opciones que describió anteriormente podrían requerir bastante memoria, ya que ambas requieren que el archivo completo se lea en la memoria para ser deserializado

Si el uso de la memoria es una preocupación (el archivo que contiene el xml será muy grande), recomiendo SAX .

Si el uso de la memoria no es una preocupación (el archivo que contiene el xml no será muy grande), utilizaría todo lo que se incluye con el JRE predeterminado (en este caso XMLDecoder) solo para eliminar dependencias de terceros.

0
agregado
El objetivo es, precisamente, cargar objetos en la memoria. Es un mecanismo de deserialización. Lo que me gustaría evitar es construir un DOM, luego recorrerlo para producir un gráfico de objetos paralelo, porque entonces tendría dos copias en la memoria, innecesariamente. XMLDecoder, al menos, está basado en SAX.
agregado el autor erickson, fuente

También preferiría XStream , ya que es muy fácil de usar y extender. Puede comenzar rápidamente si va con la configuración predeterminada. Si necesita personalizar el comportamiento, tiene una API muy limpia y muchos puntos de extensión, por lo que tiene un control muy detallado sobre las cosas que desea modificar sin interferir con otras partes del proceso de clasificación.

Como el xml creado por XStream se ve bien, la edición manual también es simple. Si la salida no satisface sus necesidades y la larga lista de Convertidores no contiene el que necesita, es bastante simple escribir el suyo.

Una gran ventaja es también la buena documentación en su página de inicio .

0
agregado

Debería evitar XMLEncoder/XMLDecoder como la peste si va a persistir una cantidad no trivial de objetos o su sistema necesita ser multiproceso. Ver http://matthew.mceachen.us/blog/do -not-want-xmlencoder-129.html por los detalles espeluznantes.

Si debe usar XML, XStream es genial. Pero pregúntese si realmente necesita usar XML. Aquí hay un proyecto de referencia de serialización que podría llevarlo a mejores soluciones:

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

0
agregado

Java también tiene una nueva clase de utilidad destinada a almacenar conjuntos emparejados clave-valor típicos de las configuraciones. Es el viejo estilo pero muy simple y práctico. Esto se hace a través de java.util.Properties class, un objeto Map con opciones de serialización. Esto podría ser todo lo que necesita a menos que esté almacenando objetos enteros.

0
agregado

Me gusta mucho el XStream biblioteca. Hace un muy buen trabajo de salida de xml bastante simple como resultado de un objeto Java proporcionado. Funciona muy bien para la reproducción el objeto de regreso desde el xml también. Y, una de nuestras bibliotecas de terceros ya dependía de eso de todos modos.

  • Elegimos usarlo porque queríamos nuestro xml para ser legible por humanos Utilizando la función de alias lo hace mucho más agradable.

  • Puede ampliar la biblioteca si quiere una parte de un objeto para deserializar de una manera más agradable. Nosotros hizo esto en un caso para que el archivo tendría un conjunto de grados, minutos y segundos para una latitud y longitud, en lugar de dos dobla.

El tutorial de dos minutos resume el uso básico, pero en el interés de mantener la información en un solo lugar, intentaré sumarlo aquí arriba, solo un poco más corto.

// 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
}

Luego use la biblioteca para escribir el 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);

Su salida se verá así:


  Joe
  
    123
    1234-456
  

Para volver:

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

El XMLEncoder se proporciona para la serialización de beans Java. La última vez que lo usé, el archivo se veía bastante desagradable. Si realmente no le importa cómo se ve el archivo, podría trabaje para usted y evite una dependencia de terceros, lo que también es agradable. Esperaría que la posibilidad de hacer que la serialización sea más bonita sería más un desafío con XMLEncoder también.

XStream genera el nombre completo de la clase si no alias el nombre. Si la clase Persona arriba

package example;
the xml would have "example.Person" instead of just "person".
0
agregado
El aspecto "desagradable" de la salida de XMLEncoder es principalmente los nombres de clase totalmente calificados. Si elijo no configurar alias, ¿qué hace XStream con los nombres de los paquetes? Tengo muchos tipos; el código específico de la clase debe ser minimizado. ¿Cómo escribiría un XSLT genérico para transformar cualquier tipo de XStreamed en, por ejemplo, JSON?
agregado el autor erickson, fuente
Esa es la buena parte. JSON ya publica en JSON . ¿Es eso lo que quieres?
agregado el autor Jorge Ferreira, fuente
No estoy seguro de cómo escribirías un XSLT para pasar de la salida de XStream a JSON. Puede hacer una nueva pregunta sobre SO. :)
agregado el autor Jay R., fuente

Además de @jay responder con un ejemplo:

Código:

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

La salida usando XStream:


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

El resultado usando XMLEncoder:

<?xml version="1.0" encoding="UTF-8"?> 
  
    
      1399041855961    123456   AAA   
 
0
agregado