是时候消除那些Java 9的误解了

Java 9将在9月到达，即使我们已经准备好了也没有，但是在到达Java 9之前，仍有一些事情需要理解。 我们需要停止思考Maven在Java 9上不起作用，并且如果没有Jigsaw，就不能使用Java 9。 在我们的访谈系列的最后一部分，我们至少会消除11种误解，但从一开始就不要破坏所有乐趣。

关于我们即将到来的模块化未来的最后一句话：模块化生态系统并不是每个人都可以喝的，而且据一些Java影响者说，社区不太可能立即依赖新的模块功能。 世界为模块化做好准备了吗？ 这取决于您问谁。 Java 9发布后，开发人员是否应立即投入模块化？ 请仔细阅读，找出答案。

访谈系列回顾

在这个由三部分组成的访谈系列中，有11位Java影响者评估了Java的流行程度，讨论了模块化生态系统，并揭示了他们对Java 10的期望清单。

在本系列访谈的第一部分中，我们邀请Java影响者讨论Node.js超越Java的可能性，并评论斯坦福大学决定以Java而非Java教授其著名的入门课程的决定。 访谈系列的第二部分全部关于Java 9：我们剖析了JCP执行委员会的决定，即不批准JSR 376的公众评审投票[ 复议投票已获批准 ]，我们讨论了模块化生态系统。

在访谈系列的最后一部分中，我们讨论有关Java 9和JSR 376的最大误解。您是否渴望了解我们的影响者希望在Java 10中看到什么？  

认识有影响力的人

Markus Eisele是Lightbend的开发人员倡导主管和Java冠军。

Mario Fusco是Red Hat的一名高级软件工程师，负责Drools，JBoss规则引擎和Java Champion。

Marcus Biel是一名软件工匠，JCP成员和CleanCode传播者。

Lukas Eder是Data Geekery GmbH的创始人兼研发主管，该公司是jOOQ和Java Champion背后的公司。

Trisha Gee是JetBrains的一名开发倡导者，是伦敦Java社区的重要成员和Java冠军。

Vlad Mihalcea是Hypersistence的首席执行官，也是《高性能Java Persistence》的作者。

Jake Wharton是Square Inc.的一名Android工程师。

Thorsten Heller是绿鸟集成技术公司的首席执行官，该公司提供网格智能平台Metercloud

Baruch Sadogursky是JFrog的开发倡导者。

Quentin Adam是Clever Cloud的首席执行官。

Bruno Borges是Oracle的首席产品经理，负责Oracle Cloud Platform，Java以及应用程序开发的相关技术上的开发人员参与。

Markus Eisele： 我有两个收藏夹。 一种是包含反应式流规范。 我看过第一篇有关如何在自己的应用程序中使用它的博客文章。 它不应直接使用，而应与参考实现（例如Akka Streams）一起使用 。 这是我所介绍的更好的博客文章之一 。

第二个是Jigsaw，或者更好的说是Java Platform Module System。 有很多方面，充其量只会导致很多混乱，而最糟糕的是会导致模块混乱。 斯蒂芬·科尔本（Stephen Colebourne）发表了三篇很好的文章，试图消除一些困惑。 他讨论了模块命名 ， 自动模块 以及模块不是工件的问题 。

误解是升级到Java 9或迁移到Jigsaw比不这样做更昂贵和风险更大。

Marcus Biel： 与所有更改一样，误解是升级到Java 9或迁移到Jigsaw比不这样做更昂贵和风险更大。 的确，每次升级都会带来风险，但是迟早您还是必须进行升级。

升级越早越好，因为您越早就能从其所有优势中受益。 对于Jigsaw，您将从模块级别正确封装的优势中受益。 拼图将使我们能够构建具有更清晰，更精确的结构的模块化系统，新开发人员加入团队或业务人员将能够更快地理解它们。

还请参见： Java仍然存在并且很好，谢谢您，并且与以往一样重要

Trisha Gee： 许多人没有意识到无需使用Jigsaw就可以使用Java 9及其所有闪亮的新功能，即，您可以非常愉快地使用Java 9而无需迁移任何代码。 Java 9中有些事情已经发生了变化（例如，隐藏内部API），但是从理论上讲，如果您的应用程序一开始就做了所有正确的事情，那么使用Java 9编译和运行就不会有问题。

模块化感觉就像是许多工具作者的厄运。

弗拉德·米哈尔西娅（Vlad Mihalcea）： 拼图。

杰克·沃顿（Jake Wharton）： 我想说模块化对于许多工具作者来说就像是注定要灭亡。 从类路径到模块路径的迁移不必是一夜之间的转换。 有足够的标志和选项可以使迁移以适合您组织的速度进行。 尽管如此，但这不是应该无限期推迟的事情。

希望，潜在的好处将足以激励人们迁移。 也就是说，至少要等到Java 10开始使用记忆棒并删除其中的一些标志和选项为止。

Thorsten Heller： 对我来说，有两个“ MOST”重要的误解：Maven讨论（意味着Maven等将无法工作）以及将所有代码移植到新模块系统上的需要。

Baruch Sadogursky： 最重要的误解是，该行业大规模拒绝了Jigsaw，因此将其从Java 9中删除。该行业强制进行了一次对话，最终做出了很好的妥协，使Jigsaw保留在Java 9中，但对开发人员更友好。

Quentin Adam： 实际上不赞成使用java.lang.reflect的方式是一个错误，因为它会引起很多错误和挫败感。 许多开发人员使用框架使用它，却不知道它是如何工作的，因此需要教学法。 有趣的是，它将如何工作。

Bruno Borges： 实际上，这是开发人员必须重写其程序并将其程序包组织为模块的程序。 无需任何人进行更改！

Markus Eisele： 开发人员的生产力是我最大的兴趣。 进一步改进Lambda，在所有API（例如JDBC）中提供更好的流支持 ，我希望看到 几个有趣的JEP草案 。

还请参见： Java处在滑坡上，Tiobe索引显示

Mario Fusco： 我对Valh​​alla项目中计划的一切感到非常兴奋。 值类型将确保最相关的改进，通用专业化将使用户避免大量不必要的装箱/拆箱操作，这些操作非常耗时。 标准化泛型的用途可能会受到更多限制，但是它们将帮助像我这样的许多程序员开发框架和库，这些框架和库通常需要大量使用反射。

最终，我最近看到了Brian Goetz的一封电子邮件，其中宣布可以在Java中引入模式匹配。 这将有助于限制访问者模式的使用（和滥用）。 但是，任何可以提高Java功能编程能力的更改对我来说都是非常受欢迎的。

对我来说，删除功能和修改过去的错误决定比添加新功能重要得多。

马库斯·比尔（Marcus Biel）： 好吧，如果我被允许一个愿望，

对我来说，删除功能和修改过去的错误决定比添加新功能重要得多。

我希望看到一些不能向后兼容的新更改。 例如，我希望看到Checked Exceptions被删除，但是这不会太早发生。

无论如何，列出一些Java 10很好看的新功能：

• 模式修补
• 价值对象
• 多行字符串
• 列表<int>

卢卡斯·埃德（Lukas Eder）： 正在Valhalla项目和其他项目的背景下讨论的所有内容，包括：

• 阵列2.0
• 值类型
• 通用专业化
• ADT和模式匹配（我个人也希望有一流的联合和交叉点类型）
• 仿制药的申报地点差异
• 通用枚举
• 命名和默认参数

哦，如果我能以Java的人的身份用Java获得这些多行字符串，我将非常高兴！ 我也希望看到其他糖，例如：

• 资料类别
• 流敏感类型（无需强制转换为“ if-instanceof”块内部）
• 销毁地图条目和其他类型
• 列表和地图访问文字
• 具有许多新功能的功能更强大的Stream API
• 输入别名
• 本地方法
• 当地进口

你们中有些人可能已经注意到，这些功能会从 Kotlin 或 Ceylon之 类的语言中被盗 。

Trisha Gee： 我想看看Local-Variable Type Inference 。 很长一段时间，我都是那些长期的Java程序员之一，他们并不在乎所有的样板，因为随着时间的推移，这些样板对您来说是不可见的。 但是，我们获得的样板减少得越多（例如lambda表达式，方法引用和新的Collections工厂方法），我越能意识到一种语言可以简洁而不丢失所有含义。

从性能的角度来看，我真的很想看到类似Value Types的东西 。 我知道有人在讨论如何做，如何做以及它有什么作用，但是我认为这些讨论确实很重要，并且这样的事情可以使Java在性能方面进一步向前发展。

Vlad Mihalcea： 多行字符串。

杰克·沃顿（Jake Wharton）： 除了我 认为 会获得的 所有花哨的东西， 例如值类型，泛型的基元和更好的模式匹配之外，我真的很想看到对部分类的支持（类似于C＃提供的支持）。 作为少数注释处理器的作者，无法修改类是可以理解的但有限制的限制。 局部类允许类作者定义一个必须由同一类型的一个或多个其他局部类来实现的契约。 这将使注释处理器能够自动填补这些类的空白，而不是像我们今天那样局限于生成子类或委托。

Thorsten Heller： 更加关注核心Java平台中的“内置” DevOps支持。

Baruch Sadogursky： 我正在等待Valhalla项目。 它将真正改变我们编写Java的方式。

昆汀·亚当（Quentin Adam）： 模式匹配和值类，但我是一名函数开发人员，所以我有偏见。

Bruno Borges： 实际上，我想在OpenJDK的JIRA上填写两个ER，我希望它们能实现。

一种是JDK-8149423，它在字节码中包含源代码的指纹，因此IDE可以验证在编辑器中打开的源代码是否确实是正在调试的源代码。 您是否曾经遇到过-调试一条线并看到断点跳到空行？ 是的，我讨厌那个。 因为源代码不是JVM内存中的源代码。

另一个是次要的：对JAR工具的增强，以恢复文件权限（JDK-8149423）。 无论如何，对于Java 10有很多建议，它们都是很棒的，但是这两个是我的想法……:-)

如果您想与Java推动者和摇动者见面，请于10月在伦敦加入我们。

翻译自: https://jaxenter.com/java-influencers-interview-3-135847.html