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.

Just 6 months after JBoss AS 6 was released, JBoss AS 7 (codename Lightning) is now available. Congratulations and a big thank you to the JBoss AS team and community. JBoss AS 7 is a major release in every respect and will become the technology underpinning for much of what we do at JBoss for the next decade. I believe it also represents a shift in the way developers will think about enterprise Java and it opens up new possibilities for deployment that were unthinkable 5 years ago due to technical and economic limitations.

If you’ve been following the AS 7 candidate releases (and AS 6 before it) then you already know that AS 7 includes some significant new features. I’m not going to list them all; but here are the highlights:

Developer Productivity

• Startup-time and memory utilization have been significantly reduced which leads to a much more productive developer experience – no more coffee breaks during deployments and restarts.This required some significant rethinking and a fair amount of innovation (something we’re good at apparently)
• The Java EE 6 Web Profile provides a much leaner, less complex platform for developers who focus purely on the web-tier – less to learn, fewer design choices – increased developer productivity
• More flexible and powerful modular classloader – less time debugging and configuring classpaths; more time writing applications
• Testable by Design with Arquillian with out of container testing for the business logic so developers can be more productive while delivering better quality applications.

Price / Performance

• It’s probably a little early to claim significant performance gain over the competition right now but request path performance is a goal and the hard work of tuning and performance improvements starts now, One early indicator will hopeful give you a sense of what we’d like to achieve is the recent SPECjms2007 submission from Red Hat. SPECjms is a pretty narrowly focussed benchmark and not all the JMS vendors are represented, that said this is pretty significant for us as it is the first public benchmark submission from JBoss and good practice for future activities

Operational Ease of Use

• Some of the more significant advances in JBoss AS 7 are around the operational ease of use. The configuration has been completely refactored around a multi-node domain model, though the simple single-instance view has been maintained for developer use as well
• There are stable, easy to use management APIs – so AS 7 deployments can be completely automated from Java or any other scripting environment.
• New shiny, task oriented domain console that also allows you to manage multiple, distributed nodes.

Anyway – time to stop reading and start playing : learn more about JBoss AS 7 here and get the bits here and provide feedback on community site.

Next post – how AS 7 relates to Red Hat’s commercial, fully supported distribution – JBoss Enterprise Application Platform 6.

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.

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 !

DZone: With Oracle’s acquisition of Sun, are you concerned at all about some of the potential changes that will come as a result, to the governance and licensing options to the OpenJDK?

Rich: I’m really not that concerned. There are all sorts of scenarios that people are suggesting. I still believe Oracle will do the right thing. They have far too much to lose, by either accidently or purposely sabotaging OpenJDK. They have a very healthy business based around Java. Creating unrest, creating any kind of distrust or fragmentation of the Java community really isn’t going to help Oracle. So I think they’ll do the right thing. I also think they probably have the ability to invest in Java more than Sun had over the last five years at least. Sun kind of had some fairly pressing financial issues. I think that, above all else, probably hindered some of the progress of Java over the last five years.

So overall, I’m coming in neutral to slightly optimistic. If things do go awry, I’m sure Red Hat the rest of the Java community will step up and help Oracle to get back on track. So, yeah, I’m pretty comfortable with it.

My only real concerns is that Oracle understands products and monetization much better than they understand community and collaboration so I think a misstep or two are more likely to occur than Oracle purposefully sabotaging Java. Harming Java will devalue their investment and their chances of getting a decent return.

On the positive side – I think there’s still huge growth potential for the Java platform – I see no reason why it can’t become the dominant standard for the enterprise – I personally think we’re at the start of the decline of Microsoft and Java is the only viable alternative to Microsoft’s enterprise foothold. Microsoft’s enterprise presence is not insignificant but neither is it guaranteed – it’s largely based on an historically well adopted OS and Microsoft’s missteps in that area are pretty well known by now .

Java needs some strong leadership, investment and a open, vibrant and growing community.

I raising my mug of tea to The Next Decade of Java !

Q: When using your Apache & Tomcat bundled software, do you provide any additional security patches above and beyond what the Apache & Tomcat communities provide ?

A: Red Hat has a dedicated Security Response Team who’s role is to track alerts and security vulnerabilities in the community which may affect users of Red Hat products and services. They work with Open Source communities to identify, classify, diagnose and coordinate fixes. If Red Hat discovered a vulnerability in any Open Source project we would work with the community to coordinate a fix, we wouldn’t keep it secret.Where we might differ from the upstream project is in how we communicate the presence of vulnerabilities and deliver fixes to our customers.

Q: can you guys point out to any benchmarks on jboss as in comparison to the other j2ee containers available (ideally updated every once in a while) online for the people who look into jboss AS evaluation to come and compare it easily with the other AS and

We don’t currently have any public benchmarks comparing JBoss to other vendors. All proprietary vendors have specific restrictions in their EULA forbidding use in benchmarks, so the only viable way to provide a comparison is by comparing vendors submissions for some thing like SPECjAppServer2004. JBoss has long argued that SPECjAppServer2004 does not represent contemporary use of modern app. servers (a position that IBM now agree with) as such we’ve never paid much attention to SPECjAppServer2004 and we’ve never made a public submission. JBoss has been working with SPEC on a new benchmark which we think does better represent modern application server usage and we will, in time, provide our own public submissions.

Meanwhile, many customers who have moved large deployments from our proprietary competitors to JBoss typically cite overall cost saving as the main reason. Performance and overall cost are tightly linked.

Q: what is the official release date of EWP ?

A: Right now the best date I can give you is that it will be released sometime in this Calendar Quarter.

Q: why isn’t seam part of the web toolkit ?

A. That’s the long-term goal. ie. to separate the frameworks from the run-tmes as they typically evolve at different rates. We also want all the frameworks to be certified on all the run-times. This is a form of Pace Layering and I think it provides the greatest flexibility / agility.

Q: What is the level of support you give spring as part of the web toolkit ?

A. With the first version of the Web Framework Kit – Spring is a Technical Preview and not recommended for production use. The intention is to promote Spring to fully supported in the next minor release.

Q: why do you think glassfish managed to have jee5 server so soon ?

A. Because Sun is the spec. lead for Java EE – they have to deliver the Spec., the Reference Implementation and the TCK. It’s impractical for anyone to deliver an implementation before Sun. Just as it is impractical for anyone to deliver an implementation of Java CDI before Red Hat (the spec. lead).

Q: Are these versions (EWS, EWP, EAP) available in the community version, or only the enterprise version ?

A : The community version for EWS is Tomcat, mod_jk and Apache HTTP – you can see the exact versions included in EWS here. JBoss EWP only exists as a ‘profile’ in AS 5.1. You can see the exact component versions for the platforms on their respective web pages, eg. component page for JBoss EAP.

Q: When will EAP 5.0 be Java EE 6 certified ?

A. There is no plan to certify EAP 5.0 with the EE 6 TCK. EAP 5.0 supports Java EE 5, though it does include some features of Java EE 6 – specifically JAX-RS (RestEasy) and the Web Profile. If you want to see ho were progressing with Java EE 6 then take a look at JBoss AS 6.

Q: I would like easier upgrade path in RH Jboss vs jboss.org when you have your customized apps.. or is this a no problem ?

A : As long as you’re using the same base versions – portability should not be a problem. You can use this page to see what version level of components are included in EAP.

Q: What type of improvements are you looking at in order to support Cloud environments ?

A. Here are some of my thoughts :

• Larger managed domains, possibly shared across BUs, requiring delegated administration and isolation.
• More automated – everything needs to be easily automated or autonomous by design
• Automation is just as likely driven by pre-defined policy as by a human sys. admin.
• Better support for virtualized environments
• Lower resource utilization
• More dynamic – eg. to deal with elasticity – grow and shrink environments depending on pre-defined policies

Bob McWhirter and Marek Goldmann have been experimenting and prototyping some of these areas as part of the StormGrind project – take a look.

Q: Would web application developed in Jboss work on tomcat ?

A: JBoss EWP / EAP is a superset of Tomcat – as long as you limit your app. to use just the Web Container (ie. Servlet, JSP) – your app. will be portable. The web-container in JBoss EWP / EAP is based on Tomcat 6.0.18 so obviously supports the same versions of the Servlet (2.5) and JSP (2.1) specs. Tomcat 6.0.18 is also what we include in JBoss EWS.

Q: are there any limitations in the number or requests handled by using mod_jk ?
A. Good one – let me find out. Check this space for an update.
A. I checked with Jean-Frederic Clere, his response is :
“Apart from the OS limitations and httpd limitations (configuration in
httpd.conf, MaxClients for example) there aren’t any limits in the
number of requests mod_jk could handle.”

Q. where can I get the slides ?A. At some point they’ll appear along with the recorded sessions here.