IllegalAccessException after updating 2.1 to 2.2

[Tom Schindl]

Am 20.08.12 14:16, schrieb Greg Brown:
>> e.g. to have an 'initialise' method, you would call it whatever you want
>> ('setupThisController') and just stick the @PostConstruct annotation on it.
> 
> This makes sense, though I think it is a bit more flexible than necessary. An FXML controller doesn't generally need more than one "initialize" method, and often does not need any.
> 
>> For something that is injected you put the @Injected annotation on it, etc.
> 
> Are you referring to @Inject?
> 
> http://docs.oracle.com/javaee/6/api/javax/inject/Inject.html
> 
> If so, this also seems reasonable. Unfortunately, it lives in javax.inject, which is part of Java EE, not SE. I don't think we want to pull all of Java EE in for one annotation. We could duplicate the annotation in FX, but that isn't really ideal either.
> 
>> I think I've mentioned this before, but just in case I didn't, for most of
>> what FXML does regarding it's controller there are a whole lot of
>> pre-existing annotations that I would think make a lot of sense to re-use.
>>
>> http://docs.oracle.com/javase/6/docs/api/javax/annotation/package-summary.html
> 
> I looked at the list but didn't see much aside from @PostConstruct that would apply to FXML. 
> 
> I also didn't see anything that might serve as the equivalent of an @FXML-annotated event handler method. I imagine we'd want something along the lines of a hypothetical "javax.inject.Execute" annotation, so a handler method could be tagged as executable by the loader. 
> 

That's what we are doing in Eclipse 4 with handlers. We have our own
@Execute annotation which allows the user to flag a method to be called
in case of an event (keyboard shortcut, button press)

> However, since nothing like this appears to exist, we'd have to create our own. The FXML annotations would then be spread out over three packages:
> 
> javax.annotation.PostConstruct
> javax.inject.Inject
> javafx.fxml.Execute
> 
> That's also not ideal.
> 
> Maybe the best approach would be to stick with @FXML, but require it on any field or method that will be accessed by FXMLLoader. That's different than the current behavior, but maybe we could provide a flag or system property that could be used to enable the legacy behavior.
>

I think I already said this in another discussion. Yes, you should
enforce the @FXML and not call anything because of its name.

Using annotations from javax.inject without being a full DI-Container is
not a good idea IMHO and I think we all agree the FXMLLoader should not
get a DI-Container, right?

BTW I might be mistaken, but @Inject alone is not a solution to what
@FXML currently does.

To get the equivalent of:

@FXML
TextField mytextfield;

you'd write

@Inject
@Named("mytextfield")
TextField mytextfield;


Since we have the controller delegation stuff since 2.2 one can anyways
use its preferred DI-Container!

Tom

-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834