- Developer Tools
John Wetherill, December 20, 2012
Twitter 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?
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 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.
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).
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).
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 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 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).
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.
Trackback URL for this post: