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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org

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

Maciej Kwidziński commented on BCEL-314:
----------------------------------------

The workaround is to reverse-engineer it and String.replace it back.

> 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)