I think we’ve created a situation in MicroProfile now that the Spring guys might have a hard time adopting that API even if they wanted to.
It’s hard to see what would technically stop them if they wanted to, and if there were issues Im sure we would all try our best to accommodate them. A more judicious path in my view would have been to adopt CDI only when it makes total sense, adopt Java SE wholeheartedly, and stick to AtInject as much as possible as a baseline. I was hoping we could correct these things with Jakarta EE or at least the Servlet part. I really think one of our big mistakes throughout the years has been fighting market realities too much instead of judiciously adapting to them in the name of technical merit alone. I don't think it has worked and I think we need to think differently at this juncture in terms of marketing too.
I think it would be a mistake to hobble the platform, and leave out fundamental elements of the EE programming model, which is what would happen if you built everything on JSR-330, since it is intentionally a partial standard. Even if we wanted to, the other specs would ultimately end up reimplementing their own DI to fill that gap (as we saw in the past), which would hurt the overall consistency of the platform. Thats not to say that the specs can’t be improved and/or better facilitate proprietary extension. I’m all for increasing the adoption of the standard, but it shouldn’t give up being an actual standard to do so.
-Jason
|
