I am super excited to announce that October 1st, I will become the first Jakarta EE Developer Advocate at Eclipse Foundation!
So, What’s new? Hasn’t this guy been doing this for years already?
Well, yes, and no. My day job has always been working as a consultant even if I have been fortunate that Cybercom Sweden (my employer of almost 15 years) has given me the freedom to also work on open source projects, community building and speaking at conferences and meetups.
What’s different then?
Even if I have had this flexibility, it has still been part-time work which has rippled into my spare time. It’s only so much a person can do and there are only 24 hours a day. As a full-time Jakarta EE Developer Advocate, I will be able to focus entirely on community outreach around Jakarta EE.
The transition of the Java EE technologies from Oracle to Jakarta EE at Eclipse Foundations has taken a lot longer than anticipated. The community around these technologies has taken a serious hit as a result of that. My primary focus for the first period as Jakarta EE Developer Advocate is to regain the trust and help enable participation of the strong community around Jakarta EE. The timing of establishing this position fits perfectly with the upcoming release of Jakarta EE 8. From that release and forward, it is up to us as a community to bring the technology forward.
I think I have been pretty successful with being vendor-neutral throughout the years. This will not change! Eclipse Foundation is a vendor-neutral organization and I will represent the entire Jakarta EE working group and community as the Jakarta EE Developer Advocate. This is what distinguishes this role from the vendor’s own developer advocates.
I hope to see you all very soon at a conference or meetup near you!
OpenJDK64-Bit Server VM Corretto-8.202.08.1(build25.202-b08,mixed mode)
Amazon Corretto is licensed under the same license as OpenJDK (GPLv2 with CPE) and there are no costs associated with using it. Amazon will provide quarterly security updates to Corretto 8 at least until June 2023.
But Java 8 is sooo old!
Relax, Amazon plans to make Corretto 11 available during the first half of 2019. Corretto 11 will be based on OpenJDK 11.
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.
September 18 All code required for GF build contributed.
September 23 Eclipse GlassFish builds.
October 1 Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.
October 22 ⚡
CI/CD release pipelines completed.
October 22 Eclipse GlassFish 5.1-RC1 milestone release.
November 5 ⚡ Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.
November 30 ⚡ Release Review completed.
December 14 ⚡ Eclipse GlassFish 5.1 release. All CTS tests are passed.
There is a lot of work to do, so every contribution is appreciated, especially regarding setting up the CI/CD pipelines for all the EE4J projects. Take a look at our status sheet and sign up where you think you can contribute.
Java EE developers using NetBeans are used to be able to run and debug their thin-war applications in their application server of choice directly from NetBeans. When developing microservices packaged as über-or hollow-jars, you expect the same effortless way of running and debugging. The good news is that you can. In this post, I show step-by-step how to run and debug the WildFly Swarm version of CloudEE Duke in NetBeans.
Run WildFly Swarm application
The easiest way of running CloudEE Duke in NetBeans is to edit the Run project action for the project. Right click on CloudEE Duke, select properties and Actions as shown below.
Configure the Execute Goals to
packagewildfly-swarm:run, remove all the default properties and your’re all set. Run Project (
F6 ) will start the application using the WildFly Swarm Maven Plugin.
Debug WildFly Swarm Appliction
To enable debugging, you follow the same steps as described above, but in this case it is the Debug Project action you select.
Execute Goals is configured the same way as for Run, but in the Set Properties, you need to configure a debug port for WildFly Swarm. This is done by setting the
swarm.debug.port property, e.g. to 9000.
Debug ProjectCtrl-F5 will start the application in debug mode. Note that the execution will halt while waiting for the debugger to attach. See the screenshot below for how it will look in the log.
Select Debug->Attach Debugger from the menu in NetBeans. Change the value for Port to 9000 (or the value you chose in the previous step) and click OK.
To verify the setup, set a breakpoint at line 16 in the class
Then navigate to http://localhost:8080/hello. The execution will stop at the breakpoint at line 16 in
The Jakarta EE name has been out for about a month, and even if Mike Milinkovich explained the names and concepts pretty well in his blog post And the Name Is…, there still is a bit confusion about how it all relates and I get questions around it whenever the topic comes up. I have tried to sum up some of it here. Hope it helps!
Java EE, or Java™ Platform, Enterprise Edition, is the name of the current platform governed by the Java Community Process (JCP). The latest version is Java EE 8, which was released in September 2017.
Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.
Jakarta EE does not replace Java EE! It is the name for the platform evolving with Java EE 8 as a starting point. Java EE 8 will still exist, but there will not be any new versions of the platform.
Jakarta EE does not replace EE4J! It is the name of the platform based on the EE4J projects with Java EE 8 as a starting point.
I could probably write a long post about why my vote goes to Jakarta EE in the vote for new brand name to take over after Java EE, but it feels much more appropriate to refer to David Blevin‘s excellent description of the process in his blog post Java EE to Jakarta EE.
It has been tough on us keeping these discussions secret since we are all working for an open community and want to share everything. But the importance of securing a name that we as a community can trademark through the Eclipse Foundation makes it well worth the efforts.
2017 was an amazing year for me with a lot of speaking engagements at conferences in four different continents!
Per Lilja joined me in leading Javaforum Malmö and we managed to meet out target of four meetups each year. We are always looking for speakers, so don’t hesitate contact us if you want to present at one of our meetups.
Toward the end of the year, the EE4J PMC started up the work. The most pressing issue right now is to find a brand name to replace Java EE. Hopefully, this will be finalized in near future.
When Oracle announced that MVC 1.0 was withdrawn from Java EE 8, they also indicated that they were investigating a possible transfer to a community member or organization for completion as a standalone JSR. True to their word, a request for a transfer ballot of JSR 371 has now been submitted to the JCP Executive Committee.
I am happy to announce that I will be the receiving part of this transfer and thus will take over as Spec Lead for JSR 371.
So, why would I want to take over a JSR that ranked so low in the Java EE Survey? Well, there are several reasons for that:
First of all the incredible community support and interest there is for MVC 1.0. For example, JSR 371 is the most widely adopted JSR by Java User Groups participating in the Adap-a-JSR program. No less than 8 JUGs have adopted this JSR!
Secondly, I feel that the wording of the question in the survey may have played a role. The question for MVC was “How important is MVC API for the next generation of cloud and microservices applications? (1=Not Important, 2, 3, 4, 5=Very Important)”. Still, 505 responded Very Important and only 361 Not Important. The rest were pretty evenly distributed. See Java EE Survey Results for the complete numbers.
Third, only 1693 surveys were completed worldwide. Out of 10 million Java developers, this is an alarmingly low number taking into consideration that the survey was open for more than a month and there were massive encouragements for participation from the community, including Oracle.
Fourth, in the Java EE Guardians survey that was performed just prior to the Java EE 8 survey more than 30% of the respondents answered Very Important to the question “How important is it to add a new action-oriented MVC framework to Java EE?”.
The Way Forward
The most important thing right now is that the request for transfer is approved by the EC. The ballot closes January 30, so shortly after that the practical work may start.