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:
XML xml = { <foo><bar>someVar</bar></foo>};
We saw several variations on this, but they were all pretty much functionally the same, with minor syntactical variations.
Frankly, I would like to see something a little more… radical.
One of the problems you always have to deal with in the XML world, wether working with SOAP or REST or POXs (Plain Old XMLs! Hey look, I coined a TLA!) is that basically Java data types just don’t match to what you can specify in a schema. java.lang.Integer can’t be defined with a 1..5 value limit. java.lang.String can’t be constructed with a length limit.
I think what I would like to see is an expansion of the java.lang.* and java.util.* classes applicable to include more schema-precise definitions:
@XMLAttribute public Integer{1..5} getMyInt(); public void setMyInt( Integer{1..5} value ); //.. public void setListOfMyInt( List<Integer{1..5}>{minOccurs=1} ); //.. @XMLExclude public DataSource getMyDataSource();
This gives you an introspect able value to match to schema definitions. I will grant you that the List above isn’t really pretty, but it contains the relevant data. This provides a very clear way, however, to map back to a schema. Annotations used to delineate between attributes and child elements, and Object can get a ” Element toXML()” method and perhaps a: MyClass.newInstance( Element ) method.
I don’t want to deal with XML “in the language,” and the proposals above still don’t get past the kind of conversions you have to do between bean classes and XML all over the place. The reason JAX-WS, and JAX-B2, to some degree, are better than what we have had before is that you simply do everything using the same Java idioms we have come to know and love. While I think XML support in the language is critical, I also think it has to be a real improvement. I am not sure the proposals I have seen to now actually are.
"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;
@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.
>>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.
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.
>>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.
Hi
Bye
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