There are no storm troopers. There is no emperor. In fact, it would be wrong to label a report from Midvale, Utah-based
Burton Group "the dark side" because there aren't any villains.
However, author Richard Monson-Haefel has identified a group of open source frameworks that do not conform to any standards set by Java 2, Enterprise Edition (J2EE), and has labeled them part of a rebellion of sorts.
According to JavaFramework, a framework is a set of common and prefabricated software building blocks that programmers can use, extend or customize for specific computing solutions. With frameworks, developers do not have to start from scratch every time they write an application.
These insurrectionary alternatives are "rebel frameworks," which were created outside of the standards set by the Java Community Process (JCP) and meant to be supplements and even outright alternatives to J2EE application programming interfaces (APIs).
Why the rebellion?
Monson-Haefel said the primary driver has been the increasing complexity associated with developing for J2EE. Rebel frameworks rose to prominence as a direct result of this complexity and offer developers a way to simplify their existing J2EE or replace it entirely.
He said rebel frameworks can essentially be divided into three categories: Web frameworks, persistence frameworks and lightweight containers.
"The rebel Web frameworks implement a Web component programming model that is simpler than using servlets of JavaServer Pages," Monson-Haefel said.
Monson-Haefel said rebel persistence frameworks implement their own object-to-relational mapping strategies that are non-compliant with Enterprise JavaBeans or any other JCP-approved Java standard, while lightweight containers can be used as alternatives to J2EE or they can supplement the J2EE programming model.
It's a risk-reward system
Monson-Haefel cautioned those tempted by the "significant advantages" of rebel frameworks that they are not free from risk.
The rebel Web frameworks implement a Web component programming model that is simpler than using servlets of JavaServer Pages.
Because rebel frameworks are based on a single implementation, they are at risk of open source lock-in. Lock-in is typically associated with proprietary software, but Monson-Haefel said that because rebel frameworks are not built on industry standards like J2EE, JDO or JSF, they are unique implementations and their API and methods are not generally compatible with other frameworks.
"Once an organization has committed to the unique programming model of a rebel framework, it is at the mercy of that open source project, just as it would be to a proprietary commercial product," Monson-Haefel said.
Open source lock-in may sound eerily similar to the vendor lock-in associated with competitors like Microsoft, but Monson-Haefel explained that there are still several key differences, both for better and for worse.
A developer, for example, can take over development of an open source framework if a project dissolves. While this gives open source a significant advantage over commercial vendors, the open source license may require the organization to release its tweaks to the development community free of charge. Most businesses today do not have the experience or budget to support such development, Monson-Haefel said.
There are exceptions to every rule, however, and Monson-Haefel said a rebel framework like Struts is so common and the user base is so large and supported that there is little worry about open source lock-in.
The rebellion will continue
The report predicts that rebel frameworks will have a huge impact on how organizations implement enterprise Java applications in the future. Monson-Haefel said some, like Struts, for example, will become the standard and others will have a profound influence on industry standards.