Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] [EXTERNAL] Re: EE11 Platform call update
  • From: Ed Burns <Edward.Burns@xxxxxxxxxxxxx>
  • Date: Thu, 22 Feb 2024 18:01:25 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Th0r+jrC2kNM+F1KVlY8uKxEzvRl1rlFlWf/bdjjRh4=; b=m57kyIkT0vZA0/RQ3LkIsJc2Z4BJ16S94FqlKSo1PxwauLvjHz/VZ/776eu8FmtmM9XxkOAa5GptIXlHW7DVj9OJtlQtgMAqvon0jbVHTABJUciRR18zXyOSHyx7HOcyWLsMO3kunKXKXjpOt5kV59B8tY7zhbMvuyvUKjUbsu1qw4Kw7bjgHxguxnxV4eFUN1VhljmOj00t/qJ1VQkjbHnEQoWqAYyhA+ZfvaAgchFiXwxQnB9EDg+59yjcmQPlC44OIUvkk7lmwu+bc+s/RdEA646nNzkOvt/HP3lgqqNn5XdvozNurLwVFYah0/jnjhomqSK2Xw9xkN8y8iJ9+Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=EnwmUfL369T0gbpXShSUdGH5ItaRltH49VV7XAOSAU/D+001LPYK2Iehm9HJX4ImOkUrbQV2rnvcJVAnNmXvPKWBUx1tJnstoCwL1nU9yU5P4lUu91BX62Bm+PIbT2UblhzyR2cKzxRRHJ8147Rs1gkvTlXgnfxypK5u1WVxF88f8mi/wQAmM0JIGwxsrFzKZ0hVdcquejtkOW2qxFcOEXXTDHVxAYQ7qJcEOtr/1vmgIAHiTHmQypgYMgPzymwnI2yPGahvav4KOLBcmy6wGvX7CWBR24objejRguyw1bd0Gc4YZIunwpeLAvZqgL4MOkHIv4aDV00ZvgpeAqVRzQ==
  • Delivered-to: rest-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=3bfcad0d-0854-443d-9c6f-b1e63427e31d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-02-22T17:55:10Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
  • Thread-index: AQHaZPOXVdvdLNmewES7iqdzSJOSurEWpqdg
  • Thread-topic: [EXTERNAL] Re: [rest-dev] EE11 Platform call update

Thanks everyone for engaging in this I deeply appreciate ya’ll’s time and effort.


Replies in line.


On Wednesday, February 21, 2024 1:27 PM rest-dev rest-dev-bounces@xxxxxxxxxxx On Behalf Of Markus Karg MK via rest-devsaid:


Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update


MK> Speaking just for myself, I need to say that I do have a problem

MK> with *removing* JAXB. I have to maintain a software that on one

MK> hand shall use latest features, but on the other hand MUST stick

MK> with JAXB for backwards compatibility. It is OK for me that JAXB

MK> would become *optional* so I can simply drop it into the mix on my

MK> own. But *removing* instead of *optional* is a no-go for me and

MK> completely WAY off Java's long-term backwards compatibility

MK> benefit. Having said that, it is not our charter to necessarily do

MK> exactly what the platform people dream of just because they would

MK> like so, in particular not *forcefully remove* things just because

MK> they want to spare maintenance costs for their paid products or

MK> whatever benefit they like to have from *removing* it.


HI Markus, I'm glad you brought this up. In my role as release co-coordinator for Jakarta EE 11, I assert that one artifact delivered by the community served by the rest-dev list is a component spec and ratifying compatible implementation for Jakarta EE 11. For discussion, label this as ASSERT_REST_EE_11.


Other artifacts delivered by this community are not of interest to me in that role.


Can someone please validate ASSERT_REST_EE_11?


MK> Due to that I am -1 for *forcefully removing* JAXB, but I am +1

MK> for having it *optional* in the sense of "application vendors can

MK> put it on the classpath if needed". As a side effect, there is not

MK> justification for a 4.0.


In my role as release co-coordinator for Jakarta EE 11 I want to draw your attention to the decision made in the Jakarta EE specification committee (aka "the platform people dream of") that predates my accepting the role of release co-coordinator for Jakarta EE 11.


On 2023-02-08, the Jakarta EE Specification Committee (not "the platform people") SpecCmte: wrote:


SpecCmte> "Draft resolution for optional features in the Platform

SpecCmte> specification (also see issue #54), to be put forward for

SpecCmte> ballot in the 02/08 call:


SpecCmte> "An individual specification can have optional features,

SpecCmte> however when a component specification is included in the

SpecCmte> Platform and Web Profile, and Core Profile an optional

SpecCmte> feature must be explicitly declared as required, otherwise

SpecCmte> it is not required. This requirement is noted in the

SpecCmte> Platform specification.”


SpecCmte> The resolution was put forward by Scott Stark and seconded by Tom Watson"


SpecCmte> Kenji Kazumura - Fujitsu [+1]

SpecCmte> Tom Watson - IBM - Emily Jiang [+1]

SpecCmte> Ed Bratt - Oracle - Dmitry Kornilov [+1]

SpecCmte> Andrew Pielage - Payara - Petr Aubrecht [+1]

SpecCmte> David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez  [absent]

SpecCmte> Ivar Grimstad - PMC Representative [+1]

SpecCmte> Marcelo Ancelmo - Participant Member -  Abraham Marin-Perez [0]

SpecCmte> Werner Keil - Committer Member [absent]

SpecCmte> Scott Stark - Red Hat - Scott Marlow  Enterprise Member [+1]

SpecCmte> Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member [+1]


SpecCmte> 7 +1 /  1 0 / 0 -1 / 2 absent

SpecCmte> This resolution passes




Now, coming back to what Markus said about the charter of this community (of which I am not a member, but I am a Java Champion and have a passionate stake in the success of this community.)


MK> it is not our charter to necessarily do exactly what the platform

MK> people dream of just because they would like so, in particular not

MK> *forcefully remove* things just because they want to spare

MK> maintenance costs for their paid products or whatever benefit they

MK> like to have from *removing* it.


Where is it documented what is in and not in this charter?


On Wednesday, February 21, 2024 1:45 PM rest-dev rest-dev-bounces@xxxxxxxxxxx On Behalf Of Jim Krueger JK via rest-devsaid:

Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update


JK> My [wording] was perhaps unfortunate.  JAXB itself is not being

JK> “removed”.  It will still be optional.  It just is not part of the

JK> platform any longer.  Liberty, for example, will still support

JK> JAXB with EE11.  What we’ve been asked to do is to remove the

JK> dependency that Jakarta Rest currently has on JAXB.  This will

JK> just involve removing the Link.JaxbLink and Link.JaxbAdapter inner

JK> classes that were deprecated in Jakarta Rest 3.1.


On Wednesday, February 21, 2024 3:25 PM rest-dev rest-dev-bounces@xxxxxxxxxxx On Behalf Of Arjan Tijms AT via rest-devsaid:

Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update


AT> I think the major issue is that JAXB cannot be in Jakarta REST,

AT> since Jakarta REST is the core HTTP engine in Jakarta EE (in the

AT> Core Profile). The core profile does not have JAXB included. This

AT> is the same reason that Jakarta _expression_ Language had to be

AT> removed from CDI.


I believe this is also technically correct. When I imagine sitting down to churn out the ENTIRELY NON NORMATIVE EE 11 M2 maven artifacts, I am pretty sure this will blow up in my face.


AT> Newer products like Quarkus can't support those older things like

AT> Jakarta _expression_ Language and JAXB (at least not out of the box,

AT> I know there are various third party add-ons that bring it back

AT> from the Quarkiverse).


AT> Traditional servers like GlassFish, Open Liberty, WildFly etc

AT> should have no problems with supplying JAXB, and build-your-own

AT> stacks using e.g. Jersey and Tomcat should also not have any

AT> problems to continue support for JAXB.


On Wednesday, February 21, 2024 5:17 PM rest-dev rest-dev-bounces@xxxxxxxxxxx On Behalf Of James Perkins JP via rest-devsaid:

Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update


JP> The removal of XML Binding was already done in the release-4.0

JP> branch [1]. I wouldn't think we'd be doing anything beyond

JP> removing the module dependency and the Link.JaxbAdatper and

JP> Link.JaxbLink [2]. Is this what you mean or do you mean

JP> specifically with the specification document removing the optional

JP> XML Binding specification?


JP> FWIW my understanding is we only want to remove the module

JP> dependency and the two deprecated types.


JP> [1]:

JP> [2]:


From: rest-dev rest-dev-bounces@xxxxxxxxxxx On Behalf Of Santiago Pericasgeertsen SPG> viOn Thursday, February 22, 2024 11:12 AM est-devsaid:

Subject: Re: [rest-dev] [External] : Re: EE11 Platform call update


SPG> That’s the only compile-time dependency that I remember, so that

SPG> is basically it AFAICT.


That is a relief.






Release co-coordinator for Jakarta EE 11



| edburns@xxxxxxxxxxxxx | office: +1 954 727 1095

| Calendar Booking:


| Please don't feel obliged to read or reply to this e-mail outside

| of your normal working hours.


| Reply anonymously to this email:

Back to the top