Java

CodeMash 2022

CodeMash is a conference I always enjoy very much coming back to, so I was extremely pleased when they decided to have a conference this year despite all that is going on. It really shows that it is possible to arrange in-person events in a safe way.

If I should describe CodeMash in one word, it would be Friendly. It is an extremely good vibe at the conference. It does, of course, help that it is held in the conference center of an indoor water park. The organizers are 100% transparent regarding the organization, budget, and everything else.

CodeMash offers a mentoring program for new speakers. When you get a talk is accepted, you get the question of whether you would consider mentoring a new speaker or be mentored by an experienced one. Since I consider myself pretty experienced as a speaker, I signed up as a mentor this year as well.

I think mentoring programs like this one is an excellent idea and would encourage anyone offered to participate in one to do so!

My talk, Jakarta EE 10 is Coming Your Way! was scheduled for the last day of the conference. Actually to the last time slot before the conference closing session. Usually, I prefer to be scheduled earlier in the program, but I guess that’s how every speaker feels. At CodeMash they have a closing session with a raffle, so there is another incentive for the attendees to stick around rather than beat the traffic on Friday afternoon.

To sum up, CodeMash was an excellent start to the 2022 conference year and I hope to be back next year! I also look forward to speaking at lots of conferences in the upcoming months and meeting up with community members in the conferences-within-the-conference happening at meals, parties, and hallways between and after sessions.

25 Years of Java!

25 years and still going strong! Java is everywhere. It is the #1 programming language in the World. And it continues to evolve! Java has been a part of my entire professional career. Let’s get together and celebrate the past 25 years and look ahead for the next 25!

My #movedbyJava timeline

1996: Wrote my first Hello, World! in Java
1998: Started my professional career as a Java programmer
1999: My first JavaOne
2007: Joined the Java Community Process (JCP)
2013: First time presenting at JavaOne
2016: Became Java Champion
2016: Elected into the JCP Executive Committee
2016: Got a Duke tattoo
2020: Still coding Java

Oracle CodeOne 2019

I am on my way back home from this year’s Oracle CodeOne. As always, this week is so filled with content and activities that it just flies by.

In previous years, I have always had the sort of empty feeling on Thursday (the last day of the conference); the exhibition hall and Groundbreakers Hub is packed away, lunch in the hallways, lots of people walking around with luggage just catching a couple of sessions before heading home.

This year was different. As Ed Burns said in the talk he held together with Phillip Krüger that he found Thursday to be the best day of the conference, to be able to just attend sessions without all the other distractions. And I agree! This year, I listened to great talks from 9 in the morning until 15 in the afternoon with only 15 min breaks between the sessions. No distractions, other than the usual short hallway discussions between the sessions.

and

Jakarta EE 8 was launched the week before CodeOne. Another important milestone for the community! We had a lot of great talks, BOFs and hallway discussions.

The general impression of this edition of CodeOne is that it was smaller than last year. Both in the number of attendees, but also the number of exhibitors. The community spirit, however, was as strong as always!

New Challenges Ahead

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!

Transitioning Jakarta EE to the “jakarta” namespace

As described in Jakarta Going Forward, we need to transition the Jakarta EE specifications to the jakarta.* namespace/base package. After long and intense discussions in the Jakarta EE Specification, we have proposed two possible ways forward to kick-start the discussions on this thread.

In this post, I am highlighting some of the content of the initial post to the mailing list for reference.

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.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

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.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

Other Proposals

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.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

Contribute

There are already a lot of contributions and lively discussions going on. Please make sure you join the Jakarta EE Platform Developer Discussions mailing list https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev to take part in the conversation. At the time of writing this post, the number of subscribers to the list has more than doubled! Another proof of the passion and commitment in the Jakarta EE community!

Jakarta Going Forward

The agreement between the Eclipse Foundation and Oracle regarding rights to Java trademarks has been signed! This is truly an important milestone for Jakarta EE since we will now be able to move forward with Jakarta EE.

As outlined in https://eclipse-foundation.blog/jakarta-ee-java-trademarks, there are two major areas of impact on the Jakarta EE projects:

  • Java Trademarks
  • The javax.* Namespace

Java Trademarks

One part of the agreement is regarding the use of Java trademarks. The implications for Jakarta EE is that we have to rename the specifications and the specification projects. This work is ongoing and is tracked in our specification renaming board on GitHub. The EE4J PMC has published the following Naming Standard for Jakarta EE Specifications in order to comply with the trademark agreement.

The javax Namespace

The major topic of the agreement is around the use of the javax namespace. The agreement permits Jakarta EE specifications to use the javax namespace as is only. Changes to the API must be made in another namespace.

While the name changes can be considered cosmetic changes, the restrictions on the use of the javax.* namespace come with some technical challenges. For example, how are we going to preserve backwards compatibility for applications written using the javax.* namespace?

The Jakarta EE Specifications Committee has come up with the following guiding principle for Jakarta EE.next:

Maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

With the restrictions on the use of the javax.* namespace, it is necessary to transition the Jakarta EE specifications to a new namespace. The Jakarta EE Specification Committee has decided that the new namespace will be jakarta.*.

How and when this transition should happen is now the primary decision for the Jakarta EE community to make. There are several possible ways forward and the forum for these discussions is the Jakarta EE Platform mailing list.

Mailing List: jakartaee-platform-dev@eclipse.org

Please make sure that you subscribe to the mailing list and join in on the discussion. We hope that we will be able to reach some form of consensus within a month that can be presented to the Specification Committee for approval.

An Opportunity

While the restrictions on the use of Java trademarks and the javax.* namespace impose both practical as well as technical challenges, it is also an opportunity to perform some housekeeping.

By renaming the specifications, we can get a uniform, homogeneous naming structure for the specifications that makes more sense and is easier on the tongue than the existing. By having clear and concise names, we may even get rid of the need for abbreviations and acronyms.

The shift from javax.* to jakarta.* opens up for the possibility to differentiate the stable (or legacy) specifications that have played their role from the ones currently being developed.

Jakarta EE Developer Survey 2019

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!

Jakarta EE 2019 Developer Survey
https://www.surveymonkey.com/r/JakartaEEMkt

Responses will be collected until March 25, 2019, at 11:59 PM Pacific Time

JCP Star Spec Lead 2018

Wow, what a year 2018 was for the MVC specification!

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.

And to top it all, Christian and I were announced as 2018 Star Spec Leads. Read more about the Star Spec Lead Program. 

A complete list of all Star Spec Leads can be found in the Star Spec Lead Hall of fame.

Have You Tried the MicroProfile Starter Yet?

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.

https://start.microprofile.io

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.

Java Community Process Update

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.

The™ Java Community Process