Berin Loritsch wrote: > > I beleive we need to go through our Coding Standards document, > purge some items (since they do not apply to modern JVMs) and > incorporate ideas from this list of documents: > > Twelve rules for developing more secure Java code > ------------------------------------------------- > http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
I see what they mean, but, like the Leo's, I don't think we should blindly apply them here. First, from the Open source point of view, it is generally bad to make classes and methods final, unless there is some overriding reason. We are a constantly shifting target. The other factor is that we don't know where Avalon code will end up. Even different jakarta projects will have different security profiles. I'm more than happy for us to have pointers to this and similar articles, but I don't think we should incorpate them into our coding standards. > > Design for performance, Parts 1 - 3 > ----------------------------------- > http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-performance_p.html > http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-performance_p.html > http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-performance_p.html These seem sensible so I'm +1 for adopting them as guidelines but I'm not so sure they should be standards. Charles --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
