By now you should all know that Quarkus 1.0 is out! Congratulations to the entire community team who have taken an initial idea we had in early 2018 through a public release almost a year later and then to a 1.0 only about 8 months after that. This is a significant milestone for everyone involved and particularly for helping to make Java relevant in the modern Kubernetes world. If you’ve been involved in this, whether as a contributor of code, raising issues, tweeting your opinions etc. then you should all take a bow!

I've seen frameworks and stacks come and go over the decades, with some of them being massively successful for their time. However, whether it's DCE, CORBA, JBoss itself, Spring ... I've never seen anything quite like Quarkus in terms of almost instantaneous popularity, the ability to capture the imagination of people, mine a deep-rooted need for Java developers and to create a new wave: true Kubernetes native Java middleware. As several people (non-Red Hatters/non-JBossians) have said, it truly feels like "a paradigm shift". It enables developers to bring their Java skills to Kubernetes and feel like they can be as productive (more productive) than developers using other languages.

I’m not going to repeat what I’ve already said about Quarkus technically in previous entries (go look if you haven’t seen them). However, I did want to make something clearer: the secret to Quarkus isn't re-architecting so many of the most popular Java frameworks and stacks, it’s not our work around OpenJDK Hotspot, it’s not how we use GraalVM (SubstrateVM), it’s not Eclipse MicroProfile use, it’s not a focus on serverless or Developer Joy, etc. There is no one thing that has really captured the attention of the community. It’s all of these and more, which in many ways makes the relatively short period of time Quarkus has been “alive” so much more impressive for what has been accomplished.

Now 1.0 isn’t the end of the road by any means! The community has great aspirations and goals ahead of them. We want to appeal to the broadest possible range of Java developers (ok, maybe other JVM languages too on a case by case basis). I won’t spoil the surprises to come (though since everything we’re doing is public, it’s not hard to find out). But suffice it to say I expect to see more around MicroProfile adoption and influence, more integration with Kubernetes/Knative/Istio etc., tooling improvements, FaaS, …

And of course another future step is to a fully supported product and for Quarkus to be used in other products, e.g., Red Hat Integration (where Camel-K will reside, for instance) and Red Hat Automation (where Kogito will reside). Busy times ahead but also exciting times!

Some things never quite go the way you expect or the way you want. Sometimes that means you get a pleasant surprise. Sometimes it doesn’t. When Red Hat, IBM, Tomitribe and Oracle stood together on stage back in 2017 to announce we were working together on moving all of Java EE 8 to an independent foundation, I think we all believed this was the next chapter for Enterprise Java.  Oracle has made the decision to enable the wider ecosystem to build more freely on the work of so many individuals over the previous 15+ years. It was a risk for everyone on that stage but probably no more so than for Oracle as they, via Sun Microsystems before them, had invested so much into Java EE over the years.

As the work progressed and we chose the Eclipse Foundation, we found a lot of interest in the community and even vendors who had previously eschewed Java EE, such as Microsoft, joined the work. Collectively we created the logo, various working groups, the Steering Committee, and presentation after presentation at various conferences and workshops. It really did begin to feel that we were back when J2EE was young and there was huge interest in its direction.

However, through all of this what those outside the Steering Committee didn’t see (couldn’t see) was the intense effort going on between Oracle and the Eclipse Foundation around the transfer of IP such that we could all go and evolve specifications which Oracle, Sun or others had traditionally driven through the JCP. There were lots of questions and concerns the teams had to address, such as: Could we keep the names? Could we evolve the javax namespace? At times it seemed like progress was being made only for something else to come up which further delayed things.

In the end, as the reader is likely already aware if the above link was clicked, it has not been possible for Oracle and the Eclipse Foundation to come to an agreement on a seamless transition for beyond Jakarta EE 8. To say that I’m disappointed is an understatement. We came so close to enabling a seamless future for Jakarta EE only for it to be pulled from our collective grasp. I’m not going to lay any blame for this because that doesn’t get us anywhere. I do want to say thanks to the Oracle engineering and PM teams involved from the start. Without people like Will Lyons and Tom Snyder, to name but two from the many others involved, I’m sure we wouldn’t have gotten as far and as close as we did. They suffered a lot of frustrations from Red Hat and others, likely also from their own legal team. They were in the middle of things and stayed sane and cooperative throughout. I’m pretty sure this isn’t the outcome they had wanted or expected. And of course it would be remiss of me to ignore the Eclipse Foundation team for trying their hardest too and likely equally disappointed.

So what next? Well let’s not forget that we haven’t finished Jakarta EE 8 yet (which will remain using the javax namespace). Therefore, we’ve got more work to do to finalise that and get various implementations out, including our very own WildFly and EAP; Red Hat remains committed to this effort. Getting to a Jakarta EE 8 release is a fantastic and important accomplishment which will help the great many community members, vendors and users who have Java EE deployments. It will ensure that Java EE 8 and Jakarta EE 8 users can move between the two with ease.

However, what are the steps beyond Jakarta EE 8? There are a couple that I see and I’m sure there will be others:

• As a community of users and developers we could try to move Jakarta EE forward but it isn’t going to be as simple as we had originally hoped. We have to change the javax namespace, update implementations, TCK, change the names of specifications for anything that we want to evolve and clearly that is going to have an impact on compatibility. Then if we (the community) decided that is an investment worth making, we will have to determine whether we do that wholesale up front, i.e., change everything immediately after Jakarta EE 8 is out just to be over and done with it, or do it when and if changes are really needed. Each option has its pros and cons (exercise left to reader). Also, new specifications under a different namespace can be added to Jakarta EE moving forward if we decided not to evolve any of the current specifications.
• If we decided to evolve only those specifications, TCKs, RIs etc. when and if needed then a parallel question should be whether Jakarta EE is the right place to do it or should this be elsewhere? If it’s Jakarta EE then it needs the community to have agreed definitively that there is a future for Jakarta EE and the existing specifications it embodies which requires them to evolve, regardless of any potential impact from this recent announcement. If the community cannot make that agreement then perhaps component pieces, such as CDI or JAX-RS, have life beyond even if they also have to be changed - the assumption here would likely have to be that any re-coding around the javax namespace would have more limited impact due to the more focussed use cases. If that were to be the community’s choice then I believe Eclipse MicroProfile would be the right place because it’s already supported by a large and similar group of community and vendors.

Therefore, let’s not focus on the past or what could have been with Jakarta EE. Someone else may analyse the in’s and out’s of the work when they come to write the history of Enterprise Java in the future, but for now we’d be better off looking to that future and collaborating where it makes sense. The community now have a number of key questions to answer, including how do we move forward under the Eclipse Foundation banner and evolve cloud-native Java?

At Summit this year I was able to meet with a number of our key customers and partners. I was also there to give a presentation with Dimitris on the future of enterprise Java, which was based a bit on an earlier DevNation Live session I gave. Now at the time I submitted the session I had no idea which customers would be there in San Francisco but it's always interesting to see how these things turn out because they came together very fortuitously. During the presentation we spoke about Jakarra EE and how it should bring together the Java communities to drive the evolution of enterprise Java towards cloud native. There was a lot of interest in the audience but it was afterwards that I probably had my most beneficial engagements with customers and analysts on the topic. The common thread with all of these meetings was that they had so-called monoliths and worried that they were being left behind by their competitors who were moving to microservices. Or so they believed.

If you are a student of history you may know about the early cold war where the US thought the USSR had huge stockpiles of nuclear weapons and used that belief to drive their own weapons plans, when in reality the USSR had very few and were just as ill informed as the Americans. I see the same with microservices: everyone believes they understand them, everyone worries their competitors are using them to get ahead and everyone wants them, when in reality they are fine with what they have or they don't need to move quite so quickly towards a new microservices architecture. But how does this play with the future of enterprise Java and specifically Jakarta EE? Well the aim with this industry wide effort is to allow developers to evolve their implementations (monoliths) towards more cloud native, agile implementations using microservices just as we have been doing with Eclipse MicroProfile based on Java EE. At their own pace. Using the skills their teams have built up over nearly two decades. Not throwing away experience but building upon it! Making data driven decisions based upon the needs to customers and their own developers. And if we can do this through the power of open source then let's add another benefit: collaboratively.

This was a key thing that the audience came away with and which our customers latched onto: don't throw away all you have learned and which works but build on it, evolve it. Evolve the people and processes as much as the software. That can give you the advantage over your competition if they are having to adopt entirely new stacks or frameworks or languages. Your advantage isn't in the software but in the people who developed it and know how your business works and why! Retaining them and their skills are key. They are the assets which cannot be obtained by contractors or consultants.

Another thing which may not be immediately apparent is that Jakarta EE is a prime example of what Hamming was taking about in his Turing Award speech by building on the shoulders of giants rather than reinventing the wheel: so much real world experience has defined the landscape of enterprise Java, of which Java EE plays a key part, and we don't want to lose that experience or the mature implementations based upon it. We want new systems to be as stable and reliable as old and to accomplish that we need many of the skilled developers and a lot of the software! Jakarta EE offers the best path forward for both!

Now while no Jakarta EE implementations yet exist we do have some work that is relevant. There's WildFly Swarm for a start and then of course there's EAP. Both available through RHOAR.

Mike from the Eclipse Foundation wrote a great post on the next thing we're doing around driving Java EE forward: the EE.next Working Group. There isn't really a lot more that I want to say which isn't covered in Mike's article and the point of my post is more to try to encourage everyone to get involved, whether you are representing a corporation, big or small, or just acting as an individual. I've said it before but I'll say it again: the future of Java EE will be determined by the community and you can help in many different ways. Start by joining the working group!

Recently the Java EE Guardians wrote an open letter on Java EE Naming and Packaging. This kicked off a long thread on the EE4J mailing list when Will Lyons, from Oracle, posted a response on behalf of Oracle. I won't go into specific details on the initial letter or Oracle's response as the interested reader can check them out directly. However, I will summarise the key points:

• The letter asks for the Java EE name to be licensed to the Eclipse Foundation so it can continue to be used; Oracle have said no in the past around this point;
• A limited form of use of the javax and javax.enterprise package names should be allowed for new specifications; Oracle has stated that they believe it should be possible (and is important) for existing specifications to continue to use these packages but not for new efforts;
• Continue to drive standards through the JCP.

I gave my input on these points in the thread but thought it would be good to pull out the relevant text here. I'll simply include it in quotes and the reader can check out more context by reviewing the archive or joining in on the thread.

First there was this piece ...

"I’m fairly sure I’ve said this before on some lists and also at JavaOne 2017 when we discussed some of this in various meetings but I will repeat here: whilst I would definitely have preferred to keep the javax namespace for new specifications and to perhaps retain the Java EE name for the branding, I understand Oracle’s position. Related to that, I therefore know that no amount of energy expended on trying to change these two things will result in a different outcome. However, I think what Oracle have done to this point in moving Java EE to Eclipse is much more important than a brand name or a Java package name and collectively we should expend that energy in moving the code and community forward collaboratively. EE4J will not fail because it’s not branded Java EE. EE4J will not fail because new specifications cannot be done under the javax package. EE4J will fail if we spend too much time away from driving these specifications forward and adding new specifications to adapt to changes in the developer space.

Therefore, whilst I understand what the Guardians have requested, I feel that we are at a point where we should focus on the positive aspects of what Oracle have done and build on those. Together we move EE4J forward and together we can make it a success!"

Then there was this ...

"When looking at where to move Java EE we (Oracle, IBM and Red Hat) did touch on the standards body option. I’m sure I wasn’t the only one, but I do recall raising the question about OASIS specifically because I know Oracle, IBM, Red Hat and others have worked together in OASIS many times over the years. However, there was universal agreement that whilst OASIS might be the right place for standards efforts such as WS-*, TOSCA and other things which might well be considered “protocol related”, it likely wasn’t the right place for Java and Java EE related activities which are much more developer focussed.

I also recall re-raising this with MikeM from Eclipse and others once we had announced the move to the Eclipse Foundation because clearly what we now have to do within Eclipse is create processes which look very much like those you’d find within an existing standards organisation, such as OASIS or W3C. There are pros and cons with this but ultimately the things which swayed me to say that we shouldn’t standardise within OASIS or elsewhere include the following:

- having the code in Eclipse and standards efforts elsewhere would mean individuals and corporations need to be members of multiple (at least two) bodies. Whilst that might not be too much of a hurdle for corporations, it’s not going to be easy for some individuals and would be a possible impediment to growing the community wide and deep.

- over the last 3 decades (ouch!) I’ve worked in pretty much all of the standards bodies around and whilst they have good processes for what they do, they’re not necessarily the right processes for what the community may need around EE4J. Furthermore, they don’t necessarily move quickly either. I believe we can come up with a bespoke process within Eclipse which feels more a natural part of the development effort than something which is adjunct to it."

I was also asked about the renaming of JBossAS to WildFly, which seems to very long ago now. I won't include the text here because I really want to encourage people who are that interested to read the thread and join in.

Onward!

JBoss and Fuse has always been about developer focus. Whether you're someone who builds applications with our projects and products, or someone who contributes to the construction of those projects, or a combination of the two, over the years we've been pretty successful at appealing to the Java and JVM communities. With initiatives like JBoss Everywhere, acquisitions such as FuseSource or FeedHenry, we've constantly grown our developer footprint and appeal. How we reach those developers, educate them on what we're doing, how we need their help etc. has always been a multi-faceted effort with JBoss.org playing a central role. If you've been with us long enough then you'll remember that JBoss.org has had a number of personality changes, going from driving interest in JBossAS as a project and other commercial activities, through the introduction of JBoss.com and making JBoss.org a purely project oriented site with focus on our many upstream projects and JBoss Labs, and then back to a more product focus coinciding with our move to give developers free access to our products, and more recently once again adding in more community efforts.

In the past few years we introduced the Red Hat Developer Program which is meant to appeal to a wider community of developers than just JBoss or Fuse. The long term aim has always been to cater to contributor developers (those who help us build our projects) and user/builder developers (those who use our projects and products to build their own applications). Slowly but surely we have moved closer towards that plan and now we are at a point where we have to consider how JBoss.org and developers.redhat.com can work better together. If you hadn't noticed, much of the JBoss developer work had moved to the developer.jboss.org location, leaving the main www.jboss.org page to focus on products (of course there are exceptions, including the various microsites like our research or IoT pages). The eventual plan is to fold the JBoss developer content into appropriate pages within the main Red Hat developer site; that's going to take a while though due to the other services and sites which are hosted from that site. But for now the product-oriented pages need to move over to developers.redhat.com and we are left with a question of where does www.jboss.org point to? There are two obvious options:

• It points to developer.jboss.org and in essence returns www.jboss.org to the community focus it had a few years ago.
• It points to developers.redhat.com, giving www.jboss.org a feel closer to that which existed at the start of the JBoss adventure.

Throughout our history JBoss and Red Hat have had an enviable track record of looking for input from our wider communities on a wide range of things we are contemplating. For example, probably one of the biggest I can recall in recent years was the JBossAS rename. It's for that reason I'm writing this blog entry, to inform our communities that we're going to be making a change. I value your input and although I and the team have our own thoughts on the right answer, I don't want to just drop this on everyone without some consultation. After all, www.jboss.org is not a site used only by Red Hat employees! One easy way for us to determine is from tracking your usage and for that reason www.jboss.org will soon show two options and when you land on the homepage you'll be able to either go to developers.redhat.com and find information on product downloads, tutorials etc. or continue to developer.jboss.org and locate your favourite community project and associated information. Let's see how this works and then we'll report back after a meaningful period of time.

Onward!

Now that the vote has passed and the EC face-to-face meeting in Austin on May 8th and 9th has also concluded, I wanted to write down a little about why we voted NO on JSR 376. Scott has already posted an article on the concerns from Red Hat Middleware teams and other members of the Expert Groups and wider Java community (note that at least 50% of the EG contributed to the document - it is NOT just from Red Hat). This has never been about Java EE versus Jigsaw as some might think; it has always been about the benefits for the wider Java communities and making Java 9 a success: Red Hat, and JBoss before it, has invested a lot in the Java ecosystem over the years and our input on JSR 376 has always been because we want Java and the JVM to continue to thrive; we understand it needs to evolve and sometimes that might mean breaking backwards compatibility. However, there's a huge JVM community out there which has developed over two decades and we have to be cognisant that we need to bring as many of them with us when we do release Java 9 rather than risk driving them to other newer languages. And unfortunately the majority of those community members don't participate in JSR Expert Groups so their feedback, both positive and negative, often comes after the fact. With something as invasive as Jigsaw, where reversing it out of the JVM if it was to break too much is probably impossible to do, it is therefore imperative that the representatives on the EG are confident as much has been done as possible to make moving to Java 9 as easy and natural as possible.

It’s a very complex situation we found ourselves in and I’ve spent months listening to the arguments from all sides, not least of which are our own OpenJDK and middleware teams. I flip-flopped between an abstain vote and a no vote, trying to remain objective on the outcome. On the whole, what swayed me to vote no was not the arguments for why WildFly or any specific module system, such as OSGi, might not work well on Jigsaw: those were important concerns but so were some counter arguments from our OpenJDK team. What did it for me was the belief that Jigsaw as it currently stands still needs modifications: in a world as polyglot as we find ourselves in today, the general lack of consensus in the EG and beyond makes it important we stop and consider the potential impact as I mentioned above; if there are smaller changes which could be made which would mitigate the issues we and others have raised in the wider Java community than just the EG, then I think it’s worth spending a bit more time doing so.

None of us have a time machine to see what will happen or predict the future. I believe I remained objective and I believe I made the right decision. However, I want to make it clear that whilst the Red Hat OpenJDK team, the WildFly team, Hibernate, Drools and many other groups gave input for and against Jigsaw, the buck stops with me: I made the decision and whether anyone believes it is right or wrong, I stand by it. At this stage we all need to come together and work together to make Java 9 a success.

I want to finish by returning to the idea of who was concerned about Jigsaw. Whilst the focus seems to only fall upon Red Hat and IBM having concerns, the document Scott posted has wider representation that that. Other discussions around Jigsaw, such as on InfoQ and social media, are full of similar concerns from individuals and other companies than just ourselves. I can't speak for IBM but I can say that this is not a vote we wanted to take in the way we did and it's certainly not a vote we entered into lightly. Whatever the outcome of the vote I hope that the Jigsaw EG, the OpenJDK teams and Red Hat can move forward positively to continue to ensure Java and the JVM are relevant to a wide range of enterprises. That's certainly our intent and we won't be putting roadblocks in the way of collaboration; if everyone can take what has been said and done on all sides to date from the perspective of assuming positive intent then I'm sure we can make this work!

Last week at DevNation we announced the MicroProfile, which is work we're doing with IBM, TomiTribe, Payara and the London Java Community, amongst others. Since then I've seen a few people write articles or talk about it on social media and there appear to be a few things we definitely need to clarify.

For a start, the work we're doing is not a standard. As I mentioned during the keynote, we may eventually take it to a standards body (more on that later), but at this stage the world of microservices is relatively new and evolving, let alone the world of enterprise Java-based microservices. In general, standardising too early results in ineffective or otherwise irrelevant standards so we don't want to consider that until we're further down the line. Now that doesn't mean we won't be using standards to develop. Far from it, as I mentioned we're thinking about a minimum profile based on Java EE (probably 7 since 8 isn't yet finalised) initially. Portability and interoperability are key things we want to achieve with this work. We may never be able to get everyone to agree on a single implementation, but at least if they can port their applications or communicate within heterogeneous deployments, then that's a much more realistic goal. After all microservices, and SOA before it, isn't prescriptive about an implementation, and probably never should be.

Although we're starting with Java EE as a basis, we're not going to tie ourselves to that. If you look at some of the other approaches to microservices, such as Netflix OSS, or OpenShift, there are features such as logging, or events or even asynchrony, which aren't currently available as part of EE. Again, I mentioned this during the announcement, but we all expect this work to evolve enterprise Java in these and other areas as we progress. Java EE represents an evolution of enterprise middleware and we all believe that enterprise Java has to evolve beyond where it is today. Maybe we'll take these evolutions to a standards body too, but once again it's way too early to commit to any of that.

Another thing which we brought out during the announcement was that we want this work to be driven through good open source principles. We're working in the open, with a public repository and mailing list for collaboration. We're also not restricting the people or companies that can be involved. In fact we want as wide participation as possible, something which we have seen grow since the original announcement, which is good! This means that our initial thoughts on what constitutes the minimum profile are also open for discussion: we had to put a stick in the ground for the announcement, but we're willing to change our position based on the community collaboration. We've placed few limitations on ourselves other than the fact we feel it important to get an agreed initial (final) profile out by around September 2016.

I think this leaves me with just one other thing to address: which standards body? The obvious candidate would be the JCP given that we're starting with Java EE. However, as I mentioned earlier we may find that we need to evolve the approach to incorporate things which go way beyond the existing standard, which may make a different standards body more appropriate. We simply don't know at this stage and certainly don't want to rule anything in or out. There's enough time for us think on that without rushing to a decision.