| Re: [jakartaee-platform-dev] [POLL] Would you support the as-isjavax JAXB and JAX-WS in your implementation |
_______________________________________________I think "legacy" profile would be fine for those features that both Java EE and SE cut away.
Maybe as an optional add-on to the Full or Web Profile (if the specs in the "legacy" profile have no externa dependencies it should be relatively easy)
As I mentioned the Problem first occurs in Java 9:
Without modularizing your app and explicitly adding modules like
java.activationjava.corbajava.transactionjava.xml.bind << This one contains the JAXB APIsjava.xml.wsjava.xml.ws.annotation
to it an existing app that worked fine with JAXB or JAX-WS under Java SE 8 will already fail in Java 9, not just 11.
That makes the problem even more severe because any JDK beyond Java 8 is affected even those that migrate to Java 9 first (not to mention that’s officially out of support now)
Werner
From: Bill Shannon
Sent: Wednesday, December 4, 2019 19:34
To: jakartaee-platform developer discussions; Jonathan Gallimore
Subject: Re: [jakartaee-platform-dev] [POLL] Would you support the as-isjavax JAXB and JAX-WS in your implementation
The challenge is that we're trying to position Jakarta EE as both a successor platform to Java EE, and as a cloud native, microservices compatible, buzzword compliant platform for the future. If you were only concerned about the former, backward compatibility would be a required part of the platform.
But to have a realistic chance of being taken seriously as a platform for the future, we need to abandon some of the things that are perceived as weighing down Java EE. We need a lighter weight more modular platform to appeal to users, and to enable new vendors to enter the market.
Almost everyone here is representing the position of an existing vendor or an existing user of Java EE, who thus cares strongly about compatibility. Although clearly we've recognized the need to define a platform for the future and abandon any requirement for compatibility with Java EE / Jakarta EE 8, which is why the Jakarta EE 9 proposal doesn't include backwards compatibility.
Our initial discussions seemed to suggest some agreement that a platform for the future did not need to include SOAP support, presumably because new applications are much more likely to use other technologies such as REST. I can't tell whether people have changed their minds, or whether they've just shifted their position to that of a Java EE user.
This is part of why I revived the proposal for a "legacy" profile. We would have one profile (the "base profile" or "full platform") that would target future applications, and a different profile (the "legacy profile") that would target applications moving from Java EE, or applications that needed to integrate with existing legacy systems.
So again I think the question for these APIs that are being considered to be "pruned" or "not added" is whether they're something that new applications with no legacy requirements should consider using. If they are, they should be part of the platform, and should be moved to the jakarta namespace so that they can be maintained like all the other parts of the platform with no restrictions. And we should understand what the competition for these would be if I was instead writing a Go or Python or C# or whatever application.Jonathan Gallimore wrote on 12/4/19 2:15 AM:
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
_______________________________________________jakartaee-platform-dev mailing listjakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev