JavaOneで既に触れられていたが、Dolphin(JavaSE7)ではJava言語自体のXML対応が検討されている。そしてそれはIBMのAlphaWorksで発表されたXjのことだった。
http://www.alphaworks.ibm.com/tech/xj?open&S_TACT=105AGX59&S_CMP=GR&ca=dgr-jw22awxj
http://www.research.ibm.com/xj/demo.html
これは簡単に引用すると次のようなことができるということである。
sales s2 = new sales(<sales unit="GBP">{conversionFactor * grandTotal}</sales>); ダブルクォートがないことに気づくのではないだろうか？
現在は拡張子xjの別ソースとして存在し、別の実行系xjで実行するのであるが、これをJava言語仕様にそのままいれるのかどうかは良くわからない。
このソースを読んだときピンとこなかったと同時になにやら気持ち悪さを感じた。私はSAX程度しかXML処理のプログラムを書いたことがないので現在Javaで本格的にXMLを処理する大変さがわからない。故に言語仕様でこのレベルの拡張が本当に必要なのか、疑問に思ってしまった。
Javaの生みの親、Goslingはあまり乗り気ではないようだ。
Father of Java Talks Futures
http://www.eweek.com/article2/0,1895,1837440,00.asp
Direct language support for XML has been a debate for some time. All these things at an abstract level kind of sound like the thing to do.
When it comes down to the details, one of the problems ends up being that using Java today you actually get pretty good access to XML.
And really what it would end up being is sort of syntactic sugar that makes certain constructions simpler, but can you come up with something that actually makes people's life better by enough that it's worth adding that baggage?
It's one of these things that these days is a community debate.
10年前にJava白書を書いたときに、GoslingはJavaの文法をできるだけシンプルにすることの重要性を説いていた。事実彼がJDK1.5でのGenericsとannotationの大幅な変更までに行った変更はJDK1.1の内部クラスとJDK1.4のassert文のみである。
彼は常にメンテナンス性の重要性を説き、シンプルな言語仕様による学習容易性の重要性を解いた。
その彼がこの計画を好むことはないだろうなと考えていただけにこの記事は嬉しかった。
このインタビューはVal's Blogにて知ったのだが彼はこのことを非常に残念がっている。
Val's blog
http://radio.javaranch.com/val/2005/07/21/1121924183653.html
I just hope that James was joking and that he gets his head out of his real-time Java stuff for a moment and looks at what people are asking for... I have already shown (+ here) that DOM programming is not at all simple and straightforward for developers to use and that something along the lines of IBM's XJ would be much appreciated.
確かに彼のいうとおり、JavaによるXMLの処理は大変なのかもしれない。
しかし、それは言語仕様を変えなければならないほど難しいことなのであろうか？
GoslingはかってJava白書にてJDBC1.0の文法が変であることを認めていた。
全てをオブジェクト指向のやり方で処理するのは大変なことを彼自身が理解していたのである。しかしJDBCは発展をとげ、JavaによるDB開発ではSQLJを打ち負かし、完全に標準となった。Mustangで採用されるJDBC4.0ではJDK1.5のannotationも採用し、さらに便利になっている。またEJB3のPersistenceAPIもJ2EEから独立し、J2SEに採用される日も近いと感じる。
このような例を見ると、XMLの言語仕様による対応は慎重に慎重を重ねるべきではないかと私は考える。
theserverside.comでのこの件に関する議論では、賛否が半々というところであろうか。
XML Enhancements for Java 1.1 released
賛成意見はこのコメントがよくまとまっている。
http://www.theserverside.com/news/thread.tss?thread_id=35489#179407
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)
反対意見はこのへんが良いだろうか？
http://www.theserverside.com/news/thread.tss?thread_id=35489#179393
http://www.theserverside.com/news/thread.tss?thread_id=35489#179447
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?
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.
賛成意見から読み取るとコンパイラによる静的チェックを挙げているが、これは本当に有用だろうか？
テスト駆動開発が非常に有効なことは誰も異論がないと思う。このとき、静的チェックの有効性は大して重要ではないと私は考える。
次にコンパイラによるオプティマイズが実行時にはできないと書いてあるが、これはJava自身がJITにより反論しているだろう。
Schemaに対するConsistencyに関してはSchema自体の悪口しか聞かないが、私はXMLに詳しくないので評価は避ける。
JAXBがコード生成を行うというのは確かに問題になりうるかもしれない。しかしコード生成はあまり良くないのも事実だが、その用い方と問題判別の容易性にて判断されるべきだと考える。XJも現在はバイトコードレベルでのコード生成を行っているのだろうから、デバッガによる動的解析では劣っているのではないだろうか。この点はまたいずれどなたかが詳しい評価をしてくださるだろう。
反対意見に対しては全く同感である。私は仕事でSQLJを使用しているが、最悪な経験であった。
JavaがJavaでないという状態は、使用できるツールが限定され、コード生成にて作成された非常に読みがたいコードに対しデバッグを行わねばならず、コードのバージョン管理とビルドに余計な手間を取られ、開発サイクルに対しても効率の悪化をもたらした。
XjはJavaソースを生成するプリコンパイラではないようだが、Eclipseを始めとする全てのツールが対応を迫られることになるだろう。EclipseがJDK1.5に対して正式に対応するのにどれだけかかっただろうか。果たしてXMLの処理にそれだけの価値があるのかどうかくれぐれも慎重な検討をJCPの方々にはお願いしたい。
（面白いのはXJを正式なJavaにしたのなら、SQLJをXJ対応にしなければならない点だろう。それこそtheserverside.comで揶揄されているように言語のミックスを永遠に続けなければならないだろう。）
