Quais são as vantagens relativas do XMLEncoder e do XStream?

Suponha que eu queira armazenar muitos objetos de configuração pequenos em XML, e não me importo muito com o formato. A classe XMLDecoder incorporada ao O JDK funcionaria e, pelo que ouvi, XStream funciona de maneira semelhante.

Quais são as vantagens para cada biblioteca?

0
adicionado editado
Visualizações: 2

8 Respostas

Eu sempre acho o XStream muito tentador, porque é muito fácil ir em frente. No entanto, invariavelmente acabo substituindo. É realmente muito buggy, e sua manipulação de coleção poderia usar muito trabalho.

Como resultado, geralmente mudo para o JAXB. É muito mais robusto, é praticamente livre de erros e mais flexível que o XStream.

0
adicionado
Quais erros estão no XStream?
adicionado o autor Marcus Leon, fonte

Outra sugestão: considere o uso do JAXB ( http://jaxb.dev.java.net ). Se você estiver usando o JDK 1.6, ele vem junto, confira "javax.xml.bind" para detalhes, então não há necessidade de jars externos adicionais.

JAXB é bastante rápido. Eu gosto do XStream também, mas é um pouco mais lento. Além disso, XMLEncoder é um pouco de brinquedo (em comparação com outras opções) ... mas se funcionar, não há mal nenhum em usá-lo.

Além disso, um benefício do JAXB é que você também pode vincular o documento parcial (sub-árvores) a ele; não há necessidade de criar objeto (s) para o arquivo inteiro. Para isso, você precisa usar o Stax (XMLStreamReader) para apontar para o elemento raiz da subárvore e vincular. Não há necessidade de usar o SAX, mesmo para a maioria dos arquivos grandes, contanto que ele possa ser processado por pedaço.

0
adicionado
Obrigado pela sugestão. Estou fazendo uma distinção entre encadernação e serialização, e essa questão é orientada para serialização. No entanto, você menciona que o XMLEncoder é um brinquedo comparado aos outros. Você poderia citar algumas características específicas do XStream que estão faltando no XMLEncoder?
adicionado o autor erickson, fonte
Justo. Na verdade, na maioria dos casos, a serialização baseada em vinculação de dados funciona muito bem. E eu não vi nada indicando que o JAXB não funcionaria. Wrt toy: falta de configurabilidade, grava apenas beans (sem base em campo), integração xml (o XE usa string concat, não xml writer), performance.
adicionado o autor StaxMan, fonte

Se você estiver planejando armazenar todos esses objetos de configuração em um único arquivo, e esse arquivo for muito grande, ambas as opções descritas acima podem consumir muita memória, já que ambas exigem que o arquivo inteiro seja lido na memória ser desserializado.

Se o uso da memória for uma preocupação (o arquivo que contém o xml será muito grande), eu recomendo SAX .

Se o uso da memória não for uma preocupação (o arquivo que contém o xml não será muito grande), usaria o que estiver incluído no JRE padrão (neste caso, XMLDecoder) apenas para remover dependências de terceiros.

0
adicionado
O ponto principal é precisamente carregar os objetos na memória. É um mecanismo de desserialização. O que eu gostaria de evitar é construir um DOM, em seguida, passá-lo para produzir um gráfico de objeto paralelo, porque então eu teria duas cópias na memória, desnecessariamente. XMLDecoder, pelo menos, é baseado em SAX.
adicionado o autor erickson, fonte

Eu também prefiro XStream , pois é realmente fácil de usar e estender. Você pode começar rapidamente se estiver indo com a configuração padrão. Se você precisar personalizar o comportamento, ele terá uma API muito limpa e muitos pontos de extensão, para que você tenha um controle realmente refinado sobre as coisas que deseja ajustar sem interferir em outras partes do processo de empacotamento.

Como o xml que é criado pelo XStream parece legal, a edição manual também é simples. Se a saída não atender às suas necessidades e a longa lista de Conversores disponíveis não contiver o que você precisa, é bastante simples escrever o seu próprio.

Uma grande vantagem é também a boa documentação em sua página inicial .

0
adicionado

Você deve evitar o XMLEncoder/XMLDecoder como a praga, se for persistir um número não trivial de objetos ou se o seu sistema precisar ser multithreaded. Veja http://matthew.mceachen.us/blog/do -não-quero-xmlencoder-129.html para os detalhes terríveis.

Se você precisa usar XML, o XStream é ótimo. Mas pergunte a si mesmo se você realmente precisa usar XML. Aqui está um projeto de referência de serialização que pode levá-lo a soluções melhores:

http://code.google.com/p/thrift-protobuf- comparar/wiki/teste comparativo

0
adicionado

O Java também tem uma nova classe de utilitário destinada a armazenar conjuntos pareados de valor-chave típicos de configurações. É o estilo antigo, mas muito simples e prático. Isso é feito por meio do java.util.Properties class, um objeto Map com opções de serialização. Isso pode ser tudo o que você precisa, a menos que esteja armazenando objetos inteiros.

0
adicionado

Eu realmente gosto do XStream biblioteca. Ele faz um ótimo trabalho ao produzir um xml razoavelmente simples como resultado de um objeto Java fornecido. Ele funciona muito bem para reproduzir o objeto de volta do xml também. E uma das nossas bibliotecas de terceiros já dependia disso de qualquer maneira.

  • Optamos por usá-lo porque queríamos nosso xml para ser legível por humanos. Usando a função de alias torna muito melhor.

  • Você pode estender a biblioteca se quer alguma parte de um objeto para desserializar de uma forma mais agradável. Nós fez isso em um caso assim o arquivo teria um conjunto de graus, minutos e segundos para uma latitude e longitude, em vez de dois duplica.

O tutorial de dois minutos resume o uso básico, mas no interesse de manter as informações em um ponto, vou tentar resumir aqui em cima, só um pouco mais curto.

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

Em seguida, use a biblioteca para escrever o 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);

Sua saída será assim:


  Joe
  
    123
    1234-456
  

Voltar:

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

O XMLEncoder é fornecido para serialização do Java bean. A última vez que usei o arquivo parecia bastante desagradável. Se realmente não se importa com o que o arquivo se parece, poderia trabalhar para você e você consegue evitar uma dependência de terceiros, o que também é bom. Eu esperaria que a possibilidade de tornar a serialização mais bonita seria mais um desafio com o XMLEncoder também.

XStream exibe o nome completo da classe, se você não alias o nome. Se a classe Person acima

package example;
the xml would have "example.Person" instead of just "person".
0
adicionado
O aspecto "desagradável" da saída XMLEncoder é principalmente os nomes de classes completos. Se eu escolher não configurar aliases, o que o XStream faz com nomes de pacotes? Eu tenho muitos tipos; código específico da classe deve ser minimizado. Como eu escreveria um XSLT genérico para transformar qualquer tipo XStreamed em, digamos, JSON?
adicionado o autor erickson, fonte
Essa é a parte boa. JSON já sai para o JSON . É isso que você quer?
adicionado o autor Jorge Ferreira, fonte
Não tenho certeza de como você escreveria um XSLT para ir da saída do XStream para o JSON? Você poderia fazer uma nova pergunta sobre o SO. :)
adicionado o autor Jay R., fonte

Além de @jay answer com o exemplo:

Código:

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

A saída usando XStream:


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

A saída usando o XMLEncoder:

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