ActiveBlog

Enterprise Java and Stackato
by John Wetherill

John Wetherill, December 20, 2012

EnterpriseTwitter recently and publicly announced that by swapping out Ruby for Java and JVM-based Scala, they were able to survive the US election.

They must have looked at the TIOBE Programming Community Index where Java is rated the second most popular programming language after C.

(This incidentally is a testament to Java’s performance improvements over the years: Not so long ago Twitter would likely have bypassed Java altogether and gone straight to C).

Performance aside, why is the Enterprise so attracted to Java?

The answer is best understood by flipping the question upside down: What software traits do enterprises value?

Enterprise Software

Corporations that rely on software to keep them competitive and profitable frequently need software that exhibits some/many of these characteristics:

 

• high performance • secure • scalable
• reliable • portable • monitorable
• integrated • managed • maintainable
• rapid development • rich, web-based UI • productive for developers

 

Java excels in these areas due to a number of its features, many of which were popularized in the mid ’90s by Java itself:

  • Threads: Java’s mature, robust, flexible, and precise threading mechanism has been succussfully utilitized to solve countless difficult synchronization problems, increasing reliability and boosting performance.
  • Exceptions: Proper use of Java’s exception mechanism significantly increases program reliability and code maintainability
  • Memory management: Improves reliability, with a side effect of increasing productivity.
  • Static type system: Improves reliability
  • JVM/Bytecode: Portability
  • ** Bytecode verification and Security Libraries
  • Rich Ecosystem: Vast and mature set of tools, libraries, APIs, IDEs, and test suites available
  • Large developer pool: easier to hire for, faster to get up to speed

     

The list goes on, but Java’s facility in delivering these features ensures that Enterprise Java is not going away anytime soon.

Stackato Welcomes Java as a First Class Citizen

Out of the box, Stackato supports Java, a multitude of Java frameworks like Spring and Play!, and most of the JVM-language derivatives such as Clojure and Scala.

 

Spring:

Spring offers a vast range of functionality including dependency injection, AOP, service abstraction, batch, integration, and security frameworks. As such it’s a popular choice for enterprise developers. SpringSource has been instrumental in Spring’s evolution.

Stackato support for Spring is automatic and requires little to no configuration. Additionally a plugin for the Eclipse-based Spring Tool Suite (STS) allows direct control of Stackato from the IDE.

Java Web:

The Java Web framework as specified in the servlet spec basically defines an exploded file structure minimally consisting of WEB-INF/web.xml deployment descriptor. This is then deployed to a container such as Tomcat, WebSphere, or JBoss.

Stackato immediately recognizes Java Web structured apps. These can be delivered in the form of a .war file (in which case the app is deployed to Tomcat/TomEE), an .ear file (these deploy to JBoss), or an exploded Java web directory. In all cases they’re deployed to Apache Tomcat (or more precisely TomEE).

JEE

Apache TomEE is an enterprise-ready, fully Tomcat-compatable Java app container with extras for enterprise development including JAX-RS, the infamous EJBs, JSP, JSF, JTA, JPA, CDI, Bean Validation, and EJB Lite.

JEE supports all the TLAs.

These apps are recognized using the same mechanism that Java Web apps are (ie. rapidly and with no configuration).

Play!:

The Play! framework, making great headway, is a Java/Scala framework that’s modeled closely after Ruby on Rails: The app structure is almost identical, as are the means of creating and invoking controls, models, and views.

From building POCs to full-fledged mid-tier apps, Play! is a great choice. It has hooks for various databases, and there is a fair amount of community activity.

I’ve heard that the Play! community may be gravitating towards Scala these days, which makes me nervous that it will fragment and the Java momentum will lose steam. But as it is now, Play! is powerful and gratifying, and worthy of the trailing bang in its name.

Stackato deploys Play! via buildpacks (see next item) and all versions of Play! are supported (up to 2.0.4 as of this writing).

Heroku Buildpacks

Heroku introduced the concept of a buildpack, a network-available directory containing (at minimum) three scripts which take care of all steps needed to deploy an application to Heroku.

Stackato Buildpacks are fully compatible with the Heroku Buildpack spec. As a result, any Heroku buildpack, such as the Java BuildPack (available in GitHub) deploys any standard Java app based on Apache Maven to the Stackato instance.

The 80/20 Rule

About 80% of the Java apps I’ve built and tested on Stackato deployed without any issues or reconfiguration required. What about the other 20%? This is where custom buildpacks come in useful.

Custom Buildpacks

Custom buildpacks are to be used for more sophisticated build procedures with complex dependencies or non-standard build scripts. Stackato Buildpacks are trivial to create by simply visiting one and clicking Fork.

Buildpacks allow you to deploy pretty much anything you can script (which is pretty much anything).

JVM-language Derivatives

Buildpacks are the basis of Stackato’s support for the multitude of JVM-based langauges that are currently available including Clojure, JRuby, Jython, Groovy, Scala, Rhino, Erjang, JavaFX Script, Clojure and more. As with Java, apps built on these languages and their associated frameworks (Grails, Rails, Lift, …) can usually be deployed to Stackato with no additional configuration.

Don’t forget Polyglot

It's rare for enterprise applications to be built on a single programming language. Java is not the best choice for everything (building a rich UI, or a test orchestration suite, or a DSL).

This is where Polyglot comes in. Multi-lingual applications can be easily deployed to Stackato just as easily as Java applications can. So use Ruby to write a DSL, Perl for text processing, Clojure for elegance, Python for maintainability/readability/fun, PHP for … pretty html printing.

And use Java for the heavy lifting.

Download Stackato now

Subscribe to ActiveState Blogs by Email

Share this post:

About the Author: RSS

John Wetherill ActiveState's Developer Evangelist. Originally from Canada, John has spent much of his career designing and building software at a handful of startups, at Sun Microsystems, NeXT Inc., and more recently in the smart grid and energy space. His biggest passion is for developer tools, or more generally any tool, language, process, or system that improves developer productivity and quality of life. Without question, Stackato is one such tool and the reason why he is here. No stranger to technology evangelism, John spent several years in the late 1990's on Sun's Technology Evangelism Team spreading the Java Gospel across the globe and focusing on the prolific number of Java technologies. Now John is now returning to his roots, as a technology evangelist working for a Canadian company, albeit remotely from Santa Cruz.

Comments

1 comments for Enterprise Java and Stackato
Permalink

Great summary!

I think GWT should work well on Stackato too. The interesting thing would be to find a GWT buildpack but it seems it does not exist yet.