I am investigating using J2EE as a primary business development platform, and though I have some experience, I have never been totally satisfied with the productivity of the environment. Yes, it is extremely powerful and flexible, but there is a lot of repetitive grunt work in creating and maintaining applications.
- Posted by: Tim Sawlor
- Posted on: March 17 2004 14:54 EST
I find that most J2EE articles and resources either treat a few different tools/options/frameworks as equal but different options, or promote a particular practice in isolation from the rest of the development/production environment. I'm hoping this post sparks a lively debate about complete environments, and which tools and technologies achieve a synergy and work well together. I also don't have the time to perform an adequate evaluation of all of the options out there, so I am hoping everyone will be able to help me narrow it down somewhat.
The biggest operational constraints I am working within are manpower and time (in that order - there will be a very small development team, and I will have to be able to quickly turn around requirements into deliverables). So I am mostly interested in finding out the best frameworks/tools/practices that exist are to create and maintain J2EE apps effectively and efficiently. I'd like to hear about commercial products as well as open source/free ones, although I'm opposed to proprietary frameworks.
As far as technical constraints go, it is a clean environment that would be set up, with no previous systems compatibility to worry about - servers, databases, etc are all open for debate, although the J2EE platform as it is does enough to make these interchangeable. GUIs would have to be rich, meaning XUL or Web Start/Swing. However, the only other interesting constraint is that certain applications would have to be able to function as stand-alone applications as well, which would synchronize certain data sets periodically. This probably means Web Start is the only viable option.
Some of the more specific questions I have are:
* What's the best (ie easiest to maintain) persistence framework to use?
* Is Borland's Together product as nice as it seems?
* Struts is useful, although DynaForms haven't been taken far enough yet, the taglibs provided could do much more, and configuring it is pretty labour-intensive. Is it the best option, or do some of the other middle-tier frameworks make for quicker development.
* Because rich clients that can exist as stand-alone applications are required, WebStart with some database synchronization must be the way to go. Are there any better options?
I welcome all constructive opinions, and hopefully this will be a useful discussion for everyone. Thanks in advance!
- Advice on Productive J2EE Dev Environment by Paul Strack on March 17 2004 22:05 EST
- Advice on Productive J2EE Dev Environment by Tim Sawlor on March 18 2004 12:37 EST
Putting together a consensus opinion on the best set of tools is going to be pretty hard. People have violent opinions about the best approach (myself included), and there is no general agreement. Most J2EE developers think this is a good thing, because it means there is a lot of competition and innovation. I admit, though, it is a pain when you are in a hurry.
I have a suggested approach for you, though. Most J2EE servers have a set of associated tools that work well with them. If you pick your server, most of the "best tools" can be derived from that decision. Websphere and Weblogic in particular both have relatively complete tool-sets.
If you want to go the open-source route, though, here is what I suggest:
1. What's the best (ie easiest to maintain) persistence framework to use?
I am a fan of Hibernate, myself.
2. Is Borland's Together product as nice as it seems?
Never used it. I am an Eclipse fan.
3. Struts is useful, although DynaForms haven't been taken far enough yet, the taglibs provided could do much more, and configuring it is pretty labour-intensive. Is it the best option, or do some of the other middle-tier frameworks make for quicker development.
I would pick both Tapestry and Web Works above Struts (and it that order or preference). I would pick my own framework about either of these, but here I am *extremely* biased, so take that with a big grain of salt.
4. Because rich clients that can exist as stand-alone applications are required, WebStart with some database synchronization must be the way to go. Are there any better options?
Web Start is probably your best option, unless you want to go with applets (which is a nightmare). Rich clients are much harder to build than web clients, though; the frameworks support is much weaker, and the user expectations are much higher.
I final item: you need to decide early on whether to use EJBs or not. This will have a big impact on the complexity of the application, and the tools you use. If you need remote access (e.g. for your rich clients) or complex transaction support, their benefits can outweigh their costs, especially if you avoid entity EJB.
Thank you for your input. I know that consensus will be impossible; I was more just hoping to get some feedback from people who have faced these types of questions, and the useful information that only come from experience in order to better make up my own mind. For example, I read quite a bit about Struts, but it was only when I used it extensively that I came up with the idiosyncrasies that I find frustrating. For example, your rating of Tapestry and WebWorks over Struts is interesting to me.
Also, what makes you prefer Hibernate over Castor, for example?
As far as EJBs go, it's hard to tell - the specs are pretty vague at this point. My leaning is that for the vast majority of apps out there, EJBs add a great deal of complexity without enough benefit, and aren't great for productivity. A well designed servlet environment does everything necessary, but I wouldn't want to close the door at this point. An abstraction layer, like Struts actions, is important. However, if the tools were sophisticated enough to make this easy, then it might be a better way to go off the bat.
And I think vendor lock-in is evil, which is why I don't like the all-in-one toolset solutions.
is J2ee deployed anywhere in production? especially in supply chain systems?
where real time response required?
I heard the hype , i also worked on it. The amount of investment in high performance pcs(SUN pcs) and maintenance of it does n't do justification to any business except a corporation with rich cash flow.
I really think J2EE concept is over hyped. J2ee project will take years to get finished, by that time,technology will change, new tools , new architecture. It never going to fly anyway. Some new management will take over , scrap the project. (my experience)
Most business does n't need J2EE , They all need basic POJOS (hibernate) / Servlet/Struts.
There is only way J2EE can succeed is it need RAD( rapid application development and less feature set/quick deployment) and cost reduction on all vendors.
For example, I read quite a bit about Struts, but it was only when I used it extensively that I came up with the idiosyncrasies that I find frustrating.I agree with you about Struts. I think Struts deserves a lot of credit as a trail-blazer, and it is a very mature framework. But since they were "first", some of their design decisions were odd and ad hoc. Many later frameworks are written at least in part to correct the flaws in Struts.
For example, your rating of Tapestry and WebWorks over Struts is interesting to me.Well, I like Tapestry because it is clean and elegant. My main hesitation about Tapestry is that it does not use JSP, and therefore you don't have access to any JSP custom tag libraries in your presentation logic.
WebWorks has a lot of nice features, but I am not convinced that combining a work-flow engine with a web framework is the right approach. I personally feel that it makes the configuration needlessly complicated.
Other people feel differently, though. Please bear in mind that I don't actually use any of these frameworks: I use my own web framework: Chrysalis [http://chrysalis.sourceforge.net]
Also, what makes you prefer Hibernate over Castor, for example?I don't use Castor, so I couldn't say. I took a look at OJB, but the fact that they took so long to get to the 1.0 release made me give up on them. Once I decided that Hibernate met my needs, I stopped looking at persistence frameworks.
As far as EJBs go, it's hard to tell - the specs are pretty vague at this point. My leaning is that for the vast majority of apps out there, EJBs add a great deal of complexity without enough benefit, and aren't great for productivity. A well designed servlet environment does everything necessary, but I wouldn't want to close the door at this point.If you can avoid EJBs, you will definitely be better off and your development will go faster. There are a few cases, though, where EJB benefits outweigh the costs. My personal "EJB dividing line" is whether or not the application needs distributed transactions, or transactions against multiple resources.
Also, EJB development is much easier if you avoid Entity Beans, which is where the bulk of EJB complexity lies.
An abstraction layer, like Struts actions, is important. However, if the tools were sophisticated enough to make this easy, then it might be a better way to go off the bat. And I think vendor lock-in is evil, which is why I don't like the all-in-one toolset solutions.Vendor look-in is evil, but it does have one benefit: simplicity. This is how Microsoft makes all of its money. Picking a single solution set makes all of your decisions easier. For the common cases, the tools have more or less equivalent functionality, and if you pick the tools of a reputable vendor, it is less likely you will be seriously burned. Having a large company providing dedicated support can be nice as well.
It sure does cost a lot of money, though, which is why I stick to the open source tools myself.
I agree with Alex to a certain degree concerning my experience with J2EE - I would describe it as overly messy - the innumerable classes, XML definition and configuration files, and the complexity of the overall picture make it a difficult platform to develop for and maintain, IMHO. There are definitely parts of it I like working with (servlets, JNDI, etc), but other parts of the platform are nauseating. Take EJBs with their remote AND local interfaces?? Come on, the company I worked for had that feature transparent in its object framework a couple of years before EJBs came out! It's also a difficult platform to perform testing in - because it is designed to work as an ecosystem, everything needs to be running and in place to make sure things work as they should. The fact that the APIs provide enough abstraction to mock the external components is good, but it requires an awful lot of work to set up a mock environment as well.
However, to me, the concepts adopted are ones that violate the central beliefs of OO. I believe that the ideal development platform would be one in which you write a class to model something, and that class would be the only file you have to edit - everything related to it would be in that class. Detailed attribute definition could be included, strangely enough, with the attribute. This attribute information could then be used to automatically persist and build appropriate UI components (complete with attribute level validation and internationalization). At a bare minimum, a tool that managed all of the files and places that an object attribute touched would be good. The persistence framework should be as transparent as possible, and basically stay the heck out of the way.
For as object-oriented as Java tries to be in some ways, in others it falls ridiculously flat. The Swing UI designers that ship with most of the IDEs are disgusting VB knockoffs - I have spent enough of my career swimming under a sea of badly thrown together VB apps, and I hate the fact Java tries to emulate it at times. I know it's to appeal to VB "developers", but I hate it.
XDoclet is an interesting paradigm. To me, it seems that it evolved to fill that inherent weakness in the platform - because everything got so convoluted, it was necessary to draw it all together somehow. I guess that's why I've never been drawn to its use - it seems like it's a bastardized version of my idealized environment (no offense intended to any XDoclet fans/developers - it's not actually XDoclet I dislike, it's the fact that it's needed).
Based on your feedback Paul, I spent a bit of time investigating the Chrysalis and Hibernate frameworks, and I have to say I am initially impressed by both - this combination seems to be close to the one I was designing in my head while bashing away at various apps over the last couple of years. I will definitely investigate this in detail.
One things that strikes me as impressive about Chrysalis is the configuration files for more precise definition of an object's attributes. While in my ideal world, I would include this in the class, this seems like the best real-world way of doing it. Perhaps for WebStart apps, I would be able to create a few Swing components that act like the JSP tags, and have a real OO UI while I'm at it!
As far as open source goes, it seems like the better model because it allows ideas to fully evolve outside the influence of an artificial business model. Ideas are fully explored and thought out, so that the end product generally is more elegant (from a concept point of view, anyways) than the commercial versions. And, of course, they are quite a bit cheaper as well! The only commercial products I've enjoyed using over the last few years are IntelliJ/IDEA and many Apple products, because the designs were always given priority.
Anyways, enough babbling for now. Thanks a lot for the ideas so far!