geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Khrishnamurthy, Sankar" <>
Subject RE: A thought on optimisation and project goals
Date Wed, 10 Sep 2003 15:22:38 GMT
Amen! That is one cogent explanation that you make!

My list would be

1) No changes
2) Easy to use and develop - Users
3) Easy to administer and maintain - Administrators
4) Efficient

-----Original Message-----
From: Alex Blewitt [] 
Sent: Wednesday, September 10, 2003 7:49 AM
Subject: A thought on optimisation and project goals

There have been several messages in the mailing list talking about 
choices in technology to use within Geronimo, and I feel that some 
choices are being made with the idea of optimisations in mind, rather 
than necessarily other reasons.

I think that in decreasing order of importance when designing and 
building Geronimo, that we should aim for:

1) Functionality -- it should do everything that we expect a J2EE 
environment to do
2) Easy to use and administer
3) Easy to develop and maintain
4) Efficient (memory, computational speed, whatever)

I don't think anyone would argue with (1), but if we want Geronimo to 
be the best (and I'm pretty sure that we are all aiming that way) then 
it probably has to be easy to use and administer over and above 
development ease. But it may be that (2) and (3) could be reordered.

I also think that in order to address (3) there are benefits in linking 
up with as many other projects as possible, rather than develop a Not 
Invented Here syndrome. I am not an Apache member, so I don't know The 
Apache Way (maybe someone can fill it in here), but what it means to me 
is that Apache builds projects that are useful, and that may then be 
integrated into other Apache projects. That certainly seems to be the 
case with the jakarta-commons packages, and indeed there are several 
packages which have been built on top of others (James on top of 
Avalon, Jetspeed on top of Turbine/Velocity, not to mention the uses of 
the commons- packages).

I know that the current focus is on (1) (and probably (2/3) as well) 
for the project, and so a getting-there-fast approach is probably a 
good idea. But let's not write off trying to use other parts (and keep 
them!) from the Apache projects when they're useful; after all, object 
orientation is mainly about reuse.

I personally think that (4) should be the last point on the list, by 
some way. J2EE servers are going to be notoriously powerful beasts, and 
whilst it would be advantageous to run on constrainted hardware, I 
really don't think that's where the target customer base is going to 
be. And as the J2EE spec keeps growing, just to cater for (1) we're 
going to have a lot of code. Optimisations that therefore target (4) at 
the expense of (3) IMHO are going the wrong way; for example, ditching 
the commons packages because Geronimo code (as yet) only uses one 

I also feel that at this stage of the project, trying to squeeze 
performance out of component X isn't the best use of (3). If we have 
two designs, one easier to maintain/extend, and one that is fast, I'd 
prefer the former. Why? Because I don't know that the latter is 
necessarily that much faster, and for that matter, don't know that it 
is in the bottleneck of the code. And until we get a working version 
that we can start running and profiling to find out where the 
bottlenecks are, any optimisation is premature optimisation.

Just my $0.02


View raw message