Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Hello,

Here is a full list of javax.* namespace involved in JRE 8 and Java EE 8
Maybe this helps.

Rieon Ke.

Java SE

PackageJar File
javax.accessibilityrt.jar
javax.activationrt.jar
javax.activityrt.jar
javax.annotationrt.jar
javax.annotation.processingrt.jar
javax.cryptojce.jar
javax.crypto.interfacesjce.jar
javax.crypto.specjce.jar
javax.imageiort.jar
javax.imageio.eventrt.jar
javax.imageio.metadatart.jar
javax.imageio.plugins.bmprt.jar
javax.imageio.plugins.jpegrt.jar
javax.imageio.spirt.jar
javax.imageio.streamrt.jar
javax.jnlpjavaws.jar
javax.jwsrt.jar
javax.jws.soaprt.jar
javax.lang.modelrt.jar
javax.lang.model.elementrt.jar
javax.lang.model.typert.jar
javax.lang.model.utilrt.jar
javax.managementrt.jar
javax.management.loadingrt.jar
javax.management.modelmbeanrt.jar
javax.management.monitorrt.jar
javax.management.openmbeanrt.jar
javax.management.relationrt.jar
javax.management.remotert.jar
javax.management.remote.rmirt.jar
javax.management.timerrt.jar
javax.namingrt.jar
javax.naming.directoryrt.jar
javax.naming.eventrt.jar
javax.naming.ldaprt.jar
javax.naming.spirt.jar
javax.netrt.jar
javax.net.sslrt.jar
javax.printrt.jar
javax.print.attributert.jar
javax.print.attribute.standardrt.jar
javax.print.eventrt.jar
javax.rmirt.jar
javax.rmi.CORBArt.jar
javax.rmi.sslrt.jar
javax.scriptrt.jar
javax.security.authrt.jar
javax.security.auth.callbackrt.jar
javax.security.auth.kerberosrt.jar
javax.security.auth.loginrt.jar
javax.security.auth.spirt.jar
javax.security.auth.x500rt.jar
javax.security.certrt.jar
javax.security.saslrt.jar
javax.smartcardiort.jar
javax.sound.midirt.jar
javax.sound.midi.spirt.jar
javax.sound.sampledrt.jar
javax.sound.sampled.spirt.jar
javax.sqlrt.jar
javax.sql.rowsetresources.jar,rt.jar
javax.sql.rowset.serialrt.jar
javax.sql.rowset.spirt.jar
javax.swingrt.jar
javax.swing.borderrt.jar
javax.swing.colorchooserrt.jar
javax.swing.eventrt.jar
javax.swing.filechooserrt.jar
javax.swing.plafrt.jar
javax.swing.plaf.basicrt.jar
javax.swing.plaf.basic.iconsresources.jar
javax.swing.plaf.metalrt.jar
javax.swing.plaf.metal.iconsresources.jar
javax.swing.plaf.metal.icons.oceanresources.jar
javax.swing.plaf.metal.soundsresources.jar
javax.swing.plaf.multirt.jar
javax.swing.plaf.nimbusrt.jar
javax.swing.plaf.synthrt.jar
javax.swing.tablert.jar
javax.swing.textrt.jar
javax.swing.text.htmlresources.jar,rt.jar
javax.swing.text.html.parserresources.jar,rt.jar
javax.swing.text.rtfrt.jar
javax.swing.text.rtf.charsetsresources.jar
javax.swing.treert.jar
javax.swing.undort.jar
javax.toolsrt.jar
javax.transactionrt.jar
javax.transaction.xart.jar
javax.xmlrt.jar
javax.xml.bindresources.jar,rt.jar
javax.xml.bind.annotationrt.jar
javax.xml.bind.annotation.adaptersrt.jar
javax.xml.bind.attachmentrt.jar
javax.xml.bind.helpersresources.jar,rt.jar
javax.xml.bind.utilresources.jar,rt.jar
javax.xml.cryptort.jar
javax.xml.crypto.domrt.jar
javax.xml.crypto.dsigrt.jar
javax.xml.crypto.dsig.domrt.jar
javax.xml.crypto.dsig.keyinfort.jar
javax.xml.crypto.dsig.specrt.jar
javax.xml.datatypert.jar
javax.xml.namespacert.jar
javax.xml.parsersrt.jar
javax.xml.soaprt.jar
javax.xml.streamrt.jar
javax.xml.stream.eventsrt.jar
javax.xml.stream.utilrt.jar
javax.xml.transformrt.jar
javax.xml.transform.domrt.jar
javax.xml.transform.saxrt.jar
javax.xml.transform.staxrt.jar
javax.xml.transform.streamrt.jar
javax.xml.validationrt.jar
javax.xml.wsrt.jar
javax.xml.ws.handlerrt.jar
javax.xml.ws.handler.soaprt.jar
javax.xml.ws.httprt.jar
javax.xml.ws.soaprt.jar
javax.xml.ws.spirt.jar
javax.xml.ws.spi.httprt.jar
javax.xml.ws.wsaddressingrt.jar
javax.xml.xpathrt.jar


Java EE

PackageJar File
javax.activationactivation-1.1.jar
javax.annotationjavax.annotation-api-1.3.jar
javax.annotation.securityjavax.annotation-api-1.3.jar
javax.annotation.sqljavax.annotation-api-1.3.jar
javax.batchjavax.batch-api-1.0.1.jar
javax.batch.apijavax.batch-api-1.0.1.jar
javax.batch.api.chunkjavax.batch-api-1.0.1.jar
javax.batch.api.chunk.listenerjavax.batch-api-1.0.1.jar
javax.batch.api.listenerjavax.batch-api-1.0.1.jar
javax.batch.api.partitionjavax.batch-api-1.0.1.jar
javax.batch.operationsjavax.batch-api-1.0.1.jar
javax.batch.runtimejavax.batch-api-1.0.1.jar
javax.batch.runtime.contextjavax.batch-api-1.0.1.jar
javax.decoratorcdi-api-2.0.jar
javax.ejbjavax.ejb-api-3.2.2.jar
javax.ejb.embeddablejavax.ejb-api-3.2.2.jar
javax.ejb.spijavax.ejb-api-3.2.2.jar
javax.eljavax.el-api-3.0.0.jar
javax.enterprisejavax.enterprise.deploy-api-1.7.jar,cdi-api-2.0.jar,javax.enterprise.concurrent-api-1.1.jar
javax.enterprise.concurrentjavax.enterprise.concurrent-api-1.1.jar
javax.enterprise.contextcdi-api-2.0.jar
javax.enterprise.context.controlcdi-api-2.0.jar
javax.enterprise.context.spicdi-api-2.0.jar
javax.enterprise.deployjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.modeljavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.model.exceptionsjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.sharedjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.shared.factoriesjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.spijavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.spi.exceptionsjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.spi.factoriesjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.deploy.spi.statusjavax.enterprise.deploy-api-1.7.jar
javax.enterprise.eventcdi-api-2.0.jar
javax.enterprise.injectcdi-api-2.0.jar
javax.enterprise.inject.literalcdi-api-2.0.jar
javax.enterprise.inject.secdi-api-2.0.jar
javax.enterprise.inject.spicdi-api-2.0.jar
javax.enterprise.inject.spi.configuratorcdi-api-2.0.jar
javax.enterprise.utilcdi-api-2.0.jar
javax.facesjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.annotationjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.applicationjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.beanjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.componentjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.component.behaviorjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.component.htmljavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.component.searchjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.component.visitjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.contextjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.convertjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.eljavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.eventjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.flowjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.flow.builderjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.lifecyclejavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.modeljavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.pushjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.renderjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.validatorjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.viewjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.view.faceletsjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.faces.webappjavax.faces-api-2.3.jar,javax.faces-2.3.2.jar
javax.injectjavax.inject-1.jar
javax.interceptorjavax.interceptor-api-1.2.2.jar
javax.jsonjavax.json.bind-api-1.0.jar,javax.json-api-1.1.4.jar
javax.json.bindjavax.json.bind-api-1.0.jar
javax.json.bind.adapterjavax.json.bind-api-1.0.jar
javax.json.bind.annotationjavax.json.bind-api-1.0.jar
javax.json.bind.configjavax.json.bind-api-1.0.jar
javax.json.bind.serializerjavax.json.bind-api-1.0.jar
javax.json.bind.spijavax.json.bind-api-1.0.jar
javax.json.spijavax.json-api-1.1.4.jar
javax.json.streamjavax.json-api-1.1.4.jar
javax.mailjavax.mail-1.6.0.jar
javax.mail.eventjavax.mail-1.6.0.jar
javax.mail.internetjavax.mail-1.6.0.jar
javax.mail.searchjavax.mail-1.6.0.jar
javax.mail.utiljavax.mail-1.6.0.jar
javax.managementjavax.management.j2ee-api-1.1.2.jar
javax.management.j2eejavax.management.j2ee-api-1.1.2.jar
javax.management.j2ee.statisticsjavax.management.j2ee-api-1.1.2.jar
javax.persistencejavax.persistence-2.2.0.jar
javax.persistence.criteriajavax.persistence-2.2.0.jar
javax.persistence.metamodeljavax.persistence-2.2.0.jar
javax.persistence.spijavax.persistence-2.2.0.jar
javax.resourcejavax.resource-api-1.7.1.jar
javax.resource.ccijavax.resource-api-1.7.1.jar
javax.resource.spijavax.resource-api-1.7.1.jar
javax.resource.spi.endpointjavax.resource-api-1.7.1.jar
javax.resource.spi.securityjavax.resource-api-1.7.1.jar
javax.resource.spi.workjavax.resource-api-1.7.1.jar
javax.securityjavax.security.jacc-api-1.6.jar,javax.security.enterprise-api-1.0.jar,javax.security.auth.message-api-1.1.1.jar
javax.security.authjavax.security.auth.message-api-1.1.1.jar
javax.security.auth.messagejavax.security.auth.message-api-1.1.1.jar
javax.security.auth.message.callbackjavax.security.auth.message-api-1.1.1.jar
javax.security.auth.message.configjavax.security.auth.message-api-1.1.1.jar
javax.security.auth.message.modulejavax.security.auth.message-api-1.1.1.jar
javax.security.enterprisejavax.security.enterprise-api-1.0.jar
javax.security.enterprise.authenticationjavax.security.enterprise-api-1.0.jar
javax.security.enterprise.authentication.mechanismjavax.security.enterprise-api-1.0.jar
javax.security.enterprise.authentication.mechanism.httpjavax.security.enterprise-api-1.0.jar
javax.security.enterprise.credentialjavax.security.enterprise-api-1.0.jar
javax.security.enterprise.identitystorejavax.security.enterprise-api-1.0.jar
javax.security.jaccjavax.security.jacc-api-1.6.jar
javax.servletjavax.servlet-api-4.0.0.jar,javax.servlet.jsp.jstl-api-1.2.2.jar,javax.servlet.jsp-api-2.3.3.jar
javax.servlet.annotationjavax.servlet-api-4.0.0.jar
javax.servlet.descriptorjavax.servlet-api-4.0.0.jar
javax.servlet.httpjavax.servlet-api-4.0.0.jar
javax.servlet.jspjavax.servlet.jsp.jstl-api-1.2.2.jar,javax.servlet.jsp-api-2.3.3.jar
javax.servlet.jsp.eljavax.servlet.jsp-api-2.3.3.jar
javax.servlet.jsp.jstljavax.servlet.jsp.jstl-api-1.2.2.jar
javax.servlet.jsp.jstl.corejavax.servlet.jsp.jstl-api-1.2.2.jar
javax.servlet.jsp.jstl.fmtjavax.servlet.jsp.jstl-api-1.2.2.jar
javax.servlet.jsp.jstl.sqljavax.servlet.jsp.jstl-api-1.2.2.jar
javax.servlet.jsp.jstl.tlvjavax.servlet.jsp.jstl-api-1.2.2.jar
javax.servlet.jsp.tagextjavax.servlet.jsp-api-2.3.3.jar
javax.transactionjavax.transaction-api-1.3.jar
javax.validationvalidation-api-2.0.0.Final.jar
javax.validation.bootstrapvalidation-api-2.0.0.Final.jar
javax.validation.constraintsvalidation-api-2.0.0.Final.jar
javax.validation.constraintvalidationvalidation-api-2.0.0.Final.jar
javax.validation.executablevalidation-api-2.0.0.Final.jar
javax.validation.groupsvalidation-api-2.0.0.Final.jar
javax.validation.metadatavalidation-api-2.0.0.Final.jar
javax.validation.spivalidation-api-2.0.0.Final.jar
javax.validation.valueextractionvalidation-api-2.0.0.Final.jar
javax.websocketjavax.websocket-api-1.1.jar
javax.websocket.serverjavax.websocket-api-1.1.jar
javax.wsjavax.ws.rs-api-2.1.jar
javax.ws.rsjavax.ws.rs-api-2.1.jar
javax.ws.rs.clientjavax.ws.rs-api-2.1.jar
javax.ws.rs.containerjavax.ws.rs-api-2.1.jar
javax.ws.rs.corejavax.ws.rs-api-2.1.jar
javax.ws.rs.extjavax.ws.rs-api-2.1.jar
javax.ws.rs.ssejavax.ws.rs-api-2.1.jar
javax.xmljavax.xml.registry-api-1.0.8.jar,javax.ejb-api-3.2.2.jar,javax.xml.rpc-api-1.1.2.jar
javax.xml.registryjavax.xml.registry-api-1.0.8.jar
javax.xml.registry.infomodeljavax.xml.registry-api-1.0.8.jar
javax.xml.rpcjavax.ejb-api-3.2.2.jar,javax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.encodingjavax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.handlerjavax.ejb-api-3.2.2.jar,javax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.handler.soapjavax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.holdersjavax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.serverjavax.xml.rpc-api-1.1.2.jar
javax.xml.rpc.soapjavax.xml.rpc-api-1.1.2.jar




在 2019年5月14日，下午9:13，Greg Wilkins <gregw@xxxxxxxxxxx> 写道：

So if we went incremental, then what kind of change would necessitate changing to the name space?
  • Adding JPMS meta data to the jars?
  • Fixing mistakes in API docs?
  • Deprecating methods?
It's hard to consider how much impact incremental will have if we don't know how often APIs will cross the threshold and need to change names.    

For the servlet spec, JPMS meta data is really needed 6 months ago, so if that is a breaking change then servlets will increment either in EE9 or soon after.  Being able to maintain the API doc is also valuable, but I'm not sure it would force an increment on it's own.  Of course deprecating methods in anticipation of a future release would also be desirable with a good lead time before any release of an updated spec.  So if we start work on servlet changes in 2020, then we'd probably want to deprecate methods in 2020.        So my fear with incremental is that with the rate of EE releases, it may just become a few medium bangs.. ie make the EE10 & EE11 just as painful as EE9.

Also, can somebody confirm that no matter what, not all javax APIs are included in this.  Specifically things like javax.sql and javax.naming are part of the JRE and thus wont be renamed.   Is there a good definitive list somewhere of what APIs are affected?

cheers

On Tue, 14 May 2019 at 14:12, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
I have seen it as a 50/50 split from the dev mailing list. Seems heavily biased toward BigBang as far as I can tell.

On Mon, May 13, 2019 at 5:09 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Trying to catch up after the weekend...  I agree with Mark's assessments of the joint presentation we did at Red Hat Summit.  There was definitely not a strong inclination towards either incremental or big bang approaches -- so 50/50 split is a good characterization.  And, if a big bang approach is taken, then do it quickly via a Jakarta EE 9 release with nothing else.
 
I also want to emphasize again that Jakarta EE 8 will still support the javax namespace.  Nothing is changing in the Jakarta EE 8 timeframe related to the namespace.  This was a topic that came up several times during my Red Hat Summit discussions.  We all need to reiterate that story so that we're all on the same page. 

---------------------------------------------------
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
 
 
----- Original message -----
From: Mark Little <markclittle@xxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ken Finnigan <kfinniga@xxxxxxxxxx>, John Clingan <jclingan@xxxxxxxxxx>, Kevin Sutter <sutter@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Date: Fri, May 10, 2019 5:58 AM
 
Should have also added: maybe one of Ken/Kevin/John can recall better than I, but I seem to recall that if Big Bang was the path taken a small percentage expressing a preference for a Jakarta EE 9 which only changed the namespace and nothing else. There was also a similar percentage in favour of a "Java EE compatible" profile, although as Kevin correctly pointed out, vendors will support javax for a long time to come.
 
Mark.
 
On Fri, May 10, 2019 at 6:53 AM Mark Little <markclittle@xxxxxxxxx> wrote:
Ken, John, Kevin (all in cc in case they're not on this group) and I gave a presentation yesterday on the EAP roadmap, MicroProfile and Jakarta EE at Red Hat Summit. For context, the session has been on the agenda for months and the EAP roadmap presentation is a regular at Summit, typically attended by developers, managers and sys admins. There were about 40 people in the room.
 
Clearly we modified the presentation this week to address the recent javax announcements and solicit feedback on the options being presented (Incremental or Big Bang). Given the mix of people in the room and the fact they're all invested in EAP or WildFly in one way or another, it's reasonable to state that they understood the impact of both but there were a few clarifying questions. I spoke with Kevin afterwards to get some confirmation that my assessment was accurate and from the feedback we received we'd put it down as a 50/50 split, i.e., 50% expressed a preference for Incremental and 50% for Big Bang.
 
Just feeding this back as promised.
 
Mark.
 
 
On Mon, May 6, 2019 at 7:23 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings.  The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]
 
As announced in the Update on Jakarta EE Rights to Java Trademarks[1] post on Friday, future modification of the javax namespace will not be allowed.  While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.
 
To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyone’s part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.
 
In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.
 
The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.
 
Other proposals should incorporate the following considerations and goals:
 
  • The new namespace will be jakarta.*
  • APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.
  • Even a small maintenance change to an API would require a javax to jakarta change of that entire specification. Examples include:
    • Adding a value to an enum
    • Overriding/adding a method signature
    • Adding default methods in interfaces
    • Compensating for Java language changes
  • Binary compatibility for existing applications in the javax namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority in their products. However, there is a strong desire not to deter new implementers of the jakarta namespace from entering the ecosystem by requiring they also implement an equivalent javax legacy API.
  • There is no intention to change Jakarta EE 8 goals or timeline.
  • Community discussion on how to transition to the jakarta namespace will conclude Sunday, June 9th, 2019.
 
It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.

Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features

The heart of this proposal is to do a one-time move of API source from the javax namespace to the jakarta namespace with the primary goal of not prolonging industry cost and pain associated with the transition.
 
Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.
 
  • Some or all Jakarta EE APIs under javax would move immediately into jakarta as-is.
  • Any packages not moved from javax to jakarta could be included in Jakarta EE, but would be forever frozen and never move to the jakarta namespace.
  • Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the javax to jakarta namespace change and immediately released.
  • Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.
  • Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.
Pros:
  • One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Easily understood rule: everything Jakarta EE 8 and before is javax, Jakarta EE 9 and after is jakarta
  • Consistent with the javax to jakarta Maven groupId change.
  • Highest degree of flexibility and freedom of action, post-change.
  • Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.
Cons:
  • Largest upfront cost for everyone.
  • Specifications that may never be updated would still likely be moved.
  • Decision to not move a specification is permanent and therefore requires high confidence.
Decisions:
  • Which specifications, if any, would we opt not to move?
  • Would we take the opportunity to prune specifications from Jakarta EE 9?
  • Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?
 

Proposal 2: Incremental Change in Jakarta EE 9 and beyond

Evolve API source from javax to the jakarta namespace over time on an as-needed basis.  The most active specifications would immediately move in Jakarta EE 9.  Every Jakarta EE release, starting with version 10 and beyond may involve some javax to jakarta namespace transition.
 
  • The most active APIs would immediately move from javax to jakarta
  • APIs not changed or determined by the community to be unlikely to change would stay in javax
  • Jakarta EE 9 would be a mix of javax and jakarta packaged APIs
  • If a change was needed to a javax API post Jakarta EE 9 for any reason, that API would transition from javax to jakarta.
  • Jakarta EE 10 would be a mix of javax and jakarta packaged APIs, but a different mix than Jakarta EE 9.
  • At some point down the road, Jakarta EE xx, it may be decided that the migration from javax to jakarta is “done” and the final APIs are moved.
Pros:
  • Cheaper up front cost and reduced immediate noise.
  • No need to move specifications unless there is an immediately visible benefit.
  • Potential for less impact from API change overall.
Cons:
  • Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
  • Use of restricted javax namespace prolonged.
  • Frustration of “always changing” packages may deter application developers and become a permanent perception of the brand.
  • Difficulty in remembering/knowing which Jakarta EE release an API was moved. “Is Connector javax or jakarta in Jakarta EE 11?”
  • Difficulty in keeping the industry in sync.
  • New implementations may find themselves having to deal with the javax to jakarta transition, unable to avoid legacy costs and therefore decide not to enter the space.
  • Transitive dependencies to other specifications may make incremental change difficult or impossible.
  • Restrictions on what Java SE implementation can be used for certification
Decisions:
  • Do we start small or start large?
  • Which APIs would immediately need to be changed?

Out of Scope

The following are very important community discussions, but do not require a decision in the time-frame allotted:
 
  • Roadmap or release date for any Jakarta EE.next that would contain new features
  • List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any
  • Specification text around backwards compatibility requirements, if any
  • What profiles should be defined
 
However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.
 
 
 
_______________________________________________
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

Back to the top