Java EE 8 and beyond

Every new release of the Java EE platform makes it incrementally better by adding new features or simplifying its interfaces which was also the main theme of the latest Java EE ver. 7 release.

Let’s review some of the aspects of the new release and touch on the subject of the platform’s potential growth vectors.

 Reduce the boilerplate code.   Is the mission finally accomplished?

One of the repeated topics in each and every Java EE release since version 5 has been “reducing the boilerplate code”.  And it looks like that with the help of meta programming facilities offered by annotations and Contexts and Dependency Injection (CDI) capability introduced in JEE6, this goal has been practically achieved. The latest beneficiary of this exercise is JMS that in EE7 underwent a major overhaul.  The incidental complexity of JEE programming has been reduced to the point beyond which it would require something conceptually similar to emoticons to make it even simpler.  As the old adage goes: “Make things as simple as possible, but not simpler.” So there is probably not too much to expect (or demand) in this department in future releases …

Caching

Java in-memory caching API (JCache) did not make it to the final release of Java EE7 and is likely to be included in the JEE8 release.  Not a big deal for those Java developers who know that they can always plug in ready-to-use in-memory cache solutions for Java objects such as the open-source Ehcache product (which is a version of the JCache specification as implemented by Terracotta).

More support for web technologies

JEE7 now offers support for a wider range of web technologies, such as HTML5, WebSockets, and JSON all of which will consolidate its position as a feature rich modern web server platform.  This is a big thing, no doubt.

Currently, JEE already has the servlets, JSPs, JSFs, and facelets with the overall trend toward increased sophistication of Web tier programming which is directly correlated with its growing complexity.

To reduce complexity of Web tier development and potentially draw additional interest in the platform, a move in the opposite direction – toward simplified Web programming models in JEE – may be a viable alternative.  Scripting support from web-aware components like Groovlets or the like may fit the bill.  Another area to explore could be simplified access to business logic via an AJAX-based bridge between JavaScript (or any other browser scripting language that may become popular in future, like Dart and Java modules.  Currently, there are quite a few Java Web Remoting frameworks such as DWR,  Apache Tuscany project (to some extent), and Google Web Toolkit, that can be used as a starting point for the analysis of such systems.

Embracing techniques and ideas from open source projects

Java EE has started to more willingly embrace proven techniques and ideas conceived and developed outside of the realm of Java EE specs.  Under this trend, JEE can effectively (and efficiently) leverage the know-how used in developing systems that are already enjoying a wide adoption in the Java community.  An example of this would be the Contexts and Dependency Injection (CDI) capability built on top of the ideas and concepts underlying the popular Spring and Guice dependency injection systems as well as the Seam context management framework.

Now, without much ado, JEE7 fast-tracked the Batch Processing spec based on the Spring Batch framework (batch jobs are tasks that can be executed without user interaction, such as ETL scripts, etc.).

Support for NoSQL Databases

NoSQL databases are on the curve of gradual adoption in the Enterprise world and this is one of the areas where JEE can take a big piece of the action.

One of the models to emulate is SpringSource’s Spring Data umbrella project that offers Spring-powered data connectors to NoSQL databases, map-reduce frameworks, and cloud-based data stores.

EIS vendors, who wish to expose functionality of their products to the JEE platform in a “standard JEE” way, are always welcome to create JCA-compliant resource adapters for their products thus lending credibility (in the eyes of some conservative executives) to their NoSQL solutions.

This activity needs to go along with an effort to standardize a “NoSQL language” (if one is ever accepted by the very diverse NoSQL database community).  Unstructured Query Language (UnQL) project is a step in this direction.
Continue reading “Java EE 8 and beyond”

Create Better Web Applications With Java EE 6 Training

At Web Age Solutions, we have the challenging task of not only keeping up with technology specifications but whether clients are actually using those technologies.  We have started to see much more interest in Java EE 6 training on various platforms so this is obviously taking hold.

Java EE 6 had the unenviable distinction of being released pretty much right as companies were trying to dig out of the 2008-2009 economic downturn.  So even though it did take 1-2 years for all of the major server platforms to release versions that supported it, many clients were taking a “wait and see” approach to upgrading.  Since companies first have to upgrade to the most recent platform before they can even think about using the new technology that is available it has taken until now to really start seeing that take hold.  Even JBoss clients, which usually take a more “figure it out on our own” approach, are doing training to make sure they can fully take advantage of the latest JBoss version, including the very different administration model (which we cover in our WA2060 JBoss Administration and Clustering course).

One of the primary barriers to taking advantage of what the new platform can do is simply knowing what is available.  Quite often projects take an approach of “we do it this way because we’ve always done it this way” and don’t look for ways to improve and simplify their applications by leveraging new approaches to programming.  With Java EE 6 (and soon Java EE 7) continuing to expand the possibilities that are out there this is becoming more of an issue.  We are a long way from the days when only Servlets/JSP were “standard” and you needed a thick “patterns” book just to create your own web framework.

To further support those that might be looking for Java EE 6 training, I’ve updated all of our course maps for Java EE 6 training on the major platforms.  These course maps show a different path depending on if you are familiar with the big changes introduced in Java EE 5 since several clients often skip versions of a server and in particular we are seeing migration paths like WebSphere 6.1 –> WebSphere 8.x.  These course maps also mention some of the Spring 3 training classes we offer since clients sometimes do training in that area as well.

Java EE 6 Course Map for WebSphere 8.5

Java EE 6 Course Map for WebSphere 8.0

Java EE 6 Course Map for WebLogic 12c

Java EE 6 Course Map for JBoss

Looking to the future, the Java EE 7 specifications are finalized and servers are being updated right now to fully support them.  JBoss is as well and will probably be released early next year (they say this year but JBoss is always missing release deadlines).  The tricky thing is that the open source project is being renamed to “Wildfly” and the “JBoss” name will be reserved for only the supported version.  There is already a version mismatch between the two and now having two different names I think is going to cause more confusion but we will see.

As servers release support for Java EE 7 I think the goal is to try and release classes as early as possible.  This will depend somewhat of course on which servers release support first.  We are going to be working internally to develop ways where we can develop hands-on labs that are more modular and can be more easily reused in different courses so we can start developing those early and support more clients that are “early adopters” and want to upgrade quickly.  Java EE 7 contains a lot of updates as well so we are looking forward to introducing that to clients as they start moving to servers that support it!

Now we get to sit back and enjoy watching the “race” of which server supports Java EE 7 first.  Any bets?

Accessing EJBs from Java SE Using WebSphere’s Embeddable EJB Container

Introduction

In this blog, we’ll explore how to employ the Embeddable EJB Container inside a Java SE application using WebSphere Application Server 8.x.

Embeddable EJB Container

One of the new features introduced in EJB 3.1 (part of Java EE 6) is the Embeddable EJB Container. The main two use cases for the Embeddable EJB Container are:

  1. Unit testing your EJBs without requiring a Java EE application server
  2. Embedding EJBs inside a Java SE application, which allows you to take advantage of their benefits (e.g., security and transactions)

The primary advantages of using the Embeddable EJB Container are:

  • You don’t need to install the application server if all you need to do is unit test or employ your EJBs within a Java SE-based application. You just need access to the vendor’s Embeddable EJB Container JAR file.
  • The Embeddable EJB Container starts almost instantaneously, unlike the server-based EJB container (which can take a minute or more to start up), since the Embeddable EJB Container initializes only EJB-related components.
  • The Embeddable EJB Container has a much smaller memory footprint than the equivalent server-based EJB container.

Continue reading “Accessing EJBs from Java SE Using WebSphere’s Embeddable EJB Container”