IBMからEclipseベースの新しいクライアント・フレームワーク 52
ストーリー by Oliver
つめこみキッチン・シンク 部門より
つめこみキッチン・シンク 部門より
tnk 曰く、 "IT Proの報道から。米IBMは，新たなリッチ・クライアント技術「IBM Workplace Client Technology」を発表した。このクライアントは，オープンソースのEclipseフレームワークの上に構築してあり，Lotus/IBMのデスクトップ・ソフトウエア製品を多種多様なクライアント環境から利用するためのものである。
このニュースではピンとこないかもしれないが，まずはLotusphere 2004の講演資料(PDF)の9枚目の画像を見て欲しい。つまりEclipseプラットフォームの上に，プラグインとしてメーラーやスケジューラーなどの「グループウェア」を構築してしまったのである。Eclipseといえば開発ツールという固定観念があった私は目から鱗が落ちたおもいである。
考えてみれば，Eclipseプラットフォームには，JavaによるGUIソフトウェアのためのSWTやヘルプシステム，更新システムなど，アプリケーションの構築のために必要な機能が一通りそろっている。これを開発ツールの作成にしか使わないのはもったいないのは確かだ。これからは，このような「Eclipseをベースとした開発環境以外のアプリケーション」がたくさん出てくるだろう。"
今でも用途は色々 (スコア:4, 参考になる)
私も開発の業務とは無関係に、Eclipse上でExcelやWordのファイルを開いたり、Webブラウジングしたりしてます（特にプラグインを追加しなくても可能です）。これらの画面は、Eclipseのエディタと同様、タブ形式で表示されるのでなかなか新鮮です。一度お試しあれ。
中でも重宝するのは、Navigator View の Working Set ですね。「xxx作業をする時はxxxのファイルしか見えなくていい」という時に便利です。ディレクトリ単位でもファイル単位でも可視不可視の設定が出来ます。
RCP (スコア:2, 参考になる)
http://www.eclipsepowered.org/rcp.html
内容はともかくSunの提供するAPIを離れたという意味ではおもしろいかと。
部門名も誤解してると思う (スコア:1, 参考になる)
今にemacsみたく (スコア:1)
GPL を広めた Emacs に対し、CPL を広めた Eclipse
と言われるようになるカモ。
* よく「重い」と言われる。
* バイトコードにコンパイルして実行する。
* ガベージコレクションする。
とても他人とは思えません。
使うかといわれればびみょー (スコア:1, すばらしい洞察)
Re:使うかといわれればびみょー (スコア:1)
Java開発環境では、結構Eclipse vs JDEE(Java Development
Environment for Emacs)の使い勝手対決があったりするわけですが、
もしデスクトップ環境としてのEclipseが盛隆になってきたらば、
生活環境対決まで起こるわけですね。
CUI系のemacsとGUI系のEclipseという住み分けになっていくのかも
知れませんが。
# Domino Userから若しかするとEclipseの扱い方を質問される日が
# くるかもしれないなんて、考えもしなかったなぁ
Re:使うかといわれればびみょー (スコア:1)
Re:使うかといわれればびみょー (スコア:2, 参考になる)
Re:使うかといわれればびみょー (スコア:0)
#Eclipse エディタ部分は使いにくいよ
# アルバイト先でEclipse 使用を要求されてるのでAC
Re:使うかといわれればびみょー (スコア:1)
まだEclipseは本格的に使ったことが無い
(てゆーか仕事の主戦場はEclipseが無い言語だし、趣味じゃ統合環境なんて要らないLightweightLanguageだし)
んですが、使いにくいであろうことは容易に想像できます。
だって、自分が好きなエディタ(の機能)が100%用意されてる、という保証が全然ないのは、
ある意味で原理的に当然だもん(^^;
そのへんのごちゃごちゃを考えると、
結局理想をいえば、自分の好みのエディタが、「そのまま」Eclipseで動けばいいんですよね。
＃これがほんとの統合環境。つまり全ての機能を自分が用意するんじゃなく、全ての「既存」機能を統合する能力があるソフト(^^;
で、そうすると、IDEとエディタの間で、どんな命令をどうやりとりすればいいのか？っていう部分を
たぶん予めそれなりに決めておかないとならない、んじゃないかと思います。
そういやGDBには最近、UnixPipeベースじゃなく独特なプロトコル(?)でもって
クライアントのエディタと情報をやりとりする枠組み、ってのがあるんでしたよね。名称失念したけど。
あれと似たようなこと(?)を、IDEがエディタに対して行なえば、いいのじゃないか？と夢想します。
なお、もっと広範に言えば、そういう話は
OSがそういう枠組みを用意しててくれたらいいのにな、という話に行き着くと思います。
それも、デバッガとかIDEに限らず、出来るだけ広いかたちで。
で、MSがそれをやる動機があるかってーと微妙でしょうね。
接続性がよくなればなるほど、囲いこみはやりにくくなるんだから。
ん？ってことは逆にいえば、接続性の確保は、我らがOpenSourceの仕事なのかも(^^;
我らの立場だと逆に、特定の環境へ囲い込むことは、デメリットは有ってもメリットは無いわけだから、
接続性については我々のほうが真剣に考え易い位置にいるんじゃないかな？
＃それの行き着く先が OLE/COM/.NET/Mono なのかどうかは、ノーコメントなのでG7
＃もちょっと素朴なレベルで、そういうこと[*]をやりたいなあ。
＃[*]ぶっちゃけ言えば、プログラム間の実行時の対話。
＃なお素朴なPipeは、Pipeの接続と子の起動終了とを独立させられないので、ここでは不適格です。
Re:使うかといわれればびみょー (スコア:0)
M$に潰されるわけですよ。
あーでも、元々無料か
Re:使うかといわれればびみょー (スコア:0)
Re:使うかといわれればびみょー (スコア:1)
# んなわけないか．．．
旅に出ます．(バグを)探さないで下さい．
Re:使うかといわれればびみょー (スコア:0)
TeX のソースはテキストファイルだから、必要に応じて様々なツールを援用できるけど、ワープロは (基本的に) 独自ファイルだから、ワープロソフトに機能をつめこんでおく必要がありますね。
Re:使うかといわれればびみょー (スコア:1)
今回の話と関係あるかどうかは微妙ですが、一応。
「ファイル(形式)が」独自だからといって、「1つの」アプリ(ワープロ)に機能を詰め込む必要は、
あるとは限りません。
だって、複数のアプリ(やライブラリやプラグイン)が同一のファイル形式をサポートしてれば済むんだもん。
しょせんはUnixのテキスト文化も、「プレーンテキスト」という特定の(^^;フォーマットに
全てのプログラムが特化してる、というだけのことなんだよね。
まあ、他のフォーマットの更に基盤となるという「メタフォーマット」的な機能が
期待しやすいという意味では、テキストファイルは便利だけど。
＃テキストの背中にXMLを乗せてーー、XMLの背中にSVGを乗せてーー、の3階層とか。
閑話休題。ファイル形式の「サポート」ってのは、結局は、
ある機能(アプリとかライブラリとか)が使ってる「ファイル解釈器」が
その形式のための解釈器であれば、それでいいんですよね。
解釈器は、テキストファイルならばgets()だし(藁)、XMLならDOMだかSAXだか(の実装)だろうし、と。
で、解釈器だと考えると、フォーマットは個々の機能(アプリとか)に専用化するよりも、
むしろ階層を細かくわけて、個々の階層は出来るだけ難しくない解釈だけを行なうようにして、
そして多くの機能が1つの解釈器(や解釈器グループ)を共有し使いまわす、というかたちにするほうが
便利そうです。少なくともプログラムの生産性という意味では。
＃XML解釈器とS式解釈器は手元に置いておいたほうがいい…のかな…なのでG7
----
余談：
WindowsのExplorerで、「ファイル内文字列の検索」機能を、上記の発想で実装しててくれたらよかったのにな。
解釈器は個々のアプリ(?)が持ってる、と捉えて、
各種のデータフォーマットの中身にご所望の文字列があるかどうかを、そのアプリに探索「させる」、ってこと。
PNGを見るツールが、PNGの中の文字列をOCR(?)で拾い上げて検索する、という機能を提供してくれるとかさ。
遅いだろうけど、速度はここでは問題ではないです。
拡張子連動設定に「Run」とかだけじゃなく「FindString」っていうアクションも存在してくれれば
よかったのかも。
非開発用プラグインという意味では... (スコア:1)
なんせもとが無料だし、プラグインの類も無償公開しているものが多いですから、それなりのコストパフォーマンスを実現しとかないと競争力つかないんじゃないのかな。
Re:非開発用プラグインという意味では... (スコア:0)
Re:非開発用プラグインという意味では... (スコア:0)
Slashdotedされてる？
＃会社から見て自分のアカウントがフィルタされたのかと
＃あせったのでAC（ｗ
1980年に戻れるか？ (スコア:1)
って開発環境と実行環境が一体化してたんじゃなかったで
しょうか。今回のEclipseは、あれ以上の環境になってるのか
な。
Re:1980年に戻れるか？ (スコア:1)
開発環境を含む仮想計算機で開発と実行を
行うようになっています．
Squeakなどでは開発中断時の状態が
仮想計算機のイメージで保存されます．
Eclipseが仮想計算機として動作するようになれば，
それ以上と言えそうです．
# その必要があるのかは不明です．
ちょっと辛口（？）になってしまいましたが，
そういうコメントがACばっかりなのも
どうかと思うので，IDでいきます．
旅に出ます．(バグを)探さないで下さい．
Re:1980年に戻れるか？ (スコア:2, 興味深い)
Smalltalk(Squeak)とは、位置付けというか用途が微妙に違うかも知れませんが、
EclipseもJVMというVM(^^;に乗って動いてるわけですよね。
違いはむしろ、Imageという巨大なファイル(素朴なOODBとも言える？？)を使う方式かどうか、
という点でしょうね。
あんまり引き合いに出す意味は無いですが、そういやDelphiは、
単体Exeも作成できますし、
一方で、プラグインやComponent属性エディタというかたちで実装すれば、
自作Object(Class)をIDEに統合されたかたちで使うことも出来ます。
＃ちなみにVM方式じゃないです。CPU Nativeで動きますんで。
>それ以上と言えそうです．
ちなみにどのへんが「以上」でしょうか？
今時っぽい使い勝手との親和性、という点でしょうか？
言語の筋という意味ではSmalltalkのほうが上と思っています。
＃尤もEclipse(つまりJava)でも、JVMで動くJava以外の言語を使えば、
＃言語の悩みはめでたく解決するとも言えますが、それはSqueakでも同じこと。
まあ、細かい差異はさておき(^^、
「充分にカスタマイズ可能(たとえばプラグインを受け入れる体制が有るとか)なアプリは、OSと見分けがつかない」
っていうか、
「最上級のカスタマイズ性は、言語処理系(やVM)を持つことで得られる」
っていうか、
そういう感じではありますね。
Re:1980年に戻れるか？ (スコア:1)
OSと見分けがつかないか否かは別にして、「Smalltalkの方は、プラグインの開発という意識もなく、
シームレスにシステムを変更してるけど、Eclipsはあくまで目的用にプラグインを開発するという
意識を持ってないといけない。｣
そんな理解でよろしいでしょうか。>> 識者の皆様、
Re:1980年に戻れるか？ (スコア:1)
ネットを通じてアップデートできるところとか、ユーザインターフェースの一貫性を持たせて、APIもそれにあわせて作りやすくなっているあたり、この実装には価値があると思います。
技術的にはEclipseがJavaで作られている必要性は皆無ですし、どうせなら軽く作れるスクリプト言語でEclipseを実装してほしかったと私は思ってますが。とにかくきっちりと実装しているのは立派。
（Eclipseの開発環境のほうも大したもの。これはリソース管理とかそれにまつわるビルド実行の処理のフレームワークが核となる機能なのですが、作り上げるのは相当大変だったはず。こういうフレームワークを決めるのは本当に難しいことなので）
Re:1980年に戻れるか？ (スコア:2, 参考になる)
うーん。なんか意外というか、信じ難いというか…(^^;
>ネットを通じてアップデートできるところとか、
実装済みかという意味ではアレですが、
まあSmalltalkでも同じことは(やれば)出来るでしょうね。
>ユーザインターフェースの一貫性を持たせて、APIもそれにあわせて作りやすくなっているあたり、
うーん。まだ知らないんですが、DragDropが綺麗に再構築されてるといいなぁと祈っています。
WinとかJava(AWT/Swing)のDragDrop周りのAPIって、七面倒くさいじゃないですか。
それがSqueak(Morphic)だと、あまりにも簡単に解決してる(らしい)です。
味噌は、「マウスポインタもWidgetである」と「WidgetがWidgetからWidgetに(親を)乗り換えることが出来る」
という只二点の特長を用意したこと。ただそれだけ。
それによりDragDropは、「つままれたWidgetが、元居た処から、マウスポインタに、乗り換える」
という至極シンプルなモデルになっちゃった。
乗り換えに不自由するWidget体系や、マウスポインタを特別扱いする(Widget扱いしない)体系とかって、
カッタルイし、考えてみれば不自然(恣意的)ですよね…
>どうせなら軽く作れるスクリプト言語でEclipseを実装してほしかったと
BSFなりなんなり経由で、任意の言語でカスタマイズ(やプラグイン作り)をする、ってのは
どうなんでしょうか？(^^;
Re:1980年に戻れるか？ (スコア:1)
> (やプラグイン作り)をする、ってのは どうなんでしょうか？
局所的にはそれは可能なのですが、とはいえ、技術基盤がどの言語で書かれているかっていうのは、それでも重要だと思ってます。その言語を使って拡張するっていうのが基本になるでしょう。EclipseのUIを別の言語で拡張することはどう考えても非現実的。
私は Ruby が好きなので、FreeRIDE [rubyide.org]が Eclipse に追いつき追い越してくれれば、こんなに嬉しいことは無いのですけども。（これにかかる労力はどのくらいになるのだろう・・・ 考えただけでも恐ろしい）
Re:1980年に戻れるか？ (スコア:1)
>その言語を使って拡張するっていうのが基本になるでしょう。
>EclipseのUIを別の言語で拡張することはどう考えても非現実的。
うーん。どうなんでしょう？
Groovy [kakutani.com]みたいなやり方も有るかなと思います。
というのは、これ読んだ範囲での推測ですが(^^;、どうやらこのGroovyって言語、
表向きはモダンな(=Rubyとかにも通じる(笑))スクリプト言語なんですが、
中身(言語仕様、オブジェクトモデル、などなど)は微妙にJava側に日和っているわけで、
いわばJavaとモダンScript言語の間を取った感じの代物かと。
そんなわけでRuby好きから見れば物足りない面も在り得そうですが、
Rubyみたいな言語のメリットの6割くらいは、こいつでも享受出来るんじゃないかと。
で、日和ったことによる恩恵(笑)として、JavaのClassをそのまま作れるらしいっていうのがあります。
となると、既存の普通のJava環境との相性は、相当楽に取れるんじゃないかと。
言語の混合ってどんなやり方でも(RubyとC拡張ライブラリの場合もそうですが)、
「こちらからCallする」のは簡単なんですが、
逆に「あちらからCallされる」やり方に色々制約が多くなることが有ります。
＃「非現実的」になる理由の多くが、ここに由来するような気がしています。Callbackは難しい…
で、Classファイルみたいなプリミティブな仕組みをそのまま流用すると、
恐らくそういう問題で悩む場面は、減るんじゃないかと…
>私は Ruby が好きなので、FreeRIDE [rubyide.org]が Eclipse に追いつき追い越してくれれば、こんなに嬉しいことは無いのですけども。
あはは。俺もRubyスキーなので、そういう意味では同意します。
ただ、IDEを作る労力と、その上で好きな言語を活躍させるための労力とは、
直交というか、技術的障壁なしに自在に相互乗り入れ可能
であって欲しいとも思います。
あと、Rubyみたいなレベルの言語になると、IDEってそんなに必要か？とも思ったりする(^^;
まあGUI構築用のRADツールとかは欲しいけど。
＃VIMの単語補完機能で充分生きていけてる昨今なのでG7
＃アプリやライブラリを作るときには、
＃俺は敢えてScriptファイルを分割せず1本でやり切るようにしています。
＃そのほうが便利なことが多いんで。単語補完の問題もそれです。
Re:1980年に戻れるか？ (スコア:1)
どういう統合の仕方かにもよると思うんですけど、同じVM上でJavaで作ったクラスをRubyで継承して・・・なんていうアプローチは、これは無理だと思いますよ。命名規則も違うし。文字列やストリーム系あたりの互換性を保つのも難しそうですし。使いにくいだけではないかなと。
> あと、Rubyみたいなレベルの言語になると、
> IDEってそんなに必要か？とも思ったりする
スクリプト言語でのプログラミングはIDEは要らないですね。（Javaとかと違って）言うまでもなくその方が望ましい。
GUIとか何か別のモノとプログラミングが連携するっていうときに、拡張可能なIDEというのは、あると便利なのかなとは思います。
Re:1980年に戻れるか？ (スコア:1)
>すよ。命名規則も違うし。文字列やストリーム系あたりの互換性を保つのも難しそうですし。使いにくいだけではないかなと。
Rubyそのものを馬鹿正直に持っていくのは無理でしょうね。
オブジェクトやクラスのアーキテクチャが違うってのもありますし、
ライブラリも違う(Rubyって変にUnixべったりだし)んで…
なので、Ruby「似」という方向性になるんだと思います。
で、Groovyは、Ruby似であると同時に、より一層Javaに日和ってるわけで。
＃4991なのでG7
Re:1980年に戻れるか？ (スコア:1)
>
>ちなみにどのへんが「以上」でしょうか？
>今時っぽい使い勝手との親和性、という点でしょうか？
開発環境と実行環境の結合の度合い，とでも
言いましょうか．
「以上」にはEclipseがSqueakに追いついた，
のような意味をもたせたつもりです．
決してEclipseの方が上だ，とまでは
言うつもりはありません．
> 言語の筋という意味ではSmalltalkのほうが上と思っています。
同じくです．
最近，心ときめいた他の言語はRubyくらいですかな．
旅に出ます．(バグを)探さないで下さい．
Re:1980年に戻れるか？ (スコア:0)
ちょっとまて、そんなことはすでに (スコア:1)
そんなことはすでにNetbeansがやってることじゃないか。
NetbeansはいつもIDEとPlatformを出してるし、Platformというのは
結局IDEのベース部分をアプリケーション開発用に公開したものだよね。
Eclipseがそれをやったってだけでそれほどすごいことなのか？
-- Netbeansが好きなのでＩＤ
Re:ちょっとまて、そんなことはすでに (スコア:1)
これが進むと、プログラマに求められるものも違ってくるかもしれないですね。作者の意図を見抜いてAPIの仕様を読む能力とか。適切な土台が構築されると、プログラマの生産性は確かにかなり上がってくると思います。ただし、高度なフレームワークを扱うことになるので、それはどうしても難しいものになるでしょうし、やはり経験が重要になってくるのかなと。（プログラミングが難しい仕事であることには変わりはないと思います）
Re:ちょっとまて、そんなことはすでに (スコア:1)
ある意味それに近い状況で、某社の独自フレームワークの中で生活してる昨今なんですが、
「意図を見抜いて」だけだと辛いですよー。
メタ機能(リフレクションとか)が結構有るんで、
中で何やってるかは調べ易いんだけど、
中で「なぜ」やってるかは結局判らないってことが多い。
メソッドの名前などから推測がつかないわけでもないですが、自ずと限界があるし、当然予想がはずれることもある。
やはり幾らリフレクションが有っても、Undocumentedは限界が有りますね。Documentが書かれてないとなあ。
＃こっちのチームの連中も内部Documentを全然書かない(それで苦しめられる)んでG7 (T_T)
とはいえ、予測もそれなりに出来るほうが良いので、
どっちも半々くらいってのが一番いいのかも。
Re:ちょっとまて、そんなことはすでに (スコア:1)
といいたいところですが、しかし、フレームワークを提供する側は、ライセンスはどうあれ、フレームワーク使う側にソースを見せるのは必須でありましょう。ここでいうフレームワークはフォトショップのプラグインのような単純なものじゃなく、複雑な相互やり取りが多くなりそうなところであって。これでソース見せていないというのは酷いと思う。
Re:ちょっとまて、そんなことはすでに (スコア:1)
プロプラだと、世間一般へは言うに及ばず、顧客に対してもデフォではClosedってことは
(いやですが現実として)有ると思います。
また、「ソース見たいなら追加料金」ってことも有るでしょうね。
その場合、プロジェクトの経費を削るために、真っ先(?)にソース代はケチられるかも知れません。
＃そんなケチったプロジェクトの末路は見えているがG7
そういや、OSという名のフレームワークも、しばしばClosedですよね。
で、高額だったり、NDA(リスクをコストに換算すれば凄い額でしょう)必須だったりしますよね。
そういやシアトルあたりにプロプラOSを作ってる大企業が存在していたような気が(^^;
Re:ちょっとまて、そんなことはすでに (スコア:1)
> ではClosedってことは (いやですが現実として)有ると思います。
そうですね。だから、今、ソフトウェアで（カネは入るかどうかは微妙だけど）名声上げたい人がいるなら、手間のかかる実装を、プラグインで拡張可能な形のソフトウェアにして、オープンソースにする、というのは、結構いいと思うですよ。需要ありますよ。たぶん。
その実装するものが、人事管理なのか、会計ソフトなのか、ゲームなのか、、、どれもフレームワークとして構築するだけの価値があるかは、やっぱりその分野に詳しくないと分からないと思うんですけどね。
Re:ちょっとまて、そんなことはすでに (スコア:1)
>張可能な形のソフトウェアにして、オープンソースにする、というのは、結構いいと思うですよ。需要ありますよ。たぶん。
アプリじゃなく、抽象(?)度が一段上の「アプリ構築用の汎用フレームワーク」という意味では、
最近IoCとかDependencyInjectionとか呼ばれてる奴が、それに近いかなと。
自分が書きたい核心の部分「以外」のことを如何に考えずに済ますか、という問題への解答としての方法論(と実装ライブラリ)の、
ここ数ヶ月流行(笑)のパターンの1つなようで。
＃とりあえず、羽生氏とかの「シーサー」とやらが今後どうなるのか、生暖かく眺め中なのでG7
>その実装するものが、人事管理なのか、会計ソフトなのか、ゲームなのか、、、どれもフレームワークとして構築するだけの価値があるかは、
>やっぱりその分野に詳しくないと分からないと思うんですけどね。
具体物と抽象物の距離の測り方ってのは、いつだって悩ましい問題ですね。
距離を測ることが出来ても、「今差し迫って」いる人ならば、
とりあえず一足飛びにアプリを作ってしまうでしょうから。
そして、
「差し迫って」いなければ、そもそも抽象的なもの(ライブラリとか)を"作り置き"する、
という作業になかなか入らない、というのも、
悲しいけども「プロ」の現場では頻繁に起きてる現象だと思います。
そう考えると、
フレームワークをオプソで出してる人(や特に会社)は、
コンピューティング的に正しい方向だ(^^;という意味で、尊敬できます。
で、蛇足ですが、翻って我が身…(T_T)
例えば、「関連する全ての」ソースの著作権ごと売り渡せ、という要求をする客も居る(俺は経験した)わけで、
そういう場合、こういうフレームワークとかは吹き飛んでしまうんですよね。
＃てゆーか、オプソ以前の問題として、自社内フレームワーク＆ライブラリも丸ごと吹き飛びます。再利用できねぇっす。
そういう契約は、こっちも客も開発のノウハウを蓄積できないという意味で「損」に繋がるはずなんですが、
そのへんAll Or Nothingに拘る頑迷な顧客企業は存在してます。残念なことです。
＃全てを明かすことと、全てを「相手に」売り渡すこととは、イコールではないと早急に気付いて欲しいのでG7
Re:ちょっとまて、そんなことはすでに (スコア:1)
> という作業になかなか入らない、というのも、
> 悲しいけども「プロ」の現場では頻繁に起きてる現象だと思います。
やはり、そこは、シンプルが一番、You aren't gonna need it の原則を大切にして、拡張可能なフレームワークを作ることには慎重になるのは、賛成です。
しかし、プログラミングに関するトピックが出尽くしたとなれば、次にプログラマの生産性を大きく上げる方法があるとすれば、大きな土台の上に、プログラマが小さなプログラムを追加していく、というアプローチになると思うので、必然的にそうなっていくもんだと思います。
Re:ちょっとまて、そんなことはすでに (スコア:1)
これ、DQNが支配的である場では、曲解されちゃうんですよね。
彼らは必要なものをも不要と呼んじゃう。
＃逆に不要なものを必要と呼ぶ。あべこべ。
ま、DQNには結局何やらせても駄目(というかそれがDQNの定義だ)なんですが。
＃4990なのでG7
Re:ちょっとまて、そんなことはすでに (スコア:0)
あとはAWT/Swingなんてつかってらんねーよという意思表示を はっきりと示したところ。
＃最下層のEclipse runtimeはUI非依存だけど、
＃Eclipse PlatformはSWT/JFace前提。
Eclipse プラグインといえば (スコア:0)
使わない，だろうな (スコア:0)
つーか，Eclipse重すぎ．非力なマシンにはつらいですよ．
職場で新しいPC買ってほしいときに「Eclipseが～」って言うと 納得してもらえたりするくらい．
Re:使わない，だろうな (スコア:0)
256MBで使ってた頃はたまに“しばらくお待ちください”状態になったけど、640MBにしたらなくなった。
Re:使わない，だろうな (スコア:0)
私は、128MBから256MBに増やして「おお、マトモに動く」とか言ってそれ以上増やしてないんですが。
Re:使わない，だろうな (スコア:0)
ないと思うのですが。
メモリけちったうえで統合環境作りたきゃおとなしく emacs -nw でしょ。
既にEclipseで２ちゃんねるだって見れます (スコア:0)
そうか… (スコア:0)
「あらゆるプラットフォームで同一の操作性を提供する」Workplace family構想が実現する時代がようやく来たのか…
ジジイなOS/2ユーザー
Re:そうか… (スコア:0)
Notesクライアント on unix (スコア:0)
個人的にはGatesOS環境が不要になるので歓迎。
#職場での話。
大規模プロジェクト (スコア:0)
グループウェアが開発環境の一部だと言われたとしても，
全然違和感を感じなかったりするかと．