NetBeansイイヨっていう話のあとに出てくるのは
「でもみんなEclipseに慣れてるから移行しないでしょ」
という言葉です。
確かに、同じパラダイムにあるツールであれば慣れているものから移行することはないと思います。
現在のところ、EclipseもNetBeansも、ビルドを自動でやってくれる超強力なメモ帳でしかありません。
でも、そのパラダイムが変わります。
今までのJavaは、APIの集合で、なにかを実現するためにはコーディングが不可欠でした。
でも今のSunを見ていると、JavaをIDE+APIの集合にしようとしているようです。
たとえばMatisseのGroupLayoutはとても柔軟で強力なレイアウトですが、NetBeansが吐き出したコードを見ると、これを手書きすることはとても現実的とは思えません。IDEが前提の仕様です。
Java RTのプラグインというのも特徴的で、今までの感覚でいえば、今のタイミングでプラグインを前面に出してプロモーションするような性格のものではありません。それでも、NetBeansを前面に出したプロモーションをしています。
JSFは、手書きでも使いやすいですが、RADツールを作りやすいように決められた仕様です。
Studio CreatorのNetBeans統合はいまのところ「ただ載っただけ」の状態みたいですけど、EJB3に対応したりリリースされて叩かれれば、どんどん開発環境に融合していくでしょう。
つまりJavaというのが、.NETのようにIDE前提の仕様の集合になりつつあるわけです。
いまはユーザーインターフェイスからロジックまですべてコード手書きが当たり前ですが、.NETのようにユーザーインターフェイスをRADで組んでロジックだけコード手書きという風に変わっていきます。
EoDと言われだしてしばらくたちますが、for(int i = 0; i < data.length; ++i)がfor(int d : data)になってEoDといわれても物足りません。
やはりEoDというのなら、退屈なユーザーインタフェースのコーディングはRADまかせで、ロジックのコーディングに集中したいものです。
.NETのようにということで言えば、多言語対応も.NETを狙っているように見えます。NetBeansのスクリプト言語対応は、Javaで動かすことを前提にしているようです。
ネイティブPythonやネイティブVBではなくて、JavaVMで動かすJythonやVB。つまりPython@JavaやVB@Java。それにRuby on Rails@Java。
そういう視点で見ると、NetBeansはVisualStudio@Javaになろうとしているように見えます。
そういう感じでJavaの開発の性質が変わってIDEの位置づけが「あれば便利」から「ないと無理」になります。
そこに向けた開発としてはNetBeansの方がEclipseより数歩進んでいるように見えます。
Javaでの開発が変わって、それを実現できる近道がNetBeansという状況になれば、環境の移行に慣れというものはあまり大きな問題ではなくなります。
ただ、仕様がオープンで実装がオープンソースとなると、Matisseのように同じ機能がEclipseでも動かせるということになって、最終的にはどこだかのブログのタイトル通りになりそうです。
「NetBeans vs Eclipse. The winner is Java」
