Jython 3 功能和可行最小产品

这是一份讨论文档，试图描述并一定程度上优先考虑 Jython 3 的功能，这些功能基于从 jython-dev 和非列表电子邮件中收集的各种意见。

定位

我们认为，如果 Jython 3 ...，人们将继续采用和使用 Jython。

• 是 Python 的现代版本，在功能上接近标准。
• 运行在长期支持的 Java 平台上。
• 与 Java 无缝集成，以访问 JDK 和用户库。
• 提供正确的并发性（有效利用可用 CPU）。
• 允许在 CPython 3.x 上开发的代码在 Jython 3.x 上运行。
• 经过充分测试以供发布，并支持错误。

可行最小产品 (MVP) 是尽可能接近所有这些目标，也就是说，如果它离任何一个目标都相差甚远，那么它就不是可行的。这并不排除不成熟的 alpha 版本的可用性。（这是一个公共项目，因此任何人都可以构建它。）

版本和形式

• MVP：一个接近标准的 Python 3.8（？）版本，能够运行 Python。
  • 只有必要的差异（例如，围绕 GC、原子性）。
  • 完整的语法（加上一些 Java 调整，例如从 Java 导入）。
  • 接近完整的标准库（在使用不特定于 C 的地方）。
• 为 Gradle/Maven 生态系统构建。
  • MVP：没有捆绑依赖项的精简 JAR。
  • MVP：作为依赖项，可在中央位置获取。
• 提供可执行命令
  • MVP：jython3 命令可安装在每个主要操作系统上
  • MVP：常用的 python3 命令选项子集
  • 与 python3 选项兼容（MVP：子集）
  • 特定于 Jython 的选项（JVM 选项和其他选项）

性能

• MVP：速度与 CPython 相当（例如，相差 2 倍）。
  • 更高的性能（单线程）是可取的，但不是 MVP。
• 未来：努力提高速度。
  • 将 Python 编译为 JVM 字节码。
  • 更快的 Python 字节码解释器。
• 牢记以下方面的性能
  • 科学计算
  • 图像、大数据和 ML 库

如果这些选择有效，那么 Python 字节码解释器就是一个合法的 MVP。

平台和环境

很难用 MECE 的方式列举所有可能性。它是多维的，尽管并非所有组合都有意义。本节中的哪些内容是 MVP？

操作系统平台

• Windows 桌面
• Linux 桌面
• Mac 桌面
• 树莓派
• Android（在“功能”下讨论的最低限度）
  • 风险：API 差距限制了我们，或者导致了特殊的 Android 版本
• 小型 JVM 设备（例如，用于物联网）

运行时环境

这些定义并不精确，但目的是在 Java 运行的任何地方运行，并充分利用每个环境。

• 桌面
• J2EE
  • 风险：Java 版本支持
• AWS
• Azure
• 物联网/嵌入式 Java

在嵌入式频谱的末端，Jython 可能只有在 Python 不直接可用（而 Java 可用，显然）的情况下才具有吸引力。

重要的集成

基于我们注意到的项目（例如，通过报告的错误）的非科学、不完整的列表。

• Robot Framework
• ImageJ
• Pig
• Ghidra
• OpenHAB
• … ?

存在一个更广泛的 Python 生态系统，它们尚未使用 Jython，因为它们依赖于 C 中的扩展。例如，没有 numpy，SciPy 中就没有太多内容。

我们如何找到时间和合作者来测试这些环境的集成？我们是否对这些环境有足够的了解，以避免无意中造成困难？

功能

• MVP：在 Java 11 SE 上运行。选择它作为最低要求，因为
  • 它是目前 Java 9 之后的“主力”。
  • 它拥有丰富的库，我们可以在实现中利用它们。
  • LTS 版本是许多企业 Java 安装的特征。
    • 企业更倾向于安全性、易于管理。
  • MVP 风险：J2EE 基于 Java 8。必须探索
    • 我是否误解了这一点？
    • 如果 JVM 字节码相同，是否就不是问题？
    • 需要关注哪些库在路径上
• 非 MVP：在 Android 8.0 API 级别 26 上运行
  • Android 8.0 API 级别 26 是第一个已知支持 j.l.invoke 的版本。
  • 对运行时类创建的限制排除了
    • 在运行时从 Python 编译到 JVM 字节码 (exec())。
    • 某些实现方法的细节。
  • 需要专门的工具链。
  • 理想的目标，但其他障碍未知。
• MVP：生成和使用 CPython 字节码
  • 这解决了大型模块（JVM 类大小问题）
  • 使采用由 CPython 编译的模块成为可能（定义版本）
  • 这对 Android 支持至关重要吗？
• MVP（？）: 使用 threading 导致实际的并发。
  • 没有全局解释器锁（也没有本地锁）。
  • 内置对象在并发访问下保持内部一致。
  • 程序员负责其代码的同步。
    • 另一个线程看到的共享对象的价值可能已过时
    • 未同步代码的行为将与 CPython 不同。
  • 在 CPython 中是原子操作的 操作 在 Jython 中不一定是原子操作。
  • 并发性几乎是独一无二的优势：可能是 MVP。
• 与 CPython 高度兼容。
  • MVP：os.name 不再混淆流行工具（如 virtualenv）。
  • 发现差异后立即修复。（采用标准库很有帮助。）
• 继续与 Java 无缝集成
  • MVP：通常与 Jython 2 中一样工作。
  • 更少的魔法：声称 Java 类型的对象在其 Javadoc 中具有语义。
    • 避免语义混淆（例如 list.pop() 与 Deque.pop()）
    • 显式转换或包装以选择 Python 语义（可能？）
    • 不再对 Swing 和 AWT 名称进行特殊处理（如现在在 PyJavaType 中）。
• 逐步支持流行的库（及其依赖项）。
  • MVP：一个使扩展成为可能的 API。
  • 鼓励将最流行的 C 移植到 Java（不同的项目！）
  • 鼓励 JyNI 或 HPy 实验。
• 将 Python 源代码编译为 Java 字节码，并
  • 持久化编译后的 Java 字节码（以某种形式）。
  • 将编译到 JVM 的 Python 视为
    • 等效于缓存的 .pyc 文件。
    • Jython 在 JAR 中可定位的资源。
    • 从 Java 可见的类（可能）。
• 命令行版本。
  • MVP：启动脚本或其他包装器。（由 jlink 生成？C？）
  • 您运行的命令是解释器，而不是启动器。
    • JNI 似乎 很容易支持这一点。
    • sys.executable 指定实际的可执行文件。
    • 进程对象指定执行工作的进程（而不是包装器）。
• MVP：解释器可嵌入到 Java 应用程序中。
  • 继续 JSR-223 支持，并进行一些清理。
  • PythonInterpreter API（仅）通常与 Jython 2 相似。
  • 风险：当前 API 是无界的：太多内容是公开的。
    • 借助 Java Jigsaw 模块减少公共 API。
    • 会有血腥。
  • 风险：许多现有指南失效（Jython 手册）。
• 从 Java 中 import 的明确语义
  • Jython 2 中的语义已多次更改。
  • import 按照编写的方式反复尝试同一件事

实现和 API 功能

可用于嵌入和扩展编写者的 Java API 将受到“内部”实现选择的很大影响。反过来说，过早的 API 选择可能会以不可取的方式限制实现自由。

对于对象模型来说尤其如此，因为为了效率起见，在 API 中交换的对象将是我们内部使用的实现。

这可能比 CPython 更容易，因为 Java 为我们提供了良好的封装工具：接口、包和模块。（模块在这里很重要。Jython 2 中的许多实现细节都变成了公共 API，只是为了跨越我们自己的包边界。）

• MVP：在 3.x beta 之前解决对象 API。其中之一
  • PyObject 是一个接口。
  • 每个 j.l.Object 都是 Python 对象。
• MVP：抽象接口（类似于 CPython abstract.h）。
  • 基本操作的抽象接口。
  • type 的内部结构（槽位等）是私有的（比 CPython 封装得更好）。
• MVP：解释器、系统状态和线程状态之间的清晰关系。（至少解释器及其语义是 API）。

Jython 2 中不应复制的功能

• 不： Java List 和 Map 隐式地转换为 Python list 和 map。
  • 这是一个诱人的功能，它几乎可以工作，但涉及复杂的猜测。
  • 建议一个简短的明确方法。
• 不： Java 包缓存。
  • 此位置对用户来说有问题。
  • 它曾是 CVE 和后续错误的主题。
  • 如果有证据表明它显着提高性能，并且没有安全问题，则可以将重新设计的版本添加到 3 中。