IllegalAccessException after updating 2.1 to 2.2
zonski at gmail.com
Mon Aug 20 05:34:18 PDT 2012
@Resource (in javax.annotation) is more or less equal to @Inject
Which leaves the @Callback style one. This might be a contentious
suggestion, but arguably this is the one that doesn't need to be annotated.
In essence the FXML is an external class calling a method on the
controller. The controller should just be able to say, "hey, here's a
method you can call on me" (by declaring it in the normal Java way). i.e.
the semantics for FXML calling it is not really any different to another
class calling that method.
This assumes the method would have public or protected scope (assuming the
FXML is in the same 'package'), but that probably is not such a bad thing
(i.e. what if I do actually want to plug in a non-FXML view - in theory my
controller code should not have to change).
Otherwise, @FXML for FXML callbacks makes sense to me.
As I said, I'm not overly fussed (it'll all work one way or another). This
just feels cleaner to me.
On Mon, Aug 20, 2012 at 10:16 PM, Greg Brown <greg.x.brown at oracle.com>wrote:
> > e.g. to have an 'initialise' method, you would call it whatever you want
> > ('setupThisController') and just stick the @PostConstruct annotation on
> 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,
> Are you referring to @Inject?
> 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
> > 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
> 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.
> 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:
> 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.
More information about the openjfx-dev