Peter Donald wrote: > > On Thu, 21 Jun 2001 23:22, 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 > > Ouch I never knew about Rule 5 - Inner classes are evil. Rule 4 no longer > applies because we could choose to seal packages if we wanted to.
Actually rule 4 still applies. Manifest sealing of a jar ONLY works when a SecureClassLoader is used. Package sealing is too easily disabled to trust. The point is important: don't trust package access (no modifiers). > > > 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 > > The only modification I would make is that with Sun hotspot VM creation of > small localized short lived objects is not much of a speed. I think you stopped your sentence somewhat short. Are you saying that small localized short lived objects is not much of a speed hinderance? I do prefer performance by design then depend on a specific JVM to help me out. Other than that--how should we modify our code standards doc?
smime.p7s
Description: S/MIME Cryptographic Signature
