On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> 2) Try to make all objects used for synchronization 'final' (we have a lot > of non-final monitors in API, so we give a chance to bugs) Could you please explain with details and an example?
This is not a bug (E.g. ExemptionMechanism:47, BeanContextSupport:149) but such code may lead (in theory or in future) to deadlock because it allows different threads to use different locks in the same object instance. Also when you analyse 'synchronized' pattern the 'final' modifier for a lock really helps in understanding code and locks logic.
3) Never call to Boolean of Integer contructors (performance issue, there > are a lot of such calls in our API) Again, an example would be useful.
grep "new Boolean" or "new Integer" over the sources. You fill find > 100 samples. New object creation when it's possible to use static and cached instances is a bad practice from the performance point of view.
4) Never do manual array copying (our crypto API does ) What do you mean by 'manual array copying'? How it should be done and why?
This is manual copying of arrays in loop instead of System.arraycopy() call (System.arraycopy() can be implemented as performance primitive in VM or JIT) Check this code as example: ExemptionMechanism:249, Statement:164 Thanks,
Mikhail
-- Mikhail Fursov Intel Middleware Products Division
