IBM XML Enhancements for Java, part of their Emerging Technologies Toolkit (ETTK), has released a tool for providing language extensions to J2EE 1.4 to support XML, XML Schema, and XPath in Java.

This is unique because it uses a Java language-based approach to developing XML applications. Through integration of Java and XML, the extensions simplify the development of XML-based applications and enable developers to reuse existing Java libraries when developing XML code.

Integration with XML at the language level is a feature supported by Groovy, and currently being debated by Java heavyweigts for inclusion in Dolphin. (JSE 7)

This is much like what is provided by JAXB but witha tighter integration with the language itself, specifically:

"XML Construction: A programmer may construct XML data in an XJ program by writing literal XML inline in the Java program. The compiler will verify that the construction is valid with respect to the appropriate Java type."

I would very mich like the authors of XJ to explain what the advantages are over JAXB 2.0. Is it mainly what I pasted above?

This is great work!

-geoff

Geoff,
   I think you have it essentially right. A couple of points that we think are in favor of XJ are :

1. You can construct XML by writing literal XML inline. It will be validated according to appropriate XML types by the compiler and errors will be reported early.

2. You can write XPath expressions on XML objects --- again the compiler can verify that syntactically the XPath is accurate and correct with respect to schema types.

3. XJ is more efficient. The compiler can perform many optimizations that are not possible in runtime library approaches (in XJ the compiler can figure out how you are suing the XML). We willbe releasing an optimized compiler in the next few weeks that will generate more efficient code for XPath evaluation than is possible with JAXB (which interprets XPaths at runtime).

4. XJ is more consistent with the XML Schema standard --- there is no translation into Java classes.

5. XJ is a two-step process (compile + run). JAXB is a three step process (generate + compile + run)

All in all, the use of XML is quite prevalent. We believe that adding support for XML in Java will make XML processing
programs easier to write, more robust, and more efficient.

...All in all, the use of XML is quite prevalent. We believe that adding support for XML in Java will make XML processing programs easier to write, more robust, and more efficient.

And more prevalent.

I forgot to mention that XJ does not require you to have a schema --- you can work with untyped XML as well and still get the benefits of XPath compilation, well-formedness checking, etc. that you don't get with DOM or JAXB.

Why not introduce multiline string literals first?

The only real advantage of embedded XML over something like GString in Groovy is Java compile time XML compilation.

Nebojsa

Ugh, now even more people will start using XML when it makes no sense to.

Reminds me of when people mingled SQL within programming languages (C & C++, Java). AFAIK it was deemed as a Bad Thing (TM) back then, so I wonder why would it be different this time with XML?

Frankly I am surprised there is no mention of XQuery in these proposed enhancements, althought I certainly share in Henrique's concern that blending languages can sometimes have undesireable results...

Goot idea. I need integration with SQL,COBOL and UML at the language level too, add it to JAVA.

Goot idea. I need integration with SQL,COBOL and UML at the language level too, add it to JAVA.

+1 ;-)

Java source is java source, not XML. What one needs is some good util classes to get the annoying stuff done; for SQL, XML and all others. Basically that is what the Groovy builders class is.

For me, dom4j is all I really need lately.

Goot idea. I need integration with SQL,COBOL and UML at the language level too, add it to JAVA.

+1 ;-)Java source is java source, not XML. What one needs is some good util classes to get the annoying stuff done; for SQL, XML and all others. Basically that is what the Groovy builders class is.For me, dom4j is all I really need lately.

+1
Developing in Java is becoming a joke. People spend more time editing hundred of XML files, scripting silly things with Groovy and other scripting languages and dealing with heavy bad JVM/GC with huge memory footprint than actually coding business code .
So sad.....when will people wake up ?
We need a language with the same syntax of Java but that it gets compiled into binary without the need of silly JVM and with optional GC and pointers.

We need a language with the same syntax of Java but that it gets compiled into binary without the need of silly JVM and with optional GC and pointers.

+1

I vote for calling it C++ ..

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

We need a language with the same syntax of Java but that it gets compiled into binary without the need of silly JVM and with optional GC and pointers.

+1I vote for calling it C++ ..Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

J++ sounds better.. ;-)

BTW this is not a critic on XJ which is excellent!

My two cents ....

I believe that XML is more universal than SQL, COBOL, and UML. While SQL's use is limited to relational DBs, etc. ... the adoption of XML is more widespread --- relational DBs such as DB2 and Oracle are putting in first-class support for XML (you don't see them adding support for UML). Web Services, messaging systems all are moving towards supporting XML as a first class construct.

As it stands, I see XML as being closer to ASCII or Unicode (that is, it is a universal data representation format) than SQL or COBOL, etc. Perhaps, this is why I feel it may be more important to integrate XML support into the language (for efficiency and robustness) than the other technologies you mentioned.

I do not understand how makup language is better than query, unified modeling or common business oriented language.
BTW language level regular experession support is a very cool feature, is not it ? AWK is a very cool transformation language, if you are going to add language level XML support then do not forget to add this stuff too.

Also, we need IDE integrated in language. Why do I need buy IDEA or download Eclipse?

I always liked domain specific languages. They make it easier to describe your problem and/or solution concisely.

However, when the only way to embed a program in such a language in a Java program is to keep it all in a String, then all the advantages of compile time checking goes away.

So, adding XML syntax as a valid Java(++) expression makes a lot of sense. It's just that it makes so much sense that I want it for other things too.

One language that is widely embedded in other lanugages, is Regular Expression-language. E.g. Perl and JavaScript have syntax for declaring regular expressions directly in that language, whereas Java still puts it into a string (with the inherent problems coming from both String literals and regular expressions using the same escape character :).

So drop this XML extension and generalize it to a full "other language" embedding technology that can handle arbitrary other languages while retaining static syntax and type checks, so we won't have to write XML, RegExp, SQL, HQL, etc. in Strings and only find the syntax errors at run-time any more.

/L 'my $.05 worth of soapbox time'