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 <[email protected] > <mailto:[email protected]>> 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 > >
