[mikewse]

Gavin King wrote on May 23, 2009 03:44:


But I need to hook into the startup sequence and run my code during bean registration, as I cannot demand this metadata afterwards.

But surely you want to build and cache your metamodel upfront, and validate that there are no errors in the user code.

At least that is what I would want to do...

I can certainly use this model for my current use-case, no worries there. And I think the design of the new SPI is great, no question about that, I really like the division into provider layers where I can hook in at will.

Though, my gut feeling here is that to solve my use-case of getting all metadata I am then really using an API(SPI) that was intended for something else, ie for modifying metadata. It is natural that this modifying API is limited to the startup phase, just like you can only modify a Struts 1 configuration before it gets frozen. The difference is that the Struts 1 configuration is available after startup, although read-only/frozen (luckily, I haven't coded Struts 1 for a long time but use it as a common ground example ;-).

So, my point is that future use-cases will want this metadata information, and maybe will have a hard time hooking into the startup phase. Maybe it is because of lazy-loaded modules, or because one cannot be sure to be the last to receive the ProcessAnnotatedType event to see the final configuration, I can't say. But if I had the choice, I would probably go with an imperative resolveByType solution, instead of hooking multiple events, to keep my own code simple. I can still validate my model after resolveByType returns.

I like when APIs are orthogonal, so the same rules are applied consistently. If the container finds it suitable to expose some metadata during its startup phase, then it should make the same data available in the runtime phase. In this specific case, the bean concrete class information is actually already exposed at runtime (getTypes), though in an obfuscated form that needs some processing to decode (finding the most derived class among the types). Thus, in this case it is not about information hiding but rather about retrieving information in a consistent way across the APIs. There may be other cases that would need more data being exposed though.

I think the spirit of the Struts 1 approach is good; don't hide any of the user code's metadata unless you have a special reason to do so.

[gavin.king]

Well, actually, for an unrelated reason, I recently added:

public Class<?> getBeanClass();

To the Bean interface. I don't love this method, because it's semantics are quite weak. For a producer method it is the class of the bean that has the method. For a custom Bean it could potentially be just about anything. So I don't really recommend relying on it for anything other than determining classpath accessibility of things.

But, well, it's there...

[mikewse]

Thanks, that looks handy, although your comment about it makes it sound like it may disappear from the next rev of the spec? :-)

One comment is if the difference in terminology is good or bad? Ie, naming the same thing AnnotatedType and BeanClass in different parts of the API. Could the same terminology be used?

[gavin.king]

Thanks, that looks handy, although your comment about it makes it sound like it may disappear from the next rev of the spec? :-)

No, it's needed, it's not going to disappear. It's just that it's not really intended to be used for what you are trying to use it for :)

One comment is if the difference in terminology is good or bad? Ie, naming the same thing AnnotatedType and BeanClass in different parts of the API. Could the same terminology be used?

Um. No. AnnotatedType is a completely different interface to java.lang.Class. Sure, if the JDK did not declare Class to be final we could use it everywhere. But that's something I can't change.

[mikewse]

Gavin King wrote on May 26, 2009 22:26:


One comment is if the difference in terminology is good or bad? Ie, naming the same thing AnnotatedType and BeanClass in different parts of the API. Could the same terminology be used?

Um. No. AnnotatedType is a completely different interface to java.lang.Class. Sure, if the JDK did not declare Class to be final we could use it everywhere. But that's something I can't change.

Sorry, I mixed things up when writing this. What I really meant to point out was that there is now:

AnnotatedType.getJavaClass()

and

Bean.getBeanClass()

that seem to return the same Class, which is also part of the

Bean.getTypes()

collection.

I'm sure there is thought behind these choices but just wanted to say that it's easier to grasp an API with fewer names for the same thing.

Maybe there could be a common word used for all of these, f ex resulting in getDeclaredClass()/getDeclaredTypes() or similar? (not that this example is very good though)

[gavin.king]

Well, both methods should be called getClass(), but of course, that name's taken ;-)

getBeanClass() doesn't work for AnnotatedType because it does not always represent a Bean

getJavaClass() is a bit non-specific for Bean, because it is specifically the bean class in the very technical sense of the word that is returned. No, it is not always a class in the getTypes() collection! For example, it is not there for producer methods, producer fields, resources, or session beans with no bean-class local view!

getBeanClass() has a very specific technical usecase to do with determining intermodule visibility of beans. It's not a generic find out what type of thing this is method.