Daniel Hinojosa, in "Inline XML in Java Code? WTF?," has something negative to say about the possibility of inlining XML in Java code. The offending example is:

void addUser(Element element, String user, String password) {
   element.add(
              <account>
              <user>null</user>
              <password>{password}</password>
              </account>);
}

What exactly does this code do, in your opinion? If it's adding an XML fragment, is this viable code? (Compare and contrast to other mechanisms to do the same thing via W3C DOM, for example.) If it's usable only for modifying an XML tree, is it worth changing the language for this feature?

On a larger scale, does changing the language to add domain-specific features like this or, for example, an equivalent to MS' LINQ technology (or SQLJ, as a reminder from the past) seem worthwhile?

We have been through this before.

SQLJ: which did not work.
Scriptlets: bad design, hard to maintain

XML/XSL is a language in its own right, we do not need to add it into java. Lets not screw up the language. And just think about how you would read code with these XML constructs that also had generics in it.

What we need is better XML processing libraries.

XML/XSL is a language in its own right.

Ahgr! XML is not a language!
XML is alphabet. XSL is language - XML is not.

We have been through this before. SQLJ: which did not work. Scriptlets: bad design, hard to maintainXML/XSL is a language in its own right, we do not need to add it into java. Lets not screw up the language. And just think about how you would read code with these XML constructs that also had generics in it. What we need is better XML processing libraries.

What are you afraid of?

Used properly this can make code much clearer. Used incorrectly it will be a nightmare. But what language feature wouldn't be?

The use of XML is only going to grow. Makeing it a first class type makes sense.

The use of XML is only going to grow. Makeing it a first class type makes sense.

It is not going to grow IMO. We are already witnessing backlash against XML in the form of annotations, employing conventions and reflection (RoR), etc.
Combo( XML+Schema|DTD+Decent XML editor) is a poor’s man implementation of D-SLang paradigm (Domain Specific Language).
When tools like MPS will mature we will not need XMLkensteins anymore ( http://images.google.com/images?q=frankenstein ).

It is not going to grow IMO. We are already witnessing backlash against XML in the form of annotations, employing conventions and reflection (RoR), etc.

True, but those are all configuration files. What about messaging? That use of XML is going to grow rapidly.

What about messaging? That use of XML is going to grow rapidly.

Read the thread please:
http://www.theserverside.com/news/thread.tss?thread_id=37238


Failure of XML as messaging medium is apparent because 'they' speak about "binary XML" :) and M$ does not promote using SOAP everywhere and (not so)quietly recommend using .net remoting instead.

Re: this the other responses here and elsewhere.

Why is it so many people seem to take everything to extremes and pose so many false either/or choices? XML is great when it is used for what is good at. So are SOAP, Java Session EJBs, JEE in general, a lot of the user interface languages and tools (I do services, so ...) SOAP and XML are not going away, they are growing, but its foolish to use SOAP and/or XML everywhere. Every service shouldn't necessarily be a web service and every web service shouldn't necessarily use SOAP or HTTP. These tools help when dealing with the outside world and when cross technology boundaries. Binary and native protocols are more efficient and a better choice in many situations. So what? Each is important and valuable. Its not always one or the other. Hammers are great tools, but not every problem is a nail.

What about messaging? That use of XML is going to grow rapidly.

Read the thread please:http://www.theserverside.com/news/thread.tss?thread_id=37238Failure of XML as messaging medium is apparent because 'they' speak about "binary XML" :) and M$ does not promote using SOAP everywhere and (not so)quietly recommend using .net remoting instead.Drivel.
This guideline document:
http://msdn.microsoft.com/webservices/choosing/default.aspx?pull=/library/en-us/dnwebsrv/html/dsgprescriptiveguidance.asp
says explicitly in the .NET remoting section:
"Therefore, we recommend that you use .NET Remoting wisely, for custom message processing or in-process, cross-application-domain communications. Prefer ASMX instead wherever possible, or ES/COM+ where you need rich distributed-object semantics."

Read the thread please:http://www.theserverside.com/news/thread.tss?thread_id=37238Failure of XML as messaging medium is apparent because 'they' speak about "binary XML" :) and M$ does not promote using SOAP everywhere and (not so)quietly recommend using .net remoting instead.

Drivel. FUD. Other colorful terms can be added.

This guideline document:
http://msdn.microsoft.com/webservices/choosing/default.aspx?pull=/library/en-us/dnwebsrv/html/dsgprescriptiveguidance.asp
says explicitly in the .NET remoting section:

"Therefore, we recommend that you use .NET Remoting wisely, for custom message processing or in-process, cross-application-domain communications. Prefer ASMX instead wherever possible, or ES/COM+ where you need rich distributed-object semantics."

It is not going to grow IMO. We are already witnessing backlash against XML in the form of annotations, employing conventions and reflection (RoR), etc.

On the contrary, XML use is growing and becoming much more widely accepted as an important and useful standard. A good example of this is increasing use of the OpenDocument format, especially in the EU and with a recent (controversial) announcement of support from Massachusetts. You mention RoR. Whatever its benefits or failings it seems to be a much-mentioned framework in the contect of 'Web 2.0'. Although I have to admit I am vague about what Web 2.0 is, it seems to involve a range of technologies such as XHTML, Web Services, AJAX, and RSS. These are all independent on XML....

Although I have to admit I am vague about what Web 2.0 is, it seems to involve a range of technologies such as XHTML, Web Services, AJAX, and RSS. These are all independent on XML....

Firstly, most of them the are _dependent_ on XML;
Secondly,_dependent_ does not mean ‘it is good’.
For example our civilization depends on oil heavily, but I do not see it as a good thing.
Thirdly, Web Services are not limited to XML based services yet :)

And all those things you have mentioned just rely on certain data structures and might be much better off if used more efficient protocols.

XML is horrible, look at the LAML for example:
http://www.cs.aau.dk/~normark/scheme/distribution/laml/info/laml-motivation.html
Much cleaner syntax than XML and keeps all the perceived advantages of XML.

XML is horrible, look at the LAML for example: href="http://www.cs.aau.dk/~normark/scheme/distribution/laml/info/laml-motivation.html
Much cleaner syntax than XML and keeps all the perceived advantages of XML.

Irrelevant. The issue is not the aesthetics of XML but how much it is used.

The issue is not the aesthetics of XML but how much it is used.

Descartes four full centuries ago said: “a man is incapable of comprehending any argument that interferes with his revenue.”

BTW: The issue is not "how much XML is used",
the issue is "How much XML _should_ be used"

BTW: The issue is not "how much XML is used",the issue is "How much XML _should_ be used"

No, that certainly isn't the issue. Java applications have to interface with the real world, not some imaginary one where some obscure replacement for XML is used.

Java applications have to interface with the real world, not some imaginary one where some obscure replacement for XML is used.

Huh? What does it mean?

Java applications have to interface with the real world, not some imaginary one where some obscure replacement for XML is used.

Huh? What does it mean?

This:

XML is horrible, look at the LAML for example:
http://www.cs.aau.dk/~normark/scheme/distribution/laml/info/laml-motivation.html
Much cleaner syntax than XML and keeps all the perceived advantages of XML.

I beg you to differentiate few things:
- have to do (XMLkenstein);
- better way of doing (LAML);
- preferable way of doing things ( IDL and CORBA );
- ideal way of doing (ICE perhaps http://www.zeroc.com/iceVsCorba.html ) ;


Without clear understanding of what is what we are doomed to use and improve horse cart (XML) when we should be using cars and planes.

We have been through this before. SQLJ: which did not work. Scriptlets: bad design, hard to maintainXML/XSL is a language in its own right, we do not need to add it into java. Lets not screw up the language. And just think about how you would read code with these XML constructs that also had generics in it. What we need is better XML processing libraries.

I agree, jaxp sucks, it isn't even properly object oriented. Then there's jaxb which IMHO is too complicated and xml centric.

I'm a programmer. 99% of my use cases for xml is as simple as I have this bean how can convert it to and from xml. Basically all of the xml stuff in Java works against you in the Java world if you try to do this.

The DOM model is basically an untyped tree of nodes. It has to be untyped because it is designed for use with untyped languages (for which it is way to complex). If you use it to fill the contents of a bean you end up with vast amounts of boilerplate code. I have a set of methods that make life a little easier: like String getChildNodeContent(Node n), String getAttribute(Node n, String attribute), etc. I've always wondered why such elementary stuff is lacking in jaxp.

Sax is a neat low level API which is used primarily to implement the DOM parser and a lot of code with poor maintainability. It has its uses for performance critical stuff where vast amounts of xml need to be processed fast. Like DOM it is also designed for untyped languages, which makes working with it a PITA.

JAXB requires you to write an XML schema and then generates a lot of stuff for you that you shouldn't use (because it can change) but you need to use anyway because you need to get stuff done in Java.

These programming models do not fit my way of developing at all: write a bean, test it, add some attributes, alt+shift+r a couple of things, move the class to a new package, etc. In short, the bean is likely to keep changing and anything that gets in the way of that is a problem: parser code, elaborate xml schemas, etc.

All of these things require way to much thinking and coding to get going when all you want is serialize & deserialize the bean objects you already have to nice, straightforward XML.

Most of the time I end up writing DOM code where classname == tagname and properties are also tags (keeps the code simple and the xml clear). It should be possible to come up with a library which automates this process in a meaningful way.

The more I read about this new weird java feautures, the more I like ruby... Who in the world thinks embeding xml in java code is a good feature, in first place ???

Rather than dismiss this out of hand, I'd like to hear a few explanations of why this is bad. Assuming that the programmer using this doesn't violate the DRY principle, how is this different than inlining SQL?

I also think that Daniel Hinojosa missed the mark on what the problem with JSPs and scriptlets was: It wasn't scriptlets themselves that were a problem, it was putting business logic, not display logic, into those scriptlets that was a problem. This is nitpicky but important, as inlining XML could be very useful. Do we really want to forgo this just because someone, somewhere will abuse it?

Rather than dismiss this out of hand, I'd like to hear a few explanations of why this is bad. Assuming that the programmer using this doesn't violate the DRY principle, how is this different than inlining SQL?

Not very, but then I wouldn't want language level support for SQL in Java either.

My main objection is that it makes the language more complex. The first Java version was very nice and simple. You could learn the language and the entire API by heart in a week. Both have swelled, making it harder to port Java to new platforms and making it more difficult for new developers to join the fun.

Arguably most of the new features are worth the added complexity, though I'm still of two minds concerning inner classes and they are definitely more useful than some syntactic sugar for XML!

Sun should focus on good class libraries instead. That way you can select an implementation that works for your specific case rather than having to live with a one-size-fits-all solution that is equally bad for everything.

Just my thoughts, of course. I like simplicity.

Rather than dismiss this out of hand, I'd like to hear a few explanations of why this is bad. Assuming that the programmer using this doesn't violate the DRY principle.

The first and foremost problem is that it basically leads you down the road to violating DRY by making it so much easier (initially) than doing things in a more structured way. As I mentioned above, I did a good bit of PowerBuilder maintenance and PB's support for SQL seems really great until you need to change a table. Few of the SQL statements were redundant, it's just that they were completely decentralized. Instead of creating a single inerface for retrieving data from the DB in Objects and updating the SQL in that layer we had hundreds and sometimes thousands of queries and updates to fix. Just finding all of them was a large task, let alone making sure they were all corrected.

Event thought the JDBC code I deal with now is pretty bad, there is pretty good centralization of the code. It don't spend weeks updating select statements when we want to change the DB schema.

Doing this is wholly unecessary. It's not something we need. It's just syntactic sugar. Fattening, but providing no nutritional value. XML is not the end-all be-all of data represntations. If something newer and better comes along, is Java syntax going to support that too?

Microsoft thinks so: C-omega from Microsoft research treats XML en ER artifacts as first class citizens just like objects.
I guess the reasoning is something along the line that object-orientation is not always the best paradigm for everything.

I think this weblog entry is a bit meager information to judge the merits of this possible Java feature on.
To qualify for a tss entry I think some solid information from the people handling the initiative (Mark Reinhold fi) would be more worthwhile then some vague hearsay.

Programs definitely need to refer to "data values" within the algorithms; and some adapted way to represent structures of data should be integrated in the language - Java so - instead of letting people implementing their own patterns and "database matcher" tool.

For me, SQLJ, JSP, are another subject; this is the subject of DSL, the ability to have additional languages adapted to a certain context. Thoses 2 specific languages fail because of weaknesses at language level :
- complex grammar, especially with the ability to "mix" java and dsl code;
- no or bad debuggers, no or bad refactoring tool, at least no as performent than those for Java.
Although all our favorite frameworks cannot avoid to propose a DSL. Today they use XML : Hibernate, Spring, Struts... And to facilitate the coding in these "languages", people proposing additional "IDE" : SpringIDE, StrutsIDE, HibernateIDE... A lot of (diffuse) efforts, with results always less performant than those for Java, again.

I'm sure of one thing : these 2 subjects require to be better adressed than the way they are today, with "manual" and uncomplete solutions. "Inlining XML within Java" is perhaps the solution - I hope Dolphin people do not consider it as the requirement !

I really wish Sun would take a breather and start putting time into improving the performance of their current libraries and fixing bugs that have been around for years.

For instance, take Java Serialization. Its sad that Sun has untouched this code for years and that we have to create projects like JBoss Serialization because Java Serialization sucks so bad.

Bill Burke
JBoss Inc.

I'd second that. After all this time I still can't recommend Java for client-side applications due to performance. Sure, it is possible to write code that performs reasonably well on a modern PC, but we must get to a point where a less experienced developer can write an application that feels snappy on hardware that is a few years old. Until we are there VB, C++ and C# will rule the desktop.

Amen, brother! Testify!

I'm not sure about making Java aware of XML constructs like the original posting seemed to imply, but I'd sure as hell like to be able to have here documents in Java. When I want to write a big exception message, or perhaps (god forbid) write a quick HQL query in my Java code it feels clunky as all hell. I'd very much like to have a bit of syntax sure to write something like:

String hql = {
    from Person
    where age > :minAge
    and age < :maxAge
    and so on and so forth
}
session.createQuery(hql);

No language knowledge of what the String is or represents, but that surely is easier to read and write than a bunch on Strings, one per line, with pluses (and don't forget a space at the end of each String etc.).

-Tim Fennell
Stripes: Because web development should just be easier.

Yeah compare the difference between these:

String hql = {
    from Person
    where age > :minAge
    and age < :maxAge
    and so on and so forth
}

String sql = "select name "
 + "from Person "
 + "where age > :minAge "
 + "and age < :maxAge "
 + "and so on and so forth";

I mean they are soooo different. It's like totally unpossible to read the second one.

I mean, hardcoding SQL in your code isn't really the best way to do things anyway but let's turn Java into PowerBuilder.

I mean they are soooo different. It's like totally unpossible to read the second one.I mean, hardcoding SQL in your code isn't really the best way to do things anyway but let's turn Java into PowerBuilder.

James, I'm glad that you took the time to write a thoughful response. What better way to make your argument than use sarcasm, and focus on the example as opposed to the concept? ;)

Perhaps I shouldn't have used a trivial example. But, where would you store hql (note: hql, not sql). HQL shouldn't have to change unless your objects change, so really there's very little reason not to embed it in code (though hopefully not scattered all over). And I don't see how having the ability to write multi-line strings makes a language like PowerBuilder.

I prefer the here document style for several reasons. 1. Try embedding some quotes in your String and it becomes less readable. 2. If I were to print my string (say in a log message) I've have to insert newlines into the regular String appended form to make it layout on multiple lines. 3. If you add another condition on to that hql (or line on to a message etc.) chances are better than even you won't remember to add a space at the end of the previous line. For hql that'll result in an exception, for a message you'll get two words clubbed together.

So, yes, I do think that here documents are more readable (more so as the String gets larger or more complex), and less fault-prone. By the same token then, are you against auto-boxing and the new for-loop? Both are simple reformulations of things you can do in Java 1.4, but they're easier on the eye and harder to screw up (in most cases).

-Tim Fennell
StripesBecause web development should just be easier.

And I don't see how having the ability to write multi-line strings makes a language like PowerBuilder.

Sorry, I thought we were talking about embedding SQL in code. Multi-line Strings... I could be convinced. Not a big issue for me. I current deal with SQL split up into poorly named literals and then concatenated with StringBuffers with ternary operators embedded in the parameters.

To me, the + version is like manna from heaven.

By the same token then, are you against auto-boxing and the new for-loop? Both are simple reformulations of things you can do in Java 1.4, but they're easier on the eye and harder to screw up (in most cases).

They are alright. I didn't see them as the most important issues in the language.

What I want the most is the ability to declare normal types (not generic types) as unions:

Component & MyComponent component;

These sytactical sugar additions seem like a lot of fluff. Not that I don't enjoy them but Java used to have a really light syntax. Now it's taking on a lot of baggage. It increases the learning curve.

What I meant to rail against was embedding SQL or XML in code the way that PowerBuilder supports SQL. I did my time as a PB maintenance guy and they ain't putting me back in the clink. Actually, that's bull, I have to deal with Tibco which is arguably worse in some respects.

IHMO, XML excels at defining data!

It is very common to have a need to describe a large data structure, but have no need to define associated behavior. With the current OO technology, the solution is to create a collection of classes, yada yada yada... To me it seems like the wrong tool.

I like XML Schema. There, I said it!

XML Schema allows one to define large nested structures of data AND to define associated limits be they simple max/min, regular expressions, etc... Java is lacking this technology.

I would like to see the core Java language evolve to include a data defining syntax like XML schema and a data manipulation language like XQuery. Obviously, this would require a lot of careful engineering.

Currently we achieve this using JAXB and Saxon, but it seems the need is fundamental and should be part of the core language.

Steve Punte
CTO JXReports
JXReports

I like XML Schema. There, I said it! XML Schema allows one to define large nested structures of data AND to define associated limits be they simple max/min, ...

Comparison with Java is incorrect at the first place. Data definition should be crossplatform and therefore Schema should be compared with IDL.

http://www.theserverside.com/news/thread.tss?thread_id=37238#189301

Validation definitely sounds cool. But the real question is: how much is actually _useful_ ?

With IDL (or POJO) we surely do not need to check if a supposedly numeric field has letters or uses comma instead of dot, or how it is formatted because we cannot assign letters to a double.

Maybe I can use schema and check if amount of the requested withdrawal is less than allowed limit? – Oops, no, it belongs to the realm of business logic validation. Oh! Perhaps I can check if the amount is negative! This way I will successfully scatter validation across multiple places and incur inconsistency in error messaging, plus get headache with i18n support. Hmm

Can I check if the ref-id in this field is the same as ID in the previous message? –Nope, cannot do that with schema.

Well, since I have to write significant portion of validation in my business level I tend to have all the validation in one place.

How about defining in the schema validation interdependencies, like if I have SSN then I do not need to have values in address, first, last names etc.?

I like XML Schema. There, I said it! XML Schema allows one to define large nested structures of data AND to define associated limits be they simple max/min, ...

Comparison with Java is incorrect at the first place. Data definition should be crossplatform and therefore Schema should be compared with IDL.

True, comparing Java and XML is like comparing apples to oranges: they are two completely different beasts. But this is why they also go well together: they complement each others strengths.

XML Schema, and others, are in effect an IDL.

If core Java was to promote XML as first class data, there would need to be a way to generate an external plain text XML schema for consumption by other tools.

But keep in mind, the point of my posting is that there are many needs to applications that would benefit from internal data defined and structured in XML which are not necessarily exported to the external world.

It is simply a superior way of defining data: IHMO.

Steve Punte
CTO JXReports
JXReports

But keep in mind, the point of my posting is that there are many needs to applications that would benefit from internal data defined and structured in XML which are not necessarily exported to the external world.It is simply a superior way of defining data: IHMO.

If a data structure is for internal consumption only then XML is the worst possible way of defining it IMHO :)

It is like using Map of Maps instead of real structures in the language. Sure there are valid cases for using that approach, but as a general rule Map of Maps should be avouded.

But keep in mind, the point of my posting is that there are many needs to applications that would benefit from internal data defined and structured in XML which are not necessarily exported to the external world.It is simply a superior way of defining data: IHMO.

If a data structure is for internal consumption only then XML is the worst possible way of defining it IMHO :)It is like using Map of Maps instead of real structures in the language. Sure there are valid cases for using that approach, but as a general rule Map of Maps should be avouded.

Using maps is a run-time only solution. Any errors in coding will not be seen until a run-time activity exposes them.

XML Schema, or a better version of this technology, offers compiler time definition of the data structure and definition of data-range. In addition, if an XQuery or XPath like syntax is supported in the procedural member functions, then this structure too would be checked at compile time.

Compile time checking of code goes a lot ways in quality control.

Why do you say it is worse? I would envision an XPath like syntax available in procedural code something like:

if( $doc//employees[@state='CA']//employee/firstname != null ) {
 ...
}


Steve

Steve,

You and other XML inline proponents should understand - not everybody doing XML thing. Althought I work with EJB 2.0, I not very annoyed with all EJB/XML staff. Once infrastructure for project done, XML's only extends without any serious work.

So, I don't care. May be another 1M EJB Developers don't care, who knows. What I care about, is keep bloody staff out of the language.

Steve,You and other XML inline proponents should understand - not everybody doing XML thing. Althought I work with EJB 2.0, I not very annoyed with all EJB/XML staff. Once infrastructure for project done, XML's only extends without any serious work.So, I don't care. May be another 1M EJB Developers don't care, who knows. What I care about, is keep bloody staff out of the language.

So don't use it. Java gave up on being a small language a long time ago. If it has no implications for your development or the performance of your runtime, but helps others...

BTW, I have posted some more notes from the Colorado Software Summit conference at which XML support was presented here.

So don't use it.

That wasn't ever work - C++/Smalltalk/PL/1 had many features. You can itself not use it, but you are living in the world with people, who will use it due various reason.. libraries will use it... language become complicated... entry level grows up... corporates start looking for another language with less expensive developers... language stagnate... language die.

That was happend and happens now with many languages. I don't want in 10 years again learn "Tapestry for IBM J++#"

Then you are pretty much doomed. Change happens.

I, too, have had to deal with other people's PowerBuilder code and witnessed the convenience of embedded SQL turn into the headache of maintaining it when the database schema changes. I suspect that similar things could occur with embedded XML/XPath/whatever. I do not think, however, that preferring JDBC over SQLJ really eliminates this problem.

Rather than trying to modify the core Java language to include a syntactically different one (SQL, XML, ...), I would like to see some more generic approach to including code to be interpreted in another way, somewhat like how SQLJ was done. Perhaps

if( $doc//employees[@state='CA']//employee/firstname != null ) {
 ...
}

could be coded slightly differently as

if( XPath<< $doc//employees[@state='CA']//employee/firstname >> != null ) {
 ...
}

where "XPath" is some pluggable parser that generated an object and the "<
Another improvement that I think would go a long way to make the code easier to read would be to create a new marker interface that instructed the compiler to convert "==" into a call to "equals()" on the object on the left. If the object also implemented comparable then ">", "<=", and so on would call the compareTo() method. I would then suggest that String implement this so that if( "a" < "b" ) {...} does something useful. Then

if( xPathResult == object ) {...}

could ease the pain of combining your XML stuff with your Java stuff.

Barry

Rather than trying to modify the core Java language to include a syntactically different one (SQL, XML, ...), I would like to see some more generic approach to including code to be interpreted in another way, somewhat like how SQLJ was done. Perhaps...

if( XPath<< $doc//employees[@state='CA']//employee/firstname >> != null ) {...}

where "XPath" is some pluggable parser ... I could see a real advantage to a string version of the above that doesn't treat quotes and backslashes [and multiple lines] as special ... a lot easier to read.

That's a brilliant idea, since pluggable parsing enables arbitrary validation, execution, and other semantics. It's shortsighted for theproposed Java 7 enhancements to regard XML as nothing more than a data structure. The semantic potential of XML should be acknowledged. Eg, the content inlined in Java could be an Ant script that get executed inline. I also love that your idea isn't limited to XML. The inlined content could be SQL, Ruby, etc. So what you've done is revealed a way to make the Java language extensible and capable of compound (ie, multi-language) source files. Though perhaps annotations can already do all this without enhancing the Java Language Specification.

Dmitriy,

Steve,You and other XML inline proponents should understand - not everybody doing XML thing. Althought I work with EJB 2.0, I not very annoyed with all EJB/XML staff. Once infrastructure for project done, XML's only extends without any serious work.So, I don't care. May be another 1M EJB Developers don't care, who knows. What I care about, is keep bloody staff out of the language.

Corba is in the JSDK and not everyone uses that, but less I digress.

Note that I agree with you in that we don't want to Java become like Perl and every feature someone could think of. And enhancements should stand up to great scrutiny before being adopted.

Perhaps it is just me, in that I'm an XML fan. But this is the proper forum to test the concept.

I thus make the conjecture that OO languages have been TOO obsessed with being "behavioral oriented" for their own good. The real world isn't all OO, or even close to being all OO. A case in point: computer science and computer programming flourished quite well before the mid 1990's when OO too off.

In my software development experiences, is it common that one simply wants an elaborate structure of data. Right now, this can be achieve with OO classes, but it feels like the wrong tool because no member function are needed. This is where XML shines: it succinctly defines structure and data associated ranges.

The vision I have is NOT to have XML like brackets inlined with Java: yuck.
Rather:

* A RELAX-NG like data definition syntax.
* An XPath and/or XQuery like manipulation syntax.

If such technology was in place with Java, I believe it would be heavily used. That is, I don't think it would be a corner case feature.

Steve Punte
CEO JXReports
JXReports

Very basic feature of Java is name and type safety. How it will work with your example? If you want something like XML inlining than look for some scripting language. For example Groovy has excelent XML support via GroovyMarkup and GPath.
If you want excelent XML support in Java look for XMLBeans. This will keep your Java code name and type safe with features like XPath and XQuery.

Extending the language grammar for the latest markup language is a *BAD* idea.

This is what JSP or XSLT are for -- or what a good library or API should be used for.

Every time a new orthogonal technology comes along the language should not be extended to address it. If we do this the language itself will become unlearnable and unteachable for all practical purposes and the resulting code will be unmaintainable.

Keep the language simple and only extend it when the solution *must* be at that level. Generics are a perfect example of an important feature that had to be done at the language level (unless you're a really big fan of pre-processors -- CFront should be enough said in this regard...). Those who simply want to stop learning may have protested, but generics are a *huge* productivity *and* maintainability gain.

XML inlining would only make Java as hard to learn and read as the worst other language out there. Just because other languages can't learn to keep the core grammar manageable doesn't mean Java should make the same mistakes. [The new C# syntax additions are a perfect example of language design gone awry -- sure you can express all sorts of crazy concepts in fewer characters, but try getting everyone to understand one another's code at a glance! As if operator overloading wasn't bad enough!]

Very basic feature of Java is name and type safety. How it will work with your example? If you want something like XML inlining than look for some scripting language. For example Groovy has excelent XML support via GroovyMarkup and GPath.If you want excelent XML support in Java look for XMLBeans. This will keep your Java code name and type safe with features like XPath and XQuery.

+1

I don't understand why people are arguing so much about something so simple as java and XML interoperability. It might not be that standardized, but it is inherently simple.

Various tools exist, from dedicated libraries to scripting languages, as stated. Do people want to get back to C/C++ prepocessor hell ? I strongly believe the Java language syntax, although not always perfect, is way productive enough, particularly with the help of the good IDE we have nowadays. I send much more time defining my object model and running test sessions, than typing code.

I believe that solid and fast standard libraries will do more to promote java and enhance developer experience much more than turning java into Groovy. Not that i do not like Groovy, on the contrary i believe it is an excellent initiative, that i personnaly used in project that are now in production. But you don't need to include it's features into the java language and plateform itself.

I successfuly use JXpath when i need to apply XPath quering to java object trees (mainly parsed XML read via Xerces), it is very cool. If ever i need some more efficient query over an object tree, i build it myself, with my own indexes.

And if ever somebody would like some readable syntax (as it seems to be all about) with high performance implementation, what about something like :

XPathObject myXPathObject = new XPathObject(Person.class, "//Person/Address[City='?']");
DomTree mySubTree = myXPathObject.XPathQuery(myXMLDoc, "New-York");
DomTree mySubTree2 = myXPathObject.XPathQuery(myXMLDoc2, "Toronto");

or in a more concise way if you don't want to reuse the query builder :
DomTree mySubTree = myXMLDoc.XPathQuery("//Person/Address[City='Toronto']");

Maybe such a library exists, by the way, but i did not bother look for it as what i use everyday really satisfies me.

Sorry for people who do not like the "readability" of this code, but for myself a java developer, it is much more readable than all the XML bracketted elements. Additionally i don't need to do the mental switch from java syntax to XML syntax while reading the code.

My 2 cents,

Christian

Christian,

DomTree mySubTree =myXMLDoc.XPathQuery("//Person/Address[City='Toronto']");

This type of implementation works, and indeed is what I presently use. However, it lacks compile-time checking, and thus lacks scalability to large implementations.

For example, suppose the element name "Address" above was changed to "Addresses". If the application was large (i.e. > 100K lines), one would have to hunt for and hope one found all the locations where this element name is used. Regression testing doesn't even guarantee all usages will be found and stimulated.

But IF XML was integrated into the Java language, then any such coding problems show up at compile time.


Steve Punte
CEO JXReports
JXReports

Christian,

DomTree mySubTree =myXMLDoc.XPathQuery("//Person/Address[City='Toronto']");

This type of implementation works, and indeed is what I presently use. However, it lacks compile-time checking, and thus lacks scalability to large implementations.JXReports

Steve,

I understand you concern, thus i do not think we should change the java language itself, for various reasons. Here is what i suggest.

1. Externalize the XPath strings into a couple of property files. Thus, even if your code is 100MBytes long, you can easily find wheer the changes have to be done. Additionally, if you are using XML/Xpath so intensively, develop your own Eclipse plugin adapted to your own needs, so that when you refactor a class the associated XPath expressions in this property files would be changed accordingly. This plugin may even exist ;o)

2. Use a different language than the java language, i.e. the Groovy language. I use it, it is excellent for this kind of use.

3. Do not use XPath, but put query capabilities into your data encapsulation classes, or helper classes. This way, you would have something similar to :
Address myAddress = myRootObject.buildParser().getPersons().getAddresses().filterCity("Toronto");

or whatever syntactic sugar you like !

100% compatible with java language thus IDE refactoring.

My 2 cents,

Christian

Christian,

DomTree mySubTree =myXMLDoc.XPathQuery("//Person/Address[City='Toronto']");

... However, it lacks compile-time checking, and thus lacks scalability to large implementations. ... But IF XML was integrated into the Java language, then any such coding problems show up at compile time.

If the XPath query string were an annotation, it could be validated at build time without modifying the Java language.

Christian,

DomTree mySubTree =myXMLDoc.XPathQuery("//Person/Address[City='Toronto']");

... However, it lacks compile-time checking, and thus lacks scalability to large implementations. ... But IF XML was integrated into the Java language, then any such coding problems show up at compile time.

If the XPath query string were an annotation, it could be validated at build time without modifying the Java language.

Brian,

Such a great idea, hopefuly myself or somebody else will have time to implement it ! I will definitely evaluate how to annotation enable XPath java libraries.

Christian BERNARD

hmm..
Who knows when sun will announch... "...New Java SE xxx supports C# based coding...you can change your Java Coding to C# just chaning this properties...blah blah.. blah....;..."

Good news indeed....

NHM Tanveer Hossain Khan (hasan)

Using clear delimiters, multi-line text would be wonderful in Java. I suppose that the multi-line text can be put as a resource in the Jar file.

I would further suggest that Sun put a multi-lingual capability for multi-line text. That is, we should have lots of block of text specified in a speparate file (maybe XML) and some text specified inside the Java code (in-line).

I do a lot of XML work, some with Java, some with XSLT. XSLT is definitely is a lot easier to work with (once you understand both it and Java), because it supports the XML data model directly. The thing that Java lacks, like most current O-O languages, is support for deep data hierarchies. What I mean is that the only way to create a data hierarchy with many levels is to have classes at each level. This differs from XML, where a single (complex) data type definition can define an arbitrarily deep construct composed on sequences and choices.

If this kind of data structure support (which is kind of an anonymous descendant class feature) was added to Java, it would make it much easier to map onto XML. It would also make it possible to reduce the number of lines of Java code required to process XML down to something much nearer the number of XSLT lines that are required. I don't think people have fully recognised the degree to which part of the success of XML and XML Schemas is related to not having give a separate type name to every single node in every data tree.

Cheers, Tony.