----- Mail original ----- > De: "David Holmes" <david.hol...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Lundi 30 Novembre 2020 13:44:32 > Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM > ?
> On 30/11/2020 8:04 pm, fo...@univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "David Holmes" <david.hol...@oracle.com> >>> À: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev" >>> <core-libs-dev@openjdk.java.net> >>> Envoyé: Lundi 30 Novembre 2020 08:57:37 >>> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the >>> VM ? >> >>> On 30/11/2020 5:08 pm, Remi Forax wrote: >>>> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType, >>>> but in order to create the error message, MethodType.toString(), >>>> getSimpleName() >>>> is called and it fails because getDeclaringClass() verifies the >>>> InnerClasses >>>> attribute. >>>> >>>> For me InnerClasses was just an attribute for javac not something the VM >>>> should >>>> take care of, >>>> it seems that the VM strongly verifies this attribute and i wonder what is >>>> the >>>> reason behind that ? >>> >>> From the VM code - InstanceKlass::compute_enclosing_class: >>> >>> // Throws an exception if outer klass has not declared k as an inner >>> klass >>> // We need evidence that each klass knows about the other, or else >>> // the system could allow a spoof of an inner class to gain access >>> rights. >>> Reflection::check_for_inner_class(outer_klass, this, >>> *inner_is_member, CHECK_NULL); >> >> I don't understand how to spoof the InnerClasses attribute to gain access >> given >> that the access rights are not based on the InnerClasses attribute. > > Good point. > > That aside though, how do you answer the is_top_level_class question if > the enclosed and enclosing classes disagree about the relationship? Good question too, only by looking to the information stored in the class that can be top_level or not, i suppose. > > David > ----- > Rémi >>> >>> David >> >> Rémi >> >>> >>>> regards, >>>> Rémi >>>> >>>> Exception in thread "main" java.lang.IncompatibleClassChangeError: >>>> fr.umlv.transmogrif.ImplMap and >>>> fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses >>>> attribute >>>> at java.base/java.lang.Class.getDeclaringClass0(Native Method) >>>> at java.base/java.lang.Class.isTopLevelClass(Class.java:1970) >>>> at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955) >>>> at java.base/java.lang.Class.getSimpleName0(Class.java:1835) >>>> at java.base/java.lang.Class.getSimpleName(Class.java:1826) >>>> at java.base/java.lang.Class.getSimpleName0(Class.java:1833) >>>> at java.base/java.lang.Class.getSimpleName(Class.java:1826) >>>> at >>>> java.base/java.lang.invoke.MethodType.toString(MethodType.java:895) >>>> at java.base/java.lang.String.valueOf(String.java:3365) >>>> at >>>> java.base/java.lang.StringBuilder.append(StringBuilder.java:169) >>>> at >>>> >>>> java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611) >>>> at >>>> java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608) >>>> at java.base/java.lang.String.valueOf(String.java:3365) >>>> at >>>> java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203) >>>> at >>>> java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333) >>>> at >>>> >>>> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280) >>>> at >>>> >>>> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270) >>>> at >>>> fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21) > >>> at fr.umlv.transmogrif.Main.main(Main.java:7)