Heroku vs OpenShift – The Battle of the JavaEE FUD

Posted in: Cloud Computing, Enterprise Java

On the same day that Heroku announced its new support for Java based applications, it also curiously posted a laundry list of FUD about the JavaEE platform. Don’t get me wrong, I share some of Heroku’s complaints, but calling out the shortcomings of the JavaEE platform by linking to documentation related to obsolete versions did not help give Heroku’s arguments credence. Last I checked, the Jetty server, which Heroku’s Java platform is based on, quite clearly states that it is a Java Servlet container, and the Java Servlet specification is part of the JavaEE family of specs. So the specs that Heroku derided are in fact the same specs that their product is running on a subset of. Interesting tactic.

Of course, the RedHat team with their OpenShift platform (that does in fact support a full JavaEE stack) managed to take the Heroku post personally and responded in a less than dignified fashion. Why RedHat felt they needed to respond at all is the first question that comes to mind. The Heroku post does not call them out by name. The level of animosity in the Redhat response makes me wonder if there is bad blood between these teams.

Personally I have real concerns about Heroku’s model of non-conformance to the JavaEE specifications. There is a wealth of knowledge and code out there based on those specs (irregardless of how flawed they may be), so expecting people to do some heavy lifting to port their existing standard Java code to run on your platform is a big ask. The tools out there (from IDEs to builders like Maven and Ant to CI environments like Hudson) are entrenched in every team and on every developer’s box. Where do you hire Java Heroku developers from exactly anyway? Now, you could argue that Heroku’s model is not that different from standard JavaEE, but the fact that it is different at all is the problem. As one commenter on Heroku’s post said “Any reason you didn’t simply allow for uploading of a .war?“. Precisely.

OpenShift has its own set of issues as well though. I cannot recall the last time I worked on a project that actually required a full JavaEE stack. I don’t think I have a JBoss or WebLogic environment on any computer I own currently (and I definitely don’t have WebSphere, that’s for sure). What I do have is about 3 different versions of Tomcat with multiple applications deployed on each. I also have a couple of packaged pieces of software installed that actually run Jetty internally. Perhaps it’s just the kinds of projects I work on, but I suspect I am most likely in the majority. Probably even more so if you looked at all the Java apps that are deployed on full JavaEE stacks out there, that could actually be deployed into a servlet container with no code changes. Arguing that a full JavaEE stack is an essential and technically superior solution when you are a vendor of such a stack (ie. JBoss) doesn’t really give your argument much objective weight.

So, JavaEE is not what it was even 5 years ago, it has gotten a lot better and has evolved via a variety of means, one of the biggest being watching what the community does to work around the JavaEE shortcomings (see Hibernate etc).

That said, a full JavaEE stack is not the answer to every problem, maybe not even a majority of problems.

As with most things in life, the middle ground is probably where the truth will be found. A non-standard Java platform is probably not the right answer, but then again a full JavaEE stack is probably not either. IMHO, as far as I can see right now, the sweet spot in the Java PaaS space are the vendors that allow developers to work as they have been previously – allow them to use the tools they know, the development workflow they know and the architecture they know. Based on that, I think Amazon’s Elastic Beanstalk and CloudBees RUN@Cloud are probably on the right track.

Java developers, meet Heroku

Posted in: Cloud Computing, Enterprise Java

Heroku, the popular Platform-as-a-Service offering initially for Ruby developers only, now supports Java. Actually, Heroku has added support for both the Node.js framework and the Clojure programming language over the past few months, but Java is in a whole other league. If it’s not the world’s most popular programming language, it’s certainly among the most popular — especially among enterprise developers.

via Java developers, meet Heroku — Cloud Computing News.

VMware Delivers Micro Cloud Foundry, Bringing the Industry’s First Open PaaS Directly to any Developers’ Mac or PC

Posted in: Cloud Computing

Cloud Foundry delivers access to modern, high productivity frameworks and a rich ecosystem of application services from VMware, third parties and the open source community. A complete version of Cloud Foundry that runs on a developer’s Mac or PC, Micro Cloud Foundry lets developers build end-to-end cloud applications locally, without the hassles of configuring middleware while preserving the choice of where to deploy and the ability to scale their applications without changing a line of code.

via VMware Delivers Micro Cloud FoundryTM, Bringing the Industry’s First Open PaaS Directly to any Developers’ Mac or PC.

Amazon Announces ElastiCache Service

Posted in: Cloud Computing

Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from a fast, managed, in-memory caching system, instead of relying entirely on slower disk-based databases. Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and popular tools that you use today with existing Memcached environments will work seamlessly with the service.

via Amazon ElastiCache.

JavaOne 2011 Schedule Builder is LIVE!

Posted in: Enterprise Java

JavaOne Schedule Builder is live at last! Don’t get shut out – go to Schedule Builder NOW to reserve your space in the must-attend sessions on your list.

via JavaOne 2011 Schedule Builder is LIVE! (JavaOne Conference Blog).

Writing A JSP Custom Tag Library for Adobe Communique

Posted in: Enterprise Java, Software Development Best Practices

I just wrote another article for CQ Blueprints.

Within CQ, Components (including Page Templates) can utilize JSPs for rendering not only HTML, but also other output formats such as JSON.

Unfortunately, many JSPs are written poorly and mix presentation logic with business logic (in the form of scriptlets) making them difficult to test, debug and maintain. One of the best ways to write better JSPs is to never use scriptlets and instead use a combination of EL expressions and Custom Tag Libraries (including the JSTL). This Blueprint details how Custom Tag Libraries should be developed and deployed to a CQ environment.

For more, see:
http://www.cqblueprints.com/xwiki/bin/view/Blue+Prints/Writing+A+JSP+Custom+Tag+Library

Remote Debugging Elastic Beanstalk with the AWS Toolkit for Eclipse

Posted in: Cloud Computing

Learn to use the AWS Toolkit for Eclipse to easily configure Elastic Beanstalk for remote debugging.

Deploying 3rd Party Libraries to Adobe Communique

Posted in: Enterprise Java, Software Development Best Practices

I just published a new Blueprint over on cqblueprints.com that details how to easily deploy 3rd party libraries into your CQ environment, even when those libraries do not contain the necessary OSGi entries in the Manifest file.

CQ is built on top of Apache Sling, and Apache Sling is built on top of an OSGi container (Apache Felix specifically).

OSGi containers behave slightly differently (in terms of how classes are loaded and made available on the classpath) than most Java developers are used to.

To be able to make classes available within the OSGi container, Jar files need to be packaged in a specific way, including adding extra meta-data to the standard MANIFEST.MF file. The problem this can create is that libraries created by other developers that have not been built with OSGi in mind are missing this extra information and so their Jar files cannot be deployed in CQ.

This Blueprint details how to easily and reliably expose non-OSGi enabled libraries in CQ.

See Deploying 3rd Party Libraries

Building and Deploying OSGi Bundles on Adobe Communique

Posted in: Enterprise Java

I just published a new Blueprint over on cqblueprints.com that details how to easily build and deploy OSGi bundles into your Adobe Communique server.

CQ is built on top of an OSGi container and as a result custom code and functionality can be added to CQ through the features provided by OSGi. To be able to deploy custom code into an OSGi container, developers must package their code as a bundle. An OSGi bundle is simply a Jar file that has had extra meta data added to it. This Blueprint details how to create an OSGi bundle using Apache Maven and how to deploy that bundle into a running CQ instance.

See Building and Deploying OSGi Bundles

PaaS Is a Cloaking Layer for Clouds

Posted in: Cloud Computing

The API for Cloud 1.0 is the virtual machine/OS. The API for Cloud 2.0 is the application container itself – services like CloudFoundry, Elastic Beanstalk from Amazon and Heroku allow a developer to hand over an application to the application container without having to know anything about what operating system that application is running on or how it communicates with other services like load balancing, failover and database.

via PaaS Is a Cloaking Layer for Clouds | SYS-CON MEDIA.