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

Firstly, let me say this is a very well-written email. In order to better inform some of my own thoughts on this, I started a Twitter poll: https://twitter.com/reza_rahman/status/1124827840652939269. The results of the poll are very clear thus far but it will end in five days. In my experience, the polls are usually well stabilized by around 500-1000 input points. So far I have 600+ input points and here are the results:

* 21% - Keep as long as possible
* 64% - Ditch as soon as possible
* 13% - Not sure yet
* 02% - Other (please comment?)

I am happy to say this coincides with my own thoughts and the few customers I have had an opportunity to speak to about this personally. The thinking reflects the trade-offs already mentioned here so there is no productive purpose in repeating them. I therefore am voting for Proposal 1.

I urge that the Eclipse Foundation do a poll similar to mine - perhaps using the text here as the poll opener. While people care a great deal, they have busy lives. I suspect we won't get 600 response emails here. Hopefully the Eclipse Foundation will get thousands of responses to a poll. If that is really not something we wish to do, I would appreciate at least retweeting my tweet. For me, there is unquestionable value in a decision like this getting the broadest input possible.

Below are additional responses. I am removing extra text for brevity.

On 5/7/2019 7:23 AM, David Blevins wrote:
  • Which specifications, if any, would we opt not to move?

This is a tough one as specifications have transitive dependencies. It is perhaps better to start with a list of specifications that should move: WebSocket, JSON-B, JSON-P, Servlet, JSF, Batch, Concurrency, CDI, Bean Validation, EJB (I am a little sad I need to include this. I wish we had replaced it in Java EE 8), JPA, JMS, JavaMail, JAX-RS, JAX-WS, Java EE Security, JAXB.

  • Would we take the opportunity to prune specifications from Jakarta EE 9?

Yes. Everything that does not make the transitive list of dependencies above. We could go a step further and aim to remove even more in the future. There is a lot of cruft.

  • Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?
Stick with Java SE 8 if possible. That is what a majority of customers are still using. They have their reasons. Upgrading to Java SE 11 for Jakarta EE 10 is a good idea. There is good stuff that could be absorbed into Jakarta EE. In fact, we are not really even done adopting Java SE 8 yet.

Back to the top