[jira] [Commented] (BCEL-314) Expose the true class name

["Gary Gregory (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BCEL-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879687#comment-16879687 ] 

Gary Gregory commented on BCEL-314:
-----------------------------------

[~Dagguh] What you propose might be better for interoperability but it also might break existing call sites. You can propose a PR which adds a new API perhaps.

> Expose the true class name
> --------------------------
>
>                 Key: BCEL-314
>                 URL: https://issues.apache.org/jira/browse/BCEL-314
>             Project: Commons BCEL
>          Issue Type: Improvement
>            Reporter: Maciej Kwidziński
>            Priority: Major
>
> Natively, in the bytecode, class names look like this:
> {code:java}
> java/lang/String{code}
> You can see it in {{NoClassDefFoundError}}, etc.
> Bytecode decompilers and other bytecode-engineering libs (like kotlinx-metadata) will use this native format.
> For some reason, [BCEL explicitly converts it to the dot notation|https://commons.apache.org/proper/commons-bcel/apidocs/org/apache/bcel/classfile/Utility.html#compactClassName-java.lang.String-boolean-]:
> {quote}
> Shorten long class names, _java/lang/String_ becomes _java.lang.String_
> {quote}
> I'm not sure how is that shorter, but it definitely makes interoperability harder, ie. if you want to base Java-specific bytecode engineering with BCEL and still reuse Kotlin-specific libraries for Kotlin-specific bytecode.
> Could JavaClass expose the real, actual, bytecode-level class name?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)