Java语言下一步可能快速演化, Eclipse将疲于跟从, NetBeans 6 值得一些期待
程序员文章站
2022-03-14 17:06:38
...
作为Java开发者, 学习了5以后带来的泛型语法之后, 不知道你有没有注意到一个特殊的地方:
Class<?> java.lang.Object.getClass();
虽然它的签名返回值为 Class<?> , 但是它的规范文档却给出了这样的说明:
Returns ...
The actual result type is Class<? extends |X|> where |X| is the erasure of the static type of the expression on which getClass is called. For example, no cast is required in this code fragment:
Number n = 0;
Class<? extends Number> c = n.getClass();
这确实让开发者更方便, 不过仔细想想, 这本质上却超出了正常的Java语法范畴.
为了实现这个特性, 其实是在Java编译器上做了特殊处理.
翻一下已经通过OpenJDK项目GPL开源的javac源码, 可以找到对应的编译器代码在
com.sun.tools.javac.comp.Attr.visitApply(JCMethodInvocation tree){}
方法中的这段程序:
也不是那么复杂对吧, 十行代码而已. 以此认知, 假如我们想现在就自己实现类似下面的语法:
只要给每个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, 感觉会是一大亮点.
Class<?> java.lang.Object.getClass();
虽然它的签名返回值为 Class<?> , 但是它的规范文档却给出了这样的说明:
引用
Returns ...
The actual result type is Class<? extends |X|> where |X| is the erasure of the static type of the expression on which getClass is called. For example, no cast is required in this code fragment:
Number n = 0;
Class<? extends Number> c = n.getClass();
这确实让开发者更方便, 不过仔细想想, 这本质上却超出了正常的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, 感觉会是一大亮点.