Skip navigation
1 2 3 Previous Next

Mark Little's Blog

182 posts
marklittle

Quarkus 1.0

Posted by marklittle Nov 7, 2019

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!

It's been quite a hectic time since the original announcement in 2018 that IBM was to acquire Red Hat. I wrote about this on my personal blog at the time. I know this has pleased some, confused others, worried people and probably a lot more emotions than that affected yet more. In the meantime both Red Hat and IBM have had to act as independent companies for legal reasons and it's only now that the deal has closed can we really start to collaborate on next steps. However, many of our teams have been working with IBM over the years and have great relationships already as well as agreement on many things around strategy and vision. I'm confident that those things won't diminish now we are part of IBM (or, as I prefer to think of it, IBM is part of the JBoss family!) In fact they're more likely to improve. Whether it's in our upstream communities, the IBM upstream communities, with partners, customers, standards bodies etc. I'm confident that we will grow together and the potential for this combination of Red Hat and IBM is definitely an example of where the sum is greater than the individual parts!

 

I really don't have much more to say at the moment. I know many people may still be concerned. All I can say is please trust us/me. We didn't enter into this lightly but I'm sure it's the right thing for us to have done and by that I absolutely mean it's the right thing for our communities too. It's going to be a heck of a ride over the coming months and year; I absolutely want to share that ride with all of you because only together can we make it a success!

 

Onward!

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?

marklittle

Quarkus is here!

Posted by marklittle Mar 7, 2019

We’ve finally released Quarkus, a project the team have been working on for the past 9 months. Our internal project name for the work was Protean because, as you’ll see, our aim is for it to be incredibly versatile and flexible for cloud development and deployment. There are other articles and presentations to come which will go into more detail but I wanted to give an overview of what we’re trying to achieve with Quarkus. (Yes, naming is the hardest part of computer science.)

 

In many ways it’s possible to trace the heritage of Quarkus back to around 2010/2011 when we started to work on improvements to JBossAS with version 6 and subsequently WildFly. The aim of that was to ensure EAP could run well in the first release of OpenShift as well as on constrained devices (aka IoT); maybe some of the readers were present at the JBossWorld keynote where we demonstrated running on plug devices, as Raspberry Pis were just about to break onto the world. The cloud focus imposed similar requirements on us as IoT: limited processing power some of the time, reduced memory availability, storage restrictions etc. Generally our thoughts were that if we could get projects and services which ran well on a constrained device then they’d stand a good chance of running well on the cloud.

 

Over the following years we’ve had many OpenShift releases, further improvements in WildFly and other projects, our entire xPaaS efforts to bring our core capabilities such as transactions, messaging, data caching etc. as services on OpenShift. In that time the entire cloud space has seen a number of paradigm shifts including the massive adoption of Linux containers and Kubernetes. In the middleware space we’ve tuned our projects and services to work well with both and outlined the vision for where we are going and why. With our OpenJDK team continuing to collaborate upstream we’ve also been making changes to Java to ensure it runs well in those environments as well.

 

However, despite Red Hat/JBoss and other vendors and communities showing that Java works well in the cloud, doubts remain and there are some often cited causes for concern. The JVM represents a huge and impressive amount of work by countless developers from a number of vendors over two decades. Despite the fact Java began life aimed at constrained devices, it rapidly evolved into a world where the assumptions are quite different to the cloud today, e.g., able to consume a lot of memory,  requirements to dynamically update the running application/environment and other run-time optimisations. It's important to remember that Java remains the number 1 programming language for enterprise developers working on the backend and many organisations have invested a lot of time and money into their Java-based developer organisations and software because it has dominated the software landscape for so many years. Being able to continue to leverage those things as they transition to the cloud is therefore incredibly important for this huge community. But concerns about Java (performance, runtime memory footprint, boot time etc.) have caused some to re-evaluate their investment with Java and consider some of the newer languages, despite the fact many of those languages don’t yet have the rich ecosystem of tools, utilities etc. which have been built up over the years by the Java community.

 

Therefore, being able to continue to leverage this Java community and ensure that our own communities and customers can do so too, has been one of the important reasons behind what we’ve been doing with Quarkus and what you'll hear about soon. As we also pointed out when we kicked off xPaaS, we also want to take advantage of as much of our own community efforts as possible because things such as WildFly, Hibernate, Apache ActiveMQ, Apache Camel, Infinispan, Narayana, Drools, jBPM, Eclipse Vert.x and many others are mature, category leaders which we believe are still relevant in the cloud space. We’d prefer to enable our communities and customers to be able to continue to rely on them rather than having to start from scratch.

 

OK so what is Quarkus and how does any of what I’ve said (The Context above) related to it? Well broadly speaking Quarkus work falls into two categories:

 

  • Leveraging OpenJDK leadership and cloud improvements, as well as the Graal and Substrate projects, it provides a way to develop Kubernetes native Java applications and microservices. As you will see from other articles, our new website, or even the quickstarts, this covers a range of things. For example, in a Kubernetes environment the Linux container images are immutable, so dynamically modifying the running application, as is possible with approaches similar to those used within the WildFly microcontainer, is typically not necessary. Furthermore, despite the fact that Write Once Run Anywhere is important for Java developers off the cloud, it’s less important when running in Kubernetes where Linux dominates. If you consider some of these constraints as possible advantages when you are targeting the cloud, heavily optimising your Java application at build-time, including potentially compiling Java to a native executable, offer some possibilities for improvement in the cloud compared to traditional Java. For example, if you can compare compiled Java with its bytecode cousin, the memory utilisation can be significantly less and the boot time can likewise be considerably quicker. And if you, as a developer, need to make changes to your application then you do so in the way all Kubernetes developers do today ... create a new container image and deploy it, as simple and quickly as that.
  • Faster, smaller and more Kube-native Java based upon existing implementations is all well and good but we simply couldn’t stop there. Building on the work we’d been doing around xPaaS, as well as new cloud work such as Strimzi and OpenShift Cloud Functions, the team all agreed that we needed to define a prescriptive Kubernetes native environment. We want to build on and hopefully influence industry standards such as Eclipse MicroProfile and Eclipse Jakarta EE. We’re taking an opinionated view on things such as Knative (for our serverless work), asychronous reactive/event-driven microservices (yes, Eclipse Vert.x has a huge role to play) and generally anything that we feel makes Kubernetes-native Java development better for public, private and hybrid cloud.

 

I’ve only touched the surface of the work the team embarked upon last year. I hope to write some more about this over the coming months and maybe do some presentations with the developers. Come to Summit 2019 and hear from us first hand (check the agenda and search for Protean). Many of our products and projects either already are making the Quarkus journey or plan to join soon. I’ll be continuing to support this upstream and in our products as a key effort for Red Hat. I’m even hoping to be able to get back to contributing some more transactions related work when I get some spare time - the little I managed to do back when we kicked off the work was enjoyable.

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.

marklittle

Jakarta EE - Onward!!

Posted by marklittle Feb 28, 2018

Well hopefully you're all aware that the vote has completed and the winner is ... Jakarta EE! I'm pleased with the name and I'm also pleased we've got that out of the way so we can move forward as a community and help drive enterprise Java to the next level. I couldn't have said it better than my friend, co-PMC member and CEO of Tomitribe did earlier:

 

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!

I've written about EE4J a few times before and many others have too, particularly on the name. Back in November, Mike from Eclipse announced that we were going to run a community effort to pick a new name for the Java EE brand once it moves to the Eclipse Foundation. We had a lot of great names submitted from the community by the time the input period ended. The next step was to run through various legal, patent and IP processes to determine whether each name was even open for use. Very similar to the processes we had to go through when we renamed JBoss AS7 to WildFly, in fact. That pruned the list dramatically to the point where we now have only a couple of names left as options. Yes of course we could re-open the suggestion box but that's not going to guarantee a different outcome and in the meantime the Java EE brand doesn't move forward. Therefore, that's why as a member of the EE4J PMC I agree with the original timeline of events and we should simply vote on the two renaming names: Jakarta EE and Enterprise Profile.

 

Now of course given that I was one of the creators of the MicroProfile effort (now Eclipse MicroProfile) you might be forgiven for thinking I'd prefer Enterprise Profile. It has a certain ring to it and in some ways compliments MicroProfile. However, I actually prefer Jakarta EE and here's why:

 

  • clearly it could be abbreviated to JEE, which many in the community have expressed their interest in preserving (even though JEE wasn't an accepted abbreviation of Java EE);
  • Jakarta is the largest city on the island of Java - 'nuff said!
  • Jakarta also has a good history with the Java language thanks to the Apache Software Foundation;
  • Jakarta One has a nice ring to it;
  • I know I said the fact it's a city on the island of Java was enough, but if you go and do some research, or especially you live in the area, you'll see that the city is thriving and driving innovation, growth etc. in the region, which are similar things to what we wish to accomplish with EE4J.

 

So all in all I think Jakarta EE is by far the best choice of the two. And in fact I can't think of a better name now that we've whittled down the list. However, this is a community effort so just remember to cast your vote.

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!

I already wrote about the work we, IBM and Oracle have been doing together to move Java EE to a foundation. At the time I couldn't say which foundation but now we know it's Eclipse and that the project will be called Eclipse Enterprise For Java (EE4J). There's a draft charter and it's vitally important that interested people read it and give feedback on the mailing list. There's a lot of pent-up passion and energy around Java EE and it would be so much better if individuals focussed that on the charter at this point than complaining about the name. Yes, I understand that some people feel the name is important to the success of this effort but I can tell you all that there's a lot more to choosing a name for a foundation or massively successful project than just ... choosing the name. Having done this when we renamed JBossAS to WildFly, you've got to do trademark searches, domain checks, legal verifications etc. and of course that the name or acronym doesn't mean something inappropriate in a different language. So getting to a name like EE4J isn't easy and changing it now is simply not going to be possible. Plus you can never please everyone all of the time.

 

There's a lot to do over the coming weeks and months. Moving the TCKs, specs and sources to the Eclipse Foundation is probably the easiest of the tasks, which isn't to suggest it's going to be easy. We've got to figure out the processes around which EE4J evolves, who leads the specifications, what about compatibility, evangelism, how does the JCP fit in, etc? And it's going to succeed or fail based upon the engagement of the entire Java (EE) communities. If you're invested in Java EE or anything related to it (yes, including Eclipse MicroProfile) then it's a great opportunity to step up and help drive this in an open manner. Gone are the cries of "this is dominated by Sun/Oracle" and "it's not open source". This is now an Eclipse Foundation effort and the best way to ensure this evolves in a direction with which you agree is to join and get involved!

 

I want to take a moment to thank everyone who has helped so far, obviously including Oracle and IBM. We've just completed the JCP Executive Committee F2F which always precedes JavaOne and the feedback from there when EE4J was presented was positive. Yes there are still a lot of unknowns, many of which I've mentioned above. But generally everyone thought this was a good thing!

 

Onward!

marklittle

We are moving ...

Posted by marklittle Aug 31, 2017

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!

By now I'm hoping that most people will have seen the announcement from Oracle around Java EE and possible moves towards open source foundations. Of course there are a few media articles on the topic now because if this does happen it's pretty significant. I haven't got much more I can add at this time from Red Hat that hasn't been said by John Clingan but I did want to echo the sentiments: I think this is a very positive thing to do and likely sits up there alongside Sun's open sourcing of Java as one of the most significant events to happen to the wider Java ecosystem. Of course the devil's in the detail and those details are few and far between at this time, but Red Hat is very happy to support this effort in whatever we we can to help ensure a positive outcome and future for Java EE and its enterprise components. Clearly I also see this as beneficial to our collective MicroProfile efforts and we will have to see how both of these things will evolve over 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!

Back at Red Hat Summit and DevNation we announced that we were working with IBM, TomiTribe, Payara and LJC (and now SouJava!) in an upstream community effort to gain experience on best practices for developing microservices using Java EE, which we called the MicroProfile. Obviously our own efforts around WildFly Swarm fed into these discussions and we've been actively participating in the forum discussions ever since. Now at DevNation we committed to agreeing on a 1.0 version of our project, i.e., what those baseline (minimum) EE components would be for developing meaningful microservices, before JavaOne. At the time we thought it would be JAX-RS, JSON-P and CDI but we really wanted wider input from users and developers. We got a lot of input and I encourage anyone who hasn't joined the group yet to do so if you want to help influence the collaborative efforts.

 

Screen Shot 2016-09-17 at 13.12.53.png

 

Well the good news is that we finished 1.0 a few weeks ahead of schedule with 6 different implementations! You can read more about the announcement but the obvious question is what next? Technically Java EE still has a lot more to offer microservices and we've been discussing these on the mailing list, including JPA, JTA (yes, I think transactions have a role to play!), Bean Validation and Concurrency Utilities, to name but four. We need to look at extensions to these efforts, or things which go beyond where they currently sit. For example CQRS is important for more advanced microservices developers. Monitoring, logging and tracing in a distributed system is critical on a number of fronts, not least of which is debugging performance problems and errors, so we need to do more here. One of my pet favourites around microservices is the move towards reactive and asynchronous, as epitomised by projects like Vert.x. It's much more than just making JAX-RS a bit more asynchronous so we have a bit of a slog here to make improvements in Java EE components/standards; maybe we'll decide it just isn't worth it and we need to look at defining new things from scratch.

 

I could go on and on with some of the technical things I believe we need to look into next, including service discovery, components from Netflix OSS, CDI annotations for things like circuit breakers and of course language level features such as JDK 8 Lambdas and Streams, or Java 9 modularity, but you can find more details at the official announcement blog. I will point out one other thing though: we've got to move away from just assuming HTTP is the only way microservices communicate. Yes, HTTP is convenient, but a text-based protocol is not the way to go if you want high performance. HTTP/2 helps, as will WebSockets (yes, more benefit from Java EE) but we need to look at messaging solutions (not just JMS). Oh and fault tolerance, reliability and security are other areas we need to focus on - it's going to be busy so get involved and help us break this down into smaller challenges!

 

Of course there's more than the technical aspects to consider. We now believe we have something worthy and useful in MicroProfile 1.0. We've always talked about standardisation once we have gained enough experience - that's where standards bodies work really well. This is something we need to discuss in the community, as with everything else we've done so far, but my personal opinion is that we are ready to move MicroProfile 1.0 to a standards body. Which standards body is again open to discussion, but it would seem logical for the JCP to play a role here since at the moment we're based entirely on Java EE. Get involved! Give your own opinion. Finally, we're going to move the existing MicroProfile effort to a Foundation. Discussions are on going (yes, again in the upstream forum) but I think we're close to a decision and should be able to announce something real soon now! Stay tuned!

 

OK that's it for now. It has been a great community effort around MicroProfile since we announced it only a few small months ago. My thanks go out to everyone who has contributed in a small or large way, no matter which company you work for or if you're an individual contributor. It all helps us to understand where enterprise Java microservices need to head. Please keep involved and help us shape the future of the industry! And if you're around at JavaOne ...

 

IMG_0534.JPG

 

Onward!

marklittle

The MicroProfile

Posted by marklittle Jul 4, 2016

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.

Filter Blog

By date:
By tag: