Developers can be passionate about the tools and languages they use for development. This passion is a double-edged knife. It can foster growth of the technology's adoption and inspire the direction of energy into the language that one has chosen to advocate. The passion might also scare off those who wish to use the language or are just entering the field, particularly when the opposing view is exaggerated, incorrect or out of date with the current state of the technology. This latter scenario injects (often unintentionally) into the dialogue regarding the technology in question Fear, Uncertainty and Doubt (FUD).
Java was introduced in the mid-1990s. Issues inherent to the technology and the governance of the technology have been numerous through the years. Many of the issues raised have been valid and significant. Others, not so much. There have been issues with speed, floating-point arithmetic, handling of unsigned numbers and so on. Most of those technical issues have been addressed as the language matured. Java recall is a catch-all for the base language, facilities that support the language (the JVM), its licensing and brand management in general. Also, the legal kerfuffle between Oracle and Google being notable and having spanned a number of years certainly opened the door for both legitimate and exaggerated FUD.
Many of the above performance and security issues have been addressed by software engineers in maintenance and full revision development releases. Indeed, the language continues to evolve, and even as version 8 of the platform seems to have hit its stride, version 9 reached general availability this past September, and the community of developers that rely on this language and facilities seem anecdotally well into experimentation and adoption. With version 9 still a pretty fresh and current release, version 10 already has reached its release candidate stage. Some Java issues have been addressed as the governance model evolved, legal issues resolved and license issues clarified. It did seem for a while various projects could have led to a fracture: IcedTea, Harmony and so on. However, these big players actively supporting and backing the OpenJDK project, bringing their side efforts, engineers and brand prestige with them, deserve a lot of credit for the acceleration and advancement of Java SE in recent years.
One area that has been a recent hotbed of movement, discussion and, yes, a source for the generation of FUD, is the Enterprise Edition of Java. So, just what is all the hubbub?
In a nutshell, Oracle pushed out control of the Enterprise Edition—which for non-Java developers and discussion purposes here—can be thought of as all the "heavy duty"-level facilities in the Java toolbox not provided by the base language, JVM and JDK. Or, put another way, EE provides to us mere mortal and all-too-busy developers all manner of facilities, frameworks and other useful tools to abstract away quite a bit of the drudgery that goes with building enterprise-scale software routines.
Oracle's move on this standard and code base governance was a huge shift.
For most of us Java folks, not a lot of time is spent thinking about memory management. Is this critical aspect of programming gone? No. But, an awful lot of boilerplate and routine tasks are simply taken care of by the facilities provided by the JVM. This catch-all "Java Toolbox" is taking care of most and often all memory management business for us.
I recall feeling a bit unsettled when I wrote my first Java program that I had declared and initialized variables and didn't circle back to clean up after myself and recover that memory. But, hey, the JVM was on it, and through the years, it grew more efficient at recovering resources no longer needed by the program. Dealing with memory was pretty much abstracted away. What was a strange sense of loss way back then seems almost intrusive when it comes up in a project now: "Hey, why am I even thinking about that? Okay, I'll do some JVM-tuning or optimize some code a bit."
In many ways, this abstracting just rolled on—sometimes faster than I realized. Some approaches stuck and made the cut into some layer of the Java SE/EE standards. Others fell from favor. Still, other fine libraries that were very well done and a delight to use (looking at you JODA time—JSR-310) seemed to be overlooked for a long time. Java SE, and to a greater extent Java EE, reflects this constant evolution a great deal. The evolutionary tree has lots of branches.
Ultimately, most included layers were beneficial. Developing routines to stitch together data from a variety of databases from a number of vendors is a typical programming task—just ordinary integration and reporting. Early on, it was great to be able to ride existing ODBC with JDBC connections! Soon after, JDBC just evolved, and the once-needed ODBC layer was discarded and unnecessary for the standard. It didn't happen overnight, but it happened. Eventually, it was apparent that Java developers still were writing quite a bit of custom or native SQL to get the data we needed and still dealing with differences across database products.
Behold, JPA—yet another layer of abstraction above JDBC—appeared. Now, in many ways, most database interactions are via the perspective of Java Objects and an entity manager to deal with flipping data in and out of Java and various data stores like PostgreSQL or MS-SQL and even NoSQL databases like Mongo. The EE JPA facilities deal with many of the idiosyncrasies between vendor implementations. Often one needs only to let the EE facilities (embodied in a container) know the "flavor" or even the version of the RDMS(s) with which I need to communicate. Just as in the earlier example of Java and memory management above, it's not that I don't think about optimizations or picking up performance when working with databases—there are tools for when I need to, or I can bypass a layer for a particular use case—but a lot of the drudge work is just handed off to the provided facilities. I step in where needed. And, in situations where I engineer on the fly (too often I admit), I just add an optimization loop (usually in code review) to pick up the speed I'd like to have or back-log the optimization for a future dot release.
Well, you have many layers and frameworks from which to choose, so you have to make decisions. There were times in the past when I would have addressed a database issue with a trigger or stored procedure. I still might in some cases today. But, before I do make a choice, I ask myself questions similar to "Is it worth it?" "Will the facility or abstraction provided get the job done?" And, of course, the very important, "Will staying in the container make it easier for the programmer that follows me or even a current teammate versus a performance pickup that might not be noticed if I optimize outside the Java provided (Standard or Enterprise) facilities?"
Of course, as with any mature language, there is a full ecosystem of projects that can fill in gaps not yet absorbed into the standard.
If a particular implementation of these extensions gets shaky—which is to say FUD enters the picture—take your code and jump to a different container. Why, because it became apparent to Sun Microsystems (acquired by Oracle) that it had a tiger by the tail and some kind of governance model would be needed to keep this Java creation on track. Was/is this model always good or smooth? No. But, did it provide a way to get folks involved? Yes.
From a big-picture point of view, it was a good call. Could it have made a bigger call? Say, push the Java out to the ISO folks or maybe the IEEE folks? Maybe. But, why debate hypotheticals, right? The point is there was a forum. The big picture is that warts, bumps and bruises aside of the governance approach the "facilities" that a Java developer can depend upon both at the JVM Standard/Base level and at the Enterprise/Extended level now had a pretty good level of predictability. If one EE product—or even a specific layer within a given EE product or container—gets shaky, just jump to one of the other 20 products that complies with this very capable lowest-common-denominator standard.
As Oracle began to signal that it was getting ready to find a new home for EE, it appeared that the reference implementation, Glassfish, was in jeopardy. What kind of jeopardy? Those of us that code against the reference implementation might not be able to get commercial support should we need it! Many developers didn't know which way the wind was going to blow, and uncertainty set in, which engendered in me a sense of fear in advance of going into production as the vendor we'd expect to turn to if trouble of some kind was encountered was seemingly but not definitively bailing on the standard code base it oversaw introducing doubt. It was the FUD trifecta with no help needed from the opinion leaders.
I depended on Glassfish. I didn't know what to do next. It was a truly terrifying six minutes! (The six minutes included refilling my coffee mug.)
I Googled Glassfish alternatives. JBoss was the first commercial link I hit. Wildfly was the upstream open-source and compliant base I hadn't re-visited in years. Hazaah! I had a path and wasn't painted into a corner. If I had scrolled down the page half an inch, I probably would have ended up taking Paraya for a spin instead.
In a decoupled polyglot programming world with EE at the core, a developer is not locked in with the logic routines coded. Precious coding hours are protected. There are plenty of open-source options, so development shops both large and small can tool up and develop on the cheap. There are lots of commercial and cloud alternatives, so production launch stress is reduced. In addition, the EE container level frees one to try different outside products (storage, database, SAAS of the Month, web) at different price/performance points and quickly, because mostly it is a matter of configuring the container to point at these services and get back to the business of coding—all benefits of open source in general but some extra sense of safety from a standardized governed stack.
A governed standardized core stack like what is provided by Java SE/EE does not prevent one from stitching together some kind of polyglot solution. So, yes, one can play with the most current programming fad or marketing term of the week and if need be fall back or build upon a technology set proven out within a standards process.
Still, Java makes a developer spoiled. Often, and more so all the time, I find myself looking for a layer, wondering when said layer or its competitor becomes the reference implementation embodied in a JSR via the JCP. Why no generalized abstraction for blockchain yet? Why no generalized subsystem for communicating with AI/machine learning in the JSR yet? Unified security! It's here and developing, but whose implementation will win the coveted (I presume) position of "reference implementation"? I move and process a lot of data between systems. Wait a minute. Why not just make Camel a formal JSR? The Wildfly folks already offer it a "module" in their container.
Wait. Isn't that bloat? It's not bloat. It's an embarrassment of riches. That's a problem with which developers can live. Also, one does not have to use the EE container. If you need some layer/abstraction from EE, just stick with the SE base and pull in the layer you need. For instance, say you need to whip up a quick routine to pull in data from multiple sources (as above) and probably will never use this one-off utility again. Grab the JPA layer and be done. The extension and layers are just tools. Just because you have these tools does not compel a developer to use them. But, boy oh boy, when you are trying to get something done, it's good to know they are available. These tools? Just let the container manage them for you. And, by the way, most containers load these layers/abstractions/tools in a "lazy" fashion, meaning they are on disk but not consuming CPU, memory or I/O until you specifically need that specific part of the standard. Disk space is cheap these days. Still, if it bugs you, try the Microprofile.
As for the above wishlist? Now that Java EE has stepped outside Oracle, I would anticipate that after the governance dust settles, these enterprise-level facilities will begin to accelerate just as the standard-level language and facilities have accelerated. A guess to be sure, but I would assert it's a pretty safe guess.
The current status of things since the six minutes of terror this past summer?
A lot has been going on. Oracle found a home for the code base of the Java EE with the good folks over at the Eclipse Foundation. The Eclipse Foundation is also the home of a very nice IDE, an implementation of the JPA layer discussed above and lots of other neat projects. Many of the big guys are already on board with Eclipse and it being a steward for EE. For instance, Oracle is still on board and Red Hat and IBM are there too.
So far, they seem to have an open ear to concerns from the little guys like myself who are generally more focused on our keyboards and screens. When things seemed most uncertain, the community of developers formed the Java EE Guardians. This group first came to my attention when I read a post by Reza Rahman. Reza and the group, though concerned about the transition, really earned points for keeping cool and making a solid effort to be metered in dialogue with the Eclipse Foundation and Oracle. The Eclipse Foundation gets solid points for being active listeners and moving some non-engineering item like branding up on the agenda. Oracle, though it would have been nice to allow the donated project to retain the Java name and the package prefixes of javax, also gets some kudos for being direct with regard to its stance on these items. It could have strung the process out and been ambiguous, but it didn't. Hey, folks at Apache! Thank you for clearing the road for the use of the name Jakarta. Lots of great projects have evolved over at Apache under that umbrella.
Jakarta as the new brand makes it feel like a seamless transition, despite there having been many stakeholders and lots of moving parts.
In modern corporate speak: great EQ folks!
Java is alive and well. It is growing. OpenJDK seems not only to continue to ensure Java SE is viable, but it also leaves one with the impression that the Java core and ecosystem is accelerating.
Java EE is now Jakarta EE. A rose by another name? And, if OpenJDK is the model for Jakarta EE at Eclipse (under an umbrella project called EE4J), we should anticipate the Jakarta EE standard soon will have its footing at its new home and will both accelerate and evolve as a standard too.
Rest easy. Let the fear, uncertainty and doubt on the future of both standard and enterprise Java fade away.
Welcome, Jakarta EE!