Bugzilla – Bug 4348
Do artifacts need no-arg constructor?
Last modified: 2013-01-16 16:28:44 UTC
Should the spec say that artifacts need a no-arg constructor?
Maybe this gets lumped into some of the other discussions with DI/CDI/etc. about artifact portability from a more generic Java perspective...
Minor clarification: I guess the point in saying the artifact would have a no-arg ctor would be to go on to say that the batch container would actually use it to instantiate the instance....
I would assume no given that the loading of artifacts is up to the underlying implementation. In the Spring example, we don't require no arg constructors and allow users to use constructor injection as they wish. Although I've never used CDI, I'd imagine similar facilities are available there as well...
Artifacts cannot be portable if spec implementations decide how constructors are supported. I believe the spec must require no-arg constructors.
Chris, I respectfully disagree. By requiring (and therefore implying the use of) no arg constructors, you will then need some form of initialization mechanism to be called once all required properties are set (similar to the InitializationBean interface in Spring). Without that functionality, I don't think we can require no-arg constructors.
Michael, I see your point, but I'm not so sure the spec can be completely mute on this subject, either. It still seems to me if the spec delegates this part of the programming model to spec implementors that we break portability.
So I'm starting to think we need to go in the other direction: rather than requiring a particular sort of constructor in the programming model, stipulate the runtime implementation must not require any non-default constructors.
In effect, that implies artifacts are initialized with the default constructor. I wonder if the spec should simply state that.
If you think the spec should say nothing about constructors, please comment explicitly on how you see code portability working.
My expectation, since we have agreed that DI is a requirement for the spec and the form of DI is not, was that we would identify a common way to associate artifacts (@Named/batch.xml) and that's as far as the spec would go. How those artifacts are constructed is an implementation detail dependent on the DI framework used. If I choose to use CDI, Spring, Guice or any other DI framework, they all have their own mechanisms for object creation and migrating from one to the other would come with a certain level of effort that is outside of the scope of this spec to mitigate (IMO).
For that reason, I would not expect the spec to weigh in on this topic.
Michael, I think you've convinced me. Construction comes with the DI implementation. The spec will say nothing on this subject.