Parser XML

“Utiliza muita memoria” eh um conceito BASTANTE relativo. Browsers usam DOM, e eu nao vejo ninguem chorando ao abrir o google de manha.

O que tem nesses XMLs? Qual o tamanho medio de um deles? O que vc tem que fazer com relacao a criptografia?

Já utilizei os dois e a velocidade do SAX é superior a do DOM quando vc tem arquivos muito grandes, no meu caso eu tinha o seguinte conjunto

<maquina> <dado1></dado1> <dado2></dado2> ........... <dado25></dado25> </maquina>

arquivo bem simples o SAX com 10000 maquinas executou em 5 segs contra 20 do DOM

até oq eu vi a diferença entre os dois está na formar que ambos faz acesso as tags o DOM perece jogar tudo para memória para fazer o parser o SAX não, bem não sei se é realmente isso, tem um artigo na Java Magazine n.º 22 com titulo XML turbinado

Um detalhe a SAX apresentou alguns problemas onde alguns arquivos não eram lidos corretamente, por isso acabamos usando o DOM que não falhou em nenhum dos nossos testes.

CV …
Não serão arquivos grandes não …
Esta ferramenta que eu estou desenvolvendo é para meu tcc … então seráo usados documentos XML para testes!

E quanto a criptografia … é para apenas o conteúdo, não será criptografado as tags … tendo em vista de que elas não necessitariam de proteção, apenas o conteúdo de alguns elementos.
Utilizarei a criptografia de chave pública mesmo.

Obrigada.

Nesse caso, vai de DOM (que eh mais facil de entender/depurar) e boa

Olá

Se você precisa ler e escrever XML, então pode riscar SAX das opções.

A dica do CV é perfeita sob o ponto de vista de fazer as coisas funcionarem do modo mais feijão com arroz possível (o que geralmente é muito bom). Até porque, há um monte de textos na web com exemplos de uso de DOM, inclusive encriptando XML como os links abaixo:
Managing XML Encryption with Java

Mas se você quiser fazer as coisas pensando em aprender soluções mais modernas use StAX.

Abaixo uma comparação entre os 3 tipos mais comuns de APIs para XML (falta o TrAX)

DOM: API tipo árvore na memória, muito fácil de usar, uso de CPU e memória muito ruim em casos grandes, lê XML, escreve XML, trata XPATH, serve para CRUD

SAX: API tipo Pull, streaming, meio difícil de usar, bom uso de CPU e memória, lê XML, não escreve XML, lê só para a frente, não trata XPATH, não serve para CRUD

StAX: API tipo Pull, streaming, muito fácil de usar, bom uso de CPU e memória, lê XML, escreve XML, lê só para a frente, não trata XPATH, não serve para CRUD e é o recomendado para usar com Java a partir do Java 6

Se eu fosse você, partiria logo para StAX, Streaming API for XML, porque assim aprenderia algo com serventia mais genérica. O StAX agora vem com o Java 6.

Links:
http://java.sun.com/javase/6/docs/technotes/guides/xml/index.html

http://javaboutique.internet.com/tutorials/stax/

Se quiser melhor desempenho leia http://netzooid.com/blog/2007/08/28/quick-intro-to-xml-performance/ e use http://sxc.codehaus.org/ (created optimized parsers and writers for XML) ou http://woodstox.codehaus.org/ (StAX ou SAX).

Antes que alguém responda, se você vai serializar objetos em XML, então olhe o XStream

Nesta sua solução tome cuidado com as questões de encoding que podem estar envolvidas.

[]s
Luca

Olá

Respondendo por aqui à mensagem privada para que todos possam participar da discussão.

O JDom pode ser usado para ler e escrever o documento XML. Para o processo de criptografia sugiro os links que já citei. Imagino que o mais fácil seja criptografar todo o XML depois de escrito e descriptografar antes de fazer o parse de leitura.

Se fosse eu que gosto de ser novidadeiro, usava o StAX como disse antes. Acho que cada hora usada para aprender StAX valerá mais do que os minutos perdidos para aprender o velho DOM (no caso, JDom). E se fosse eu, também atualizaria o Eclipse.

Mas como bem disse o CV e eu corroborei, o velho DOM é simples e tem um monte de links com exemplos.

[]s
Luca