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