Thoughts on XML and Java.

by Robert Cooper

One of the sessions I went to today was more of a discussion about the future of XML in Java. There was a proposal for a java.lang.XML class, and various tactics for including XML syntax in the language. You may have seen some of these they tend to look something like:

<br />
 XML xml = { <foo><bar>someVar</bar></foo>};<br />

7 Comments

Tim O'Brien
2006-05-17 17:57:30
"XML xml = { someVar};" - Egad, that makes me want to cry.


Also, I really think that the second half of the post could be better handled by a set of usable annotations ala javax.persistence. We should be able to place constraints on properties in annotations, and these annotations should feed into runtime validators that are built into the system.


Take a look at XMLBeans (http://xmlbeans.apache.org) - I'm using it in a few project and while I'm not 100% satisfied with the coupling of pure beans with the underlying XMl implementations, it does provide a good schema driven bridge between Objects and XML. Take a concept like XML beans, improve the code generation tools such that the bean interfaces are completely decoupled from underlying implementations, and add some sort of annotation driven validation like you have about and then I think we'll have something worth using.


In other words, your



private Integer myInt;
@XMLAttribute
public Integer{1..5} getMyInt();
public void setMyInt( Integer{1..5} value );


Could be changed into something ala:



@Property
@Array(size=5)
private Integer[] myInt;
Thomas
2006-05-17 23:41:08
@Tim O'Brien:
I don't think your re-write captures what the article tried to express. To me it seemed that the author wantd to limit the range of possible values for the myInt attribute to 1..5 (inclusive), and the list was supposed to contains "at least one" of those.
However, I admit the example given seems contradictory, since it declares the myInt as a Integer-based property, and offers a setter for a list of them.
Maybe the annotation mechanism should be adjusted to reflect what I've seen (or thought I had seen) with Java beans.


@XMLAttribute
private Integer{1..5} myInt = 3;


would internally provide the getter and setter and even provide a default value.
An important question (which might be less critical once your annotation idea is compared to the "wonderful" "XML xml = {};" example) is readability and complexity of the annotation, since there can be a lot of constraints applied to a simple value (I once coded the list of 2-letter codes of language as an enumeration...).
Another point is, whether this kind of annotation would be needed only when anonymous types are used or for all cases.

kebernet
2006-05-18 08:06:38
>>Also, I really think that the second half of the post could be better handled by a set of usable annotations ala javax.persistence. We should be able to place constraints on properties in annotations, and these annotations should feed into runtime validators that are built into the system.


Well, the problem with annotations -- and also note the JAX-B and JAX-WS specs "kinda" provide these -- is that they can't be compile time checked, and WON'T be checked at runtime barring some secondary call. There won't be an exception if a @FOO(maxOccurs=1) List gets a 3 element list passed into it.

Peter Becker
2006-05-18 15:53:21
What this proposes is a set of constraint languages for different classes. Note that this would introduce quit a few new minilanguages into Java, potentially one for each class you want to subtype through constraints (which is what you are doing). That has the potential of turning Java into something even more chaotic than Perl ;-)


I agree that Java's type systems are either weak, flawed or broken. XSD Datatypes is much stronger in its expressiveness, and I think of "an integer between 1 and 5" as quite a natural and extremely useful thing to express (useful since tools can help me doing the right thing then). They also realized that enums are a subtype of the type of their members (more exact: the most specific common supertype -- you could do mixed enums), something Java didn't grok.


Unfortunately I believe that adding more syntactic sugar to the existing mess (I currently count 4 distinct type systems in the Java language: primitives, objects, arrays (broken), references (the pain of null)) will not help at all. But Sun is probably not up for a true Java 2.

kebernet
2006-05-18 17:29:27
>>What this proposes is a set of constraint languages for different classes. Note that this would introduce quit a few new minilanguages into Java, potentially one for each class you want to subtype through constraints (which is what you are doing). That has the potential of turning Java into something even more chaotic than Perl ;-)


Well, yes and no. XSD doesn't have a whole ton of value validations. 90% of what you would need to get there, aside from swappable groups, is a set of validations that apply to java.lang.Number, java.lang.CharSequence, arrays and java.lang.Collection. That isn't a whole lot of stuff there, and it is something that could reasonably be done by the compiler.


For instance, using Annotations would work, if you stacked them with Aspects. Then you simply have a compliance checker somewhere in there. What I am saying is that:


a. You extend the annotations to include a "special annotation" that weaves in validation at method invocation.
b. You can basically just add an "static final checkValid( Params p, T object )" on each of the above root classes that throws an unchecked SchemaValidationException.
c. Any methods -- that is, setters, function calls to @WebService, etc, that take input can runtime check it, and then the compiler can compile time check it on returns and assignments by doing a superset determiniation. Indeed the compiler itself could pre-compile regexes and set up validators for each combination so they are instantly available for use at runtime.


Is it a "bunch of minilanguages"? Maybe, but if you look at it that way, then sow is the schema specification, and yet we seem to muddle through there. Moreover, when given the option of smarts in the compiler vs "XML xml = { <foo><bar>someVar</bar></foo>};", I think the choice is pretty clear. We have done all we can to get SQL out of our Java, bringing XML right into it at this point, rather that giving us a workable Java idiom for it, is a mistake.

http://music-lyrics-61723a500.bigcitybucks.info/ music lyrics
2006-10-12 02:01:15
Hi


Bye





rabbi D%C3%83%C2%BCsseldorf
2007-03-16 01:47:52
One of the sessions I went to today was more of a discussion about the future of XML in Java. There was a proposal for a java.lang.XML class, and various tactics for including XML syntax in the language. You may have seen some of these they tend to look something like:
I do not agree. Go to http://www.financesjobs.info/reck_Germany/spongy_Nordrhein-Westfalen/rabbi_D%C3%83%C2%BCsseldorf_1.html