Thanks Paul and Chris,
very interesting indeed.

regards,
Rémi

----- Mail original -----
> De: "Chris Hegarty" <chris.hega...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev" 
> <core-libs-dev@openjdk.java.net>
> Envoyé: Mercredi 14 Octobre 2015 16:29:15
> Objet: Re: java.lang.reflect.Method.copyOf
> 
> On 14 Oct 2015, at 15:15, Remi Forax <fo...@univ-mlv.fr> wrote:
> 
> > ----- Mail original -----
> >> De: "Paul Sandoz" <paul.san...@oracle.com>
> >> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>
> >> Envoyé: Mercredi 14 Octobre 2015 13:46:38
> >> Objet: Re: java.lang.reflect.Method.copyOf
> >> 
> >> 
> >>> On 14 Oct 2015, at 12:38, Remi Forax <fo...@univ-mlv.fr> wrote:
> >>> 
> >>> Given that j.l.r.Method is mutable, the best way to have performance is
> >>> too
> >>> encapsulate it in a non mutable class, if possible.
> >>> 
> >>> As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable
> >>> and
> >>> become mutable with Java 1.2, (yes, someone seriously fucked up !)
> >> 
> >> Some harsh language there :-) I don’t know the full history but i like to
> >> think this may have been a frustrating compromise due to some demanding
> >> serialization requirements under a tight schedule.
> > 
> > Methods are not serializable.
> 
> No, but was Paul referring to the fact the the custom readObject
> and writeObject methods must be private, and somehow
> accessible to the Serialization framework ?
> 
> -Chris

Reply via email to