javafx 项目
因此, Java 9可能会破坏您的代码 ……
如果您的项目使用JavaFX,则这尤其可能,因为许多自定义和自制控件都需要使用内部API。 借助Project Jigsaw,这些内容将无法在Java 9中访问。幸运的是, Oracle在几天前宣布了 JEP 253 。 其目标:
为JavaFX UI控件和CSS功能定义公共API,这些公共API当前仅可通过内部API使用,因此由于模块化而变得不可访问。
JEP 253 – 2015年5月14日
让我们看一下JavaFX,Jigsaw项目和JEP 253是如何交互的。
总览
为了更好地了解内部API在JavaFX中的作用,了解其控制体系结构将很有帮助,因此我们将从此开始。 然后,我们将研究为什么在使用JavaFX时经常使用内部API。 这将有助于将新的JEP置于上下文中。
因为我熟悉它,所以我经常以ControlsFX为例。 我假设类似的库(例如JFXtras )以及其他自定义JavaFX的项目都处于相同的情况。
JavaFX控制架构
模型视图控制器
JavaFX控件是根据model-view-controller实现的 。 无需赘述,让我们快速了解一下如何完成。 (有关详细信息,请参见GuiGarage 。)
所有正式控件都扩展了抽象类Control
。 这是MVC的模型。
该控件定义一个skinProperty
,其中包含一个Skin
实现。 它可视化控件的当前状态,即它是MVC的视图。 默认情况下,它还负责捕获和执行用户交互,这在MVC中是控制器的任务。
皮肤通常是通过扩展BehaviorSkinBase
实现的。 它创建了BehaviorBase
的实现,将所有用户交互委托给该BehaviorBase
的实现,并相应地更新了模型。 因此,这里有MVC的控制器。
按键绑定
还值得注意的是控件如何解决用户输入。 为了将动作链接到输入(例如,“ CTRL +鼠标单击”中的“在后台打开新选项卡”),它们创建了KeyBindings
列表。 然后将输入事件与所有创建的绑定进行比较,并调用正确的操作。
JavaFX中的内部API
使用JavaFX时,通常依赖于内部API。 这样做是为了创建新控件,调整现有控件或修复错误。
创建新控件
虽然Control
, Skin
甚至SkinBase
都是公共API,但经常使用的BehaviorSkinBase
和BehaviorBase
不是。 使用拼图项目,将无法访问它们。
不过,该API的使用率很高。 ControlsFX包含大约二十个控件,其中大约一半需要这些类之一的实现。
同样,键KeyBindings
没有发布,因此创建键KeyBindings
来管理用户交互会增加另一个有问题的依赖性。
调整现有控件
自定义现有控件通常会更改可视化效果或调整某些用户交互的行为。
对于前者,简单地扩展和修改现有的外观通常是最容易的。 不幸的是,现有控件的所有外观都位于com.sun.javafx.scene.control.skin
。 当它们变得不可访问时,许多自定义控件将不再编译。
要更改控件对用户交互的React,必须干预BehaviorBase
定义的BehaviorBase
。 这类似于创建新控件,通常通过扩展BehaviorSkinBase
和BehaviorBase
并创建新的KeyBindings
。
通过CSS设置控件的样式
在JavaFX中,可以实现控件,以便可以通过CSS设置样式。 所有官方控件都具有此功能,其他一些控件也由其他项目提供。
设置控件样式的中心步骤是将属性的文本表示形式从CSS文件转换为Number
, Paint
,enum…的实例,以便可以将它们分配给属性。 为了确保统一,高质量的转换,JavaFX为此提供了一个API。 不幸的是,它位于com.sun.javafx.css.converters
。
高级样式要求必须在StyleManager
帮助下实现,您猜想它也没有发布。
解决错误
JavaFX相对来说还很年轻,但仍然包含一些很难接触的错误。 通常,唯一的解决方法是侵入控件的内部工作原理,从而使用私有API。 (此类情况的示例可以在OpenJFX邮件列表中找到,例如RobertKrüger , Stefan Fuchs和Tom Schindl在这些邮件中。)
这些变通办法将在Java 9中失败。由于似乎所有错误均已修复,因此它们不必要变得不必要,因此可以理解以下问题:
当然,从理论上讲,如果所有[那些bug]都已在[Java] 9中得到了修复,那我很好,但是如果有一段时间将其中的一半修复在9中,而另一半只能在8,我该如何处理我的产品?
罗伯特·克鲁格– 2015年4月9日
杰普253
我们已经了解了为什么在使用JavaFX时普遍使用内部API。 那么, JEP 253如何解决这个问题?
(除非另有说明,否则本节中的所有引号均取自JEP。)
目标,非目标和成功指标
该提案恰好解决了到目前为止所描述的问题。 而且它认识到“在很多情况下,要获得理想的结果,开发人员别无选择,只能使用这些内部API”。 因此,“此JEP的目标是为内部API当前提供的功能定义公共API”。
(请注意,当开发人员将其代码从内部移动并且现在无法访问新的公共API时,这仍然会带来编译错误。)
同时,该JEP既不计划对现有已发布的代码进行任何更改,也不进行任何改进:“不受模块化影响的所有其他现有API都将保持不变。”
定义了两个成功指标:
- “依赖JavaFX内部API的项目,尤其是Scene Builder,ControlsFX和JFXtras,在更新到新的API之后仍可以继续工作,而不会失去功能。”
- “最终,如果所有工作都按计划进行,那么第三方控件应该是可构建的,而不依赖于内部API。”
三个项目
JEP分为三个项目:
项目一:使UI控件外观成为公共API
现有控件的外观将从com.sun.javafx.scene.control.skin
移至
javafx.scene.control.skin
。 这将使它们成为已发布的API。 (请注意,这不包括行为类。)
项目二:改进对输入映射的支持
行为将通过输入映射来定义。 这允许在运行时更改控件的行为,而无需扩展任何特定(且未发布)的类。
项目三:审查并公开相关CSS API
com.sun.*
软件包中当前可用CSS API将进行审查和发布。 该提案将更加详细,并描述每个项目的当前状态以及一些风险和假设。
这些项目解决了上述四个用例中的三个。 可以合理地假设可以满足这些要求,并且在Java 9中,即使无法访问内部API,也可以正确地创建,调整和皮肤控件。
如何解决错误? 至少其中一些似乎可以用相同的工具解决(例如,扩展现有的皮肤)。 但是我不能说这是否对所有人都适用,以及没有解决方法留下来的重要性有多重要。
时间表
如果您想试用新的API,则必须耐心等待一段时间。 JFX 253的所有者,JavaFX UI控件团队的Oracle技术负责人乔纳森·吉尔斯(Jonathan Giles)在推文中说,“他可能在几个月内不会合并到存储库中……”。
另一方面,由于Java 9的功能完整性计划于12月发布 ,因此它必须在接下来的七个月内可用。
反射
我们已经看到,使用JavaFX常常需要使用私有API。 这发生在三个截然不同的区域:
- 根据控件体系结构(MVC)创建新控件。
- 通过扩展其外观或更改键绑定来调整现有控件。
- 通过CSS设置控件的样式。
- 解决错误。
JEP 253分为三个项目,分别针对前三个领域。 (对于我来说)尚不清楚它们是否足以仅使用公共API来解决错误。
翻译自: https://www.javacodegeeks.com/2015/05/javafx-project-jigsaw-and-jep-253.html
javafx 项目