Monday, January 06, 2003

Pooled EJB Objects Ted Neward wonders, in reply to my Aristotelian classification of object managers, ...one thing I'm curious about with respect to resource management of infinite objects (that is, objects not bound by some constraint outside the normal boundaries of the VM) is whether or not it actually serves any useful purpose. Case in point: EJB makes heavy use of object pooling wihtin its definition, going so far as to include pooled states in its lifecycle diagrams within the EJB Specification. Yet nobody has ever published definitive profiling statistics proving that pooling achieves anything! In fact, according to Sun's own documentation, "Pooling objects will cause them to live longer than necessary. The garbage collection methods will be much more efficient if you let it do the memory management. We strongly advise taking out object pools." EJBs are a wierd case, in which pooled the EJBs may be either expensive or cheap to create. Ted assumes they are cheap -- even trivial -- to create, in which case yes indeed object pooling serves no useful purpose in terms of resource efficiency. Objects which are cheap to create and relatively infinite should be managed with a factory, and even then the factory is only there to manage the potentially complex allocation and tear-down procedure of the resource objects. However, if the EJB object is developed with a significant amount of creation-time work to do (work in ejbPostCreate(), for example), then the object is no longer cheap to create. Furthermore, if you buy the argument that a heavily-taxed server cannot support a relatively infinite number of heavyweight simultaneous EJB objects, then the objects are also finite. Finite, expensive objects when pooled will provide a higher level of efficiency to a system. I think a mathematical/statistical proof based on client usage pattern modeling would show this clearly. However I must agree with Ted for all practical cases because I've never actually seen an EJB object with a significant amount of work being done in ejbPostCreate(), or anywhere in the construction process. 10:53:39 PM    comment []

Obfuscation: Goldberg Refactoring While playing* with the greatest Java IDE in the world -- IDEA -- it occured to me that obfuscation is really just refactoring. Most current obfuscators will modify class, method and field names. Those are three simple types of refactoring. If my IDE had a macro language, I could make my own obfuscator using the IDE's refactoring tools pretty easily. I've found that obfuscation is just a  nusciance. Generally I find I can pull what I want to know out of obfuscated class files, though it probably takes 3 to 6 times longer than it would with undocumented source code. For example, when plumbing for undocumented information about my IDEA's plugin API, I pulled what I wanted to know from its obfuscated class files pretty quickly. (BTW, have you ever read the source code that passes for commercial quality? I swear some developers are born with obfuscated brains...) However, if some more complicated refactoring (than simple entity renaming) were applied to source code, I'm sure you could make decompiled class files completely impractical to use. Loop unrolling, converting loops to recusion, creating (or collapsing) intermediary super- (or sub-) classes, creating pointless extracted methods, etc. Now that would be obfuscation! * Working with IDEA feels like play. Try it if you haven't yet... 4:54:36 PM    comment []