Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] NEW VOTE 2: Leave Jakarta Activation in javax namespace

These votes had to finish one week ago.
They still continue. Why?
Architect's arguments about leaving javax in Activation API because Java 11 removed it.
My question: Is Jakarta EE compiled with Java 11+? No! It is compiled with Java 8. Has the Arcitect realized that the modification of application server may cause classloader problems in J8-10 due to the package is the same? It is a perfect reason to repackage javax to jakarta everywhere.

Next thing is very interesting. The Architect provided a link from Tomitribe with dependencies between Java EE packages. But I found that JSR-93 is used in JAX-WS specification as a dependency in he PDF/text. It is written in the text of the PDF and therefore the analysis of the dependencies in EE packages is not enough to do. You have to read all spects in EE, evaluate them and rewrite beforehand! Do it together with developers from TomEE, etc.

On Tue, Dec 10, 2019 at 10:37 AM Jonathan Gallimore <jgallimore@xxxxxxxxxxxxx> wrote:
-1 - my personal preference would be to migrate to the new package, particularly in light of Bill's proposed changes highlighted in this thread.

Jon

On Wed, Dec 4, 2019 at 11:33 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Preamble:  https://www.eclipse.org/lists/jakartaee-platform-dev/msg01180.html

Please vote +1/0/-1 on the following.  Any non +1 vote, please provide reasoning in your reply.  Thank you!

Required (leave in javax namespace) - Vote
• Jakarta Activation 1.2

Jakarta Activation was one of the APIs dropped from Java SE 11 per JEP 320.  Several Jakarta EE technologies require the use of Jakarta Activation, so we can't make it optional.  It is required for Jakarta EE.  This vote is for whether we move this feature to the jakarta namespace (-1) or leave it in the javax namespace (+1).  The recommendation is to Jakarta Activation in the javax namespace.  And, if at some later date, this API needs to evolve and move to the jakarta namespace, then we can deal with the ripple effect on other specs at that time.


Note:  A -1 vote indicates that you want Jakarta Activation to be migrated to the jakarta namespace.  And, if we do that, then there is a ripple effect that will also require corresponding changes to jaxb, jax-ws, and soap.  Thus, a -1 vote here means that Vote 3 on the other Optional specs won't apply.  That is, voting -1 here and +1 on Vote 3 doesn't make any sense.  Check out this tool from Tomitribe:  https://www.tomitribe.com/jakarta/ns/poll/vote

Note2:  This assumes that all of the existing Specification PRs for these technologies are properly brought under the EE4J umbrella.  We discussed these at the Spec Committee call today and we are well aware that we need to move on these and get them approved.
https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3Ajavase

---------------------------------------------------
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
_______________________________________________
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


--
Jonathan Gallimore
_______________________________________________
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