写点什么

无视社区担忧,JPMS(Jigsaw)将被提交公开预览

  • 2017-05-09
  • 本文字数:3292 字

    阅读完需:约 11 分钟

Oracle Java 平台组首席架构师 Mark Reinhold 证实,虽然 IBM 和 RedHat公开表达了担忧,但通常称为 Jigsaw 的 Java 模块将被提交公开预览。在 OpenJDK 邮件列表的一个话题中,他写道:

关于转到公开预览,我们在 EG 内还没有达成共识。这只是因为有部分成员仍坚持认为,我们必须实现既没有在最初提交的 JSR 中提到又没有在协商一致的需求中记录的目标。然而,进入下一阶段符合更广泛的 Java 生态系统的最佳利益,那样,我们可以兑现我们实际承诺的目标。因此,尽管没有达成一致,我还是提交了公开预览规范。

作为回应,来自 IBM 的 Tim Ellison 提供了一些其他的背景信息,说明为什么 IBM 将投反对票,他用一条非常长的消息概述了自己和其他人的担忧。

虽然我理解继续推进这个进程的愿望,但我认为,听取 EG 的集体智慧并尊重他们的意见是有价值的。它不应该让人如此震惊,执行委员会代表向 EG 成员发表讲话,让他们就规范是否已经准备好进入下一阶段支持自己的立场。

有必要读一下整个评论,下面是他列出的其中一部分技术问题:

隔离不充分——模块的非导出(私有)程序包应该严格实现细节。JPMS 默认每个层一个单独的类加载器,这意味着,当同时加载时,私有程序包可能导致出人意料的冲突。

模块名称自动化——模块的依赖是通过模块名表示的,因此,提供一个标准 API 的实现者都必须使用相同的模块名。然而,模块名称自动化的基础是 jar 文件名,而它们是实现细节。我们需要确定,模块名是一组 API 还是一个具体实现的简写。

访问限制会破坏执行反射的程序库——模块必须事先知道是否向反射开放,并且知道反射者的模块名。这会破坏依赖注入,诸如此类。

对于最后一点,我们和目前处于预览状态的 CDI 2.0 的规范负责人 Antoine Sabot-Durand 进行了交流。当然,作为 RetHat 的员工,他当然站在 RedHat 和 IBM 的立场上,他表示:

Jigsaw 应该仅对 CDI 规范产生有限的影响,但在具体实现时,影响将是巨大的(反射部分、代理处理、类加载)。按照我的理解,Java 9 提供了一个新的 Layer API,那可以解决部分类加载和可见性问题,但文档中缺少示例,切换到 Layers 可能意味着巨大的工作量,而且没有绝对的保障。

不过,Spring Framework 项目负责人 Juergen Hoeller 告诉我们,Spring Framework 5.0 RC1 或 4.3.8 依赖于最新的 JDK 9 build 167:

  • 开放模块不必知道反射者的名称;它们可以只是选择性地将自己暴露给特定的模块。应用程序模块很容易声明,本身或具体的程序包向其他任何模块开放。在我看来,这很方便,当然不是 Jigsaw 的设计缺陷。
  • 即使不公开声明,导出类型的反射也可以很好地工作;只不过是操作一个非公有的字段,或者调用一个最终会失败的非公有方法。也就是说,我们可以通过内省找出任何导出类的注解……只要我们在公有构造函数 / 方法上找到这样的注解,那么在任何情况下,我们都可以执行依赖注入——即使没有公开声明。
  • 为了处理类的“非公有”成员,模块其实需要将自己或者至少是受影响的程序包声明为公开。这会影响私有字段注入、到私有字段的数据绑定以及 Spring 将 CGLIB 用于 @Configuration 类和非接口 AOP 代理……这就是为什么我们建议(但不是必须)使用 Spring 时公开声明。总之,将当前的 Spring Framework jar 文件用作 Jigsaw 模块路径的“自动化模块”是一种开箱即用的顺畅体验,无需为此自定义命令行标识。应用程序可能会在它们自己的模块描述符中遵循 Jigsaw 的自动化模块命名方法,声明对“spring.context”等的模块依赖。只要这种基于 jar 文件的模块名目前没有问题(我非常喜欢它对 Spring jar 和常见第三方库的命名),基于 Spring 的应用程序就已经可以选择一种不错的 Jigsaw 设置体验了。

尽管如此,Hoeller 也指出,他希望大多数基于 Spring 的应用程序留在类路径上,即使升级到 JDK 9 时也是如此,这主要是为了更方便地集成类似 Hibernate 这样的第三方库。

Java 社区进程执行委员会的 25 个成员中,有三分之二采用了新的 Java 标准。InfoQ 和另外一名专家组成员、来自 Hazelcast 的 Christoph Engelbert 进行了交流,他表示,Hazelcast 也可能投反对票:

我认为情况相当复杂,因为赞成者和反对者双方可能在不同的点上是正确的。Mark Reinhold 提到的其中一个问题是,某些特性起初是不必要的。虽然这很可能是对的,但之所以一定要实现,是因为 Java 世界的开发者们不想在今后几年的开发中作出改变。显然,那也是不正确的。

一般来说,在 Hazelcast,我们看到,JSR376 专家组(EG)没有达成一致,规范负责人的处理方式也很值得怀疑。我们还没有投票,但根据和社区及 EG 成员的讨论,我们可能会投“反对票”。

不要误会我,我是说,Jigsaw 是一个重要的特性,但它需要更多的时间或者换种方式来停止它。使用“大关闭开关(big Kill-Switch)”没问题,但激活它意味着你会在 stdout 上看到警告,而这些警告不会出现在 Oracle 的跟踪系统中,但会出现在我们的支持团队那里(至少对于我们的用户和客户是如此)。这是我们很可能投反对票的第二个原因。

我们知道这对于发布日期意味着什么,但是我们认为,更高程度的共识很重要,执行委员的部分职责是保证 Java 生态系统的健康。在当前状态下,对于许多库、框架及应用程序而言,Jigsaw 可能仍然是一个问题。

可是,InfoQ 也了解到,另一个专家组成员 Azul Systems 可能投赞成票。首席执行官 Gil Tene 告诉我们:

关于这一点,我们有点纠结。Jigsaw 是一个对 Java 开发人员有帮助的模块系统,我赞成其中一部分(不是全部)反对意见。在我看来,根据现实世界常见的实际案例,缺少对单个应用程序中同一模块的多版本支持,限制了它在 JDK 之外的可用性(应用程序使用了 Maven Central 程序包 A 和 B,两者均依赖模块 C,但 A 需要 C.1.1.0 ,而 B 需要 C.1.2.1)。

不过,尽管有反对意见,但我们还是会投赞成票。其中许多都是来自沟通不顺畅及过高的期望。虽然有些反对意见是合理的,人们对 Jigsaw 的期望(Java SE 9 的规划)远远超出了它的实际,但我没有理由拒绝它作为一个主要在 JDK 内部使用的模块系统(出于批判 Java SE 9 的立场,我就是这么看待 Jigsaw 的)。在我看来,我们将会看到 Jigsaw 在 JDK 之外的有限应用,对于公开发布的库和可重用代码尤其如此。举例来说,JDK 本身永远不用处理多版本的问题,所以按照现在的情况,Jigsaw 在 JDK 里可以工作得很好。我期望的是,可以为非 JDK 开发人员带来更多好处的“真正的 Jigsaw”(Jigsaw 2.0?)会晚一点推出。Java 10? 或 11?,希望不是永不……但是,in-JDK Jigsaw 已经接近完成,随时可以发布,我没有理由延误 Java SE 9,我不能因为希望重做它或者解决其中部分重大事项而延误整个发布序列。

我们接触过的大多数人都告诉我们,他们尚未达成一致。例如,代表 LJC 的 Martijn Verburg 就告诉我们:

对于 JSR 送审,规范负责人和专家组的分歧如此之大还是很少见。我在执行委员会工作了大约五年,我不记得以前曾经出现过这种情况。

投票即将在 5 月 8 日关闭,JCP 执行委员会正在讨论规范负责人和专家组成员提出的各种观点,并考虑来自更广泛 Java 社区的成员的评论。在投票结束之前的两天时间里,他们会在一起开会,这将是议程上的一个重要课题。伦敦 Java 社区当然认为 EC 颇能代表更广泛的 Java 社区,并且认为它非常适合评估 Jigsaw 以其目前状态对 Java 及其生态系统有益还是有害。

模块化很难,Jigsaw 团队在设计和实现上已经进行了大量的思考,特别是,我们当然不希望看到已经完成的 Java 模块化工作本身被延误。不过,如果更广泛的生态系统拒绝支持当前的设计 / 实现,那么它就无法获得广泛的应用,那至少会让生态系统中的许多人失望。

有趣的是,在我们最初报道这一事件的博文的留言板上,来自 Red Hat 的 David Lloyd 表示,那可能会稍微导致一些延误,直至解决问题:

我觉得,延误几周,讨论、实施、测试让其达到一个最小可接受状态所需要的修改,可能对于每个人而言都是最好(和最现实)的。

我们将看下当投票于 5 月 8 日关闭时会发生什么。

查看英文原文 Mark Reinhold Confirms JPMS (Jigsaw) Will Be Submitted for Public Review, Despite Community Concerns

2017-05-09 19:001239
用户头像

发布了 1008 篇内容, 共 391.0 次阅读, 收获喜欢 344 次。

关注

评论

发布
暂无评论
发现更多内容

听说最近AI应用爆了?!来AI Studio玩转大模型应用

飞桨PaddlePaddle

百度飞桨

使用Leangoo领歌敏捷工具实施多团队规模化敏捷管理

顿顿顿

项目管理 敏捷项目管理 敏捷工具 scrum工具

ChatGPT与软件架构(4) - 架构师提示工程指南

俞凡

人工智能 架构 ChatGPT

软件测试|手把手教你用Python来模拟绘制自由落体运动过程中的抛物线

霍格沃兹测试开发学社

软件测试|Pytest必会技巧(二)

霍格沃兹测试开发学社

多模块项目使用枚举配置spring-cache缓存

javalover123

Java lombok Enum spring-boot spring-cache

AI版女网红“半藏森林”上线,服务项目让人意想不到

引迈信息

人工智能 AI 低代码 JNPF

大模型时代下的企业系统架构变革

蔡超

架构 AI 大模型 GPT ChatGPT

inBuilder低代码平台特性推荐系列-第三期

inBuilder低代码平台

朱珠代言Moto razr40登618手机榜首,小折叠成新摩登主义造风者

科技之家

au音频编辑 Audition 2022 中文激活版

真大的脸盆

Mac Mac 软件 音频编辑 音频处理 编辑音频

利用 AWS CodeWhisperer 激发孩子的编程兴趣

汪子熙

人工智能 AI AWS AIGC 代码生成器

架构实战营模块 1 第 4 课 - 如何做好架构设计

净意

精选一线企业最佳生产实践,《Apache Doris 用户案例集》重磅发布!

SelectDB

数据库 大数据 数据分析 实时数仓 Doris

软件测试|Pytest的必会技巧(一)

霍格沃兹测试开发学社

软件测试|Pytest必会技巧(三)

霍格沃兹测试开发学社

大数据公司数据分析取数流程以及SQL示例

MobTech袤博科技

面试官问:kafka为什么如此之快?

JAVA旭阳

kafka

【零售电商系列】走进电商

小诚信驿站

6 月 优质更文活动

ChatGPT与软件架构(2) - 基于Obsidian和GPT实现解决方案架构自动化

俞凡

人工智能 架构 ChatGPT

ChatGPT与软件架构(3) - 软件架构提示工程

俞凡

人工智能 架构 ChatGPT

软件测试|PC端应用自动化最佳解决方案——Pywinauto

霍格沃兹测试开发学社

区块链代币DAPP通缩燃烧模式系统开发技术方案

I8O28578624

九科信息获评“第一新声”最佳信创企业管理软件,案例入选信创产业研究报告

九科Ninetech

你说的是哪一种 IDP:内部开发者门户 OR 内部开发者平台?

杨振涛

DevOps 平台工程 内部开发者平台 内部开发者门户 IDP,

软件测试|不会Python RPC,一篇文章教你入门

霍格沃兹测试开发学社

ChatGPT会取代低代码开发平台吗?

力软低代码开发平台

深入剖析Redis性能问题及优化方案

xfgg

redis 优化 6 月 优质更文活动

龙蜥社区 5 月度运营大事件回顾

OpenAnolis小助手

开源 总结 生态 龙蜥社区 运营月报

软件测试|一步到位教会你Python字典操作(一)

霍格沃兹测试开发学社

无视社区担忧,JPMS(Jigsaw)将被提交公开预览_Java_Charles Humble_InfoQ精选文章