javafx移动端开发_JavaFX 14：“在进行移动开发时，无需使用旧版本的JavaFX。”

javafx移动端开发

JAXenter： JavaFX 14 / OpenJFX 14在这里 ，再次在Java 14发布之前。 JavaFX 14是否将立即与JDK 14一起使用，还是人们必须等待将来的发行才能享受JDK 14的新功能？

Johan Vos： JDK 14发布后，开发人员可以立即使用JDK 14功能。 使用JDK 14时，JavaFX 14可以正常工作。我们没有提高使用JavaFX的最低要求的标准，这意味着使用Java 11或更高版本的开发人员将能够使用JavaFX 14。

这是一组重要设计目标的结果：

• 从第一天开始，我们希望开发人员能够使用JDK中的最新功能。
• 我们不想强迫开发人员升级到最新版本的JDK。

JAXenter：OpenJFX 14 / JavaFX 14为用户提供了哪些功能？ 有亮点吗？

Johan Vos：我们的首要任务是在开发人员应用程序和库中使用的JavaFX API在不断发展的基础架构上处于一流水平。 这意味着我们需要为新工具和库以及底层操作系统的更改提供支持。 在Linux世界中，从GTK2到GTK3的过渡值得关注，Apple在Catalina版本中提出了一些有趣的挑战。

在确保开发人员可以使用最新的操作系统和库的同时，我们还支持较旧的系统。 这在每个发行版中都是一个挑战。 我们希望长期保持OpenJFX代码库的干净，因此，我们不急于考虑允许长期维护的最佳方法，而不是快速修补新功能或修改后的低级功能。

Webkit和相关库进行了升级，并执行了一些常规代码清除。 根据（图书馆）开发人员的意见，控件中的许多修复和说明已集成。

我们还可以使用GraalVM在静态链接的环境中使用JavaFX平台。

• 添加了缺少的API，以允许第三方控件自定义或扩展TableView（请参阅JDK-8207957 ）
• 将tabSize属性添加到Text和TextFlow（请参阅JDK-8130738 ）
• 在WebView中支持HTTP / 2（请参阅JDK-8211308 ）

还请参见：

JAXenter：JavaFX 14背后的开发人员再次专注于在移动设备（iOS / Android）上使用JavaFX。 JFX 14为框架的最终用户带来了哪些新变化/好处？

Johan Vos：在JavaFX 11之前，基于旧快照，移动JavaFX开发是在单独的存储库中完成的。 在移动设备上使用JavaFX 11时，我们从干净的OpenJFX分支开始，并在该分支中添加了特定于移动设备的部分。 在以后的每个发行版中，此fork与主存储库之间的差异变得越来越小。

使用JavaFX 14，我们重写了与Android本机窗口系统的集成，并且该代码直接进入了OpenJFX。 这是一项正在进行的工作，许多移动更改（例如，iOS的Webkit）已在OpenJFX中推送，并计划在JavaFX 15中使用。

对于开发人员而言，重要的后果是，这种方法使他们能够在JavaFX的桌面版和移动版之间保持同等水平：台式机上的相同API也可以在移动版上使用。 在进行移动开发时，不再需要使用旧版本的JavaFX。

JAXenter：JavaFX与GraalVM结合使用时存在一些问题。 那里是什么样的问题，你们是如何解决的？

Johan Vos：首先，GraalVM包含许多组件。 我们正在使用（或继续使用）的主要组件是本机图像工具，该工具可以预先预编译Java代码，并且可以制作静态链接的图像。

我们必须进行一些调整才能找到灵活性和性能之间的最佳平衡。

这就引入了根本的区别：在典型情况下，用户以某种方式获得JavaFX应用程序，并且在运行该应用程序时，假定存在所需的jar文件和库。 使用本机图像创建的图像时，不再需要此操作，因为该图像已经包含所有库。 这意味着尽管我们需要为JavaFX组件创建静态库，而不是动态库。

另外，GraalVM AOT编译器会在构建期间尝试执行尽可能多的工作。 因此，构建可能要花费很长时间，但是应用程序的启动要快得多。 构建只是开发人员需要做的事情，而应用程序启动则是由最终用户完成并注意到的事情。 因此，由于有了GraalVM，最终用户通常会更加高兴，因为他的应用程序启动非常快。

但是有一些含义，因为并非所有内容都可以或应该在构建时进行编译或评估。 我们必须进行一些调整才能找到灵活性和性能之间的最佳平衡。

我们没有急着进行修改以使所有功能都可以在GraalVM上运行，而是研究了共享库链接与静态库链接之间的许多概念差异。 我们正在与不同的开发团队（OpenJDK，GraalVM，当然还有OpenJFX）合作，以提出最佳方法。 本着Java的精神。 质量和可维护性极为重要。 我们要确保JavaFX的顶级API在不同的配置中具有相同的行为。 在此讨论中也考虑了移动平台和嵌入式平台。

由于GraalVM本机映像需要一些配置（例如，开发人员需要提供应该进行反射或JNI访问的类的列表），因此我们创建了Gluon Substrate，它为开发人员完成了该配置的主要部分，并且添加了对JavaFX的特定支持。 我们正在逐步添加功能，例如对Media和WebView的支持。 其中一些支持服务将在14日提供，其余的计划在15日提供。

还请参见：

JAXenter：此版本中还解决了其他主要错误吗？

Johan Vos： JavaFX 14中修复了大约50个错误，可以在这里获取列表： https : //github.com/openjdk/jfx/blob/jfx14/doc-files/release-notes-14.md

JavaFX中的一些错误已经存在很长时间了，由于开发人员遇到了这些错误并提供了补丁程序，因此现已修复。 由于底层操作系统的更改而引入了其他错误。 在此发行版中，我们必须修复由于在最新的Apple操作系统MacOS 15（又名Catalina）上运行JavaFX应用程序而引入的许多错误，这并不奇怪。

JAXenter：和往常一样，有些依赖项需要更新； 升级到JFX 14时，开发人员必须记住什么？ 哪些依赖项已更新？

Johan Vos：我们没有为该版本强制使用新的依赖项。 但是某些操作系统改变了它们的依赖性，我们试图确保开发人员不必安装其他软件包。

JAXenter：安全是一个大话题。 是否有任何与使JavaFX使用更加安全相关的更改？

Johan Vos：像往常一样，此版本中的安全补丁主要集中在Web和媒体组件上。 这些是最易受攻击的部分，因为它们涉及的外部代码并不总是类型安全的。 OpenJFX开发人员会仔细跟踪这些组件的发展，并在需要时应用安全补丁。

JAXenter：JavaFX正在作为从mercurial迁移到GitHub的试点项目。 如果一切都按计划进行，那么JDK可能会与JFX一样执行此操作。 事情进展如何？

Oracle公司的Skara团队在使平滑和强大的功能（从陈旧的内部OpenJDK基础架构过渡到更现代的GitHub）方面做得很好。

Johan Vos： GitHub上已经有一个适用于OpenJDK的GitHub镜像，并且Skara工具每天都在变得越来越好。 这些工具是必需的，以便为OpenJFX和OpenJDK等项目保留高质量和所需的过程。

Oracle公司的Skara团队在使平滑和强大的功能（从陈旧的内部OpenJDK基础架构过渡到更现代的GitHub）方面做得很好。 现在越来越多的检查是自动进行的（例如，如果我们指示“拉取请求”需要2个审阅者，除非2个具有审阅者身份的开发人员批准了PR，否则PR不能被合并），并且Skara团队非常开放并且响应Swift。

至于OpenJDK项目的具体计划，这是我无法评论的。

JAXenter：您对此版本的个人重点是什么？为什么？

Johan Vos：我非常高兴我们能够如此快地解决MacOS 15问题。 苹果发布此新版本时，发生了很多事情。 在这个领域获得清晰和开放的开发人员文档并不总是那么容易，但是许多人一起工作，现在，我很高兴JavaFX 14在Catalina上运行得很好。

另外，我很高兴看到移动/嵌入式代码与主流代码之间的差异如此之小。

JAXenter：JFX 15有什么计划吗？

Johan Vos：是的。 实际上，JavaFX 15开发已经非常活跃。 我们倾向于在新周期的早期阶段做大事情，以便可以很好地对其进行测试。 我们正在增加对移动设备的支持：iOS的Webview代码得到了重大改进，并且在移动设备上使用软件键盘的代码也正在重构。

我们还正在努力使JavaFX代码与JDK的最新发展保持同步，正在进行的事情之一就是删除代码库中不推荐使用的finalize方法。

非常感谢您与我们交谈！

翻译自: https://jaxenter.com/javafx-14-mobile-java-release-169554.html

javafx移动端开发