Humphrey
I want to mention a couple of things which I think would make it faster for
your team.
JIKES is definitely much much faster than standard javac compiler. You have
a believer here.
We have moved to using ANT (XML based scripting) which further cuts down the
development time. You just have to use it to see what all you can do with
it.
To subscribe to the list, send a message to:
<[EMAIL PROTECTED]>
We use TogetherJ which is as open an IDE can get without throwing in a bunch
of their own com.blah.blah.blah stuff. They have awesome templates for
building entity and session beans (of all flavors). Then you have templates
for building code according to patterns (singleton and other GOF stuff).
Intelligent use of these 3 should cut down your development time
considerably. Mind you, I havent mentioned anything about GUI rich
development here. Plain Servlets and maybe JSP.
Hot Deployment -> We use WL 4.5.1 and it works well for us.
Ofcourse you need a fast machine for all of this.
Enough said,
Gotta go back to the dungeons.
Good Luck
Madhu
-----Original Message-----
From: Humphrey Sheil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 12:57 PM
To: [EMAIL PROTECTED]
Subject: MI2: Strategies to reduce EJB development time?
I've been trying to improve this for a while and I've come to the conclusion
that beyond doing what I've listed below, there isn't anything else possible
to reduce the net amount of development time required in the EJB world at
present.
So the problem is that our code->build->deploy->test cycle is taking too
long, especially for impatient developers who are new to the distributed
component model. We've been using javabeans / Servlets and jsps on
e-commerce apps. prior to adopting a fully-fledged J2EE architecture and as
you can all imagine, although it's not as powerful, it's a hell of a lot
faster to develop in.
Here are some of the things I've been looking into to mitigate the problem.
1. Hot deploy of EJBs when supported by app. servers. Instead of having to
bounce the server, instead redeploy your EJBs.
2. Invest in an IDE with a dynamic class loader to reload changed classes
(e.g. Visual Age).
The problem with both approaches above is that any changes to either the
home or remote interfaces (method names, params, throws clause etc.) or
referenced support classes (usually value objects) means that you still need
to stop, rebuild and restart. In my experience, this accounts for a large
part of the time when I want to hot deploy anyway!
Even given that I've met the restrictions above, if I want to be sure that
an exception I'm getting is my fault and not the hot deploy feature or funky
IDE classloader, I'll bypass them and bounce the server anyhow (do you have
100% faith in your hot deploy feature or IDE?)
I'm not worried about having to hot deploy gracefully to a production system
(that's a whole other problem in itself), my only concern is speeding up the
development cycle.
3. Use jikes to reduce the build cycle time - I haven't seen any great
reduction in time here.
Are there any design patterns, rules of thumb, howtos etc. that I'm missing
which are applicable here? I had thought of building business logic first
as a regular Java class and then moving over to an EJB approach when the
class does what I want, but I feel this will lead to headaches later on down
the line as you have to add in the EJB plumbing (JNDI lookup, etc. etc.)
Plus, divorcing what I want (business logic) from how I get it (the EJB
model) doesn't make that much sense (at least not in our world at present).
On the subject of IDEs, I've evaluated most if not all of the IDEs promising
tight integration with various app. servers and I find them all unstable
enough that when something goes funny in development (especially if I'm
building on more than a couple of EJBs), the first thing I do is close down
the IDE, bounce the app. server and start from basics myself so I don't
think they're good enough to address this problem yet.
I'm interested in hearing about other folks best practices on this subject.
Humphrey
PS If anybody else wants to get into the steel building market for peanuts
let me know, I think we can beat the guy down if we go for a bulk purchasing
strategy.
===========================================================================
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".
