[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9
|
Mohamed,We can't deprecate
something that doesn't exist... :-) The Specifications/APIs
that are being proposed to be added were actually part of Java SE. Years
ago, these technologies were deemed pervasive and should move from the
Java EE (Enterprise) space to the Java SE space. The Platform spec
still referenced them, but it was explained that these were part of the
Java SE offering, not Java EE.But, now as of
Java 11, these "Enterprise" APIs were dropped from Java SE. So,
they are in limbo. If there is desire to evolve these APIs in the
Java EE space, then they would need to be re-added to the Java EE space.
That is what we are discussing -- whether to re-add these technologies
into Java EE that used to be part of Java SE.If we leave them
where they are, then they will stay in the javax namespace. As a
reminder, any evolving of the javax APIs has to be done in a separate namespace
(ie. jakarta).
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
"Mohamed
M. El-Beltagy" <melbeltagy@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
11/23/2019
12:50Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Why not deprecate
its usage in Jakarta EE.It would be
giving users some period to refactor out of it.Same as what
happened with Entity Beans in favor to JPA (at Java EE 6 release).Also, that
allows individual specs to evolve (if required) without impacting Jakarta
EE.Best regards,Mohamed ElbeltagyOn
Saturday, November 23, 2019, 9:14:07 AM GMT+2, Edwin Derks <ederks85@xxxxxxxxx>
wrote: Or
maybe put this “optional” in a separate new profile?EdwinOn
Sat, 23 Nov 2019 at 00:35, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote:How
is "optional" different from "not added"?
What can I do with an optional spec vs. a spec that exists but is not included
in Jakarta EE?
Steve
Millidge (Payara) wrote on 11/22/19 10:36 AM:Perhaps
we need to kick off a vote on JAX-WS, it could be optional? Adding it as
optional will still mean the project will have to do a release so will
likely impact timelines. From:jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>On Behalf Of Kevin Sutter
Sent: 21 November 2019 14:08
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] VOTE: Specifications to add in
Jakarta EE 9 Scott,
This is exactly what we're struggling with in our discussions at IBM. We
have many existing JAX-WS customers. So, if we move JAXB to the jakarta
namespace, but not JAX-WS, then we will have two different JAXB APIs to
support. But, we also recognize that JAX-WS is a legacy technology
that probably shouldn't be part of the long term plans for Jakarta.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Scott
Stark <starksm64@xxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/21/2019
03:04
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
There still could be an update of JAX-WS to match the JAXB package changes
without JAX-WS being an official part of EE 9 I suppose. JAX-WS is certainly
a legacy tech that I would not expect customers to want to have to update
their use for JAXB changes, but it could be beneficial to porting layers
to have a JAX-WS release that allows for a runtime to make use of a single
EE 9 based JAXB implementation.
> On Nov 20, 2019, at 1:58 PM, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote:
>
> If JAX-WS is not in EE 9, and a product that implements EE 9 wants
to also support JAX-WS, that that product would need to satisfy the dependency
on JAXB. It could provide both javax.xml.bind and jakarta.xml.bind
APIs, or it could use one of the backwards compatibility approaches to
map javax.axml.bind APIs to jakarta.xml.bind APIs.
>
> But yes, having two implementations would make it hard to share binding
classes.
>
> Andy McCright wrote on 11/20/19 11:19 AM:
>> Would this also require adding the JAX-WS APIs to the EE9 spec?
>>
>> The JAX-WS APIs that have been removed from the JDK currently
have a dependency on JAXB. If we evolve JAXB in EE9 (or just rename
the packages), then we have some specs (like JAX-RS and maybe JPA, etc.)
that depend on the jakarta.xml.bind.* packages while others (JAX-WS) that
would depend on the javax.xml.bind.* packages. That would certainly make
it difficult for EE9 applications to use both a JAX-RS and JAX-WS frontend
that shares the same XML binding classes.
>>
>> Thanks, Andy
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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_______________________________________________
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