Custom Java XMLBuilder vs Standard classes-based

Question

¿Cuál es la mejor solución de rendimiento para la generación XML?

Mi objetivo es crear unos pocos XML simples a partir del código. Voy a implementar una implementación simple basada en StringBuffer de XML Builder. Desde el otro lado hay varias bibliotecas como http://code.google.com/p/java-xmlbuilder/ y http://code.google.com/p/xmltool/ que tiene un buen DSL, pero creo que la falta de rendimiento.

Dado que mi objetivo es construir XMLBuilder suficientemente simple con un gran rendimiento, creo que construiré una solución personalizada. Se ofrece:

• DSL basada en Java Niza para las construcciones XML (añadiendo etiquetas básicamente)
• Gran StringBuffer rendimiento basada.
• Manejo de escape de datos de cadena al agregar etiquetas XML.
• Auto-guión

Para sugerir si estoy equivocado en las expectativas de rendimiento y sus Probablemente es mejor utilizar las bibliotecas ya hechos.

ACTUALIZACIÓN. Por qué creo que el rendimiento de los constructores xml estándar no es muy bueno.

Los constructores XML estándar utilizan Document Builder Factory y trabajan con clases detrás de escena. También estas clases optimizadas para adaptarse a todos los usuarios. Por ejemplo, yo no necesito el apoyo de espacio de nombres, etc.

<?xml version="1.0" encoding="utf-8"> 
<root> 
<testdata>value</testdata> 
</root> 
</xml> 

Considere código XML muy simple anteriormente. Si construye con herramientas estándar, implicará tantos trabajos solo para hacer este simple XML. Considero que es mejor generarlo solo usando String.

ACTUALIZACIÓN 2. El requisito de rendimiento es que el código debe hacer tantas cosas como se requiera para generar XML simple y no más.

ACTUALIZACIÓN 3. Gracias ¡todos por excelentes comentarios! Ahora entiendo mejor lo que necesito y que mi objetivo inicial no se configuró muy correctamente con la palabra "rendimiento". Mi verdadero objetivo es utilizar una solución lo suficientemente simple con DSL conveniente para describir la estructura XML y generar el resultado XML.

Utilizaré objetos planos de Java como DSL para XML y generaré XML utilizando la biblioteca XStream, que es una solución bastante sencilla.

ACTUALIZACIÓN 4. JAXB. Discutí XStream vs JAXB y descubrí que JAXB es más rápido que XStream. Además, ya uso JAXB en mi proyecto y me gustan sus anotaciones estándar. Cambio de opinión e iré con JAXB por ahora porque XStream originalmente estaba muy desarrollado en el momento en que JAXB no era tan bueno como hoy.

Answer 1

voy a sugerir algo muy controvertido, pero aún así ...

realizar pruebas de rendimiento de perfiles y con las dos bibliotecas.

Si no tienes tiempo para eso, asumir que algo es lento sería una opción incorrecta en mi opinión. Porque si resulta que en realidad no es lento, le ahorraría mucho tiempo utilizar una biblioteca/marco ya construido y compatible.

Otra idea. Deberá probar su solución completa de alto rendimiento contra las soluciones ya disponibles de todos modos, para comprobar si realmente es de alto rendimiento. Por lo tanto, le sugiero que mida el rendimiento de las bibliotecas disponibles antes de comenzar la suya propia.

Answer 2

Hay NodeBuilder de Groovy potente y flexible (http://groovy.codehaus.org/GroovyMarkup).

def root = new NodeBuilder() 
    .people(kind:'folks', groovy:true) { 
    person(x:123, name:'James', cheese:'edam') { 
     project(name:'groovy') 
     project(name:'geronimo') 
    } 
    person(x:234, name:'bob', cheese:'cheddar') { 
     project(name:'groovy') 
     project(name:'drools') 
    } 
    } 
XmlUtil.serialize(root, System.out) 

Esto se traduce en un documento XML:

<?xml version="1.0" encoding="UTF-8"?> 
<people kind="folks" groovy="true"> 
    <person x="123" name="James" cheese="edam"> 
    <project name="groovy"/> 
    <project name="geronimo"/> 
    </person> 
    <person x="234" name="bob" cheese="cheddar"> 
    <project name="groovy"/> 
    <project name="drools"/> 
    </person> 
</people> 

Answer 3

Con respecto a:

constructores XML estándar utiliza Documento Constructor de fábrica y trabaja con clases detrás de las escenas. También estas clases optimizadas para adaptarse a todos los usuarios. Por ejemplo No necesito el apoyo de espacio de nombres etc.

Una alternativa a DOM es StAX (JSR-173). Es una API de Streaming para XML que es bastante rápida. Hay varias implementaciones, he encontrado que Woodstox es bastante eficiente.

Answer 4

Una sugerencia más de alto rendimiento: use StaxMate - es tan rápido como el escritor XML basado en Stax subyacente, que es bastante rápido (40 - 80 megabytes por segundo, sostenido). Solo asegúrate de NO utilizar la implementación predeterminada de Stax JDK 6 (Sun sjsxp) sino algo más rápido como Woodstox o Aalto.

Recomiendo encarecidamente que no escriba su propia grabadora de XML; por lo general es arriesgado (es muy probable que se olvide de alguna parte del escape) como otros mencionaron, y no es probable que sea más rápido que soluciones eficientes (no todas las soluciones existentes son eficientes, necesita encontrar las que son) Y al final ... a menos que realmente quieras escribir estas cosas, ¿por qué no trabajas en algo más interesante y significativo?

Pero si desea hacer algo más allá de los escritores existentes, podría considerar el uso de un escritor simple y aumentarlo con la funcionalidad adicional que necesita. Por ejemplo, si solo usa Stax XMLStreamWriter como base, es bastante fácil agregar abstracciones simples pero eficientes. O si le gustan los paquetes existentes, vea si puede sugerir mejoras a sus autores (o incluso contribuciones de código).