FXML version number

[Daniel Zwolenski]

I think marking the FXML version is a good idea, but not sure what the
implications of an incompatibility are though if it is in the backwards
direction?

There definitely will be version compatibility issues in FXML, but any
backwards compatibility issues will break running apps that are web
deployed when the JRE auto-updates on users. If the loader barfs when it
hits an incompatibility issue it just means those failures will be more in
your face.

If a running, web-deployed app has FXML that is an older version but just
happens not to be using the broken bits then the loader failing at this
point is highly undesirable.


On Fri, Jun 7, 2013 at 6:49 PM, Milan Kubec <milan.kubec at oracle.com> wrote:

> Hello,
> I have implemented simple versioning for FXML documents in FXMLLoader, but
> without support in tools it won't be very useful. I have agreed with
> NetBeans and Scene Builder folks that they will include support for
> versioning too. Support means that they will produce document with two XML
> namespaces - one defines version of fx: prefixed elements and attributes
> (xmlns:fx; it's already there, just the version is appended) and the other
> of actual JavaFX API used to produce document (xmlns; default, no prefix).
> The first will be checked, because wrong version can cause failure. The
> latter is only informational, no strict checking of version is possible,
> but tools can suggest to upgrade runtime, translate document etc.
>
> JavaFX API version is stored in System Properties as "javafx.version". The
> open question is still where and how to store fxml version in code. I think
> that we could have also property for this purpose, e.g. "fxml.version" in
> System Properties. So far it's part of FXMLLoader API, which is probably
> not very fortunate. What do you think?
>
> Issue details: https://javafx-jira.kenai.com/browse/RT-28599
>
>  Milan
>
>