eclipse-plugin issueshttps://gitlab.ow2.org/asm/eclipse-plugin/-/issues2019-09-29T07:55:41Zhttps://gitlab.ow2.org/asm/eclipse-plugin/-/issues/317558Relicense to EPL and move to eclipse.org2019-09-29T07:55:41ZAndrey LoskutovRelicense to EPL and move to eclipse.orgI was asked if we shouldn't move the BCO code to the Eclipse platform, where it can be used as default classfile viewer (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=540436#c1).
As the original author of this tool I see the value t...I was asked if we shouldn't move the BCO code to the Eclipse platform, where it can be used as default classfile viewer (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=540436#c1).
As the original author of this tool I see the value to move there, I'm committer in JDT and JDT Debug, so it will be just a win-win.
For this to happen, we need following:
* Switch the license to EPL 2.0 (see below)
* Rename packages
* Cleanup code (especially Java 9+ support is a hack)
* Get rid of embedded asm libraries (consume those from Eclipse Orbit)
* Check if we can continue to redistribute the bytecode reference contributed by Eugene Kuleshov (eu@javatx.org), "Reprinted with the permission of O'Reilly Media, Inc.", see commit dce274e66d54cd4e9744d410c720bc4153eada69, or need to ask permission again.
@ebruneton : to switch the license, I need agreement of all past contributors, right?
I see you, me and Eugene in the git log.
* First question: would you agree to move the code under EPL 2.0?
* Second: if yes, do you have contact with Eugene and could you ask him about EPL and also O'Reilly permission background? I will see if I can reach them by myself too.Andrey LoskutovAndrey Loskutovhttps://gitlab.ow2.org/asm/eclipse-plugin/-/issues/317557eclipse plugin: display method size2018-05-18T07:33:49Zphraktleeclipse plugin: display method size```
Similar to overall class size, It would be very useful to display the size of individual methods. Since
Hotspot inlining heuristics depend on this (e.g. methods longer than 320 bytecodes will never be
inlined), this is quite helpf...```
Similar to overall class size, It would be very useful to display the size of individual methods. Since
Hotspot inlining heuristics depend on this (e.g. methods longer than 320 bytecodes will never be
inlined), this is quite helpful to know during optimization.
```https://gitlab.ow2.org/asm/eclipse-plugin/-/issues/316366Ability to compare two class files after fields, methods, etc. have been sorted.2018-05-18T07:33:49ZhenddherAbility to compare two class files after fields, methods, etc. have been sorted.```
The idea is that two classes are compared such that the occurrence of fields,
methods, etc. do not "confuse" the diff view.
The use-case is this:
Source-code and its corresponding .class are available. Then, .class is
modified str...```
The idea is that two classes are compared such that the occurrence of fields,
methods, etc. do not "confuse" the diff view.
The use-case is this:
Source-code and its corresponding .class are available. Then, .class is
modified structurally (fields, methods added, removed, changed) such that when
new .class is compared with the original .class, the new structural changes do
not longer confuse the diff view.
The changes are the following:
(patch form)
### Eclipse Workspace Patch 1.0
#P de.loskutov.ByteCodeOutline
Index: src/de/loskutov/bco/asm/SortedClassNode.java
===================================================================
--- src/de/loskutov/bco/asm/SortedClassNode.java (revision 0)
+++ src/de/loskutov/bco/asm/SortedClassNode.java (working copy)
@@ -0,0 +1,54 @@
+package de.loskutov.bco.asm;
+
+import java.util.Collections;
+import java.util.Comparator;
+
+import org.objectweb.asm.ClassVisitor;
+import org.objectweb.asm.tree.ClassNode;
+import org.objectweb.asm.tree.FieldNode;
+import org.objectweb.asm.tree.InnerClassNode;
+import org.objectweb.asm.tree.MethodNode;
+
+
+public class SortedClassNode extends ClassNode {
+
+ public SortedClassNode(final int api) {
+ super(api);
+ }
+
+ @Override
+ public void accept(final ClassVisitor acv) {
+ sortAll();
+ super.accept(acv);
+ }
+
+ public void sortAll() {
+
+ Collections.sort(interfaces);
+
+ Collections.sort(innerClasses, new Comparator() {
+ @Override
+ public int compare(Object arg0, Object arg1) {
+ InnerClassNode ic0 = (InnerClassNode) arg0;
+ InnerClassNode ic1 = (InnerClassNode) arg1;
+ return ic0.name.compareTo(ic1.name);
+ }});
+
+ Collections.sort(fields, new Comparator() {
+ @Override
+ public int compare(Object arg0, Object arg1) {
+ FieldNode fn0 = (FieldNode) arg0;
+ FieldNode fn1 = (FieldNode) arg1;
+ return fn0.name.compareTo(fn1.name);
+ }});
+
+ Collections.sort(methods, new Comparator() {
+ @Override
+ public int compare(Object arg0, Object arg1) {
+ MethodNode mn0 = (MethodNode) arg0;
+ MethodNode mn1 = (MethodNode) arg1;
+ return mn0.name.compareTo(mn1.name);
+ }});
+
+ }
+}
Index: src/de/loskutov/bco/asm/DecompilerHelper.java
===================================================================
--- src/de/loskutov/bco/asm/DecompilerHelper.java (revision 1635)
+++ src/de/loskutov/bco/asm/DecompilerHelper.java (working copy)
@@ -31,7 +31,7 @@
DecompilerOptions options)
throws IOException, UnsupportedClassVersionError {
ClassReader cr = new ClassReader(is);
- ClassNode cn = new ClassNode(Opcodes.ASM4);
+ ClassNode cn = new SortedClassNode(Opcodes.ASM4);
int crFlags = 0;
if(options.modes.get(BCOConstants.F_EXPAND_STACKMAP)) {
crFlags |= ClassReader.EXPAND_FRAMES;
```Andrey LoskutovAndrey Loskutovhttps://gitlab.ow2.org/asm/eclipse-plugin/-/issues/316206Opening inner class byte code view by mouse click (make the inner class name ...2018-05-18T07:33:49ZlhotariOpening inner class byte code view by mouse click (make the inner class name a link in the byte code view?)```
The compiled Groovy source code contains a lot of inner classes . Viewing the
byte code of them is possible currently by opening the class file directly in
Eclipse/STS. I've attached a simple Groovy project which contains one inner...```
The compiled Groovy source code contains a lot of inner classes . Viewing the
byte code of them is possible currently by opening the class file directly in
Eclipse/STS. I've attached a simple Groovy project which contains one inner
class in the Hello class. It would be easier to view the byte code of Groovy
classes if inner class names were links in the byte code view.
```Andrey LoskutovAndrey Loskutovhttps://gitlab.ow2.org/asm/eclipse-plugin/-/issues/315500Bytecode debugging instruction by instruction2018-05-18T07:33:49Zxkr47Bytecode debugging instruction by instruction```
I would really love to be able to step bytecode instruction by instruction in
the debugger view - even when source is available.. and to be able to view the
stack and local variables somehow.
Also, if I have an java agent installed ...```
I would really love to be able to step bytecode instruction by instruction in
the debugger view - even when source is available.. and to be able to view the
stack and local variables somehow.
Also, if I have an java agent installed (which translates bytecode on the fly
when classes are loaded), the original bytecode does not apply.. would it be
possible to access the transformed bytecode somehow? Does java have debugging
hooks for this?
Thanks for a great product!
```Andrey LoskutovAndrey Loskutov