Details
-
Type:
New Feature
-
Status:
Closed
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
It would be nice to have a way of creating java code from an arbitrary xml file.
For example, the xml file:
<person>
<name>Joe</name>
</person>
could (given a package name) emit:
package personpackage;
public class Person {
private String name;
}
This could be extended by creating types that are bean's or IOC-3 type components.
This would be very handy in the processing of xml, and I think (??) that it could be handled by a special case of Converter.
Am I right?
Activity
Unlike most other XML serialization/marshalling tool, XStream does not duplicate in the XML what can be found in the .class file - this seperation of data from schema results in much cleaner XML. However, the downside of this is that XStream needs both to operate.
In the example above, how would we know that the field Person.name was of type String without an existing schema definition somewhere (either in the form of an XSD or .class)? It might be possible to guess for that scenario, but other scenarios would be near impossible (for example, empty elements, different types of numbers, collection implementations, polymorphism, etc).
I can't see how this could ever work, but I'm open to suggestions.
> Thinking of it, it would be VERY interesting to emit java code, pass
> it into a runtime-code generator (BCEL/ASM/Janino) and be able to
> use it as an object. This would enable programs to create
> data-strctures on the fly based on xml files....
XML already is one big runtime data structure, that's easy to wrap with APIs to make it easier to work with. Why would you ever need to generate strongly typed classes when you can't access them at build time?
Joe Walnes
added a comment - Unlike most other XML serialization/marshalling tool, XStream does not duplicate in the XML what can be found in the .class file - this seperation of data from schema results in much cleaner XML. However, the downside of this is that XStream needs both to operate.
In the example above, how would we know that the field Person.name was of type String without an existing schema definition somewhere (either in the form of an XSD or .class)? It might be possible to guess for that scenario, but other scenarios would be near impossible (for example, empty elements, different types of numbers, collection implementations, polymorphism, etc).
I can't see how this could ever work, but I'm open to suggestions.
> Thinking of it, it would be VERY interesting to emit java code, pass
> it into a runtime-code generator (BCEL/ASM/Janino) and be able to
> use it as an object. This would enable programs to create
> data-strctures on the fly based on xml files....
XML already is one big runtime data structure, that's easy to wrap with APIs to make it easier to work with. Why would you ever need to generate strongly typed classes when you can't access them at build time? XStream presents a few potential abstraction levels over normal programming:
1. When storing objects as xml you no longer need to use complex object-relational models to store application data. (Prevayler,ODB etc)
2. Generating interfaces of arbitrary data-structures is becoming possible (naked objects)
3. Generating whole (simple) applications will soon be possible due to xstream, odb's and runtime-datastructure interface creation.
Imagine passing an xml file to an application parser:
<java.util.List>
<com.someapp.Person>
<name>Joe</name>
<address>ffff</address>
<...>
</com.someapp.Person>
</java.util.List>
and automatically creating you a contacts application...
This would of course be language neutral if xstream could emit a class hierarchy.
This is probably beyond the scope of xstream, but would still be an interesting project none the less.
ben
added a comment - XStream presents a few potential abstraction levels over normal programming:
1. When storing objects as xml you no longer need to use complex object-relational models to store application data. (Prevayler,ODB etc)
2. Generating interfaces of arbitrary data-structures is becoming possible (naked objects)
3. Generating whole (simple) applications will soon be possible due to xstream, odb's and runtime-datastructure interface creation.
Imagine passing an xml file to an application parser:
<java.util.List>
<com.someapp.Person>
<name>Joe</name>
<address>ffff</address>
<...>
</com.someapp.Person>
</java.util.List>
and automatically creating you a contacts application...
This would of course be language neutral if xstream could emit a class hierarchy.
This is probably beyond the scope of xstream, but would still be an interesting project none the less. By the way, ASM already have an XML package which allows to convert bytecode to-from XML.
Eugene Kuleshov
added a comment - By the way, ASM already have an XML package which allows to convert bytecode to-from XML. After all these years, I'd simply say, it is out of scope for XStream to generate Java code.
Jörg Schaible
added a comment - After all these years, I'd simply say, it is out of scope for XStream to generate Java code. 
Thinking of it, it would be VERY interesting to emit java code, pass it into a runtime-code generator (BCEL/ASM/Janino) and be able to use it as an object.
This would enable programs to create data-strctures on the fly based on xml files....