I think asking your specific question and collecting the feedback is very reasonable. I'd be interested to see if anyone was planning to do that, and if so, what their perspective is. So far, I've been on 2 calls, and read the same emails as everyone else. I don't recall seeing anyone looking to build a non-backward compatible implementation without JAXB and JAX-WS. Is there specific guidance or goals from the steering committee or elsewhere that is driving the pruning effort that provides more context behind the desire to remove these specs?
I do think the poll is worth asking and I'm grateful that people are answering. However, to me, both questions appear to focus on what vendors want, as opposed to what consumers need from the platform. Consumers will be looking at what's in the platform to understand what they are going to get. If the group decides to remove JAXB and JAX-WS from the platform, I think that needs to be publicized, and we need to be able to explain why removing these specs is in the best interests of both the platform, and consumers. I don't think the statement of vendors will likely include these as part of their backwards compatibility anyway, provides a good explanation as to why removing these widely used specs is in the best interests of the platform or consumers.
> I think the issue here is really about JAXB and JAX-WS et. al.
I'm specifically thinking about these two specifications. We've pointed out technical issues with split packages for providing backwards-compatibility for EJB should some of the EJB functionality be removed. I don't particularly have issues with Jakarta XML Registries, Jakarta XML RPC, Jakarta Deployment or Jakarta Management being pruned, although if people state that they are still widely used, then that ought to be considered.
Thanks
Jon
