FXML version number

[Milan Kubec]

Hello,
evolution of FXML is meant to be backward compatible. Any change in fx:
namespace (no plans yet) will increase fxml version, but FXMLLoader of
version 2 will load fxml of version 1 and 2, of course. On the other
hand FXMLLoader of version 1 (e.g. JavaFX 2.2.21) won't be able to load
new feature of version 2 (e.g. JavaFX 9.0). FXML version of 2 will only
be required if given fxml file would use new feature of fx: namespace.

Versioning is mainly meant for authoring tools like SceneBuilder or
NetBeans IDE.

  Milan


Dne 8.6.2013 0:43, Daniel Zwolenski napsal(a):
> 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
> <mailto: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
>
>