2010年春Java平台圆桌会议 - 展望Java行业的未来 - 编程入门网

一些最有趣的并发工作正独立于 Java 7 进行，Glover 说，比如一些开源工作，基于 Java 的框架 Kilim 和函数语言如 Scala。

“JSR 203 是 NIO 中非常有用的增强。JSR 166 有一些很好的并发更新，并且我仍然希望 JSR 310 继续发扬光大。” Alex Miller 说。

Miller 还看到 JVM 中新增了一些好功能，他表示，“一些围绕 invokedynamic 的工作正在进行之中 ，可能会是一些热门的新型垃圾收集器 G1。”

就闭包而言，Miller 说，他们仍然值得争论，并且我很高兴它们能重回阵营。

其中，闭包将 “为各种 JVM 语言之间的通信提供一种公共的标准字节码格式”，Neal Ford 说，“ 现在，Scala 使用与 JRuby、Clojure 和 Groovy 不同的内部表示；它们都有自己的字节格式。” 建立 一种内部格式可以让所有基于 Java 的语言解析相同的内部表示，他说。

“Groovy 的成功表示人们希望闭包出现在 Java 中”，Dan Allen 说。他还对 Java 中缺少属性和直 接字段/方法引用表示失望，他说这样会导致浪费和/或传递类型安全性。

“许多语言信息会在编译时丢失，而它们本来可为框架开发人员提供很大的用处”，Allen 说。“一 个例子是方法参数的名称以及各种通用类型信息，它们已经从 Java 移动到字节码中。”

“虽然注释极为出色，但它们仅是需要支持的元数据最表面的一层”，他说。

但是，“Java 语言设计者应该在版本 7 时释放 Java”，Ford 说，“Java 语言将成为 JVM 的汇编 语言：允许低级访问，因为您所编写的是低级库，以及允许维护。”

甚至在平台前端，Miller 说，“Java 就其本身而言当前并不适合革命性改变 — 它仍然会顺变趋势 和用户的期望。而企业正希望如此。”

2010年春Java平台圆桌会议 - 展望Java行业的未来(4)

Project Jigsaw

JDK 应该模块化的争论应追溯到 90 年代中期，但对 Java 模块性的兴趣 — 或对可实现解决方案的 希望 — 在过去数年中已经激增。作为 OpenJDK 项目的一部分，Project Jigsaw 是 Sun 在 Java 7 发 行版中模块化 JDK 的努力。

我们向与会者提问 “Project Jigsaw 与 OSGI 的关系是什么”，以及 “是否能够满足模块化 Java 平台和编辑模型的需求。”

Chris Mackie 说，“我怀疑并没有一个正确的模块化 Java 解决方案。可以很容易发现关于‘正确’ 的模块性有许多立场。”

在提及关于模块化的 JSR 时，Alex Miller 表示，“我认为围绕 JSR 294、277 的整个过程以及 Project Jigsaw 从一开始就没做好。相关人员目的性很强，但我还是希望最终产品能是我希望的那样。

“我认为 OSGi 是一项伟大的技术。我并不认为它是唯一的解决方案”，他说。

我们需要的是一个 “可允许版本跟踪，支持编译时和运行时版本依赖性检查的工具，以及一个开放元 数据组件系统”，Ted Neward 说。相反，Project Jigsaw 已经 “变为另一种复杂的 OSGi 和 Maven” ，他说。

“很让人不耻，因为我认为 Mark Reinhold 和 Alex Buckley 在模块性方面的展示确实非常有吸引力 ”，Miller 补充说，“集成模块定义、依赖关系管理和紧密部署的概念可支持 CPAN、Ruby Gems 或 Groovy Grape 系统，并且能更好地构建和部署 Java 软件。”

但是，模块化 Java 平台也有其缺点和批评者。

“我认为 Project Jigsaw 不切实际”，Steve Perry 说，“他们提议的解决方

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!