Confidence in Java, Groovy, HTML5, CSS and JavaScript

During the past several Ellucian user conferences, a question I’ve been routinely asked as CTO relative to Banner XE is, “why Java, Groovy, and JavaScript?” The evolution of the historical Banner ERP, (from PL/SQL and Oracle Forms to a modern stack) is a fascinating journey, involving years of experimentation and architecture hardening to come up with the right mix, but the final selection of key foundational attributes was established with absolute confidence and can serve as a case study or data point for others pondering programming languages. This post will answer the question, while at the same time it can be leveraged to provide general evidences surrounding the future certainty and stability of these languages.

A primary concern with any technology choice, in particular foundational components, is the ownership pedigree and patterns. Longevity of software development investments can be volatile and exposed if core components are dependent upon proprietary ownership (e.g. Adobe Flex). Accordingly, when Oracle acquired Sun, the blogosphere was lit up with concern about Java’s future, despite evidence of a strong commitment to Java via some investment patterns (e.g. BEA Systems acquisition). With very little doubt as to the power and capabilities of Java relative to its fit with Banner’s evolution, I have to admit, I was very uneasy about the turmoil created by Oracle’s move, bringing sufficient uncertainty to Java’s future.

Fears were fueled when James Gosling left Oracle, and the lack of direction on things like OpenSolaris, (which ultimately killed the project) provided the skeptics with reason to believe the open culture in the Java community was about to change dramatically. In frustration, communities began to break away to control their own destinies, such as Hudson which split to form the Jenkins continuous integration project. Certainly, the legal drama contributed to the fears, such as when Oracle sued Google for its use of Java in Android. And if those events weren’t enough, Google was a no-show at JavaOne, sessions were cancelled, mass confusion ensued, dogs and cats living together (Ghost Busters) and releases of defect-laden Java software seemed to underscore the lack of focus (e.g. Java 7 had serious defects Oracle knew about prior to release).

Thankfully, (and with the benefit of hindsight) those early issues appear to be long-gone at this stage. Scores of key features, tools and innovations in Java have been added or redone and brought to light. A strong push to new platforms (e.g. ARM and iOS) gives additional confidence to Java’s continued relevancy, and a robust roadmap shows the commitment to the future (e.g. JDK 8’s Lambda project, JDK 9’s modularity and the footprint optimization of J2EE promised). And finally, it came full circle for me when Gosling revised his opinion regarding Oracle’s stewardship of Java, exclaiming that Oracle has been good for Java, and the Android platform won the lawsuit against it, paving the future for Java adoption with that OS (of course we’d be a bit naive if we thought the battles between Oracle and Google are over, nevertheless it’s a good thing to see such fantastic adoption of Java in mobile).

Although certain areas still need to improve (e.g. Java Community Process and the Open Source Software communities), it’s clear that Oracle is continuing the development of the language, and it’s encouraging that adoption continues to rise with new platforms providing whitespace for the curve.

Next, JavaScript’s resilience historically is amazing and inspiring. It first appeared in 1996 with the Netscape web browser to satisfy the growing need to be able to functionally do more with hypertext rendered on the desktop. Because it was easy to use and it worked well, adoption grew but it wasn’t smooth, (e.g. when ASP.NET was first released, developer exposure to HTML was abstracted and javaScript was hard to get to). Then, AJAX appeared, and tools were forced to ensure developers had consistent and simple access to JavaScript. The contemporary combination of HTML5 to build layout, CSS3 to style it and JavaScript to manipulate page elements is clearly the most popular method in building rich UIs for the web.

Growing adoption of JavaScript has pushed it beyond the browser (e.g. node.js) so that its simplicity and power can be leveraged in many other contexts, and it will continue to be comfortably used outside the browser due to the standards upon which it is based (ECMA-262 and ISO/IEC 16262:2011). And, we continue to see major vendors throw their weight behind JavaScript (e.g. Windows 8 fully embraces JavaScript).

With a powerful foundational language for business logic and a bright future (Java), and client-side technologies for building rich UIs (HTML5, CSS and JavaScript), the final remaining part is server-side dynamic scripting. As evidenced by popular interpreted languages on the server (e.g. Perl, PHP, Python, Ruby) clearly a large and complex ERP can leverage the capability. And given the Banner user community is already asked to undergo skill-set evolution from PL/SQL to Java, adopting yet another language for dynamic server-side scripting would be overhead intensive, which brings me to Groovy. Among many other fantastic attributes, Groovy embraces Java syntax, which addresses a key concern in the Banner community relative to skill set evolution (keeping it simple).

There you have it, the foundational technology choices of Banner XE and the background behind them. These are clear and stable choices, providing confidence as we move Banner forward, into the Extensible Ecosystem (XE).