Discussions

News: Opinion: On mountain biking and J2EE

  1. Opinion: On mountain biking and J2EE (22 messages)

    Bruce Tate, author of Bitter Java/EJB, and Better, Faster, Lighter Java, has written about the state of J2EE by making an analogy to mountain biking. He thinks the hill is getting steeper and steeper, and that it is time to lighten up the load to continue.
    The real trail tapered off, screamed down a hill, and went right back down to a natural rhythm of a little up, and a whole lot of down. I think that the Java community actually has a fork in the trail. On the left is a narrow but simple trail that goes back down to the creek. On the right is a huge, wide trail that will accept any type of bike, but it goes straight up. We can abandon the current trail, of heavyweight EJB, and full-blown J2EE containers, but we've got to lighten up. We can use the work that we've done, and the knowledge that we've accumulated, and ride the momentum down for a while. Some fantastic simple, yet sophisticated frameworks lead the way. Spring, Hibernate, Kodo JDO, and IDEA are a mix of open source and commercial products that do it right. Or, we could get overly ambitious, and die on the hill. Think Tomcat with Spring. Think Pico. Maybe some developers are strong enough to make it up that hill, and many will doubtlessly try.
    Read On mountain biking and J2EE

    Threaded Messages (22)

  2. Sounds like a good place to mention lightweight distributed architectures like Jini too, it fits in nicely with the others.

    -John-
  3. Go home Texas! ;-)[ Go to top ]

    I can't help but wonder if an analogy can't be made here with a Texan coming to Colorado and then complaining about the hills?

    Java still pretty much has all the easy stuff unchanged from way back when. The frameworks for servlets, enterprise applications and web services are meant to assist with getting over the big hills in an orderly manner. Any framework can seem bloated and complicated depending on the perspective and experience of the person.

    Choose the right tools for the job and the team - maybe you should have rented a YZ400?

    Once you get over that last hill on Hermosa Creek, it's all downhill to the hot springs and the van full of beer :-)
  4. Go home, Texas![ Go to top ]

    Love this post. In one of my classes last month (nofluffjuststuff symposiums...check them out. Awesome value.), a Colorado ski patrol told me a joke:

    "The first thing that I ask a victim on my hill: What part of Texas are you from?"

    Keep in mind that I'm not trying to say that Java is inherently bad, or flawed. Like everything else, Java will bloat. Vendors are motivated to keep raising the bar, to make things more flexible but also more complex. My contention is that we can and should actively fight the bloat. You vote with your pocketbook.

    In my first blog, I'm trying to make the point that we've simply gone beyond the point where the average developer can cope. This blog, my book, simplicity are not about the top 20% or so of developers who read The Server Side. I know that you understand hardcore Java, and most of you know it better than I do. But a huge job of a developer's job is communication, and making this stuff accessible. It's about the masses. J2EE as it's currently used, forms a hill that's too steep for the average Joe Tourist from Texas to touch.

    So, we take a few steps back (away from the integrated containers and other mega-frameworks), and take one big step forward (with lightweight containers and dependency injection.) We Java developers need to understand that simplification will sometimes be a bitter pill, but it's one that we've got to take. Most of this stuff is not new, and that's OK.

    Let me also point out that things like EJB will still have a place, within the hardest 5% or 10% of the problems that we need to solve. And since that customer set spends a huge percentage of the money, the big vendors will continue to move that space forward. That's OK. We just can't continue to force the masses to go up that trail anymore. You can't force the average developer to have a phd and ten years of experience. No more departmental calendars on EJB. No more distributed object applications when independent stateless clustered apps will suffice. It's simply not sustainable.
  5. slimming down java[ Go to top ]

    This blog, my book, simplicity are not about the top 20% or so of developers who read The Server Side... You can't force the average developer to have a phd and ten years of experience.
    I think that misses, or at least underempahsizes, an important point. The problem with the EJB framework is not that you have to be smart to use it effectively. The problem is that it's cumbersome. It requires reems and reems of code to be written just so that the framework can be used. The promise of light weight cotainers isn't that they are idiot proof, it's that a coder will only need to bring in mechanisms that he/she needs to solve a business problem.
  6. Go home, Texas![ Go to top ]

    I agree wholeheartedly with Bruce on this topic. In October of 2002 I authored a guest editorial for JDJ entitled "Is Complexity Hurting Java?" that made the same point I believe Bruce is trying to make. Yes, many of us who read TSS.com on a daily basis can handle the weight load that is J2EE, but the average Joe Programmer plight worsens everyday. I've thought about starting up a non-profit organization so I could run commercials that state "For less than a $1 per day, you could sponsor a struggling programmer who, despite their best efforts, simply can't grasp J2EE in its entirety."

    However, I do differ with Bruce on his position regarding voting with the pocketbook. Businesses have needs and will continue to purchase Java application servers and related technologies for building server solutions simply because Java/J2EE continues to be the de facto server-side development standard. Fighting with the pocketbook is an unrealistic position because it places the impetus on businesses to stop buying application servers, and that's like asking them to postpone their development projects until the vendors listen. It just won't happen.

    How many people in the J2EE community have to hear respected technologists, like Bruce, make statements surrounding the complixity of J2EE before someone takes tangible steps to end the madness? I still contend today, as I did nearly 2 years ago, that the solution to this problem lies with the JCP. The JCP continues to roll out bloated JSR after JSR. I mean no disrespect to any JCP spec lead or participant. Without them we wouldn't have made it this far. And I'm sure I'll endure the mandatory flame here about development isn't about specifications. But if that's the case, then why are the EJB books growing in size and scope after each and every J2EE release? Perhaps the solution is yet another form of scripting in my JSP page beyond the JavaScript, Java server-side scriptlets and the newer expression language (yes, sarcasm and in my opinion a case-in-point of spec bloat. Was the new JSP expression language really necessary, or does it just add to the complexities the average Joe Programmer has to endure to now learn how to develop JSP pages). The JCP committee members must become more focused on solutions, not specifications. Until the spec leads on these JSRs hear the cries from the trenches AND shift their efforts towards more lightweight solutions, the average Joe Programmer will continue to slam their head into their desk.

    Yet another Texan speaking his opinion,

    Jason Weiss
    jasonweiss@yahoo.com
  7. Go home, Texas![ Go to top ]

    However, I do differ with Bruce on his position regarding voting with the pocketbook. Businesses have needs and will continue to purchase Java application servers and related technologies for building server solutions simply because Java/J2EE continues to be the de facto server-side development standard. Fighting with the pocketbook is an unrealistic position because it places the impetus on businesses to stop buying application servers, and that's like asking them to postpone their development projects until the vendors listen.
    I agree with Bruce here....If you can run your app in Tomcat for $0 in licensing (or in Resin for a $500 site license) then your management will be VERY happy to hear that they don't need to shell out $10 - $17K / CPU in licensing. Notice I'm not saying Tomcat is free.. There's still hardware and operational costs, but these will probably ALSO be lower than the same costs on the full J2EE stack side.

    Let's face it, with Spring / Hibernate / WebWork most apps don't need a full stack. I'm not talking 51% here, either, probably more like 85%-90%. Once there's good JMS support in Spring and other lightweight containers to make JMS development as easy as MDB's that number will go up to 95+%. Most of us are just using EJBs for transactional boundaries anyway... And for those of you who will undoubtedly mention entity beans, go check out Hibernate :-) You're going to have to learn something similar for EJB3 anyway...
  8. Go home, Texas![ Go to top ]

    ....If you can run your app in Tomcat for $0 in licensing (or in Resin for a $500 site license) then your management will be VERY happy to hear that they don't need to shell out $10 - $17K / CPU in licensing.
    You'd think this would be the case but all too often it isn't all about the pocketbook. Some managers will not go with open source for various different reasons. Lack of support, relationship with a vendor, politics, or just plain ignorance are all reasons why managers are willing to pay $17K / CPU instead of $0 for an open source solution. Unfortunately, it happens too often.

    Just another two cents from another Texan...
  9. Go home, Texas![ Go to top ]

    ....If you can run your app in Tomcat for $0 in licensing (or in Resin for a $500 site license) then your management will be VERY happy to hear that they don't need to shell out $10 - $17K / CPU in licensing.
    You'd think this would be the case but all too often it isn't all about the pocketbook. Some managers will not go with open source for various different reasons. Lack of support, relationship with a vendor, politics, or just plain ignorance are all reasons why managers are willing to pay $17K / CPU instead of $0 for an open source solution. Unfortunately, it happens too often.Just another two cents from another Texan...
    Note that Resin is a non-opensource commercial vendor with support available... At a much more reasonable price... And it's very fast and easy to run from within your IDE as an added bonus :-)
  10. Go home, Texas![ Go to top ]

    Love this post. In one of my classes last month (nofluffjuststuff symposiums...check them out. Awesome value.), a Colorado ski patrol told me a joke:"The first thing that I ask a victim on my hill: What part of Texas are you from?"
    My favorite bumper sticker seen in Colorado: "Love Texas? Take 25 South."
    Keep in mind that I'm not trying to say that Java is inherently bad, or flawed. Like everything else, Java will bloat. Vendors are motivated to keep raising the bar, to make things more flexible but also more complex.


    The question is why? Vendors don't raise the bar simply for the sake of doing so, or because they're bored, or even to offer new wow factors in the hope of increased profits(OK, so that is big part but throw me a bone here). Vendors are trying to address the complexities in the enterprise, those that their customers have and demand solutions for. There's a reason for the 'EE' in J2EE; when you look across the depth and width of a complete end-to-end enterprise solution there is a ton of complexity in there (using the entire enterprise as the proper scope). J2EE must increase and adapt to accommodate or keep pace with that,especially as enterprise complexity grows, otherwise maybe Sun should change the name to J2FMSA or J2FSCA (java 2 for medium size apps) (j2 for _some_ complex applications)
    My contention is that we can and should actively fight the bloat. You vote with your pocketbook.
    Developers for the most part don't, corporations do. Corporations like seeing common and recurring complexities addressed within the platform or tool, especially CIO's, CTO's or enterprise architects looking for a standard solution accross the entire enterprise. I think this is a reverse argument for increased complexity especially WRT to frameworks, tools, etc. I would agree that as advisors and keepers of the flame so-to-speak we should fight needless, or redundant bloat.
  11. Hitting the wall[ Go to top ]

    Java and XML were adapted for enterprise applications and we’ve made do with them but they aren’t keeping up with the complexity of enterprise wide software. Assembly, C, and C++ were fine until a level of complexity was reached. Then they hit their point of diminishing returns (economics analogy) or hull speed (nautical analogy) or they hit the wall (bike analogy).

    Java and XML are hitting the wall. Spring and Hibernate take us further but they aren’t the 10x solution we need.

    It’s curious that the limitations of enterprise Java/XML have been common knowledge on the serverside for a year or so but vendors and management still want to use tools that hit the wall years ago.

    Gary
  12. Hitting the wall[ Go to top ]

    It’s curious that the limitations of enterprise Java/XML have been common knowledge on the serverside for a year or so but vendors and management still want to use tools that hit the wall years ago.Gary
    I agree with the basic argument, but this statement implies that there is an existing alternative that provides a 10x solution. And that vendors and managers are totally blind to it. Care to share what it is?

    To stay on topic - my view is that J2EE would've been a complete disaster and couldn't survive for long, if not for the open source projects that work despite all the "standards". And I mean things like Tapestry, Spring, Hibernate and Cayenne.

    Andrus
  13. No arguments about EJBs but for the most part, Java must keep pace with technology and the needs of customers. As time goes on and more applications get completed, the requirements get more diffucult for future endeavors.

    Web Services is not a product of java but came about from the need for interoperability. Java kept pace. Some vendors do it better than others. Distributed computing in Java became easier with Jini. Or would you prefer to go back to CORBA? Java, over the years, has done many things to deal with new technologies and complexities in a more simplified way.

    It seems to me that his problem isn't with Java but with the complexities that are intertwined with progress and advancement.
  14. Or would you prefer to go back to CORBA?
    YES!
    Java must keep pace with technology

    IT industry mostly drives technology for the sake of technology alone and keeps reinventing wheels, which are square at first, then we polish them over time and when they are almost round vendors come with new set of parallelogram shaped wheels.
    ( CORBA -> XML-RPC -> SOAP -> WS with binary wire protocol )
  15. IT industry mostly drives technology for the sake of technology alone and keeps reinventing wheels, which are square at first, then we polish them over time and when they are almost round vendors come with new set of parallelogram shaped wheels. ( CORBA -> XML-RPC -> SOAP -> WS with binary wire protocol )
    So you agree. This is an industry problem. Not a Java problem.
  16. IT industry mostly drives technology for the sake of technology alone and keeps reinventing wheels, which are square at first, then we polish them over time and when they are almost round vendors come with new set of parallelogram shaped wheels. ( CORBA -> XML-RPC -> SOAP -> WS with binary wire protocol )
    So you agree. This is an industry problem. Not a Java problem.
    I am not trying to say: There are not problems with Java language and Java platform. They do exist, but they are minor in comparison with others:
    1. Lack of education and understanding among developers that leads to quest for “THE SOLUTION” and numerous attempts to solve all problems with one tool/technology/etc. EJB is not ideal but main problem is: people try to use it where lightweight solutions like Pico, Hibernate and others would work just fine. With proliferation of “light” containers we will see another problem: lightweight solutions applied and failed where heavyweight tool should be used.
    Let’s look what has happened with SOAP: now “they” pretend that “S” never stood for Simple. Because calling all that stack of technologies “Simple” will sound like a joke.

    2. We have short memory and do not want to study past. We carry the attitude: “ZZZ in 24 hours”. C’mon: development is for professionals, and it requires years of education and training as any another tech job.
    No more departmental calendars on EJB. No more distributed object applications when independent stateless clustered apps will suffice. It's simply not sustainable.
    There is nothing wrong with technology. If quality of such application were good then it would work for years. Real problem is poorly designed ( I would even say non-designed) applications. Also about 70% (IMO) applications should not be written at all.
  17. We're going in circles here in this complexity debate. I wonder if it would be a step forward if we can accept a few things once and for all:

    * The breadth of a general development and runtime platform will always have to include much more than each single project or organisation needs. So, yes platforms are bloated by definition.

    * There will always be ill conceived specifications that we have to live with for political reasons or just because to cope with them is still cheaper than moving away from the mainstream altogether.

    Now, I think, what we should think about is how to avoid going round in circles by throwing out technologies that are considered too bloated, replacing them with simpler alternatives that again become bloated as they broaden their space of applicability. Of course, this circle can never be completely avoided as it's probably a necessary part of every technolgy life cycle. But it appears to me that the pace of this cycle has become too fast in recent years. Some attribute this fact to the low quality of design by committee. I'm not sure. Sometimes I think this is exaggerated and has become part of a kind of anti establishment chic. Anyway, my point is that we have to accept to some degree that not all specs are first grade. We can just avoid some of them but we will have to use others, be it only for personal carreer reasons.

    So to stop going round in circles, I suggest that we consider another fact:

    * Most organisations have at least one very experienced 'guru' in their ranks who has a good understanding of the platform as a whole (maybe not in every detail).

    So, I think it would be extremely helpful to discuss and design ways for more experienced people (architects?) to define subsets of those very broad (bloated) platforms, that are relevant to one particular project or organisation. Of course we have such mechanisms in place to some degree, like design patterns, development tools and so on. But the process of defining subsets and shielding less experienced developers from having to learn the whole platform is, in my view, underspecified, not well investigated, not well supported through formal methods, not enforcable by tools and neglected by the JCP.

    Inevitably some will say this is just another idea causing even more bloat, but wouldn't it be great to have a JSR that deals with ways of formally specifying platform subsets that could be read by tools and presented to developers as simplified views on the system?

    -Alexander
  18. You've hit the nail on the head. Ideally, what we need is a clean layering between abstractions. EJB packages up a whole lot of ideas into one tightly integrated mass. EJB should be about producing, consuming and packaging services. Rather define or crown a persistence API under the EJB spec, it should define how to consume and integrate one. As it stands, EJB is good for an app server vendor with a whole lot of resources, but not such a great thing for the customers or the smaller vendors.

    For example, JMS is an extension and a standard that's marvelously well defined. You have a common API, and a pluggable provider. EJB doesn't try to define messaging. It just tells you how to consume JMS. I'd like to see this philosophy extended. Otherwise, I won't use it. I just don't want to eat the whole thing in one bite.
  19. You're right, of course, that EJB should be better modularised. But that's not enough. Very often we have that situation where we do want to use a functionality like JMS or the managability features of EJB's but we use it in just one of maybe 10 possible ways. That is we create a project specific pattern for how we use it.

    For example, an architect could decide that a particular project uses only stateless session beans, that transactions must always be container managed and that all EJBs must have remote interfaces. If these global decisions are made, it shouldn't be necessary or even possible for individual developers to specefiy this information over and over in the deployment descriptors. There should be a way of formally defining templates that describe project or module specific platform subsets. You can't do that by modularising the platform in the first place because there is a huge number of possibly overlapping combinations.

    And to some degree, we do all this today, for example by writing all the defaults in the build scripts or into the templates of various generators. But I believe, there should be a standardised way to formulate these platform templates so that tool vendors have access to them and architects can specify them in a uniform way. Because what we have today is that one generator/script knows about the defaults but other tools that don't know about them again show all the useless details to every developer and possibly allows them to change them.

    -Alexander
  20. I was just wondering if there is an os-project out there doing just all that stuff. I've written my build-scripts (for EJBifying or Springifying or whateverifying) and container emulation proxies several times ...
  21. Useless bashing[ Go to top ]

    I can't help but feel there are too many people pre-occupied with finding faults in various specs and technology. What ever happen to sensible development that uses the appropriate tool for the job and taking time to understand the problem. I'm sure everyone has seen developments fail misrably because the wrong tool was used. What we really in this world is common sense, not a lighter form of EJB. If you really don't need to use EJB, then just use servlets with JMS, or what ever is appropriate.
  22. Two things that I think will help in the quest for simplicity:

    - Tool induced abstraction: Everybody doesn't need to learn the complexities and rules of J2EE. We need standardized tools (similar to Visual Studio) that will hide all the complexities. With this, we need true "component" based architectures like the .NET windows and web components that you can buy from Infragistics or ComponentOne. Java needs a platform that will deliver such components. JSF was promising to do that, but unforunately with Strust, Cocoon, Tapestry, youNameIt front-end framework, the space is too fragmented to make that easy. Further, initial impressions (from what I read) of JSF don't seem to be too encouraging.

    - Overall vision: Case in point - EJB persistence. We had the 1.0 specs which was an endless debate about CMP, then we had EJB2.0 with a blessing in the form of JMS (and a good integration architecture that focusses on prudction and consumption as mentioned by an earlier post), and the persistence layer became a lot more bloated. Now EJB3 threatens to abandon all that and go to POJO approach aka Hibernate. Now stop and think about what's happening here to the poor customer of J2EE. We all love to hate M$ and their money wringling scheme using forced upgrades. The picture with J2EE is no more flattering.

    An organizations starts out building servlets, JSPs and a rudimentary J2EE 1.2 based architecture. Then they realize that Strust or Tapestry is the way to go. Further, their persistence mechanism is modified to fit EJB2.0. A little while later they realize that JSF will be the mainstream tech of the future and EJB3 takes them back to the POJO world. The customer is not immune to these changes. As the app server vendor releases upgrades and no longer supports older API/Specs, the poor customer has to deal with this myriad of technologies and specs that keeps changing. Where does this end?
  23. The Wisdom of Change[ Go to top ]

    "Know thyself" is a great piece of advice. How many of us have taken the time to honestly assess our own strenghts and weaknesses as developers and architects? The issue with Java is that there is so much you can do with it, and so many ways in which to do it, one suffers from analysis paralysis. The sense that the hill is quite steep arises. I argue that is an illusion. It's not that the hill is steep, it's that we are distracted and lose site of our trail. There are countless other riders on the hill beckoning, "Come this way, it is so much easier to do it this way!" If we don't know our own capabilities, and trust our own judgment, then we move laterally from trail to trail without making any headway.

    This is why pattern analysis has been so popular. It gives people the sense that they can evaluate the various trails and their trade-offs. It's a way to deal with massive quantities of information. But I feel that the truth is very simple; "when you have a hammer everything looks like a nail" is used derisively, but in fact I think it's good to homogenize one's approach.

    Finally, the hill really can be quite steep, and the complexity is justified. I just had a run-in with JTA, Java's XA standard. It's mildly annoying to set up and get going, but once you have the right drivers and settings, it really does do what it says it will do. I'm sure glad I didn't have to implement something like that!

    Mr. Tate, don't give in to the generalized angst! Have confidence in your own judgement and take the trail that seems right to you. Even if it turns out to be wrong, that's far less costly then evaluating all possible trails before proceeding on any one.