[home-page:放置中]
|
[最近のツッコミ] |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [全文検索] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ☆基本的に個人的なリンク集、偶に思い出したように文章を綴る日記。 ☆JAVA・Ruby・RELAX NGネタ中心です。O:原文,P:ポップアップ辞書,t:和訳 ☆[category]：カテゴリフィルタ画面 ☆[blogger]：Blogger出張所。徒然。 ☆[kuro]：個人的ライブラリ開発プロジェクト「Kuro Project」サイト。 ☆[kuro-pj]Kuro Project開発日誌。 ☆[ruby]Ruby学習日誌。 ☆[vox]：VOX出張所。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
焼き直し、括目するような機能はない。DOMパーサの改良、パフォーマンスの改善。
/* from 誣告の...(on off) */
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
メモメモφ。
後半はGeronimoかぶれの戯言、脈絡がありませんな。
"IBMがGeronimoを買収した"という一文が作者の勘違いぶりを如実に物語ってますな。
->著者が原文を修正してるので注意。
APサーバはサービスの集合体であり、EJBもAPサーバの提供するサービスの一つ。
APサーバの真価はその提供するサービスにこそあり、サービスを簡単に切り離せる構造に
ある訳ではない。いくら構造が先進的でも提供されるサービスが古いようなAPサーバは魅力的
とはいえない。その意味で現在、J2EE1.4の実装の最終段階でJavaEE5実装の端緒にも
辿り着いていないGeronimoは魅力的とはいえない。
サービスを"仕様どおりに"実装しているGeronimoとサービスを"仕様策定に開発者が携わりながら"
実装しているJBoss、どちらが凄いかは一目瞭然。
GeronimoがDIコンテナベースであることに著者は価値を見出しているようだが、JBossも"POJOサーバ"
を開発中、5.0はPOJOサーバベースになると思われる。
EJB3 PersistenceAPIはO/RマッパとEJBコンテナ間で共通のAPIを利用できるように策定
されたモノであり、EJBコンテナがO/Rマッパをそのエンジンとして利用できるのは副次的産物。
JBoss Inc.はHibernateにEJB3 PersistenceAPIを実装中であり、HibernateとEJB3コンテナ間
での同一インターフェースによるプログラミングを実現しようとしている。
(おそらく、OracleもTopLinkにEJB3 PersistenceAPIを実装し、EJBコンテナのエンジンにする)
OracleがEJB3 Persistence APIのリファレンス実装をGlassfishに提供するらしいので、
多くの商用サーバはこの実装をEJB3コンテナに利用すると予想できる。
但し、GeronimoはCDDLで提供されるこの実装を利用することはできない。つまり、
GeronimoがEJB3コンテナ実装に利用できるO/Rマッパは現状では存在しないのだ。
[追記:2005/07/17]
JBossとEJB3の間に関連性がないと思っている知ったかぶりすぎる君がいるようなので
追記しておきます。
EJB3の誕生はRod Jhonsonによる著作２部作でのEJBへの苦言とJBoss Incによる"Beyond J2EE"が
出発点となっています。
当時、JBoss IncはSunとのライセンス交渉を行っていましたが、そのライセンス料金等で交渉は
難航していました。
この交渉中にJBoss IncはEJB3のCMPの雛形となるORマッパHibernateの開発者"Gavin King"
を開発メンバーとして迎え、CMPをHibernateを基盤として拡張・発展させていく方向性へ
舵をきり、J2EE1.4仕様を越えていく方向性を明確に打ち出します。
J2EEライセンス交渉は水面下で行われ、その数ヵ月後にJBoss IncはJ2EE1.4のライセンシーとなり、
その直後、EJB3仕様がJSRとしてアナウンスされ、EJB3エキスパートグループが誕生します。この
グループにはJBoss IncからGavin Kingが参加することになり、発表された概要は既存のEJBとは
似て非なるモノだったのでこれに反発した幾人かのEJB仕様を牽引してきたメンバは去りました。
この急展直下での方向転換は"JBoss IncとSun間のライセンス交渉の間に交わされた議論"が
大きな引き金となったと推測しています。
現にEJB3仕様はJBoss Incが"Beyond J2EE"として打ち出したモノを踏襲しています。
最後に"この文章"のもととなった発言では「サービスであるEJB3と基盤であるGeronimoを比較し、
EJB3を否定している」ので、この文章で「JBossとJBossの設計思想から生まれたEJB3を
持ち上げる」のは"あながち的外れではない"と思っていることを付け加えておきます。
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from オレンジニュース */
Beehiveの失敗の穴埋め...。/* from オレンジニュース */
メモメモφ。Java SE7.0(Dolphin)でメソッド参照が導入されるかも。
関数ポインタではなく関数参照というのがミソですな、きっと。
/* to 星暁雄×Java(on off) */
あぼ〜ん。
Ruby/ActiveRecordのJava版。/* from TECHMemo(on off) through marsのメモ(on off) */
メモメモφ。/* from オレンジニュース */
製造元が企業として存在するのは商用ベースでは大きな強み。
JBoss IncはミドルウェアベンダでSIではないし...。LGPL->ASLは×、ASL->LGPLは○だし。
メモメモφ。
メモメモφ。メルマガ記事をWebで公開。/* from オレンジニュース */
メモメモφ。Rod Jhonsonの"アンチEJB"は〜2.xに対するモノでEJB3を含んではいない。
だいたいRod Jhonsonが"J2EE Without EJB"を書いたのは3.0仕様登場前なんだから当たり前。
このタイトルはおかしい。携帯電話用Javaの場合、当初から共通部分の上に独自拡張を
各キャリアが行っていたし、今も行っている。昔から指摘されていた問題であり、現在
そこにある危機ではない。
携帯電話の機能追加に併せて共通APIとして拡張していくよう方向に向かうと思う。
メモメモφ。
⇒ REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy) (on off)
メモメモφ。/* from オレンジニュース */
W3C XML Schemaを本音ではみんなが嫌い...やはり。
[トリビア]元記事のブログの著者、村田真氏はRELAX NGの仕様策定者の一人。
村田氏のRELAXとJamas Clark氏のTREXの融合でRELAX NGが生まれた。
RELAX NGの論理的基盤である生垣オートマトン(on off)はXPath、XQueryの論理的基盤となっている。
ちなみにW3C XML Schamaに論理的基盤はない。
あぼ〜ん。
1.抱負・意気込み
グラナダ・エスパダはプレーヤが指揮官(傍観者)として仮想世界の複数の住人を導くという
オンラインRPGとしては一風変わったスタイルのゲームなのでβテスターとして参加すること
を非常に楽しみにしています。
オンラインゲームは常に進化し続け、ユーザに新たな刺激を提供し続けることが求められて
いると思うので、βテスターとしてベータテスト期間中に少しでもグラナダ・エスパダのさらなる
進化に貢献できればと考えています。
2.当局への意見・要望
ベータテストはバグ出しがその主な役割の一つだと思います。BugzillaやJIRAのような
WEBベースのバグ管理システムをベータテスタ向けに公開されてはいかがでしょうか？
そうすることで同一バグの重複報告等がなくなり、テスタからのバグ・要望報告が
管理しやすくなると思います。
でてます。当初予定していた機能の幾つか(XMLまわり、GUIビルダまわり等)は
次期バージョン以降への持越しが確定。
メモメモφ。
メモメモφ。
メモメモφ。
VMのクリーンルーム実装、IBMでも"ちとキツイ"のでは。/* from Cafe Babe(on off) to TSS(on off) */
Sunからライセンシーに提供されているコードは一切使えないし...
SunがJavaSEの実装をオープンソース化したら何の意味もなくなるし...。
一年半間隔でのメジャーリリースに遅れずに対応するのはまず無理だし...。
Sunより上手に"Bug Parade"を管理できるとも思えないし...。
Hotspotコンパイラに替わるVM統合型のコンパイラをゼロから短期間で開発
できるとも思えない。
"実装はオープンソース、仕様はJCP"が最終的な落としどころとは思うけど...。
オープンソースという言葉が独り歩きして、さも最善の選択肢であるかのように
語られすぎ。
ビジネス的観点から視ると、SunのJavaSE実装の独自ライセンス以外での
オープンソース化はありえない。何故ならVMの実装にSunの特許技術が
含まれているから。
Sunが現在に至るまでJavaに投じた・投じている人的リソース及び金銭を
考慮する必要もあると思う。
現在でもJavaVMの開発に一番労力を割いているのはSunだと思うので。
NetscapeがブラウザをMozillaとしてオープンソース化した後に起こったことを
忘れてはいないだろうか？Mozillaが再始動するために要した空白の期間を。
Sunがリソースを引きあげても同じことにはならないと言い切れるのだろうか？
メモメモφ。
メモメモφ。