I don't think anybody is saying this. ----- Original Message ----- From: "Ron Yust" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 30, 2002 5:46 PM Subject: Re: [EJB-INT] EJB Development Cycle
> I am standing and applauding Hu on his insightful perspective of EJB > development. Finally, someone is also seeing that the emperor is not > wearing any clothes (well only some). > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development [mailto:EJB- > > [EMAIL PROTECTED]] On Behalf Of Hu Shih > > Sent: Wednesday, January 30, 2002 3:49 PM > > To: [EMAIL PROTECTED] > > Subject: Re: EJB Development Cycle > > > > Perhaps you have lot of experience working with EJB on a large > project, > > but > > I beg to differ with much of what you said. > > > > I'm not a great fan of MS, but you can compare what's happening with > EJB > > with MFC. At least with MFC, you were given a set of library classes > that > > performed crucial work for you and the code was available. If > something > > goes wrong, you debug the framework code along with your code. > > > > Also, until you complete your test in your development environment, > you > > don't have to build an installation of your application. EJB's > deployment > > requirement is like requiring people to build installation disk. And, > you > > must install the system to have the other half the system be > generated. > > How > > can you call this productive or conducive to iterative development? > > > > My complaint with EJB is that much of "what the system does for you" > is > > generated during deployment time and is hidden away from the > developer. > > > > This is certainly the case with Sun's reference EJB server > implementation > > which I've been working with. Perhaps it's a bit better with open > source > > stuff like JBOSS. But the fact remains: deployment/installation must > be > > done before you can test your modules with the rest of the system. > The > > other half ("better half") doesn't even come into existence until you > > deploy. > > > > > > >compiling/deployment for you. And depending on how you design your > > >application you often time don't have to redeploy your beans at all > > unless > > >some major interface changes. It could also be that you are not unit > > >testing > > >your code enough. If you are waiting to discover bugs only when you > > deploy > > >your stuff I think it's a little too late to complain. > > > > How do I unit test a CMP bean before it's deployed? Could you share > some > > concrete ideas based on your experience, instead of empty talk? > > > > > > > > >From: "Tinou Bao" <[EMAIL PROTECTED]> > > >To: "Hu Shih" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > >Subject: Re: [EJB-INT] EJB Development Cycle > > >Date: Wed, 30 Jan 2002 15:44:54 -0500 > > > > > >I don't think you can simply blame EJBs for your development aches. > EJBs > > >provide you with several features, such as security, transaction, > > >persistence, distributed. Naturally the container needs to generate > > classes > > >to do this work for you. Otherwise you'll endup writing this code for > > >yourself. So, do you want to have a lot of classes generated by the > > >container or a lot of classes your developers code? If you don't need > > these > > >features then don't use EJBs. Regarding deployment time. Yes, EJBs > > require > > >an extra step but this should in general not cause you all the pains > you > > >speak of. You can write scripts that pretty much does all the > > >compiling/deployment for you. And depending on how you design your > > >application you often time don't have to redeploy your beans at all > > unless > > >some major interface changes. It could also be that you are not unit > > >testing > > >your code enough. If you are waiting to discover bugs only when you > > deploy > > >your stuff I think it's a little too late to complain. > > > > > >_________________________________________ > > > > > >Tinou Bao > > >BAO Systems > > >Chairman of the Board and Chief Software Architect > > >www.baosys.com > > > > > >----- Original Message ----- > > >From: "Hu Shih" <[EMAIL PROTECTED]> > > >To: <[EMAIL PROTECTED]> > > >Sent: Wednesday, January 30, 2002 10:08 AM > > >Subject: [EJB-INT] EJB Development Cycle > > > > > > > > > > Please forgive my frustrated tone, but > > > > > > > > I've been working with EJB (CMP beans with session facades) using > > Sun's > > > > J2SDKEE. I find the development cycle extremely tiring and slow. > I > > >write > > > > bean code. I go to their deploytool to deploy it. I run the > thing. > > >Find > > > > problems and come back to my development environment. > > > > > > > > I understand some IDEs will make this cycle easier. Still, I've > been > > >used > > > > to developing and testing code quickly in an iterative cycle. > After > > >many > > >of > > > > these iterations, I deploy to user environment--many > > >code/compile/test-runs, > > > > very few deployments. > > > > > > > > One of the big advantages of a quasi-intrepretive language like > Java > > is > > > > precisely that the repetitive code/compile/test-run cycle is > quick. > > > > > > > > EJB changed all this. They stuck a rather long, tedious, and > often > > >painful > > > > deployment phase right between compile and test-run, often > breaking > > the > > > > development cycle with 10 to 20 minute breaks. > > > > > > > > Debugging such a deployed app is a nightmare. Because EJB > (especially > > >CMP) > > > > generate so many classes and because so many of these are system > > >generated > > > > stuff, I have very little idea what's going on or what I have done > > >wrong. > > > > > > > > Also, so much information that are important to developers are > hidden > > >away > > > > from them in multi-level jars/ears/wars, etc. (and these things > are > > > > humongous). And, why so many classes? When running, I see over 4 > > >classes > > > > generated for each EJB bean. This is excess and debugging > nightmare! > > > > > > > > With Java, the trickiest configuration parameter was CLASSPATH. > With > > >EJB, > > >I > > > > have to know and worry about so many of these configurations, I > feel > > >like > > >I > > > > need a dictionary of them. > > > > > > > > What's going on? It's almost as though EJB put Java back to the > level > > >of > > > > C++ and C++ templates. I don't know about others, but I > generalize > > >dislike > > > > and dispise the condescending attitude of any system that tells > > >developers: > > > > "Don't worry. We'll take care of you by generating lots of stuff > > under > > >the > > > > covers. Why would you care about long breaks in the development > > cycle? > > >Go > > > > take a coffee break." > > > > > > > > Developers are an impatient and controlling bunch. Java has been > good > > > > because it gives speed of development and gives enough control for > > > > developers. In my opinion, EJB is going backwards (the wrong > > >direction). > > > > Is there an effort to address these? Or, is it that to be an EJB > > >developer, > > > > you have to take all this willingly and gladly? > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > >======================================================================= > == > > == > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the > > >body > > > > of the message "signoff EJB-INTEREST". For general help, send > email > > to > > > > [EMAIL PROTECTED] and include in the body of the message > "help". > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > ======================================================================== > == > > = > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > body > > of the message "signoff EJB-INTEREST". For general help, send email > to > > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
