As I reported in a previous blog I accepted a position as Sr. Analyst for Burton Group. I’m still pretty new to that organization but I’ve never failed to be impressed by the level of integrity they demand from their staff. Shortly after signing on I was asked to sign an 8 page document agreeing to maintain neutrality in the industry. Many analyst firms engage in dubious pay-to-play projects with vendors, such as writing “white papers” that are essentially vendor marketing materials falsely presented as independent analysis. Burton Group doesn’t do that kind of work (and never has); their customers are predominately end users companies, not vendors. In fact, vendors that do subscribe to their analysis services do so to learn more about future trends –Burton Group never writes vendor reports for hire.
Anyway, this desire for neutrality is pervasive through out Burton Group. In fact, when I was discussing working for them they told me that their analysts tend avoid active involvement in organizations that might bias their opinions. In my case, it was thought that my position on the JCP Executive Committee and my work on various JSRs (including EJB and J2EE) was a conflict of interest. How can I fairly analyze an industry for which I am a booster, advocate, and active participant? Burton Group didn’t require me to resign from these activities as a condition of employment, but the question they posed gave me pause. Before I joined them, I decided that it was in the best interest of our clients that I maintain independence.
Originally, I had planned to send a letter to each JSR, the JCP EC, and open source projects announcing my resignation. I still plan to do this, but it occurred to me that my allegiance belongs first and foremost to the end user community, so I’m announcing my resignations in a venue that is public rather than private. (The exception is the EJB 3.0 (JSR 220) expert group from which I resigned a couple weeks ago.)
As of today, I am resigning from the JCP Executive Committee, all JSRs in which I’m involved, and the Geronimo and OpenEJB open source projects. I will no longer participate in these organizations, except as an outside analyst, and I will not join any other organizations that may be perceived as a conflict of interest.
I believe, in my heart, that I’m taking the high road. That I’m being true to my mission for Burton Group. I know that there will be a lot of people who will second guess my motives – we live in an industry in which the truth is, well … often ignored in favor of FUD and self-advantage. That’s fine, but for those who know me know that I’ve been truthful in this blog entry.
Thanks to everyone who has read my books, e-mailed me their opinions, and have supported me throughout my Java career. Thank you also to those who do not agree with me: In most cases you have given me a different perspective on issues and have had a positive influence on my thinking.
Although I’m changing my involvement in the Java community, I will continue to voice my opinions on things that I, and my clients, feel are important. I’ll be writing reports on J2EE and Java as well as other topics. Hopefully, my industry experience will provide value to our customers … time will tell.
Thank you,
Richard ]]>
Advanced EJB Testing with OpenEJB
David Blevin's and I founded OpenEJB some five years ago to create a fast and lightweight EJB container system that could be easily embedded in any application (its even been used in handheld devices). I stayed with the project for the first couple of years, but haven't been very involved in it since. David Blevins, on the other hand, has kept the project going and has continuously improved it (along with a small army of volunteers). Today OpenEJB the EJB container system used with Apache Geronimo - its very powerful, fast, and best of all lightweight.
The fact that OpenEJB is so lightweight and embeddable is why it actually serves as an excellent EJB testing tool. It starts up and deploys EJBs is seconds (that right I said seconds, not minutes). In addition, it provides a robust and fully compliant EJB container system - one that is used by Apache Geronimo for production enviorments.
Rather than create some type of home spun "moch" container system use OpenEJB. All the hard stuff is done - you don't have to re-invent the wheel. As you'll see in Rupp's article, OpenEJB is ridiculously easy to work with and provides you with the best EJB testing framework available today.
I would go a bit further and encourage people who are using commercial products like WebLogic and WebSphere to use OpenEJB in development. A developer can deploy and redeploy his EJBs over and over again quickly, giving him time to focus on developing his EJBs rather than waiting for a server to start-up and deploy an J2EE application - a process that I believe saps as much as 80% of development time.]]>
It turns out that publishing was both easier and harder than I had expected. I found that with some research and work I was able to publish a couple of excellent books of professional quality. Both of the books I published are workbooks or companion guides to my EJB book. They were very well received and very successful in some ways and not so successful in others. For example, the free download versions of these books did great! People loved them. The sale of paper editions by me directly and through Amazon.com were less successful for a variety of reasons. Most importantly, was the workload of daily operations and marketing.
I discovered after about six months that I was spending way too much time marketing and managing the production and sale of the workbooks. At first I sold them directly to customers on-line from my own Web site. I used Yahoo!Store and was very satisfied with how it worked, but I was spending a lot of time (at least 20 hours a week) fulfilling orders and managing day-to-day operations. For me it was a very unprofitable venture. I also found out that people were shy of buying books from my web site because they didn't trust my publishing company as a vendor. I don't blame them. I rarely give out my credit card info to companies I don't know. In an attempt to reduce my work in fulfillment (not to mention directly customer support) I started to exclusively sell through Amazon.com's Advantage program. This required that I sell the books to Amazon.com at wholesale (actually 45% of cover price) which sapped my profits enormously, but it turned out to be a lot easier for me personally. Once a week or so I would ship out a bunch of books all at once per Amazon.com's request. One destination, one client, one package -- it all became much easier. But again, the revenue was diminished by 55%! Which hurt my profits and the royalties I paid to the authors.
In the end I gave up on the whole dream of publishing for one reason: For me, it was too much work for too little profit. I think a person could still make this whole thing work if they were smarter than I was about fulfillment and marketing. Not a big stretch since I'm only human and tend to have limitations. I ended up selling the rights to the workbooks to O'Reilly, which allowed me to cover some but not all of my expenditures. Like I said, it came out as a loss in the end but only monetarily. The adventure was worth it.
What I learned is that publishers earn their money. I don't think they are raking in a lot of money like I used to. It's very difficult to manage the production process, marketing, sales to retailers, etc. With only 1 out of 10 books breaking even, its clearly a numbers game and not that great of one. Grocery stores make about 3% profit (something I learned consulting in the Consumer Package Goods industry) and I'll bet publishers are somewhere in that ball park (Just a guess). Personally, I'll stick with the middlemen and traditional publishers. They fulfill a purpose and, in my opinion, are necessary to get books from my typing fingers to the eyes of my readers.]]>
A few months back, maybe a year ago, I was contacted by Budi Kurniawan. Budi wanted advice on self publishing - I don't even remember what I told him, but he says it was helpful so there you are. Last week Budi contacted me to tell me he has successfully written and self published his first book, How Tomcat Works. You can buy it directly from Budi and get a 45% discount (www.brainysoftware.com) or from Amazon.com. How cool is that!?
Well, I've been reading Budi's book and I have to say that it's really excellent. I mean, I can't put the thing down! His writing style is really straight forward and engaging. The book is in need of some serious copy editing, that's for sure, but in many cases those little rough spots add to its home-grown charm.
Budi's book, How Tomcat Works teaches the reader exactly how the Apache Tomcat Servlet engine works. Budi starts with a very simple (3 classes) web server and slowly, over the course of a dozen chapters, enhances that example until it becomes Tomcat. It's a really cool approach to explaining the inner workings of a system and I just love it. I'm staying up way too late reading the thing and learning a lot about how Tomcat works.
You don't have to be rocket scientist to appreciate the book or understand it. If you have intermediate to advanced Java skills and know something about Servlets, you'll have no problem at all and you will learn a lot.
I hope the book continues to be as good as the first couple of chapters. If it is, I'll probably become its biggest booster. In my opinion, knowing how the software you use works under the covers is far more important than anything else you can learn. Patterns and APIs are fine, but nothing beats knowing how things really work. The best in the business have this type knowledge, so if you want to be the best at Servlet development, than this book is for you. ]]>
While I've had a great time and made many new friends on the speaking circuit, I own an apology to Bruce Tate, the author of Bitter Java and Bitter EJB. You see, at each of these NFJS symposiums we have a couple of panel discussions in addition to regular tutorials. Invariably the panel discussion turns to the merits of EJB. Understandably, Bruce and I don't always agree on the question of EJB, so it frequently turns into a point-counter-point discussion. Although I try very hard to present what I think is reasonable and fair counter arguments to Bruce's points, I sometimes get a little over zealous. In the past couple of panel discussions that I shared with Bruce, I ended up inadvertently insulting him.
This weekend in Colorado, after hearing Bruce express the opinion that EJB 3.0 was basically Hybernate and that Gavin King was writing the entire CMP spec, I provided my own opinion on the topic. I'm part of the EJB 3.0 JSR so I'm privy to the discussions between all the expert group members. So, I said: Although we owe a debt of gratitude to Gavin and the Hybernate project (as well as Spring, PicoContainer and other open source projects) CMP 3.0 is not Hybernate and Gavin is not the sole author of that part of the specification. If you were ask Gavin himself – a very honest person AFAICT - I'm sure he would tell you that there is a lot of give and take in the design of EJB 3.0 and everyone is working hard on it - anything else you hear is pure non-sense.
While all this is true, I went a bit far by saying at the end of my counter point that, "I hoped that my explanation set Bruce straight." Well that was rude of me and for that I apologize. Bruce Tate has contributed a lot to the EJB community and has helped us better understand many of EJB's drawbacks. He doesn't need me to "set him stright" on anything.
Bruce, I'm sorry.
Richard]]>
Well the good news is that I have accepted a job as a Sr. Analyst at The Burton Group – I start May 24th.
Although I found the job the old fashioned way, through networking, I wanted to thank everyone that responded to my original blog entry and offered support, advice, leads, and occasionally a Job. Thank you. I'm very grateful.
When I made that post I fully expected to get flamed, but I figured it was worth showing a little vulnerability so that people understand that (in at least my case) working on the JCP EC and the JSR Expert Groups and Open Source comes at a cost – even if there are very real benefits.
I'm really looking forward to working with The Burton Group. They are a top notch and very respected organization that has a more technical focus than Forrester and Gartner – anyway its right up my alley.
Thanks again to all those who responded – it was a very positive experience and I'm grateful.
Richard]]>
Recently I had the honor of being named one of the 53 most influential people in the Java industry by The Middleware Company. My card was the 9 of Clubs – I have no idea how to interpret that distinction. Obviously, it’s a nice complement especially considering that the votes came from developers who subscribe to TheServerSide.com mailing list – a resource I consult regularly even if the threads are frequently hijacked.
You would think that a guy in this deck of cards is probably making gross amounts of money and living a leisurely life. I can't speak for the other people on the list, but that doesn't describe my life at all. I work really freaking hard – as hard as anyone reading this blog – and I don't own a yacht or drive a Lamborghini. I'm not poor by any stretch of the imagination, but I'm not going to make the Forbs list anytime soon.
The truth is being an independent is hard work. I've been at it now for about five years and its never been a cake walk – ok occasionally it's been easy, but most of the time its not. For the most part I'm busting my butt trying to convince companies that I'm worth what I'm worth even if John and Jane Doe charge a faction of the price. The truth is, I'm usually over qualified for most consulting gigs so the spectrum of opportunities available to me is actually less than the average developer.
I heard once that winning an Oscar in Hollywood is a double edge sword. Actors who win are recognized for the quality of their work, but subsequently find it hard to find work. I even heard it descried as the Oscar "Death Knell": Its great to win, but its better to get nominated. This is probably a bit of hyperbola and I don't mean to compare my meager success to winning an Oscar, but the truth is: Success is measured in many ways and peer recognition – while wonderful – doesn't always translate into big bucks and loads of free time.
After more than five years of going-it-alone, I finally asked for help. This Monday I decided to try my luck for the first time with the grape vine. Although I have frequently helped others find work, I've rarely asked for help myself. Why? Well I guess I felt that I should be able to find my own work. Also it’s a matter of pride. I don’t like to ask for help. I don't want my peers to know that its hard for me to find work that fits my skills and pays well – everyone seems to assume that if your well known you automatically make tones of money. Its not always true.
I've been very involved in the Java industry. Two months after I started learning Java I started the Wisconsin Java User's group – that was back in the spring of 1996. Since than I've volunteered for all sorts of things from open source projects to JSRs and I'm proud of what I've accomplished. The culmination of all this altruism was being voted into the JCP Executive Committee last fall – an honor I've take very seriously.
I've done good things for our industry, but I feel its time to step back and let others have the glory. I have a family now. My boy, Henry is about 2 1/2, and my daughter, Olivia, is just 9 months. I need to look inward toward my family and put them first. That means I need to find a stable job with some longevity and hopefully something with a lot less travel. I think I was honored with the 9 of clubs because I've donated so much of my time to the Java community – people will probably laugh at that, but I can't think of any other reason. Working on expert groups, open source, and the JCP consume enormous amounts of time, but pays nothing, zip, zilch. That's ok, I knew that going into these endeavors and its expected that I should be able to leverage my contacts and name recognition into a living. I have done that to some extent, but it hasn't been easy. You still have to find work that fits your credentials and sell yourself at rates that are affordable – these are usually contradictory objectives after a certain point.
OK, so why this blog? Well, I'm hoping that someone will read it and say "Hey, I got just the job for this guy! What's his e-mail address?" (btw it is Richard@Monson-Haefel.com). Head hunters and other professional placement guys should not bother to contact me - you guys are evil.
There is another reason: On occasion I've had people ask me how they can manage their career to become more successful – to be more like me. This always makes me wince. I've been fortunate – no doubt about it – but I wouldn't recommend my life style to anyone. It’s a lot of work with very little pay. As I said, peer recognition is great – its probably the best recognition you can have – but making a living is not a bad thing either. I'm honored to be counted in that deck of cards with the likes of James Gosling, Rod Johnson, Gavin King and others – but its time to join a new deck – one that gives me more time with my family and actually pays a salary.]]>
Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down.
An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more.
To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself.
Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. Its the recognition that the Java is more than a programming language; its a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform.
The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.
So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform. ]]>
There is, in my opinion, only one solution to Amazon.com's fraud-ridden book review system: Only customers who purchased the book from Amazon.com should be able to post a review on that book. Reviewers should be allowed anonymity, as long as Amazon.com keeps track of the reviewer's real identity. Amazon.com should not allow any Tom, Dick or Harry with a Yahoo! Or HotMail Email address to post reviews on any books they want that's the system they have now and it has resulted in a review process that cannot be trusted. If you buy the book from Amazon.com, then you can review it. ]]>
What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB.
In particular developers appear to be most interested in the following:
1. Ditch CMP or make it simpler like Hibernate or JDOSupport for these top 13 features are shown in the order of preference. In other words, most people wanted number "1: Ditch CMP or simplify it like Hibernate/JDO". Of course these rankings are suspect because there were only 131 relevant "nominations" (out of 240+ postings). Still, this anecdotal pole provides us with some idea of what developers are looking for.
2. Use a POJO programming model
3. Add support for Interceptors/filters/AOP.
4. Eliminate/Consolidate the component interfaces (remote, local and endpoint).
5. Make deployment descriptors more like XDoclet
6. Instance-level authentication/entitlement.
7. Replace the JNDI ENC with Dependency Injection (a.k.a. IoC).
8. Add a Mutable Application Level Context
9. Support development and testing outside the container system.
10. Define cluster-wide singletons for EJB.
11. Clearly specify and standardize class loading requirements.
12. Standardize the deployment directory structure for EJBs.
13. Support Inheritance.
Some of the items can be grouped together to give more weight to a particular approach. For example, item 1, 2, 4, 7, 9 and 13 all seem to point at a CMP programming model that is more like Hibernate. Hibernate uses a POJO programming model with dependency injection (IoC) and is not dependent on client interfaces. In addition, Hibernate applications can be developed and tested without a container system. A tip of the hat to Galvin King and crew.
Other items were interesting but not surprising like asking for an XDoclet-like vendor-agnostic deployment processes. This is a big concern of mine since EJB isn't really portable in its current incarnation you can't just drop an EJB JAR into most J2EE servers without adding some vendor specific deployment information. Actually this aligns nicely with the request that EJB define a standard directory structure for deployments similar to Web components.
The mutable application level context was a surprise for me. Standardization and specification of class loading behavior was not a surprise. Requests for instance-level authorization was also expected it's something developers have been asking for since EJB 1.0.
I was delighted to see so many posts on this subject. Clearly people feel there is much to be done. I was less excited to see the thread wander off into Spring vs. JBoss vs. Mike Spille territory but I found those posts interesting too.
Obviously, there are better mechanisms for measuring public opinion than a blog. Perhaps someone will take on the task of organizing a more accurate pole, but for me the information and posts were very informative. I read every one of them. I greatly appreciate the time and effort so many put into responding. Thank you.
I'm sharing these findings with the JSR 220 (EJB 3.0) Expert Group and expect your comments will generate a lot of discussion and a great deal of solid action by the group members. Keep an eye on JSR 220, eventually it will make it into public review at which time you'll have something solid to review and comment on. Your feedback is critical to the success of EJB.]]>
What do you like or dislike about EJB? If it's broke, how should we fix it?
This is an excellent chance for you to make a real difference. All I ask is that you stick to the facts and your own experiences. Please try to avoid flames, zingers, and debates so that I can make the most of your feedback. ]]>
I've received a lot of mail and seen a lot of postings about this blog entry. Some of it has been supportive and some of it has been . Well, not. The one thing that is common to all but a few of the responses is that people have misunderstood my point. This is good evidence that I did a poor job of articulating it something writers struggle to avoid. Anyway, I offer the following as a clarification.
Here is the point of the blog:
The majority of open source developers are not paid for their contributions. I'm not talking about high profile core contributors; I'm talking about all the other people who make open source a success. What pains me is that some of the few who make a living doing "professional open source" try to paint the picture that everyone is making money. That's not true, and its not why open source works.
Open source works because it gives developers freedom of choice and expression. Developers get to choose which projects they work on and therefore the direction of their own technical growth. Developers get to choose what to contribute and how much. It's about freedom of choice.
People give all kinds of reasons for doing open source that are simply variations of the freedom of choice theme. For example, developers feel a need to "give back" to their community. Well open source makes that possible because it gives you the freedom to contribute code, bug fixes and documentation. Another reason given, is that people get involved in open source to "build their resume", which is just another freedom of choice. Open source lets you build practical experience in just about any area of software you are interested in ask your employer if you can start doing game development on their time and see what they say.
I have worked as a professional open source developer, and sometimes I've been paid for my work. Today, I'm not paid to work on open source but I continue to contribute as best I can because it gives me the freedom to work on those things I find interesting.
Open source does offer the potential to make money - No doubt about it - but that's not why open source is successful. It's simply a benefit of the freedoms open source offers us as individuals. It's not about ego; it's about choice. It's about fulfillment and creative expression. Money is great. I'm all for it, but its not why I work on open source. I could make a lot more money working for a vendor, but then I wouldn't be able to choose what and when and how I do my work.
The simile that I gave of a "fine artist" was meant to illustrate the motivation of the average open source developer. I have a few friends that are artists. Some are commercial artists and others are non-commercial artists, sometimes called "Fine artists". My commercial artist friend has never had a lot of choice in the medium he works in or the subject of his work or even the creative direction. He does what the customer wants, which is how most successful business work. My non-commercial artist friends, the "fine artists", work in any medium they please, on any subject, in any way they want. The motivations of the fine artist are intrinsically the same as those of the open source developer freedom of choice and expression.
Paradoxically, freedom always comes at a cost. You must give something up, usually something tangible like money, lives, comfort, and such things to have freedom. Most open source developers do not make money doing open source work (contributing patches, bug reports, helping others on the mailing list, etc.), but they do benefit. They have freedom.
*************************************************************************************************
Oringinal Blog Entry: Janaury 22nd, 2004
I have a friend who works in commercial software and makes a pretty good living actually a real good living. He finds the "whole open source thing" quite incomprehensible. Why on earth would you waste hours of your own time creating software without pay? My wife wonders the same thing.
The truth is: The difference between open source developers and commercial developers is the pretty much the same as the difference between a starving fine artist and a fat and happy commercial artist. The commercial artist, if she is any good, is probably paid a decent amount for creating logos, advertising, album covers and such things for someone else. A person who creates fine art, on the other hand, isn't likely to make more than a pittance even if they are lucky enough to get a show. While it's true that that some fine artists make it big, this is relatively rare when you look at the whole population. So why do people choose to create fine art, rather than commercial art? Freedom. Fine artists get to work when they want, create what they want, take credit for their work, and in the end enjoy the public scrutiny of their peers.
The same is true of open source developers. While a few make really good money selling consulting and training and other services, the vast majority of open source developers don't make anything. But they do have freedom. Open source developers can choose which projects they will work on and how and when they'll do the work. In the open source world no one will tell you what projects you must work on, or when you should work, or how much you should do. That's up to you. For the most part you are free to be as creative with your code as you like if your code is good it will be adopted. If its sucks it won't.
So the price of freedom of expression for most, if not all, open source developers is well poverty. Ok, that's a bit of an exaggeration since a lot of open source developers have a day job, but that's just as telling. To do open source, you have to have a day job. You can't expect open source to feed your family or even your cat for that matter. As I said there are exceptions, but most open source developers do it for the love of writing software. While commercial software developers do a great job of feeding their families, open source developers do a better job of feeding their minds. In the end, you have to ask yourself which is more important: The things you own or freedoms you have. ]]>
Groovy combines features of Python and Ruby (two popular scripting languages) into a Java friendly syntax. It makes working with object graphs (e.g. a bunch of business objects that have complex relationships) really easy it's great for working with collections, XML and HTML. There is also support for regexp, SQL and scripting of Ant tasks.
Groovy saw its first release last December 2003, but its still very much a language with room to grow. If you are interested in getting in on the ground floor of what I believe will be an important new scripting language, than please visit the Groovy web site and see what you can do testing code is always a big help. Personally, I hope to help with the documentation of this language.
The bottom line is that Groovy is not a replacement for Java its a tool you can use to be more productive with Java. Groovy's not a silver bullet either. I can imagine lots of scenarios where I would prefer to work with the Java programming language, but its very useful in certain circumstances especially when organizing and filtering object graphs or text data for example text files or XML or what have you. ]]>
So what's next? I've wanted to write a book on J2SE for a couple of years, but since this space is already crowded I've put it off. Recently, however, I've decided to test out some material for such a book - I may post it on the Internet. The purpose of the book, tentatively titled This is Java, is to explain how Java works under the hood. If all goes well, the material will be easy to read and accessible to intermediate developers and άber-wonks alike.
In addition to working on This is Java I'm going to be very involved in the JCP Executive Committee this coming year. There are a lot of specs going through the process now and probably a lot more to come, so this will take up a fare amount of my time. I'm also working on JSR-220 (EJB 3.0) and the Apache Geronimo and the OpenEJB projects. Of course all these efforts are more or less philanthropic since they don't pay cash. To earn a living I'll be spending about 20 hours a week consulting and/or doing some training nothing solid to report on that end yet.]]>
An explicit programming model, by my definition, is one that reflects the complexity of the underlying system by offering developer very precise fine-grained control. An example of an explicit programming model is EJB, which gives developers a lot of control over how enterprise beans interact with their container system and serve requests. EJB is explicit, because it exposes a lot detail about the underlying system to the developer. An explicit programming model like EJB offers developers a lot of control, and therefore flexibility, but at a cost. Explicit programming models tend to be complex and difficult to master.
An implicit programming model, also by my definition, is one that hides the complexity of the underlying system. I can't think of any good examples of implicit programming models in J2EE today. All the standard J2EE APIs are pretty much explicit. Something that comes close, IMO, is the JAX-RPC Service Endpoint (JSE) component, which is really just a POJO (plain old Java object). The JSE allows you to develop sophisticated Web services but doesn't require familiarity with SOAP, http, or even the Servlet APIs. Its not prefect: You still have to know about the JNDI Environment Naming Context to do something useful, but its a start in the right direction.
Personally, I would like to see all of the J2EE components and APIs offer a simpler, optional, programming model. One that can be easily mastered by novices but allows users to incrementally leverage more sophisticated features as needed. ]]>