Naming is hard and changing names that we have become attached to is even harder. Most of us also have this inherent feeling that change is bad and should be avoided. At the same time, we live in this ever-changing industry where embracing change is, not only a mantra but also a requirement to survive. Add to this, that some of the names we are talking about in this context are pretty bad. Some of them so long that we have to google the acronym to be able to describe what it actually abbreviates. Some of the acronyms we are using daily aren’t even acronyms, but more of an artificially created letter combination following some sort of standard. A couple of examples:
I think most of us agree that Jakarta Authentication is far more easy to remember than The Java Authentication Service Provider Interface for Containers.It may not be as precise and descriptive, but should that really be the requirement of the name? Wouldn’t it be better to have a name that we can remember and use in daily talk?
Think about Jakarta REST versus Java™ API for RESTful Web Services. I don’t think anyone ever uses the long name, but rather the abbreviation/acronym JAX-RS. Which isn’t even an acronym! It is just some collection of letters to fit into the JAX-* naming standard used by Sun back in the J2EE days.
The Java™ Message Service specification covers create, send receive and read messages. So it is much more than just a message service. In this case, Jakarta Messaging would be a much more descriptive name.
Please join the discussion by commenting on the issue related to the particular specification you are interested in. If you are the first commenting on an issue, please move it to the In Progress column. I will try to keep the status updated, but all help is welcome.
I am positive to renaming the specifications even if it is a lot of work and may seem like an unnecessary use of resources. It is an opportunity to fix something to the better in one go and this is probably the perfect time to do it.
Those of you following Jakarta EE probably know that the upcoming Jakarta EE 8 release will be functionally equivalent to Java EE 8. The reason for this is that we want to prove that the transfer from Oracle is complete and that we are able to produce the processes, specifications, test suites and a compatible implementation through the Eclipse Foundation.
So far Eclipse GlassFish 5.1 has been released and certified as Java EE 8 compatible. The next step is to set everything up for Jakarta EE 8 and release Eclipse GlassFish 5.2 as Jakarta EE 8 compatible.
One of the tasks that need to be done in order to release Jakarta EE 8 is to transform the existing Java EE specification documents to Jakarta EE. This will involve renaming the specifications according to the trademark agreement between Oracle and Eclipse Foundation*.
What I have described in this post is just a couple of the things that need to be done regarding the specifications in order to get Jakarta EE 8 out the door. There are a lot of other activities involving the TCK and not the least Eclipse GlassFish 5.2 that need to be done as well. But for now, the most critical item is to get through the legal hurdles of the trademark agreement and the transfer of the specification documents over to Eclipse Foundation.
*) The details of this agreement is yet to be defined when this blog post is published.
The Jakarta EE 2019 Developer Survey is available!
Take the survey today and help the community gain a better understanding of what’s in store for Java innovation. This is your chance to share your thoughts and experiences and help shape the future for Jakarta EE!
Responses will be collected until March 25, 2019, at 11:59 PM Pacific Time
I know we are well into 2019 now and that I did sum up 2018 in early January. In that post, I mentioned that Christian and I received the JCP Outstanding Spec Lead Award at the JCP party for our work on JSR 371. At the same ceremony, Daniel Dias Dos Santos received the Outstanding Adopt-a-JSR Participant Award, also for his work on JSR 371.
The SPRING INITIALIZR at https://start.spring.io has been around for a while and is the best way to bootstrap a new Spring Boot application.
So far, there hasn’t been a similar way to bootstrap a new MicroProfile project even if the different vendors have provided starters for their implementations. But the wait is over! The MicroProfile Starter is currently in “Beta”, but works like a charm. Just navigate to https://start.microprofile.io and start generating.
Based on which version of MicroProfile you select, you will get the available implementations that supports that particular version. You have the option of generating examples for the specifications included in the selected version. This is an excellent way to learn how the different technologies work.
Devnexus 2019 is happening in Atlanta next month. This is truly an awesome tech conference run by the Atlanta Java Users Group and I am so happy to be part of it as a speaker for the third time.
My talk this year is a presentation of patterns commonly used in microservice architectures. Each of the patterns will be explained and demoed live using Eclipse MicroProfile.
Another think I look forward to at Devnexus is to meet up with will all the people participating in Jakarta EE that are present at the conference.
The party theme this year is R3, which stand for Reflect, Relax, Recharge and is definitely the place to be to meet all the awesome community members, Java Champions and Groundbreaker Ambassadors present! Everybody will be there, and so should YOU!
There is a limited number of super cool t-shirts exclusively made for this party. One of them could be yours simply by writing a blog post!
The Java™ Community Process has been updated through JSR 387: Streamline the JCP Program. The most significant change is to open up for Iterative JSRs, i.e. JSRs that intend to deliver multiple releases of a technology on a time-based cadence. The driving force for this change is the 6 month release cadence for Java™ SE.
The first JSR using the option for being iterable is JSR 388: Java™ SE 13 (I guess the JSR name will have to be changed to not include the version number…).
Another change made in this update where changes to reviews and ballots in order to make the process even lighter to accommodate shorter release cycles.
I am super happy to have gotten the opportunity to test out Oracle Functions through theCloud Native Limited Availability Program. When I last tried out running serverless functions in Oracle Cloud during the Oracle Groundbreaker APAC Tour last year, there were two options available. Either run my own Fn server in a virtual machine or set it up in a managed Kubernetes cluster. Now, a third option is available!
Oracle Functions is built on Oracle Cloud Infrastructure (OCI) and offer a managed environment for the Fn project. This means that you don’t have to manually manage an Fn cluster yourself. It also means that any function that runs on Oracle Functions will also run on any Fn server, something that offers you full flexibility.
The Fn project supports functions written in Go, Java, Node.js, Python or Ruby. The fn-duke function that I am using in this test is, of course, written in Java.
Oracle has made a good choice when investing in the Fn project and use it as a basis for the Oracle Functions platform. It integrates extremely well with Fn and no extra tooling is needed to get started.
The Apache NetBeans project is really shaping up. Version 10.0 was released on the 27th of December 2018. The main features added since version 9.0 are listed on the download page. For me personally, the most important feature is the JDK 11 Support.
So, what about Java EE then?
Until all the NetBeans sources have been transferred from Oracle to Apache and incorporated into the Apache NetBeans build, an additional step is required in order to get Netbeans set up for Java EE development.
The first thing you need to do is to add the NetBeans 8.2 Distribution Update Center. Select Tools->Plugins in Apache NetBeans 10.0. Then click on the Settings tab and choose Add. Paste in the URL:
After saving the configuration, the next step is to select the Available Plugins tab and type java ee in the search field.
As a minimum, check the plugin called Java EE Base and click the Install button. Follow the instructions and accept the licenses. NetBeans will need to restart before continuing after the installation.
After this, you are able to set up a Java EE server as shown with GlassFish 5.0 below. Choose Tools->Servers and then click Add Server.