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?
S/MIME Cryptographic Signature
