Digital Edition

Wiseman's Law, TLAs, and Java: Expert Proposes a Brand-New Meaning for JSR
Wiseman's Law, TLAs, and Java: Expert Proposes a Brand-New Meaning for JSR

-The original premise behind a J2EE container was glorious: abstract multithreading issues, server memory management, wire protocols, and so on, from the programmers and allow them to focus on implementing solutions, not server infrastructure. Somewhere during this journey the JCP has shifted from its solution-oriented roots to merely implementing specifications. This trend must be reversed...for the sake of our community. -

(October 8, 2002) - In the current (October) issue of Java Developer's Journal, the director of technology at Personified Technologies, Jason Weiss, has lit a flame under the jewel of the Java specification crown, J2EE.

The spec, says Weiss, is too complex.

"EJB, JSP, JMS, JMX, JCA, JTA, JAAS, JAXP, JDBC, JNDI..." he rattles off the acronyms. "This is just a partial list of the acronyms in the 228-page J2EE v1.4 public draft. . .and I was able to assemble this list of acronyms before I even reached the bottom of page six!"

This new version of J2EE is presented as the Web services version, Weiss adds. "So to be fair I should add SOAP, SAAJ, JAX-RPC, and JAXR to this list. In this age of integration, I wouldn't feel right if I didn't include JCA and JACC. I also feel obligated to at least mention the unfortunate specifications that were absent the day acronyms were handed out, like servlets, JavaMail, J2EE management, and J2EE deployment."

If this list of acronyms overwhelms you, Weiss has a suggested course of action that will help Java developers become educated in J2EE 1.4. Each one of the aforementioned acronyms is a specification unto itself, so all you have to do is read each one, and you'll be set!

Or maybe not. Let's see: the EJB 2.1 PFD specification is only 640 pages, so we can cover that tonight and tomorrow. On Wednesday we can review the Servlet 2.4 PFD specification, which is a more palatable 307 pages. Then Thursday we can download and review the JSP 2.0 PFD specification - a mere 374 pages. Hmmm, maybe reading each of these in sequence isn't a solution either, unless you're fortunate enough to be employed by a company that will let you sit and read specifications for a month straight (in which case, where do I apply for a job?!).

Weiss's approach is almost philosophical. It requires a sense of history

"We must ask ourselves what makes a technology successful," he says. "Looking back about 12 years, we saw the popular adoption of client/server technologies, and we saw business solutions implemented rather quickly. The kingpins of client/server were PowerBuilder and Visual Basic. I was fortunate enough at the time to be a Microsoft Certified Trainer and a Certified PowerBuilder Instructor. In the course of about five years, I taught a little over 1,000 students, balanced with intermittent consulting engagements that kept my feet in the real world. While client/server had its weaknesses, I think we can reach a consensus that by and far PB and VB were successful at what they did."

"In fact," Weiss continues, "both technologies passed Wiseman's Law, which states: A successful technology will saturate an 80% sampling of programmers only if 80% of the technology can be understood by those same programmers without forcing them to work beyond their regular work hours."

As Weiss puts it: "Rarely is there a discussion on the learning curve of a piece of technology. As a manager I'm responsible for a team of programmers and I must ensure that the team maintains a high degree of productivity. One weakness of Wiseman's Law is that it doesn't define any time frame for achieving the 80% milestone."

He continues his train of thought, "What's an acceptable time frame for a learning curve? Again, let's look at history. Both PB and VB offered a one-week fast-track training course. A developer certainly wasn't ready to pass any certification tests after that one week. However, most students were fluent enough in the technology that after completing the course, assuming they used the technology on a daily basis at work, within three months they could be implementing business solutions."

If we applied these same metrics to Java and J2EE, Weiss wonders, how would the technology rate? "Right now, I believe the answer is very poorly. The problem, however, lies not with Java or J2EE, but with the way Java evolves through the Java Community Process."

The formal goals of the JCP are found at The Java Community Process is the way the Java platform evolves. It's an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits.

"Specifications don't solve business problems, they solve technology problems," Weiss reminds us. "Companies expect their programming teams to solve business problems."

"Take any average Fortune 500 programming team with little or no Java experience," he continues, introducing a simple example designed to bolster his argument. "A team with a deadline to meet. Show them the number of specifications being released with J2EE 1.4. When you multiply that number by the complexity, size, and learning curve of each specification, I bet they become scared and want to reconsider the use of Java. If Java can't continue to entice new programmers while retaining the programmers it already has, how will our community survive?"

"At present, the open-source community appears to be the only one focused on building solutions," Weiss adds, "but signs of strain are clearly evident among even the most popular projects."

"As a case in point," says Weiss, "consider the Apache Axis project. Axis is an innovative next-generation Web services engine that, when completed, will transform a number of interrelated Web services specifications into a solution that can stand strong as one of the cornerstones in any enterprise-scale project. The most disconcerting aspect of Axis is that since its inception in late 2000, there has yet to be a production-quality integer release issued. In my opinion, this is due largely to the deluge of specifications the project must digest. Each time I visit the project's Web site, I'm amazed at how the acronyms are multiplying like rabbits."

"To the vendors and active members of each of the ongoing JSRs, hear your constituents speak!" urges Weiss. "We need a break from this explosion of TLAs (three-letter acronyms). We aren't interested in expanding our already voluminous library of specifications - we can't get our arms around what we have today. As a community, we must pay attention to the beleaguered JCP process and realign it with creating solutions, like those routinely released by the Apache Software Foundation."

He concludes: "By taking steps now, we are investing in the future of both Java and the community that grew up around Java. The entire JCP process must thematically reflect our desire to build solutions that simplify complex technologies for programmers. In fact, the JCP process should continue to use the JSR acronym, but with new meaning: Java Solution Request."

About Java News Desk
JDJ News Desk monitors the world of Java to present IT professionals with updates on technology advances, business trends, new products and standards in the Java and i-technology space.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Back in the old days when I learned C, I read The C Programming Language. If I had read the ANSI C specification back then, I never would have started programming. A 3 year old doesn't need to understand gerunds, infinitives or adverbs to start speaking. Programmers don't need to read the specs to learn a new language - they just need to get started - all things in their own time.

I enjoyed reading the article, and seeing that I'm not the only person out there that thinks J2EE is complex. I will be forwarding this to some of my peers!

Many good points have been made and I think most are correct. The specs are indeed daunting. The main alternative seems to buy equally large books at $50+ a pop, and then you have to research to make sure you buy a good one (for each of the TLAs) - result, same 2000 pages of reading and who has the spare time.

But I do agree that in the long run the use of new and innovative frameworks (possibly several) will help out. I especially appreciate the several that responders have recommended (even if it's their own company) as I might not have heard of them elsewhere.

Along that line of thinking, I'll toss in another (and I don't work for the company or own stock). The Wakesoft Architecture server provides a framework that helps you comply with Sun's Blueprint design patterns and supposedly makes it much easier to do J2EE. Even if you don't end up using their product, the claim is that it is also a real good learning tool. This is all hearsay at this point, as I've yet to find the time to try it out (and if you don't have time for the super-tools, when are you gonna find time to read the specs?), but I intend to check it out eventually.

See and possibly also check out the article at

Look it's a real programming language, not a scripting language. If it is too tough for you then ComSci may not be for your. Go back to VB if Java is too tough. The TLA's keep your mind on where you are and the rules for that area.

No you can't just click and point at this stuff and make it work. So y'all better start getting a clue or leave for some easier language. Let's not lower the bar so that any idiot can wake up one day and say they want to do Java. It don't work that way, deal with it!!

So when are y'all going to rip BillG a new one for all of the TLA's in .Net?

J2EE has much to do with implementation technologies. Architecture and system design should be understood first. Then, when deciding on how to implement, it is easier to pick and choose which technologies fit, and sort through and pinpoint available solutions. Sometimes VB or PB may be the best implementation technology, other times J2EE components may be.

As humans, we tend to critisize what we don't know. I wouldn't expect a PB or VB developer to be proficient in Java, and visa-versa.

After working with M$ on server side for many years, I enjoy working with Java. Since I learned DOS and Win$ first, so I also enjoy developing Java applications on Win$ and deploying on Linux:)

I took a course on EJBs about 3 years ago. It is very complicated. The tools are relatively expensive, and have a significant learning curve. Because of this, I developed a library that allows a Java developer to create a DB and manipulate complex data relationships using ordinary (simple) data classes, all without knowing any SQL; and works with multiple DBs. My goal was to provide an intuitive API that was easy to learn - in less than a day.

Dave Dillon
Dillon Software Services, LLC

Looking at the issue: Java specs have too many pages and too complex, it is easy to blame JCP. But, one must understand this - J2EE has relied on multi-vendor licensing scheme for growth and diversity. Under this system, each vendor is motivated to advance its product portfolio business through introducing new features that supposely leapfrog its competitors. And, the best way to gain that edge is to publish some JSRs with JCP. Often, those JSR are pointless and self-serving. To balance interests between vendors, naturely, JSR becomes wordy and sometimes carries overlapping features. For example, JSP-bean include, tag-lib, ... Redundant features of cause create unnecessary complexities.

Clearly, reforming JCP is a superficial cure for a problem that runs much deeper - balancing bickering between vendors. The only good thing is that the number app-server vendors has been shrinking. Maybe, that will cut down on proposed JSRs.

IMHO you're all right and have only yourselves to blame for the mess you're in. All this NEW technology can work, it's not easy but hey it's meant for distributed application dev't not C/S. There aren't many tools but whenever something new does arrive no one wants to pay for it, and start ups can't grow on 199 a pop payouts.

Furthermore, most people seem hell bent on shoe horning their existing tech and ways of thinking into these new techs no matter what. Result, spit and bogie solutions of RDB's, stored procs, triggers, messaging, mapping, strange OO models and complex biz logic.

IMHO you're all right and have only yourselves to blame for the mess you're in. All this NEW technology can work, it's not easy but hey it's meant for distributed application dev't not C/S. There aren't many tools but whenever something new does arrive no one wants to pay for it, and start ups can't grow on

Java is a programming language, nothing more. When you have a business problem to solve that the standard SDK doesnt extend to, you read the specification that best matches the requirement. Simple! If you want to make money programming youll never do it by knowing the APIs, you

Java is a programming language, nothing more. When you have a business problem to solve that the standard SDK doesn

Unfortunately "ease of use" is not part of the specs.

The only issue with the spec being complex( and rapidly changing) is the ability for developers to get a hold on this and curn out their apps quickly.

I agree this has more to do with using the right tool than understanding the specs. Vendors need to address this issue in practical usage if their products are to succeed.

Using good RAD tools like Jbuilder/VisualCafe(now TogetherSoft) etc with your app server should get developers up and going in no time!

These IDEs are also a big help to developers who are used to RAD tools like VB /PowerBuilder!!!

Let the JCP do what it does and allows us to use the solutions as appropriate!

When you look at a set of APIs(J2EE) and the docs that accompany them, you must look at the problems they solve, and then weigh the solution against the work you would need to do with any other set of similar APIs (.NET and everthing else) to provide the _same_ level of service you could get with the first set of APIs(J2EE). I can't think of a cross platform framework that even comes close to hitiing all of the services provided withing J2EE, much less gets it done with more sucess than Java and J2EE thanks in part to the JCP.

Java, J2EE and indeed JCP is by no means perfect, indeed it is a work in progress. But I am happy to say it is progressing nicely as far as I am concerned. If you are dedicated enough to your craft to read an hour or two a day about your profession and apply it your craft you will prosper, no matter what you do for a living, but this is especially true as an enterprise software developer. At least as developers we have been blessed with a rich and full featured toolkit in Java and J2EE with which to fashion our work as we will. The sad fact is that many script kiddies are just to eager to hit their X-box instead of picking up a spec and trying to digest something that could make them a better developer. I am convinced based on experience that with even a little investment in time the promise of J2EE soon becomes evident, and delivering on that promise is as simple and open as ever. Take projects like JBoss, ANT, XDoclet, JUnit. All of these open solutions build on open APIs. I think Sun needs to open up even further, but at least JCP is a step forward, which is a huge breath of fresh air after M$.

The instant gratification crowd will sink to their level. The rest of us will find the good in a process like JCP and make it better in the future.

Quit complaining and start contributing.

The software industry is so predictable, constantly bouncing from one extreme to the other. First we create tools/environments which are very cool, and over-hyped, but then we want more. So we create J2EE with specs and APIs to separate what we are doing from how we are doing it. Then we complain that these technologies are too difficult to learn and keep up with. Well, constantly wanting more is part of the everlasting human condition, so stop buying into the notion that current technology is going to last, and the notion that there aren't shortcuts taken in any technology.

One of the current short-comings in J2EE is in training. J2EE is big and will continue to change and grow. That doesn't make it bad, it is actually a good thing. However, expecting to teach the remaining 80% of developers the same way the first 20% of early adopters ramped up is just not going to fly.

Does this mean throwing more money at current technical training methods. Absolutely not!! I am amazed that for all the object-oriented designs and patterns we have, books and courseware has remained large and immobile. Try getting a good course or book on any technical topic that is not at least 3-days long.

Tools don't solve the problem. A constantly active developer knowledgebase and mentoring program is a good step towards a more productive enterprise development team or department....regardless of the technology.

The specs aren't at fault, we all are. J2EE isn't the problem, we all are.


I think managers have to start seeing past the hype and realize that a web app is going to take 20 times the effort than a similar project in a 4GL like Powerbuilder. Not every little app that is required needs to be web-enabled. Client/server in PB = one week, web-enabled in Java = 4 months!

Subscribe to the World's Most Powerful Newsletters


"Calligo is a cloud service provider with data privacy at the heart of what we do. We are a typical ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, disc...
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
When building large, cloud-based applications that operate at a high scale, it’s important to mainta...
Having been in the web hosting industry since 2002, dhosting has gained a great deal of experience w...
NanoVMs is the only production ready unikernel infrastructure solution on the market today. Unikerne...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO Silicon Valley 2019 will cover all of these tools, with the m...
SUSE is a German-based, multinational, open-source software company that develops and sells Linux pr...
Your job is mostly boring. Many of the IT operations tasks you perform on a day-to-day basis are rep...
Technological progress can be expressed as layers of abstraction - higher layers are built on top of...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (No...
All in Mobile is a mobile app agency that helps enterprise companies and next generation startups bu...
Big Switch's mission is to disrupt the status quo of networking with order of magnitude improvements...
Every organization is facing their own Digital Transformation as they attempt to stay ahead of the c...
Dynatrace is an application performance management software company with products for the informatio...
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism...
Yottabyte is a software-defined data center (SDDC) company headquartered in Bloomfield Township, Oak...
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in developm...
Blockchain is a new buzzword that promises to revolutionize the way we manage data. If the data is s...
Serveless Architectures brings the ability to independently scale, deploy and heal based on workload...