FXML backwards compatibility issue

[Daniel Zwolenski]

Sounds good and this should avoid the worst of my two problems. Might it just be best not to try and inject it if it's not annotated with @FXML, private or otherwise? I'm not fussed though, so long as it works. 

I don't think I'm going to get out of my ComboBox problem so easily. I'm a little scared of what other less obvious side effects there may be from other fixes. The problem is really the auto updating rather than the fixes. And I guess I'm in for fun all over again in 2.3, 2.4, and on to infinity unless I get them off the jnlp deployment model. 

Thanks for the prompt reply on the resource issue. I appreciate it. 

Just for your info my resources get injected into the controller via a custom loader that wrappers the FXMLloader. This loader gets passed the resources to set on the loader and then if the controller implements HasResources it get set on that. Looks like in 2.2 I'll be able to ditch this code for future projects now that yours does the same job. 


On 27/06/2012, at 11:26 PM, Greg Brown <greg.x.brown at oracle.com> wrote:

>> In my FXML Controllers I have the following member variable:
>> 
>>   private ResourceBundle resources;
>> 
>> In version JFX 2.1 and lower this works fine but in version 2.2 it looks
>> like JFX has decided it has control over this variable now?
> 
> OK, I see the problem. In 2.2, we added support for automatic injection of the "resources" and "location" fields. We only do this if the controller does not implement Initializable - the thinking being that, if the controller does implement Initializable, it will get the location and resources via the initialize() method. Otherwise, we assume that the controller wants to get these values via injection.
> 
> I'm guessing your controller does not implement Initializable, but also does not want these fields injected. The fix is simple - FXMLLoader can just ignore the IllegalAccessException when attempting to inject these fields. If we ever deprecate/remove Initializable, we can go back to throwing in this case. Make sense?
> 
> Greg
>