FXML version number

[Milan Kubec]

Well, changes in classes referenced by FXML is a bit different story.
This "API" is in fact defined by classpath that is available to
FXMLLoader. And assuring compatibility on this level is more about
JavaFX API backward compatibility, e.g. Scene in JavaFX 8.0 API should
be signature compatible with Scene from JavaFX 2.2.21 API. FXML file
will just store a hint in form of default XML namespace saying version
of JavaFX API the document was created with (or last modified -
depending on authoring tools; see the issue for the namespace definition).

And builders are completly different story. Builders were created for
developers convenience and builders are not used in FXML directly (you
don't create <SceneBuilder> but <Scene>), they are in fact
"implementation detail" of class creation when loading FXML file. So
deprecation and possible removal of builders should not be problem for
developers using FXML, it must be transparent for them. Builders are
used to create classes that do not have any other means of creating
their instance. And we are working on solution with using constructor
annotations for mapping constructor arguments to instance properties,
which would allow to create an instance of class which e.g. doesn't have
default constructor.

  Milan


Dne 13.6.2013 3:57, Daniel Zwolenski napsal(a):
> I guess there's the FXML namespace and directives to the Loader as one consideration, which I think is what you're focusing on here. 
>
> The other issue though is changes to the classes that the FXML references. For example when Builders go, suddenly a whole lot of FXML files will suddenly become invalid.
>
> Are there any plans for version management at this level, and if not could/should there be?
>
>
>
> On 13/06/2013, at 12:12 AM, Milan Kubec <milan.kubec at oracle.com> wrote:
>
>> 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
>>>
>>>