Request Review: JDK-6479237 (cl) Add support for classloader names

[Coleen Phillimore]

On 11/2/16 8:53 PM, Mandy Chung wrote:
>> On Nov 2, 2016, at 5:48 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>>
>> On 11/2/16 8:47 PM, Mandy Chung wrote:
>>>> On Nov 2, 2016, at 5:40 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I missed some of the iterations of this. To avoid making a large change larger, I think you should keep the original names of ToStackTraceElement and GetStackTraceElements.
>>> There is no change to the name of these JVM entry points.
>>>
>>> This patch changes the private native methods in the library.  Is that what concerns you?
>> Yes, the names of the library methods don't match the JVM names anymore.  I think changing the names are unnecessary and makes it not obvious the mapping.
> Is there such convention?  I wasn’t aware of that.  In addition, it would be impractical to synchronize the native methods to match JVM function names.

Yes, there's a convention of having very similar names.  It's not 100% 
but having completely different names here is really not helpful for 
maintaining this code.   This is from looking at the names in 
src/java.base/share/native/libjava.  Some of the names have additional 
namespace-like strings like "Class" but basically they're close to the 
same.  I think it's a good convention to have.  In this case, I think 
the names toStackTraceElement and getStackTraceElements are pretty well 
descriptive and don't see the reason to change them.

I'll read the thread.  We've had a runtime offsite all week and haven't 
been able to read this thread, and thought you'd checked in what I'd 
reviewed before.

thanks,
Coleen
>
> Mandy