レベル: 初級 Ted Neward (ted@tedneward.com), Principal, Neward & Associates
2008年 5月 27日 Java™ が間もなく消え去るという最近の報告を見聞きした皆さんは、Java というプラットフォームを捨ててもっと優れたものに移行する時が来たのだろうかと思っていることでしょう。しかし結論を下す前に一歩下がって Java のエコシステムとその競合とを検証し、冒頭の噂が内容を伴ったものかどうかを調べてみましょう。つまりアメリカ大統領の一般教書演説にならい、Java プラットフォームの評価に関して高慢も偏見も交えずに Java の一般教書演説をしてみようというわけです。
歴史を学ぶ学生は、トーマス・マルサス (Thomas Malthus) の予言を思い出すかもしれません。マルサスは著書の中で、文明を形成する男女の集団は農業システムによって支えられているが、やがてその農業システムそのものが人口の増加傾向を支えきれなくなり、疫病の大流行や他の自然災害などが主たる原因となって人口が減少に転じるということが、間近に迫っていて不可避である、と述べています。彼は、「人口は、抑制されずに放置されれば幾何級数的に増加する。最低限の生存に必要な物資は算術級数的にしか増加しない。数字を多少理解できる者であれば、前者による増加は後者による増加に比較して膨大であることが理解できる。これはつまり、生活物資の供給困難を起因として強力かつ定常的な人口の抑制が必要なことを意味する。この供給困難はいずれかの場所に生ずるはずであり、それは必ず人類の大多数に深刻に受け止められなければならないものである。」
トーマス・マルサスは彼の『人口論 (Essay on the Principle of Population)』(「参考文献」を参照) を 1798年の 6月に発表しました。私達はそれ以来、彼の言う「マルサス論による抑制」が人口の増加に対して実際に働くのを待ち続けています。
プログラミングを学ぶ学生 (特に Java プラットフォームと Java 言語を使用する学生) は、彼らが選択したプラットフォームが間もなく確実に消滅することを暗に示す予測や統計に気付いており、不安を感じ始めているかもしれません。Java の置き換えとなりうる候補は無数挙げられており、.NET や Ruby、さらには Python まで、「Next Big Thing (次なる大きな潮流)」であると言われています。
これらの 2 つの「マルサス論による抑制」には驚くほど類似点があります。
マルサスは、食料は私達が生存する上で必要であるが、地球で生産できる食料は限られており、そして私達の生物としての繁殖衝動は不変であるため、やがて地球は人口を支えきれない時点に達すると主張しました。言い換えれば、もし私達が今のままの生活を続けるなら、私達は滅びる運命にあります。1798年の頃には、この論理に反論することは困難でした。
それと同様に、この 18 カ月ほど、Java コミュニティーには Java プラットフォームの終焉を予測する新たな傾向が生まれています。Java を 90年代の技術であると呼ぶイエロー・ジャーナリズムの記事から、今はやりの言語を伝道する大げさな技術講演者、Java を「超えている」と主張する著者による本に至るまで、要点は明確です。つまり彼らの主張は、十分な根拠のある兆候や、コード、適用されているロジック、あるいは統計などから明らかなように、Java は退場の道にあるというのです。
しかしマルサスは、ちょうどその頃に兆しの見えていた産業革命を見逃していました。マルサスは彼の存命中、蒸気機関や綿繰り機などの発明によって人類による農業の生産性が信じられないほど向上するのを目撃することができました。つまりそのような装置が新たに発明されたことによって、彼の論理に必要な「失われた環」が見つかり、食糧生産を何倍にもするために必要なものが提供された結果、大幅な人口増加をもたらした「男女間の情熱」を上回る農業システムがそれによって可能となったのです。その後、さらなる技術的革新 (今度は産児制限) によって人口増加への抑制要因が提供されたことにより、食糧不足の緩和に同様の効果がもたらされ、完璧に理にかなったマルサスの論理とはまったく対照的に、今や多くの西欧諸国では人口の減少が起きています。こうした要因はどれも、マルサスが『人口論』を執筆した時点では予測不可能でした。農業システムが崩壊し、ぎりぎりの生存への逆戻りが必然的に起こるという彼の予測をはるかに超えて人類が存続できたのは、こうした要因によるものです。
技術評論家達は、Java 仮想マシンにとって別の言語が登場しつつあることを見逃していました。しかし私の言うことを言葉通りに捉えず、さまざまな議論を一通り調べ、それらが私達とどう関係するのかを見てみましょう。
マルサスの論理で Java を予測する
一部の人は、プログラマーが使用する言語の最上位の地位から Java が転落したという統計による「一節」を、Java が消えつつあることの明確な兆候として引用しています。また一部の人は、Java に代わる環境で提供される特定の機能、つまり顧客や顧客のアプリケーションの要件に「必須」とされる機能が Java にないことを指摘します。またさらに一部の人は、「大企業では Java を使用していない」というような (十分に考慮したものではない) 発言を取り上げ、もし大企業で Java を使用していないなら、それは Java には使用する価値がないことを明確に示唆していると指摘します。
Java 言語は、そしてもっと広い意味での Java プラットフォームとその関連エコシステムは、C++ や C、COBOL その他の言語と同様、Simon Peyton-Jones が言うところの「不死のための敷居」をずっと以前にまたいでいます。そうした言語は、ほぼ永遠に存在し続けるツールです。なぜならそれらの言語は有用な目的に使われているか、あるいはそれらの言語のコードを再作成するためのコストが、それらの言語のシステムを「そのまま」使用して維持し続けるためのコストに比べて膨大になるからです。(ある特定の言語またはシステムが前者のカテゴリーに当てはまるのか後者のカテゴリーに当てはまるのかには大いに議論の余地がありますが、この記事ではその点はまったく重要ではありません。)
また、賢明な人々が皆 Java を見捨て、(プラットフォーム X) あるいは (言語 Y) に移っているという別の主張もあります。2005年の BusinessWeek の記事「Java? It's So Nineties (Java？それは 90年代のものだ)」(「参考文献」を参照) は、ずっと前に消えていったアプリケーション・サーバーの会社 NetDynamics の CTO であった Peter Yared の発言、「Java is a dinosaur. (Java は恐竜のように古い)」を引用しています。その記事はさらに、利害の衝突があることなど目もくれず、もっともらしい理由付けによる論理もなく、Yared が所有する会社がアプリケーション・サーバーに関する経験を LAMP (Linux®/Apache/MySQL/P-言語) スタック上で生かそうとしていると報じています。
(Ruby が作られたのは実際には Java よりも前であり、それは Perl や Python、そしてもちろん Linux、Apache、MySQL なども同様なのですが、それを指摘するのは生意気なので言わずにおきます。)
私の好きな映画を引用すると「殿下、人生は苦しいものです。そう言わない人は、何か下心があるのです。」あるいはこの記事の主題に合わせて言い換えると、「CTO、新しいプラットフォームへの移行は苦しいものです。そう言わない人は、何か下心があるのです。」そして、おそらく驚くには当たりませんが、他の技術領域に引っ越した一部の Java エキスパートが経験しているのは、まさにその通りの事態なのです。
次の主張を考えてみてください。「Java は世界の頂点の言語の地位から転落した。その衰退の様は悲惨なものに違いない。そこで雪崩のような崩壊から逃げ出すのが最も得策なのだ。」この主張の基本的な前提は、Java が世界における圧倒的なベストセラー技術でないならば、Java をサポートする価値はないに違いない、ということです。この前提は、冷静な論理に照らしてみれば、2 つの点であまり意味をなしません。
その 1 つ目の点は、統計を使用する方法は、不注意に使用される場合には疑問の多い方法であることが長年実証されているという点です。これについては Benjamin Disraeli の発言、「世の中には 3 種類の嘘がある。それは、嘘、真っ赤な嘘、そして統計である。」の中で的確に指摘されています。議論の中にどの統計を引用するかを注意深く選択しさえすれば、完全に誤った立論でさえも統計を使って証明することができます。先の BusinessWeek の記事での、次の引用によく注意してください。「・・ 報告によれば、LAMP や Microsoft® の .NET 技術が勢いを得るのに伴い、Java の使用は減少している。」これは悪い知らせに思えます。しかし読み進めると、「Evans による今秋の調査によると、北米において、主要なプログラミング言語の 1 つとして Java を使用する開発者の割合が 2002年の秋の 51.4% に対して 47.9 % にまで落ち込んでいる。」とあります。つまり 6 年の間に、主要なプログラミング言語の 1 つとして Java を使用する開発者の間で、Java の使用の割合が 3.5 ポイント減少したのです。
この文が「主要な」プログラミング言語について述べていることによく注意してください。これはつまり、開発者自身が、自分の「主要な」言語が何かに関する判断を強要されたということです。Spring/Hibernate/JSP による Java スタックを使用している開発者であれば、このスタックに含まれる膨大な XML の構成を考えると、もはや彼らにとって Java は主要言語ではないと思っても当然です。
また、この 6 年の間に Java プラットフォームで使われるようになった動的言語 (Jython、JRuby、Groovy、さらには JavaFX) の台頭にも注意してください。こうした動的言語だけでも十分に 3 ポイント減少の要因になりうるのです。これは、「No Fluff Just Stuff」という催しで、私や私の仲間である講演者達が行っているざっくばらんな投票から判断することができます。
あるいは、同じ記事の別の部分を考えてみてください。その部分を引用すると、「別の一連の調査によると、北米における PHP の使用は 2003年秋の 26% からこの秋には 36.1% に増加している。ヨーロッパやアジアでも、ほぼ同様に急速な伸びを示している。」これが「別の一連の調査」であることを考慮すると、この調査は PHP の伸びを示しているにすぎず、Java の減少を示しているわけではありません。PHP にとっては喜ばしいことですが、大企業の環境で働いたことのある多くの開発者ならばわかるように、製品ソフトウェアの展開はとてもゼロサム・ゲームと言えるようなものではありません (私はそれを暗に示そうとしています)。大規模な IT 環境は多くの場合、非常に広範なツールやプラットフォーム、言語、そして製品から構成されています。実際、こうした環境では、特に例のメインフレーム関連のものに関しては、なんとか統合を行えないものかと望みたくなるほどなのです。
ところでメインフレームと言えば、COBOL がそうした第 1 位の座を降りてから今や何十年にもなりますが、それでもなお COBOL は、無数の業界評論家達によって「死んだ」と断言されたにもかかわらず、小切手の現金化や預金からの振込み、クレジット・カードの支払い、そして主な金融ネットワークを実行するために使われ続けています。墓場の中で腐敗しているはずのものにとっては悪い話ではありません。私はこのことからマーク・トウェインを思い出します。彼は、彼の故郷の新聞に自分自身の死亡記事が掲載されたのを見せられた時、「皆さん、私の死亡記事は非常に誇張されています」と言ったそうです。
さて、統計の問題は別にすると、2 つ目の点はもっと重要です。皆さんの選択するツールがナンバーワンではなくなったからといって、なぜ今そのツールを見捨てる時だと思うのでしょう。Java はソフトウェア開発における第 1 位の座を、ほとんど 10 年近く維持しています。Java がランキングの 2 位に「落ちた」からといって、ゲームは終了なのでしょうか。勢いを失った Java が第 1 位の座を奪還することは不可能という推測をたとえ受け入れるとしても、10 人中 4 人のプログラマーはこの言語を使い続けるという事実は残り、Java が今後何十年間も存在し続けることは確実です。また、きしみ音と共に Java の成長は止まり、Java によるデプロイメントは今後 1 つも行われなくなる、という (少しばかげた) 推測まで受け入れるにしても、Java が業界全体にわたって広く展開されていることを考えれば、少なくともこれまでと同じくらいの長い時間 Java が存在し続けることは確実です。
年収がドルで 6 桁か 7 桁にもなる COBOL の技術者に対して、「死んだ」言語を扱う作業がどんなものか尋ねてみてください。
証拠を検証する
しかし、相手の主張の欠陥を指摘しても自分の主張を証明したことにはなりません。ここでもそれは同じです。Java 言語とプラットフォームに関して、そして Java の長所と短所に関して、確固たる分析に耐えうる冷静かつ批評的な目を向ける必要があります。Java が生き残るかどうかは、この先 10 年間に待ち受ける困難を乗り越えられるかどうかにかかっており、どこかの著者や評論家による、Java が生きるか死ぬかに関する発言にかかっているわけではありません。
そうした点から、現在の Java プラットフォームを構成している要素を考えてみましょう。
-
Java プログラミング言語。正直なところ、Java のプラットフォームのうち、特に、より「最近の」言語 (C# やGroovy、(j)Ruby、Scala など) と比較した場合に年齢を感じさせる部分が Java 言語です。最近では Java 言語の改善方法に関して洪水のように大量の助言が寄せられていますが、例えば Java 言語にクロージャーを追加するなどといった Java と競合する提案は、他の言語にはあって Java では「失われた要素」を Java プログラマーがいかに熱望しているかを示しています。しかし、Java 5 で行われた最新の言語機能強化が成功かどうかの評価が分かれている事実は、言語に関して新たに大幅な変更を加える際には十分に注意する必要があるという警告とも言えます。一部の機能強化、例えば拡張
for ループやアノテーションなどは (比較的) 広く受け入れられた一方、例えば Generics などは (比較的) 広範な愚弄と批判に遭っています。これらの言語機能は、本来開発者コミュニティーを支援するはずのものであるにもかかわらず、開発者コミュニティー全体にわたって一様に受け入れられたものはない、という事実から、1 つのことがわかります。つまり10 年以上経った言語に新たな言語機能を追加する試みは簡単ではなく、もし再度そうした機能強化を行うと、その言語が自分の重みに耐えられずに崩壊してしまう可能性が十分にあるということです。Java プラットフォームに関する地図の上で、この Java プログラミング言語の領域には、かつての船乗り達が使った「龍の住む海域」という警告の印が付けられています。
-
Java 以外の JVM プログラミング言語。Java が去った場所を、他の言語が取り上げ、機能強化し、そしてソリューションを提供します。Groovy は、Java オブジェクトの周囲に動的でオブジェクト風のスクリプトによるソリューションを提供します。(j)Ruby は JVM 上に Ruby 実装を提供し、Java プログラマーに Rails と ActiveRecord の世界を開きます。Scalaと Jaskell は JVM に関数型の概念をもたらし、問題になりつつある並行性に対する潜在的なソリューションを提供します。そして他にもまだまだあります。これらの言語はどれもバイトコードにコンパイルされるか、あるいは javax.script API をとおして JVM 上でインタープリター言語として実行されるため、Java のエコシステムの豊かさ全体を相変わらず利用することができます。これは Ruby 主義者が見返りとして得られるようなものではありません。Java プラットフォームの地図の上で、この領域には、「希望の地」とマーキングされています。
-
Java 仮想マシン。Java 言語には改訂や抜本的な変更の要求が大量に浴びせられていますが、幸いなことに Java プラットフォームの基礎である JVM に対するそうした要求は比較的稀です。最近では、動的言語を扱いやすいように JVM を変更した方がよいというブログの世界での助言に応え、Sun のエンジニア (John Rose) が JVM の改訂版を提供しています。この JVM は最初 MLVM (multi-language virtual machine) と呼ばれましたが、今は (コードの中に非常に緊密にラップされているため) Da Vinci Machine と名前が変えられています。ここで重要なことは、JVM に関する変更の提案は Sun がJVM の最適化のために行った巨額の投資を無駄にするようなものであってはならない、ということです。JVM の機能強化の話題に関する議論から判断すると、助言を行っている人達は、その点を明確に念頭に置きながら詳細を検討しています。
-
Java Standard Edition のライブラリー。Java Standard Edition には、C++ の標準ライブラリーと比べて桁外れに大量の機能セットが同梱されており、その数はかつての Java 1.0 の頃の Java そのものよりも何倍も多いほどです。しかもこれは (次に取り上げる) Enterprise Edition のライブラリーのことを考慮もしていない場合の話です。表面的に見ると、これは Java 開発者にとって当然の勝利のように思えますが、少し考えてみると、いくつかの微妙な問題が現れてきます。まず、ともかくライブラリーの規模が膨大であるため、多くの Java 開発者は、これまで知らなかったパッケージのどこかに自分たちが作成しているコードと同じものが隠れていて実際には既に存在していることに気付かないことがあります。またライブラリーの年代により、ライブラリーそのものが API 設計の古さを露呈する場合もあります。そうしたライブラリーの多くは 90年代中期の絶頂期のものであり、その当時のクラスやライブラリーの設計は今日私達が行うような 2008年の設計とは大きく異なっています。また一部のライブラリーは、ファクトリーの例に見られるように、過剰な抽象化の犠牲となっています。ファクトリーはオブジェクト・ビルダーを作成し、オブジェクト・ビルダーはインターフェースのインスタンスを作成し、そのインスタンスは開発者にとって関心があるメソッドを実装する場合もあれば実装しない場合もあります。とはいえ、JSE ライブラリーにはさまざまな欠点があるものの、JSE は全体としては実質的にプラスであり、特に言語による機能強化 (例えば Groovy によって JDK に提供される拡張機能 (GDK と呼ばれます) など) と組み合わせた場合にはプラスです。
-
Java Enterprise Edition のライブラリー。EJB ほどコミュニティーから強い批判を浴びている技術はありません。そして幸いなことに、Java コミュニティーには EJB に代わる軽量の手段が生まれつつあり、軽量の代替手段が選択肢として適切な状況で適用できます。その好例は Spring と Hibernate です。しかし EJB をしばらく議論から外してみると、Java EE ライブラリーは驚くほど成功していることがわかります。サーブレットとサーブレット・コンテナーはインターネットにおいても企業のイントラネットにおいても Web アプリケーションのかなりの部分を占めており、JMS によってメッセージ指向のさまざまなミドルウェア・システムを利用することができ、またその他、JEE 環境におけるプレーヤーとして認知度は薄いものの、JNDI などはほとんど不満の声を受けずに役割を果たしています。JSE ライブラリーの場合と同様、JEE ライブラリーも API を再設計すれば非常に便利になるはずですが、JEE ライブラリーは全体としては Java 開発者の要求に応えています。最大の問題は多くの場合、そもそも JEE ライブラリーが実際に必要となるのはいつなのかを知ることです。しかしその問題はこの記事とは別に議論すべき話題です。
-
JAX (Java-API-for-XML) ライブラリー。JAX API は名目上 JEE ライブラリー・セットの一部ですが、JAX API の数と規模は他の JEE とはかけ離れた速さで増大しており、おそらく JEE のコンテキストとは別に検証するのが適切です。10 年近く前は XML をサポートすることへの要求は大きく広範でしたが、そうした要求はこの 10 年でいくらか和らいできており、他の技術スタック (最も顕著なものは .NET です) とどこでも容易に相互運用可能なことを約束する Web サービス (WS-*) やその膨大な仕様の領域では、特にそうした要求が弱まっています。JAX に関しては、Java には明らかに何らかの刷新が必要です。SAX や DOM、StAX などの API は、特に E4X や Ruby、あるいは Scala など XML をもっと柔軟にサポートできる言語と比較した場合、本格的なタスクを行うためにはずっと大量のコードを要求することが多いからです。この場合にも、XML に関する考え方は、初期の WS-* 実装での「XML を視界に入れない」から、RESTful な方法での「XML に触れ、それを整形式で意味のある URI としたい」へと大幅に変わってきています。この点からも JAX 全体のリファクタリングが必要なことがわかります。Java の世界の地図では、この領域は「非推奨 (とする必要がある)」とマーキングされています。
-
クライアント上の Java。Sun が最近ベータ・リリースした、刷新された「Java クライアント」システム (やや素っ気ない「Java SE 6 Update 10 Beta」という名前が付いています) では、Nimbus と呼ばれる Swing の新しいルック・アンド・フィールを含めて、クライアント・サイドの機能が強化されています。残念ながら、クライアント・サイドで Java がどの程度使われているかの判断は常に問題の多いものでした。その大きな原因は、この判断は長年の間、インターネット全体で使用されているアプレットを調べることを意味していたからであり、また Web によってホストされるアプリケーションの設計やアーキテクチャーで焦点とされたのはほとんどの場合 HTML の生成であり、現在「リッチ・クライアント」アプリケーションと呼ばれるものを生成することではなかったからです。採用率の点で見ると、Java はこの領域での主な競合である Flash には遠く及ばず、また Microsoft がこのゲームの新しいプレーヤーとして Silverlight を導入したことにより、状況は Java にとって一層困難になっています。Java がこの領域を完全に失う可能性は十分にあります。これは Java プラットフォームの「死」を意味するものではありませんが、問題を悪化させ、業界評論家や業界誌はこれを「Java の技術的な弱点を示す明白な例」として格好の話題にするでしょう。覚悟してください。
-
サーバー上の Java。これに関してはまったく防御の必要がありません。Java はサーバーの領域において地位を確立したプレーヤーであることは疑問の余地がなく、特に Windows® 以外のバックエンド・ファームに対する選択肢を検討する際にはそれが明らかです。LAMP スタックは (Ruby on Rails と同様) フロントエンドまたは特殊用途のための代替手段になりうるかもしれませんが、サーバーによる本格的な計算インフラを調べてみれば Java スタックが際立っています。実際、こうした Java の圧倒的優位こそ、そもそも Microsoft が WS-* 仕様を積極的に追求することになった原因なのです。その結果、WS-* 仕様によって、少なくとも .NET コードから Java インフラを呼び出すことができるようになり、また Java インフラと適切に動作できるようになりました。Microsoft がケンブリッジにある彼らの「Interoperability Lab」を含めて、もっと正式なレベルでの相互運用性に関して最近合意したことは、この点を裏付けています。
-
エコシステム。Java プラットフォームほどリッチで変化に富んだエコシステムを備えたプラットフォームは他になく、これはしばしば Java 開発者が (「どちらの Web フレームワークを使うべきなのか」という選択に) 少し心を痛める元になるとはいえ、Java のエコシステムが他の環境 (特に .NET の環境) にまで広がっているのは事実です。.NET プラットフォームにおける、ごく最近の技術進歩を考えてみてください。これらは Microsoft の外部と内部の両方から登場しており、ObjectBuilder (依存性注入フレームワーク)、ASP MVC (MVC ベースの Web フレームワーク)、NHibernate (Hibernate の一部)、NAnt と MSBuild (構文や概念が Ant に似た XML ベースのビルド・システム)、さらには Silverlight そのもの (ブラウザー内部で CLR をホストすることでクライアント・サイドでの実行が多様になる) といった具合です。多くの面で、.NET のエコシステムは現状で Java コミュニティーから約 5 年間遅れており、.NET 開発者達は Java 開発者が 5 年前に直面した同じ痛みに気付いていくはずです。Java もまだまだ .NET コミュニティーから学べる面はありますが (例えば通信 API が統一されていることによる便利さや明らかに軽量なワークフロ・エンジンの強力さなど)、それは 2 つの環境が共に相手から学び合っているという事実、そして .NET は Java を不要とするほどのものを備えていないという事実を裏付けているにすぎません。
もちろん、Java 開発者はこのリストに追加するための独自の項目を持っているはずです。しかしここまでの要点として、Java プラットフォームのことを「死んだ」、「死にかけている」、さらには「少し具合が悪い」と言うには、まだまだ Java プラットフォームには良いものが非常にたくさんあることが理解してもらえたのではないでしょうか。
まとめ
以上から、Java、Java のプラットフォーム、Java のエコシステム、Java の環境、そして Java の開発コミュニティーは、現在使用されている他のどのような言語またはプラットフォームと比べても、的外れの極みから同じように離れているか、あるいはもっと離れた位置にあるという単純な事実が残ります。たとえ非常に積極的に統計を駆使したとしても Java を最上位の地位から追い落とすことはできません。
しかも、もし Sun Microsystems が明日消滅したとしても、それによってプラットフォームがなくなることはありません。Java 開発者よ団結せよ！あなた達を束縛する鎖を恐れる必要はありません。そうした鎖は実際には存在しないことがわかったのです。Java プラットフォームがオープンソースであるおかげで (今や OpenJDK と呼ばれます)、そしてもちろん、他の、オープンソースによる Java の「クリーン・ルーム」実装 (Apache Harmony と Soy Latte はそのうちの 2 つにすぎません) のおかげで、たとえ Sun が崩壊し、地図から完全に消えてしまったとしても、IBM® や Apache、BEA、Oracle など他の会社が JVM やライブラリー、ツールを提供し続けることができ、全体としてのエコシステムをサポートすることができます。
いつの日か Java は死ぬのでしょうか。当然です。しかし私は、(COBOL の場合とまったく同じように) 現在 Java を使っているプログラマー人口の大多数よりも Java が長生きするのではないだろうかと強く信じています。さらには、今大学を卒業しようとしている第 2 世代の Java プログラマーよりも Java は長生きするかもしれません。
そうなると、確かに「恐竜」ということになりそうです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Ted Neward は、Neward & Associates の代表として、Java や .NET、XML サービスなどのプラットフォームに関するコンサルティング、助言、指導、講演を行っています。彼はワシントン州シアトルの近郊に在住です。 |
記事の評価
| 
