[home-page:放置中]
|
[最近のツッコミ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [全文検索] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ☆基本的に個人的なリンク集、偶に思い出したように文章を綴る日記。 ☆JAVA・Ruby・RELAX NGネタ中心です。O:原文,P:ポップアップ辞書,t:和訳 ☆[category]：カテゴリフィルタ画面 ☆[blogger]：Blogger出張所。徒然。 ☆[kuro]：個人的ライブラリ開発プロジェクト「Kuro Project」サイト。 ☆[kuro-pj]Kuro Project開発日誌。 ☆[ruby]Ruby学習日誌。 ☆[vox]：VOX出張所。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
再構成中..,。
ShaleやWebWork2は"DIコンテナ連結部分を外だし"しているので容易に他のDIコンテナとの
連携が可能。
JBoss Seam(on off)もJSF拡張。EJB3との連携が容易なのが特徴。EJB3仕様に依存するが、
特定の実装には依存しない。
プレゼンテーション・フレームワークは特定の実装(DIコンテナやEJB3実装)に依存しないモノが
普及すると思う。
->(on off)
あぼ〜ん。
あぼ〜ん。
あぼ〜ん。
あぼ〜ん。
あぼ〜ん。
その壱(on off) その弐(on off) その参(on off)
その四(on off) その伍(on off)
IDLや専用コンパイラ不要のORB。ORB自体、使ったことはありませんが、
このORBはORB自体の知識なしで使えそうです。
JavaとRubyでの実装が予定されています。JavaからRuby、RubyからJavaが簡単に
できる模様。ライセンスはMITライセンス。
#keisukenさん、リリースに向けて頑張ってください。陰ながら応援しています。
メモメモφ。
何か遠まわしに嫌味を言われているような--);
JBoss5.0のコアはおそらくMicroContainer2.0。
JBoss EJB3.0 Ｅｍｂｅｄｄableのコアも最終的にはMicroContainer2.0になるのでは？
#MicroContainer2.0がどんなモノか調べてみました。
MicroContainer2.0ではシンプルさは同じで主にDeployerまわりが実装されます。
デプロイメント仮想化フレームワークが用意され、各Deployerがこれを利用します。
JAR Deployer、Main Deploer、Classloading Deployerだけでなく他のDIコンテナを
プラグインするDIコンテナDeployerの実装も予定されています。Spring Deployerだけでなく
Seasar2 Deployerも実装されるかもしれません。
(JBoss4.x用にSpring Deployerがリリースされているので、それを見ればイメージし易いかも。)
これは他のDIコンテナで管理されているPOJOを容易にMicroContainerから利用できる
ようにするということだと思います。他のDIコンテナの管理するPOJOをそのままハイジャック
できるので"MicroContainer"にはシンプルな機能しかいらないと。
#力(勢い)のあるミドルウェア・ベンダはすごい...。
今まで単純なテキストファイルの読込にInputStreamReaderを使ってたけど、1.4からNewIOが
導入されていることだし、遅まきながらFileChannelを試してみる。
一括してバイト配列に読み込めるし、小規模ファイルの一括読込では問題なさそう。
あとはパフォーマンス、ファイルの一括読込で差はでる？
テキストファイルを一行ずつ処理したい場合はInputStreamReader -> BufferdReaderが簡単、
ファイル全体を読み込んでグリグリいじりたいような場合はFileChannel -> ByteBuffer、
というふうにIOと用途によって使いわける感じ。
#Channel APIはFileとSocketを同じAPIで透過的に扱えるのがミソなんだろうな、やっぱり。
#Socket周りには縁がないけど、そのうちいじってみよう。
A.InputStreamReaderでの読み込み
(BufferdReaderをかます必要は実はない...readLineメソッドでないのは改行コードがいるため)
StringBuffer sb = new StringBuffer();(1.5の場合、StringBuilder = new StringBuilder();)
//ファイルのオープン
FileInputStream fis = new FileInputStream(filePath);
InputStreamReader isr = new InputStreamReader(fis, encoding);
BufferedReader br = new BufferedReader(isr);
//読込及び格納
while ((s = br.read()) != -1) {
sb.append((char) s);
}
//ファイルのクローズ
br.close();
fis.close()
String str = sb.toString();
//ファイルのオープン
FileInputStream fis = new FileInputStream(filePath);
FileChannel channel = fis.getChannel();
ByteBuffer bbuf = ByteBuffer.allocate((int)channel.size());
//読込及び格納
channel.read(bbuf);
bbuf.clear();
byte[] bytes = new byte[bbuf.capacity()];
bbuf.get(bytes);
channel.close();
//ファイルのクローズ
fis.close();
String str = new String(bytes,encoding);
使ってみた感じ、StAXはSAXより柔軟性があり、SAX的な記述も可能。
SAXを齧ったことのある人なら、おそらく、すぐに習得可能。
SAXより癖がない気がするので、XMLパースの初学者にもStAXはおすすめ。
ハンドラを継承する等、煩雑な手順がいらないのも魅力。
サンプルはこちら(on off)。
JAX-WS(旧名JAX-RPC)も内部で全面的にStAXを使っているとのことなので
やっぱり時代はSAXよりStAXかも。
JAXB2、XFire、ActiveSOAP等最近のXML周りのフレームワークはStAXを採用する
のが多い。
現在、両者の処理速度に差はないように感じる。
Jakarta OROはPerl互換の正規表現書式を採用しているので、Ruby等のLLでもそのまま
通用する。Java標準正規表現APIとJakarta OROの採用する正規表現のサポート範囲に
ほとんど差はない。
但し、Jakarta OROは現在、メンテもされず放置中、安定しているからなのかは謎。
Java標準正規表現API はJava言語仕様の一部なのでメンテは期待できる。
#CometをJava標準正規表現API、 Jakarta OROを用いて開発している経験に基づく。
#正規表現は便利、文字列操作には必須。覚えておいて損はない。
#このブログの設定をいじっているときにこんな正規表現もありと気づいたりする。
メモメモφ。/* from Kohsuke Kawaguchi's Blog(on off) */
XMLStreamReaderでのバイナリデータの読込を可能にする等、StAXを小粋に拡張する
プロジェクト。Sunの人間が取り組んでいるので、StAXの次期仕様に反映されやすいかも。
メモメモφ。
この日記では自分の守備範囲(趣味も含む)や取り組んでいく分野(未だ模索中...)だけでなく
自分の興味のある分野、眼にとまった記事等についても積極的にブックマークしています。
LLまわりやC++まわり等は現在、完全に興味の対象です。
#カテゴリわけした時系列のブックマークは情報の新旧を即座に判断できるので便利。
#この日記にその都度整理してブックマークしておけば後々管理の手間はいりませんし。
#もちろん、時系列で管理する必要の無い情報は別にブックマーク中。
で、たまに自分が気になったことを自分の主観を交えて文章にしていると。
この日記で自分の仕事について触れる気はありません。
"Memory allocation profiling"のことだと思いますが2.0での実装が予定されています(on off)。
2.0はここに書かれているスケジュールのままなら1月か2月に登場します。
dotTrace Profiler EAP はこちら。(on off)
#"dotTrace Profiler"が褒められていたので、JetBrainsびいきとしては嬉しくなって
#調べてみるとITNのフォーラムにありました^^)v。
->(on off)
あぼ〜ん。
あぼ〜ん。
メモメモφ。
"プレゼンテーションテンプレート"と"プレゼンテーションロジック"から出力用スクリプトを生成する
一種のコンパイラ。/* from TECHMemo(on off) */
メモメモφ。
IDEAを持たない人のプラグインの開発への参加を促すために、コンパイルは
できるようにしてみましたくらいの印象。。/* from TSS(on off) */
#marsのメモ(on off) へのツッコミ
#JetBrainsの本拠地のあるチェコ共和国(Czech Republic)は日本や欧米より物価が安い(日本の半分くらい？)
#と思うので、資金繰りについては大丈夫だと思います。
#JetBrainsのマーケティング担当の方は市場調査に励んでいらっしゃるようですが、
#JetBrains自体が日食の影響で"財政的に苦しい"ということはおそらくないです。
#日食の影響のない.Net周りに進出しているし、開発環境以外の製品にも進出していますよね。
IDEA5.0に添付されているMavenide IDEA(on off)、次期Verの登場は何時？
開発が停滞ぎみなのはMaven2待ちをしていたための模様。
Demetra(IDEA次期Verコードネーム)ではビルド関連機能も大幅に強化されるし。
SubversionまわりはIDEA4.xで外部製プラグインが添付され、IDEA5.0では内製された。
(外部製プラグインでは中々眼が肥えたIDEAユーザの満足を得られないから...
痒いところまで手が届かないと。)
Maveide(on off)との違いは何？Maven2対応だけ？/* from Heretic Programmer(on off) */
4W1Hについてページには何の記述もない。
MavenideのMaven2対応は現在、NetBeans用が先行中(on off)(on off)。/* to TSS(on off) */
他のIDE用も近々でてくるはず。Mavenideのサイトを見た感じではIDEに依存しない部分は
共通モジュールとして切り出されているっぽいので。
MavenideはNetBeans用が活発、現在0.9。日食用は0.4。
何故、M2Eclipseがこのタイミングでcodehaus上にでてくるのか、謎。
Mavenide Eclipse開発者の茶目っ気？codehausでMaven支援プロジェクトが立ち上がり、
Mavenideが合流する前触れ？(codehausがmaven.orgを取得している...)
同じ目的のIDE用プラグインを作るのなら、リソースを分散するよりは統合したほうがいいのでは、
OSSなんだし、とこんなところに書いてみる。
[追記:2006/01/06]
リンクをhttp://m2eclipse.codehaus.org/からhttp://maven.apache.org/eclipse-plugin.html
に変更。Apache Mavenのページに4W1Hがあった...。
何故Apache Mavenのページではなく、codehaus上に頒布ページを持つのか、それはM2Eclipseが
Apache Mavenのプロジェクトではないから。Apache Mavenのサイト上にあるのはよく読むと紹介ページ、
開発元企業はM2Eclipseの日食のプロジェクト入りを狙っているらしい。
(ライセンスはASL2.0、日食入りすると変更するとのこと。)
M2EClipseの開発元企業が売名行為のため、Mavenideにぶつけてきた可能性がかなり濃厚。
それ以外に敢えてcodehaus上に頒布ページを開設する理由は考えにくい。
現在、M2Eclipseではコントリビュータに契約書を要求している。
メモメモφ。/* from オレンジニュース */
メモメモφ。/* from wildcatsの日記 */
メモメモφ。
(X)HTML仕様への準拠に関する指摘。
メモメモφ。/* from Heretic Programmer(on off) */
#MXParser(on off)はXPP(on off)準拠のXML Pullパーサ。
Servlet APIのような低レベルAPIにアノテーションを導入する意味は...。
互換性維持のために"web.xml"は残り続けるだろうし。
初回起動時にXMLファイルから設定を読み込むのと、実行時に毎回アノテーションを
参照するのとどっちがいいのかは微妙。
The new features in Servlet 2.5: worthwhile? o(on off)p(on off)
New features added to Servlet 2.5 o(on off)p(on off)
Servlet 2.5, the bad, the ugly, and the pointless(on off)/* from wildcatsの日記 */
あぼ〜ん。
その壱(on off) その弐(on off) その参(on off) その四(on off)
その伍(on off) その六(on off) その七(on off) その八(on off)
その九(on off) その壱拾(on off) その壱拾壱(on off) その壱拾弐(on off)
メモメモφ。
メモメモφ。/* from プログラマー日記(on off) */
#Ruby2.0(Rite)に採用内定(?)のYARV(VM)があるし、需要があるのかは疑問。
#モノが公開されていないので、何ともいえない...。
メモメモφ。
あぼ〜ん。
スレッドの同期用処理があるかないかくらいの違いなんだけど、処理速度に案外差がでる。
StringBufferを内部で多用する文字列処理系のライブラリではStringBuilder or 自作の非
同期似非StringBufferに差し替えるだけで処理速度が改善される。
String#+、String#concat、StringBuffer#append、StringBuilder#appendは呼出回数
が多いほど、トータルの処理速度に差が出る。(参考記事:文字列連結のスピード(on off))
複数スレッドから参照している場合のみStringBuffer、それ以外はStringBuilder。
あと、文字列リテラルをメソッドに埋め込んでいるのをよく見かけるけど、Static変数にするのが定石。
処理速度的にメリットはないけど、メンテナンス性や可読性が向上するので。
メソッドに埋め込まれた文字列リテラルはメソッド呼出時に毎回オブジェクトとして生成されるのに対して、
Static変数にした文字列リテラルはオブジェクトとして生成されない。(厳密にいうと、Static変数にした
文字列リテラルは属するクラスがメモリにロードされるときに一度だけオブジェクトとして生成される。)
文字列リテラルが埋め込まれたメソッドも文字列リテラルを埋め込まない場合との間に呼出回数が
多いほど、差が出る。
#正に「塵も積もれば、山になる」。処理速度の改善は小さなことからコツコツと。
#javanさんのツッコミへの反応
#Javaおぼえがき(on off)に拠れば
#「String str = "文字列リテラル";」は「String str = new String("文字列リテラル").intern();」と
#同じ処理。メソッドに組み込まれたリテラル文時列は一度"オブジェクトとして生成"された後、(String#intern
#を介して?)VMの持つ文字列リテラルプールにアクセスし、メソッドに組み込まれた
#リテラル文時列と等価な文字列が文字列リテラルプール内にあればその参照を返し、なければ
#自分自身を文字列リテラルプールに登録し、その参照を返すことになります。
#Javaコンパイラが優秀でバイトコード生成時に"メソッドに組み込んだ文字列リテラル"をStatic変数とほぼ同じ
#扱いとなるように変換するのか...。
#誤認識を訂正できたので、javanさんのツッコミに感謝。
#->(on off)
メモメモφ。/* from wildcatsの日記 */
あぼ〜ん
# Kazzz [> 2.0はここに書かれているスケジュールのままなら1月か2月に登場します。 "Memory allocation..]