Community
Participate
Working Groups
R3.2
Please resurrect IClassFileDisassembler which got deprecated: we do not migrate to the new API since there's no easy way to get the byte array which is required by ClassFileBytesDisassembler. Another solution would be to provide API to get those byte for an IClassFile. In addition it might be a good idea to allow to pass in an IClassFile: String disassemble(IClassFile classFile, String lineSeparator, int mode) Currently some parameters are controlled through the class file reader (e.g. whether to show fields or methods) and some through the disassembler (default vs. detail).
Can this be fixed for 3.3? I've now fixed bug 3537 but the fix is pretty bad because I use the ClassFileBytesDisassembler.SYSTEM constant along with the deprecated IClassFileDisassembler.
*** Bug 3537 has been marked as a duplicate of this bug. ***
Helper methods to reach the bytes could be added on a different class (IClassFile?)
This won't be done for 3.3M2. Adding an API to retrieve the bytes from a IClassFile would be sufficient. No need to resurrect an old API.
>No need to resurrect an old API. Sure, I already discussed this with Philippe, that's why he added the comment. Before crafting the new API please take a look at how we currently use the old API so that we can indeed use the new API and not stay with the deprecated stuff ;-)
Created attachment 59091 [details] Proposed fix
Created attachment 59092 [details] Proposed fix for the JDT/UI side
Daniel, If this patch is good enough, I would request an API addition to the pmc mailing list. Thanks.
Update title accordingly
The API is fine (it misses the @since 3.3 tag). The UI patch could be simpler since the reader is no longer needed. Easier patch follows.
Created attachment 59117 [details] Fix for JDT/Text
I noticed one difference: it now seems to show the inner classes, e.g. for P11Key you now see this at the end: Inner classes: [inner class info: #94 sun/security/pkcs11/P11Key$P11DHPublicKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #113 P11DHPublicKey, accessflags: 26 private static final], [inner class info: #109 sun/security/pkcs11/P11Key$P11DHPrivateKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #115 P11DHPrivateKey, accessflags: 26 private static final], [inner class info: #107 sun/security/pkcs11/P11Key$P11DSAPrivateKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #116 P11DSAPrivateKey, accessflags: 26 private static final], [inner class info: #91 sun/security/pkcs11/P11Key$P11DSAPublicKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #117 P11DSAPublicKey, accessflags: 26 private static final], [inner class info: #88 sun/security/pkcs11/P11Key$P11RSAPublicKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #118 P11RSAPublicKey, accessflags: 26 private static final], [inner class info: #105 sun/security/pkcs11/P11Key$P11RSAPrivateNonCRTKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #119 P11RSAPrivateNonCRTKey, accessflags: 26 private static final], [inner class info: #103 sun/security/pkcs11/P11Key$P11RSAPrivateKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #120 P11RSAPrivateKey, accessflags: 26 private static final], [inner class info: #85 sun/security/pkcs11/P11Key$P11SecretKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #121 P11SecretKey, accessflags: 26 private static final], [inner class info: #98 sun/security/pkcs11/P11Key$P11PrivateKey, outer class info: #28 sun/security/pkcs11/P11Key inner name: #122 P11PrivateKey, accessflags: 26 private static final], [inner class info: #208 java/security/KeyRep$Type, outer class info: #43 java/security/KeyRep inner name: #289 Type, accessflags: 16409 public static final] }
This could be filtered out. However with this change in, I'd like to see a checkbox or another widget that would offer all different flavour for the disassembler. Then the user could choose what he/she wants to see.
I know I know ;-) My point is that with the new code the user gets a different result.
My point is that it doesn't matter :-).
ok. what else is shown? I when I started to show more it was Philippe who told me to reduce it. Can you talk to him about this?
With a toggle button or something that would offer a choice to the user, each user could choose how much he wants to see. You could have DEFAULT, DETAILED, SYSTEM and more is necessary :-).
I can't wait to see a patch :-]
I'll provide one if I can get it to work :-). But should I request the new API on the pmc mailing list?
Yes, the API by itself is fine, but my question remains: what do I have to change in the UI code to get the M5 behavior?
I don't understand why you absolutely want the M5 output. Who cares as long as you propose a disassembled output? We never specifies what was supposed to be displayed. If you really want it, I guess I can add a new mode (which would require a new constant), but I think this is completely useless.
I personally don't care that much as long as I won't have Philippe coming to me and asking to reduce it again.
+1 for the API
API added. Released for 3.3M6. Added regression tests in org.eclipse.jdt.core.tests.model.ClassFileTests#testGetBytes and org.eclipse.jdt.core.tests.dom.ASTConverterTest2#test0522
Adopted new API by committing attached JDT Text patch.
Verified for 3.3 M6 using build I20070320-0010
