Java语言下一步可能快速演化, Eclipse将疲于跟从, NetBeans 6 值得一些期待

作为Java开发者, 学习了5以后带来的泛型语法之后, 不知道你有没有注意到一个特殊的地方:

Class<?> java.lang.Object.getClass();

虽然它的签名返回值为 Class<?> , 但是它的规范文档却给出了这样的说明:



这确实让开发者更方便, 不过仔细想想, 这本质上却超出了正常的Java语法范畴.
为了实现这个特性, 其实是在Java编译器上做了特殊处理.
翻一下已经通过OpenJDK项目GPL开源的javac源码, 可以找到对应的编译器代码在

com.sun.tools.javac.comp.Attr.visitApply(JCMethodInvocation tree){}

方法中的这段程序:

// as a special case, x.getClass() has type Class<? extends |X|>
if (allowGenerics &&
    methName == names.getClass && tree.args.isEmpty()) {
    Type qualifier = (tree.meth.tag == JCTree.SELECT)
        ? ((JCFieldAccess) tree.meth).selected.type
        : env.enclClass.sym.type;
    restype = new
        ClassType(restype.getEnclosingType(),
                  List.<Type>of(new WildcardType(types.erasure(qualifier),
                                                   BoundKind.EXTENDS,
                                                   syms.boundClass)),
                  restype.tsym);
}

也不是那么复杂对吧, 十行代码而已. 以此认知, 假如我们想现在就自己实现类似下面的语法:

var list = new ArrayList<String>();
list.add("Haha");

只要给每个CompilationUnit增加一个 var 类型定义, 然后类似的替换成变量初始化表达式的结果类型就可以了.


整套SUN JAVAC的代码既然已经通过GPL开源, 那么我们就可以毫无顾忌的去做一些修改, 重新发布自己的版本了 - 只要基于GPL就可以. 而最大的意义还不止如此, 因为我们不大会去变动javac的公开接口, 所以我们自己版本的javac将可以和JDK无缝兼容, 最原始的办法是将标准JDK的tools.jar更名为sun-tools.jar, 把我们自己的 javac.jar 更名为 tools.jar 放到 JDK/lib 下面去, 同时在我们jar的MANIFEST.MF里增加一个Class-Path, 引用 sun-tools.jar. 这样不仅让命令行的 javac 完全变成我们的编译工具, 连通过Apache Ant的编译脚本也无需任何改动, 成为我们扩充版本Java语言的完备的编译系统.

有人担心Java通过GPL开源以后因为上面的原因会造成太多的变形版本, 从而毁了Java语言, 不过我倒不这么认为. Java始终还是SUN的注册商标, SUN有法律权利要求变形版本不得称为 Java, 如果其它商业实体想利用SUN发布的Java相关内容另立门户, 名称问题其实很致命. 因为Java规范实质上仍旧通过JCP控制在SUN手里, 与JCP规范不完全兼容的语言版本, 是不可能得到SUN的认证从而获得Java冠名权的. 另外GPL提供了强有力的法律保障, 衍生版本的全部修改都可以合法的被SUN归入它维护的Java软件版本中, 这意味着SUN没有失去任何Java控制权, 反而会有越来越多的研究者无偿贡献他们的改进, SUN将有更多免费的, 直接可以吃下的, 经过实践检验的Java语言增值特性可供选择, 并且时机可以自己掌控. 作为Java5泛型语法源头的GJ编译器是一个先例, 以后这样的事情只会更普遍起来.

快速演进的Java语法对Eclipse来说将是一场噩梦. Eclipse相对于其它Java IDE的最大优势是从VisualAge 4J编译器演化来的增量编译器, 因为此编译器与IDE无缝紧密的集成, 让Eclipse收到很多其它IDE无法达到的好处. 但是, 成也风云, 败也风云. Eclipse JDT Compiler是Java语言语法稳定性的最大受益者之一, 但是一旦Java语法开始快速增强, JDT 弄不好就要跟着疲于奔命, 从主导Java IDE功能特性的领导者, 变成被动适应Java新语法的跟从者.

而对NetBeans来说, 在这方面的形势则颇为有利, Jackpot子项目展示并且有效的推动着SUN Javac向一个增量的, 动态恢复的, IDE友好的Java编译器兼语法元素建模工具前进. 从NB 6开始, 其Java编辑界面已经是基于javac的Compiler API模型, 虽然NetBeans团队对javac的动态特性增强还没有真正合并到SUN javac的代码当中, 但这一步已经是目前工作的方向, 完全合并的目标已经指日可待. 这个目标一旦实现, 最激动人心的结果, 那就是:

你可以基于openjdk的GPL javac, 开发并且发布你自己的Java编译器, 增加各种想要的语法元素, 只要仔细考虑一些兼容性问题, 完全可以让那些利用了这些新语法的Java项目代码, 不光是能够顺利通过javac命令行成功编译, NetBeans IDE将能够经过简单的配置, 就可以让一个Java项目引用你发布的javac版本, 通过可移植的Ant脚本, 来编译这些项目. 并且新语法元素, 将直接在NetBeans IDE中得到支持, 包括关键字高亮, 重构, 引用检索 以及更多的高级开发功能特性. 这点将是其它IDE, 特别是用自家编译器的Eclipse非常难于做到的.

另外, 通过对开发版本的NB6的试用, 我发现它已经远远超出了当年那个为了效仿Delphi而作的GUI Builder, 很多特性, 比如 重构, 相关内容高亮 等等已经直追Eclipse. 特别是从Update Center可以安装一个免费版本的Jalopy用于Java代码自动格式化, 感觉已经比Eclipse默认的自动格式化插件强了不少. 如果NB6的正式发行版也会包含免费的Jalopy, 感觉会是一大亮点.

自己添加动态特性这种事情没有那么多人整天实践，就好像自己做一个hibernate这种事情没有许多人整天实践一样。
更多的可能性是出现开源社区广泛认同的动态语法的事实标准，eclipse直接去支持那个标准就行了。

关键点是 NetBeans 在它成为标准之前就可以很好的支持, 而且很可能就是NB把它促成为标准的.
而等它已经成为标准了, Eclipse再支持就已经晚了, 所以说会很被动.

我觉得以IBM的后台实力，加上如今Eclipse极其广泛的号召力和业已形成的庞大受用者规模……想要撼动其地位，挑战者就必须对其具备接近于压倒性的优势。

JDT和Java最新版本的配合程度应该不会落后太多，而未来NerBeans所带来的“异常灵活的javac版本配置”是否足以吸引众多的开发者还有待观察。

在众多项目原地踏步在JDK1.4甚至1.3的中国大陆，你能指望众生对“先进的语法元素”会抱有足够的期待吗？

国内的应用开发市场一二十年内还是会跟着欧美走了.

看看 JSR 270: JavaTM SE 6 Release Contents 的 Final Approval Ballot (http://jcp.org/en/jsr/results?id=4051), Vote log 里, 唯有 IBM 把关于GPL的牢骚也带到了这里, 抱怨肯定是有商业利益因素的.

NetBeans这么个免费软件, 也在大肆打广告, 矛头其实还是指向Eclipse的.

这牢骚确实是挺够的了：

引用

On 2006-11-03 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

不过Red Hat为什么还没有投票呢？他应该是很支持Java在GPL下面开源的啊……

还有就是，我对富士公司也来投票感到有点莫名其妙，不知哪位高手可以解答一下？难道富士在基于Java的软件开发上有着不菲的投入，所以才加入了JCP？

看来我也要养成关注一些JSR的习惯了啊！

言归正传，我对NetBeans的Update Center确实感到十分方便友好（更新时的速度也不错），而且NetBeans对中文的友好程度似乎也逐渐盖过Eclipse……

我的经验不多，但是觉得NetBeans想挑战已经形成“垄断优势”的Eclipse绝非易事，如今Eclipse不是当年的JBuilder，应该很难给别人留出太好的机会来。

我真正所期待的能够有这样的业界标准，使得一个workspace能够被不同的IDE所兼容。这样无论参与的人身在何方，使用者怎样的开发环境，都可以毫无障碍的参与到开发当中来。从而让开发者对IDE的选择纯粹变成了个人爱好的范畴……就好像作家选用一只合适的钢笔一样。

嗯, 我觉得一个Java项目想跨IDE, 目前比较实际的办法还是通过可移植的Ant script, NetBeans的Freeform build script我也还没仔细看, 不过表面上看起来可能比Eclipse的Ant支持好一些, 不确定.

到目前为止我一直是Eclipse的忠实用户, 也靠它克服了SUN javac 5编译我的项目会crash的bug (javac 6 才修正好). 不过Eclipse只是提供一个Ant脚本的集成执行环境, 还不能从任意Ant脚本导入项目设置.

其实NetBeans目前的局限还是挺多, 比如一个项目只能有一个输出目录, 不像Eclipse那样每个src目录可以单独设置. 这样一个带Applet的web项目就不得不把applet单独拆分出来作为单独的项目处理.

感觉Eclipse在IBM文化下, 是要做一个集大成的王者; NetBeans则是一个相对目标方向单一一些, 实现也更直白一些的游勇. 不过对 NB6 dev version的试用确实让我感觉不错, 它是效仿也好吧, 功能觉得比以前版本顺手多了.

原因：Java语言下一步可能快速演化
结果：Eclipse将疲于跟从, NetBeans 6 值得一些期待
我认为没有必然联系，IDE的选择很多因素．大部分开发也会基于成熟的java版本．

嗯,其实我也主要是说一下心里的预感,这三个事情也不一定有很强的因果关系.

可以说在这个趋势出现之前, Java的成熟模型是SUN投资做研发定型, 大家跟一个比较稳定的语法规范, 这种情势下Eclipse有很强的优势; 而之后Java规范可能接受更多方面的科研, 应用投入, 变得更快演进, 从而势力分布上出现一些转机.

而NetBeans很有可能成为孕育新内容的孵化平台, 从而占据更有利的位置. 当然Eclipse等一个东西成熟之后还是可以并揽过来, 但比起目前为止的情势来, 就变得被动了.

富士？工业上，嵌入式，等等等等......

跨IDE？嗯，或许是当时我打死不用JBuilder的原因，虽然那个时候他是那么的流行。