RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing

[Baesken, Matthias]

Hello  David, 
Here is a change  that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass  -

With this change, I checked the output of   LD_DEBUG=libs     java Test   ,  and the error I observed before is gone .

Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8236183

http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/


Thanks, Matthias


> >>
> >> By chance I noticed  the following  output when running a trivial Java
> >> program  :
> >>
> >> LD_DEBUG=libs     /linuxx86_64/output-jdk-
> test/images/jdk/bin/java   Test
> >>    . . .
> >>       12241:
> >>       12241:
> >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol
> >> lookup error: undefined symbol:
> >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal)
> >>       12241:
> >>
> >> What is wrong with
> >> "Java_jdk_internal_reflect_Reflection_getCallerClass"  ?
> >> Does the error message  occur because of  the naming
> >> Java_jdk_internal_reflect_Reflection_getCallerClass__  with the added
> >> "__"  at the end of the method  (Reflection.c) ?
> >
> > That definitely looks like an error in the C source to me. The ending
> > "__" should not be there. How is this working ??
> 
> Ah! It is a remnant of when there were overloads of getCallerClass. The
> "__" should be followed by the signature - which is empty in this case.
> So IIRC the lookup will first try to use the short name (without the
> trailing "__") which will fail, then it will use the long name which
> will succeed.
> 
> It should be fixed so we don't waste time doing two lookups.
> 
> David