Why then, if Java is such a miserable platform to develop on would Heroku bother ?

Here are a couple of thoughts :

1. Huge Developer Base

2. Massive Adoption

3. Large, Active Ecosystem

Only Java gives developers such a broad range of tools, technologies and APIs – both commercial and open source. Only Java gives you Open Standard enterprisey features like Transactions, Object Persistence, Messaging, Security, Integration, scalability and high availability for when you need them.

Basically, most professional developers use Java (if they aren’t beholden to Microsoft that is) and they, to a degree, decide how to spend money on deployment and long-term care and feeding of applications. And Heroku, like any other company wants to make money.

But why would a professional Java developer choose Heroku given their very out of date and poorly informed opinion of Java ?

Surely – Red Hat’s OpenShift is a better choice ? Instead of whining about Java’s shortcomings over the years – Red Hat / JBoss has put a huge amount of energy in fixing Java’s shortcomings – and doing it in an open and collaborative way so the entire ecosystem can benefit. Red Hat has a deep understanding of Java technology and open collaboration – more than anyone else in the industry. OpenShift’s support for Java EE 6 is a recent example of this – we didn’t sit around complaining that Java EE didn’t fit with the new deployment paradigm that PaaS represents – we simply did what we had to do to make it work. And you can try it for free.

Finally, as Isaac makes clear, it’s time for the folks at Heroku to wise up about Java and maybe trade in their 2004 copy of “Beginning J2EE 1.4: From Novice to Professional” and have a look at some of the advancements in Enterprise Java over the last decade. Hey – Adam – leave a comment and I’ll buy you a new book

You probably didn’t see Red Hat’s press release as those things are typically only read by the press so I wanted to draw to you attention a single paragraph :

“JBoss Application Server 7 represents a major milestone in the evolution of Java application servers from complex and monolithic to more lightweight, modular and agile. This release will enable developers to re-think how they develop and deploy enterprise Java applications.”

I wrote that and I meant it. Over the last 5 years there has been a significant difference between the Java EE servers like JBoss, Weblogic and Websphere and Apache Tomcat. Tomcat has been the poster-child for the lightweight container movement (but we shouldn’t forget Jetty and Resin – both very capable servers) and has established itself as probably the most popular Java run-time.

But I think we’re at the point where there is no-longer a lightweight division between Java EE servers and Tomcat (and other Web Containers) – some good blog posts here and here that discuss typical developer requirements like startup time and deployment speed (make sure you read the comments). When we’re at the the point where we’re discussing sub-second differences between startup or deployment times then I think we have convergence. I think we’re at a point where you can no longer paint Java EE servers into the big, slow and heavy corner and Tomcat into the lean and fast corner.

Developers have more choice today than ever before – they can choose a lightweight container but no longer have to make a tradeoff between footprint and features. Or start with a basic server like Tomcat and incrementally build a full featured application server from the ground up as more features like caching, persistence, transactions, messaging, view layer are required.

OK before the Glassfish fanboys chime in – yes Glassfish did a great job of addressing light-weight needs for Java EE some time ago but by any available measure Glassfish still doesn’t represent a mainstream choice like Tomcat, JBoss, Weblogic or Websphere.

The mistake that people make (Mike included) is that vanilla Tomcat addresses the full spectrum of enterprise web / app platforms. It simply doesn’t. There is only a small class of applications that need nothing more than a servlet container. The vast majority of Tomcat deployments require a whole bunch of additional technology – the de-facto Tomcat stack is Tomcat + some view layer tech. (eg. Spring MVC) + some persistence / ORM (eg. Hibernate). That is the basis for the alternative to Java EE. Most people end up adding a lot more stuff than that and find themselves somewhat accidentally maintaining a full featured application server. I know of customers who have been very successful doing this; they’ve invested in very knowledgeable people to manage the stack; I’ve also seen customers fail or simply decide that they aren’t willing to become an app. server vendor.

Finally, full disclosure – I do work for one of the vendors Mike mentions – specifically Red Hat and we would be delighted to sell you a subscription to a full featured Java EE Application Server (and a broad range of middleware) but if you have chosen Tomcat – we can help you with that too – we provide a distribution of Tomcat and even certify and test other elements of the Tomcat stack like Hibernate and Spring. Or as most customers actually demand – we can help you with both.

So after a fast sprint JBoss AS 6 was released at the end of the year and it passes the Java EE 6 (Web Profile) TCK. It’s great to see the culmination of efforts from fellow Red Hatters that went into this release. But Red Hat’s involvement in the future of Enteprise Java goes way beyond this release – many of the technologies delivered in AS 6 as part of Java EE 6 were driven through the JCP by people like Gavin King, Emmanuelle Bernard, Pete Muir and Jason Greene to name a few. Work on these specifications started several years ago so for some this has been anything but a sprint.

It’s great to see the release cadence of JBoss AS pick up – AS 6 had a number of milestone releases over the year’s development and I think this has gone down pretty well judging from the download rate (about 200k even before GA).

While AS 6 has been going through the last stages in the development and certification cycle, the next major release – AS 7 has already released an early alpha to demonstrate it’s “lean by default” services architecture – the feedback so far seems to be very positive.

You can read more about AS 6 from Stan, Gavin, Shelley, Jaikiran and Dimitris as well as J-Development,  InfoQ and NetworkWorld.

Another day, another survey – this one from Tools Vendor ZeroTurnaround. From what I can tell survey participants were self-selected – but the results underline what has been a solid trend over the last several years and I’ve seen the same in internal surveys I’ve commissioned.

Below is the 2009 / 2010 Container Popularity chart. Note the significant decline of Websphere and Weblogic and the growth in leaner, Open Source containers like JBoss, Jetty and Tomcat.

Glassfish bucked this trend – likely due to uncertainty about it’s future under it’s new owner Oracle. JBoss showed only a little growth – I’ll put this down to a fairly slow year in 2010. But 2011 is going to be very, very different. We already have a Java EE 6 Web Profile container (released last week) and JBoss AS 7 is taking shape pretty rapidly. With our increased attention to slimming the footprint and increasing the speed of adopting new technology and standards like Java EE 6 — my prediction is that JBoss will catch or overtake Tomcat in the next year.

Mike makes some valid points but to claim that Java is a dead-end is a bit sensationalist. By Forrester’s own data – it’s the only mainstream tech. that’s showed sustained growth over the last couple of years – I’m fairly sure 2010 data will continue the same trend.

Sure, Java has it’s limitations and it’s continued commitment to compatibility has hindered its ability to meet new needs but there still really is no better alternative. While Ruby, Scala, Groovy, etc. are compelling for some applications they would need unprecedented sustained growth before they become real main-stream alternatives to Java or .NET. During that adoption ramp they will no-doubt expand to meet additional requirements and their simplicity will be compromised.

These things move at glacial paces – I still meet with customers who are only just starting out with Java. It’s important not to be biased by what the alpha-geeks are looking for – it’s the late majority that provide the momentum.

So thanks for the opportunity to explain some of this.

First the obvious disclaimer – yes I work for Red Hat. Specifically I am the Director of Product Management for JBoss Enterprise Application Platforms and as such responsible for the product roadmap and technical direction of JBoss branded products like JBoss EWS, EAP and EWP.

So let me explain Red Hat’s model – something we call the Fedora / RHEL model internally. Red Hat provides subscriptions for use of its Enterprise distributions. A subscription provides the following (in no particular order) :

• long-term world-class technical support – and we do it very well (PDF report)
• long-term application compatibility
• long-term stability and predictability
• long-term partner certifications
• legal assurance
• long-term provision of security patches, performance enhancements bug fixes and RFEs

It may seem contrary if you’re used to the traditional model of “buying bits” but in our model, the provision of the bits is somewhat secondary; it’s something we have to do to support the value outlined above. For example, partners will only certify their applications and products if we have some way of identifying specific releases – supporting a continuous stream of releases is impractical. We can only provide application compatibility if we focus on specific identified releases.

So, one of the entitlements of a subscription is access to the supported binary distributions of a product – this is the thing to which we can apply all the other things I’ve outlined above.

For all of Red Hat’s products there are one or more upstream Open Source projects. In the case of JBoss EAP – the JBoss AS project is the primary components but JBoss EAP also includes Seam, mod_cluster, Apache CXF to name a few. Some of the projects that Red Hat uses in it commercial platforms are essentially Red Hat (or JBoss) projects – we provide the majority of developers, drive the roadmap and the release cadence (eg. JBoss AS, Seam, Hibernate), for others we’re merely one collaborator among many (eg. Apache CXF, OpenJDK, Apache HTTP).

The upstream Open Source projects is where the innovation happens – the focus of many of the Open Source projects driven by Red Hat is to act as technology incubators. Releases for projects like JBoss AS are frequent, experimental features are released, refined and re-released. That’s the focus – agility, speed, innovation. There’s never been any promise, implicit or otherwise that any given release is suitable for running your business critical applications. In fact we make it pretty clear on JBoss.org :

OK, so let’s dig into the relationship between project (or community) releases and platform releases. I’ll use JBoss AS (project) / JBoss EAP (platform) as examples as they are among the most widely downloaded / deployed :

Let’s take the JBoss AS 5 branch which was the foundation of the most recent JBoss EAP 5 family. JBoss AS 5 was focussed on a couple of big things : i) providing a new level of modularity via the Microcontainer 2.0; and ii) providing a Java EE 5 certified container. JBoss AS 5.0.1 was released in February 2009, followed a few months later by 5.1.0.

JBoss AS 5.1.0 met our functional criteria for JBoss EAP so that is what we picked up for our ‘productization’ process and JBoss AS 5.1.0 essentially became the Alpha Release for JBoss EAP 5.

The productization process is really not dissimilar to the kind of process you’d see in any other software company – we bring in all the major components, refine the dependencies, remove duplicates, perform additional testing above and beyond the community / project testing – focussing on security, performance, scalability, failure, longevity and the component integration points. We also look at documentation and the certification of third-party products like databases, Operating Systems, JVMs and other Application that work with JBoss. During this process we also run a traditional Early Access Program (aka Alpha, Beta) – this augments the attention the individual components receive during their own community release cycles. We’re fortunate to have some very willing customers who are able to apply significant resources to push our technology very hard using real-life applications and operational scenarios – often finding issues that are very hard to flush out in QE or during community release cycles.

The result of this process is an Enterprise Platform GA that differs from the upstream binary release we started with. First, we bundle additional components – like APR (Apache Portable run-time), Seam, mod_cluster, Apache CXF. And the core JBoss AS we include has a large number of fixes to address the security, performance and other issues identified during the productization process.

But that’s just the start.

JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.

All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation.

OK so what happens to the community project once we’ve delivered an application platform? Well in the case of AS 5.0, from a Red Hat contributor perspective – the work was complete and Red Hat’s developers moved on to the next wave of innovation in AS 6 and AS 7. The goal of AS 6 is to deliver a Java EE 6 Web Profile implementation, the goal of AS 7 is to tackle the operational use-cases with a new domain model and console.

So to summarize this rather long post – if you want to deploy your business critical applications and receive long term support from Red Hat then the JBoss Enterprise Platforms are what I would recommend – if you’re more interested in seeing how those platforms will evolve and more interested in emerging technology but willing to take on more risk then upstream projects are where you should be looking. It all a matter of assessing the risk.

Kurian discussed the roadmap for JDK 7 and JDK 8, which will be based on OpenJDK

“In addition, Oracle remains committed to OpenJDK as the the best open source Java implementation and we will continue to improve OpenJDK and welcome external contributors.”
http://www.oracle.com/us/corporate/press/173712

“Oracle will work with the OpenJDK code base and the OpenJDK community
like Sun did. We will continue to develop the JDK in the open under a
GPL license. We welcome the cooperation and contribution of any member
of the community – individuals as well as organizations – who would
like to be part of moving the most widely used software platform
forward.”

http://blogs.oracle.com/henrik/

I’ll be speaking at JBoss World / Red Hat Summit again this year. I’m part of 3 sessions focussed on JBoss :

JBoss Enterprise Application Platform Roadmap, Wednesday 2pm

I’ll be sharing our 3-year roadmap and will touch on Java EE 6, HornetQ, Infinispan, support next-Gen (aka Cloud) infrastructure. I’ll also go through some of the changes we’ve recently made to our “release taxonomy”. What I expect you to get from the session is a clear understanding of our major areas of focus and the direction that JBoss EAP is heading in so you can better plan your own deployments. I looked at the feedback forms from last year and the only 2 negative comments were “more chairs please” – hopefully we’ll have a bigger room this year but come early.

Andiamo – Towards Operational Excellence with JBoss, Wednesday 5.30pm

Myself, Andy Miller, Brian Stansberry, Jason Greene and Charles Crouch will be holding this BOF session to discuss some of the changes we’re considering for JBoss EAP 6. Generally the discussion will be around operational ease of use, management, monitoring, tuning, diagnostics, deployment. Getting community input at this stage is super important so come along and tell us what you’d like to see. There’s a good chance of beers afterwards

Java 2020

I’ll be sharing the stage with fellow Brit. and JBoss CTO – Mark Little to discuss Java past, present and future and give a Red Hat perspective of some of the challenges and opportunities ahead. We’ll be covering Next Gen. Infrastructure (aka cloud), Multi-language VMs, virtualization, SOA and many other subjects. We may have time towards the end to discuss England’s performance in the World Cup.

If there are questions or areas you’d like to see us specifically cover in these sessions – either leave me a comment or drop me an email (rich dot sharples at my employer dot com) or message (@richsharples).

JBoss World and Summit represents a great opportunity for me to meet some of my colleagues, learn about other technology areas at Red Hat and spend time with customers. As with all tech. conferences – the real value is in the contacts you make and the hall-way conversations you have. I’ll be around all week – if you want to chat – get in touch.

See you in Boston !

“First they ignore you, then they laugh at you, then they fight you, then they produce lame marketing videos, then you win.”

- with apologies to the late Mahatma Gandhi.

Actually, I’d say if your competitors are producing videos at the rate that the Websphere marketing team are producing them about JBoss I think you can safely conclude that they’ve given up all hope competing with products and technology. The latest almost makes me feel a little embarrassed for the Websphere team. How the mighty have fallen.