java.lang.reflect.Method.copyOf

forax at univ-mlv.fr forax at univ-mlv.fr
Wed Oct 14 14:49:41 UTC 2015


Thanks Paul and Chris,
very interesting indeed.

regards,
Rémi

----- Mail original -----
> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev" <core-libs-dev at 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 <forax at univ-mlv.fr> wrote:
> 
> > ----- Mail original -----
> >> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> >> Cc: "core-libs-dev" <core-libs-dev at 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 <forax at 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



More information about the core-libs-dev mailing list