Would future versions of Spring leverage the new features in Tiger such as annotations and generics.
Would future versions of Spring leverage the new features in Tiger such as annotations and generics.
We will certainly offer annotation support as an option, especially for transaction management, and sooner rather than later. This can be implemented as an add-on to the core container, so won't affect backward compatibility. We hope to have a preview of transaction annotation support before Spring 1.2 is released.
I would love to rewrite the code base to get rid of untyped collections and use generics, but unfortunately we need to consider backward compatibility. Currently we use 1.4 optimizations only via reflection, but fall back to 1.3 in a 1.3 environment, as we have a number of enterprise users on 1.3. So unfortunately I think it will be a while before we can take advantage of Tiger language features in the frameowrk itself.
However, of course you can use as many Tiger features as you want in your applications running on Spring...
One thing I would like is annotations to indicate a required dependency. The BeanFactory could then use it to verify dependencies when loading the XML, rether than the bean to throw a NPE when trying to access the DataSource attribute.
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
That would be helpful. You can do something like that now:
Check out the InitializingBean interface. There is a method in there that specifically gives you a place to check if all required properties are set.
Or something I recently was pointed to in the javadoc for IntializingBean: Define your bean with a init-method in the spring config, and that method gets called after the bean's properties have been set. You can still throw an exception here and it will cause the BeanFactory to fail. That way, your bean doesn't rely on the Spring APIs.Originally Posted by sethladd
Patrick
That's a good idea, we'd definitely consider that. It would need to be done in such a way that the core container wasn't Tiger-only, but we're pretty good at abstracting thingsOriginally Posted by ronaldtm
![]()
Have you looked at the dependency-check attribute?