asm issueshttps://gitlab.ow2.org/asm/asm/-/issues2017-12-26T10:44:47Zhttps://gitlab.ow2.org/asm/asm/-/issues/314964AnalyzerAdapter does not treat <init> calls correctly2017-12-26T10:44:47ZseweAnalyzerAdapter does not treat <init> calls correctly```
This issue has been discussed on the mailing list already:
<http://mail.ow2.org/wws/arc/asm/2010-03/msg00013.html>. At least to Eugene my
understanding of the issue is correct
<http://mail.ow2.org/wws/arc/asm/2010-03/msg00014.html>; ...```
This issue has been discussed on the mailing list already:
<http://mail.ow2.org/wws/arc/asm/2010-03/msg00013.html>. At least to Eugene my
understanding of the issue is correct
<http://mail.ow2.org/wws/arc/asm/2010-03/msg00014.html>; after a constructor
call of the form SuperClass.<init>() the AnalyzerAdapter should label the top
of stack with *SubClass*, not SuperClass. But the code says otherwise:
[...]
if (opcode == Opcodes.INVOKESPECIAL && name.charAt(0) == '<') {
Object u;
if (t == Opcodes.UNINITIALIZED_THIS) {
u = owner; // argument of visitMethodInsn, not this.owner!
}
[...]
```https://gitlab.ow2.org/asm/asm/-/issues/314969Counterintuitive interaction of arguments to ClassWriter(cr, flags)2017-12-26T10:44:37ZseweCounterintuitive interaction of arguments to ClassWriter(cr, flags)```
Currently, no stack map tables are inserted if a method can simply be copied
from ClassReader to ClassWriter. At least to me this is counterintuitive, though.
IMHO, the correct thing to do would be to never copy methods if either
CO...```
Currently, no stack map tables are inserted if a method can simply be copied
from ClassReader to ClassWriter. At least to me this is counterintuitive, though.
IMHO, the correct thing to do would be to never copy methods if either
COMPUTE_FRAMES or COMPUTE_MAXS is set. But at the very least the JavaDoc of
ClassWriter(cf, flags) should make this interaction very clear.
```https://gitlab.ow2.org/asm/asm/-/issues/314944visitLocalVariable skips index for long parameter2017-12-26T10:45:00ZmindlessvisitLocalVariable skips index for long parameter```
Consider a class with a method like:
public void test(long x, String y) { ... }
When using ClassReader.accept() to traverse the methods, the "index" value for
the visitLocalVariable calls of "x" and "y" will not be consecutive. Fo...```
Consider a class with a method like:
public void test(long x, String y) { ... }
When using ClassReader.accept() to traverse the methods, the "index" value for
the visitLocalVariable calls of "x" and "y" will not be consecutive. For some
reason after a parameter of type "long" the next index will be skipped.
I have seen this in asm 2.2.3 and 3.2. Is this considered a bug? In
collecting parameter info I was expecting sequential index values.
```https://gitlab.ow2.org/asm/asm/-/issues/3158405 Documentation Bugs in Various Classes2017-12-26T10:38:44Zkivancmuslu5 Documentation Bugs in Various Classes```
The following methods contain documentation bugs relating to Java naming
conventions. The methods either throw an Exception or return an unexpected
value when used as currently documented.
We explain each of these documentation bugs ...```
The following methods contain documentation bugs relating to Java naming
conventions. The methods either throw an Exception or return an unexpected
value when used as currently documented.
We explain each of these documentation bugs in detail below.
We detected these errors using the Checker Framework
(http://types.cs.washington.edu/checker-framework/).
Attached to this bug report is a patch file that corrects all documentation errors.
Bug #1:
The constructor "org.objectweb.asm.ClassReader.ClassReader(String)" is
documented to take a fully qualified name, however it should take a binary name.
If called as documented (with a fully qualified name that is not also a binary
name) the method throws IOException.
Details: The argument string is transformed into a path (by replacing '.' with
'/' and adding .class at the end). Then this path is passed to
ClassLoader.getResourceAsStream(String) method. This method looks if the file
exists in the file system and if it does not, it returns null. Since the
compiled file generated for an inner class has '$' in it (i.e., they follow the
binary name convention), for inner classes, getResourceAsStream will return
null if called with a path that does not include '$' (but includes '/'
instead). Later the result of getResourceAsStream is passed to
ClassReader.readClass(InputStream). This method throws an IOException if the
input is null.
Bug #2:
The method "String org.objectweb.asm.Type.getClassName()" is documented to
return a fully qualified name, however it should return a binary name.
The return value of the method contradicts the documentation when the type
represents an Object.
Details: When the type is an Object, the first and the last elements of the
'buf' (which is the char array for the underlying field descriptor) is
stripped, and '/' is replaced with '.'. Since field descriptors for inner
classes contains '$', and the operation done on the array does not change this
sign, the resulting string will also contain '$' sign. '$' signs are only
contained in binary names.
Bug #3:
The input for the following programs:
org.objectweb.asm.util.CheckClassAdapter.java
org.objectweb.asm.util.TraceClassVisitor.java
org.objectweb.asm.util.ASMifierClassVisitor.java
are documented as a "fully qualified class name or class file name", however
they should be "binary name or class file name".
The input given to these programs are passed to org.objectweb.asm.ClassReader's
constructor. As explained in bug #1, they should be binary names.
```https://gitlab.ow2.org/asm/asm/-/issues/314563exception from asm.commons.LocalVariablesSorterremap2017-12-26T10:48:24Zsander24exception from asm.commons.LocalVariablesSorterremap```
hi,
got a strange exception from mentioned class.. i'm actually using jarjar which
in turn is using asm-commons, but i'm 90% sure the exception is yours.. namely,
when i write:
public void someMethod() {
String line;
...```
hi,
got a strange exception from mentioned class.. i'm actually using jarjar which
in turn is using asm-commons, but i'm 90% sure the exception is yours.. namely,
when i write:
public void someMethod() {
String line;
// and use it later..
i get:
java.lang.IllegalStateException: Unknown local variable 1
at com.tonicsystems.jarjar.asm.commons.LocalVariablesSorter.remap(Unknown Source)
at com.tonicsystems.jarjar.asm.commons.LocalVariablesSorter.visitFrame(Unknown
Source)
at
com.tonicsystems.jarjar.asm.commons.RemappingMethodAdapter.visitFrame(Unknown
Source)
at com.tonicsystems.jarjar.asm.ClassReader.accept(Unknown Source)
at com.tonicsystems.jarjar.asm.ClassReader.accept(Unknown Source)
at com.tonicsystems.jarjar.ext_util.JarTransformer.process(JarTransformer.java:35)
at
com.tonicsystems.jarjar.ext_util.JarProcessorChain.process(JarProcessorChain.java:31)
....
(never mind about the package names being renamed.. that's what jarjar is about)
Why i'm sure this is a bug is that this exception disappears when i instead write:
public void someMethod() {
String line = null;
// and use it later..
sry, no time to dig for the reason myself.. np, i just work around this myself
but maybe it's a bug you'd like to fix ;)
```https://gitlab.ow2.org/asm/asm/-/issues/314592Incorrect stack frame handling in AnalyzerAdapter2017-12-26T10:48:11ZtrkropIncorrect stack frame handling in AnalyzerAdapter```
Hi all,
I use the AnalyzerAdapter for tracking the stack frames as suggested
in the documentation. At certain points I copy the state (locals and
stack) for later recovery.
When I replay the state using visitFrame(...), it is not r...```
Hi all,
I use the AnalyzerAdapter for tracking the stack frames as suggested
in the documentation. At certain points I copy the state (locals and
stack) for later recovery.
When I replay the state using visitFrame(...), it is not recovered
as expected. The problem is that the following function introduces
an additional TOP for each LONG and DOUBLE:
private static void visitFrameTypes(
final int n,
final Object[] types,
final List result)
{
for (int i = 0; i < n; ++i) {
Object type = types[i];
result.add(type);
if (type == Opcodes.LONG || type == Opcodes.DOUBLE) {
result.add(Opcodes.TOP);
}
}
}
May be I misused the AnalyzerAdapter, when I introduced it behind
the transforming class. Actually I might change this, but I think
the problem is more general and would result in incorrect informa-
tion whenever there are LONGs and DOUBLEs on the stack before the
AnalyzerAdapter gets called. If the Language Specs expect TOPs on
the stack, than the function should assume them to exist, itself.
Thus, the function should either check for TOPs after LONG or
DOUBLE as below or ignore such concerns completely, as shown
below:
private static void visitFrameTypes(
final int n,
final Object[] types,
final List result)
{
for (int i = 0; i < n; ++i) {
Object type = types[i];
result.add(type);
if (type == Opcodes.LONG || type == Opcodes.DOUBLE) {
if ((index++ > size) || (types[index] != Opcodes.TOP)) {
throw new IllegalArgumentException("error: stack/locals");
}
result.add(Opcodes.TOP);
}
}
}
private static void visitFrameTypes(
final int n,
final Object[] types,
final List result)
{
for (int i = 0; i < n; ++i) {
result.add(types[i]);
}
}
Both behaviors would be acceptable.
```https://gitlab.ow2.org/asm/asm/-/issues/314719method length is sometimes calculated incorrectly2018-01-20T10:15:51Zdgulottamethod length is sometimes calculated incorrectly```
asm sometimes writes an incorrect method length to a class file. Attached is a
malformed class file produced by asm.
``````
asm sometimes writes an incorrect method length to a class file. Attached is a
malformed class file produced by asm.
```https://gitlab.ow2.org/asm/asm/-/issues/314701Improper signature when parsing an enum2017-12-26T10:47:24Zmdhirsch30345Improper signature when parsing an enum```
ASM 3.2 is giving me contradictory information about the constructor of an
enum. The description (i.e. the type erased signature) seems right and the
signature seems wrong.
I have a simple enum:
public enum MyEnum {
MINE;
}
I'...```
ASM 3.2 is giving me contradictory information about the constructor of an
enum. The description (i.e. the type erased signature) seems right and the
signature seems wrong.
I have a simple enum:
public enum MyEnum {
MINE;
}
I've implemented a simple ClassVisitor named ClassPrinter which I run like so:
public static void main(String[] args) {
try {
ClassPrinter cp = new ClassPrinter();
final InputStream stream =
ClassLoader.getSystemResourceAsStream("MyEnum.class");
ClassReader cr = new ClassReader(stream);
cr.accept(cp, 0);
} catch (IOException e) {
e.printStackTrace();
}
}
The ClassPrinter just prints the information each visit method gets. When the
constructor of the MyEnum is called, this is the critical information:
method: <init>
desc: (Ljava/lang/String;I)V
sig: ()V
access: private
So the description says that the constructor takes a string and an int and
returns void, while the signature says the constructor takes no arguments and
returns void. If I print out the class with javap, it show the same
information as the description.
Particularly confusing to me is that for every other example I've worked
through, if the description is complete, i.e. there are no generics in the
method, then the signature is always null. Why in this case is the signature
non-null and wrong?
I'm using JDK 1.6.0_16 to compile and run this example.
```https://gitlab.ow2.org/asm/asm/-/issues/315417LocalVariablesSorter.remap() incorrectly process long/double types2017-12-26T10:40:53Za_glasmanLocalVariablesSorter.remap() incorrectly process long/double types```
LocalVariablesSorter.remap(final int var, final Type type) method contains the following condition:
if (var < firstLocal) {
return var;
}
to check whether the remapping is required.
It works as expected wh...```
LocalVariablesSorter.remap(final int var, final Type type) method contains the following condition:
if (var < firstLocal) {
return var;
}
to check whether the remapping is required.
It works as expected when type size is 1. At the same time when (var == firstLocal - 1) and (type ==
Type.LONG_TYPE) the remapping should be performed. However above condition leads to missing
remapping. As a result maxLocals can be calculated incorrectly.
The following fix is suggested to take into account the long/double types:
if (var + type.getSize() <= firstLocal) {
return var;
}
```https://gitlab.ow2.org/asm/asm/-/issues/315414AnalyzerAdapter.visitFrameTypes incorrectly adds Opcodes.TOP after long types2017-12-26T10:41:09Za_glasmanAnalyzerAdapter.visitFrameTypes incorrectly adds Opcodes.TOP after long types```
Locals passed to visitFrameTypes can already contain Opcodes.TOP after the long
type. At the same time this method adds Opcodes.TOP in any case - it doesn't
check the next item after the long value.
In this case long local values are...```
Locals passed to visitFrameTypes can already contain Opcodes.TOP after the long
type. At the same time this method adds Opcodes.TOP in any case - it doesn't
check the next item after the long value.
In this case long local values are processed incorrectly: we can have the
following: .... Opcodes.LONG, Opcodes.TOP, Opcodes.TOP, ...
As a result we can have incorrect mapping with existing locals and get
incorrect stack map info.
The following fix is suggested to resolve this issue:
if (type == Opcodes.LONG || type == Opcodes.DOUBLE) {
if ((i == n - 1) || ((i < n - 1) && (types[i + 1] != Opcodes.TOP))) {
result.add(Opcodes.TOP);
}
}
```https://gitlab.ow2.org/asm/asm/-/issues/314198NullPointerException from Label.isSameSubroutine()2017-12-26T10:50:56ZaarongreenhouseNullPointerException from Label.isSameSubroutine()```
Under certain circumstances it is possible to have a NullPointerException from
Label.isSameSubroutine() while computing the basic blocks in
MethodWriter.visitMaxes(). The immediate problem is that the field
srcAndRefPositions of the...```
Under certain circumstances it is possible to have a NullPointerException from
Label.isSameSubroutine() while computing the basic blocks in
MethodWriter.visitMaxes(). The immediate problem is that the field
srcAndRefPositions of the argument block will be null. This seems to happen
when the label preceeds a JSR instruction (sometimes by a few instructions,
that is, the label need not be immediately before the JSR) and that label has
no forward references.
Seems to me this can be fixed by better management of the srcAndRefPositions
field in Label. I have hacked inSameSubroutine() thusly
boolean inSameSubroutine(final Label block) {
// BEGIN: MY CHANGE
if (block.srcAndRefPositions == null) {
block.srcAndRefPositions = new int[srcAndRefPositions.length];
}
// END: MY CHANGE
for (int i = 0; i < srcAndRefPositions.length; ++i) {
if ((srcAndRefPositions[i] & block.srcAndRefPositions[i]) != 0) {
return true;
}
}
return false;
}
with no ill effects, but probably there is a better way to fix it.
This comes up because my transformation has to remap labels occasionally, so
sometimes the generated code has two labels on the same code position, and the
second label is never actually referenced. (This happens because the I cannot
know whether the new label is truly needed until after the labels need to be
created.)
I have been able to fix this problem in my code by having it insert a GOTO to
the second label immediately before the second label, thus insuring that the
label has a forward reference. That is, instead of generating
...
OP1
L1:
L2:
OP2
...
I now generate
...
OP1
L1:
GOTO L2
L2:
OP2
...
This results in silly looking bytecode, but it keeps the control-flow algorithm
in Label happy.
```https://gitlab.ow2.org/asm/asm/-/issues/314260AdviceAdapter bug with method enter/exit2017-12-26T10:50:36ZivandAdviceAdapter bug with method enter/exit```
I found a bug in AdviceAdapter from ams v3.2 stable release.
The bug is when in constructor of a class has more complex
code like this when call this(...):
...
public AdviceAdapter_Bug(String t, int size, int factor, int minimumF...```
I found a bug in AdviceAdapter from ams v3.2 stable release.
The bug is when in constructor of a class has more complex
code like this when call this(...):
...
public AdviceAdapter_Bug(String t, int size, int factor, int minimumFill) {
this(size, factor, minimumFill = minimumFill <= size * factor ? minimumFill
: size * factor);
System.out.println("t: " + t + " size: " + size + "factor: " + factor);
}
protected AdviceAdapter_Bug(int size, int factor, int minimumFill) {
System.out.println("size: " + size + "factor: " + factor);
}
...
The bug is that for first constructor there is no onMethodEnter() call.
I check the AdviceAdapter code and I think it is a bug with calculating
the branches.
I attached simple test class which could be used to test AdviceAdapter
```https://gitlab.ow2.org/asm/asm/-/issues/314328[patch] minor improvement to serialveruidadder2017-12-26T10:49:57Zdbrosius[patch] minor improvement to serialveruidadder```
code executes block of code, whether it needs it or not... pushed down to where
it's used. pretty trivial.
``````
code executes block of code, whether it needs it or not... pushed down to where
it's used. pretty trivial.
```https://gitlab.ow2.org/asm/asm/-/issues/314329[patch] unnecessary casting, using HashMap v. Map2017-12-26T10:49:41Zdbrosius[patch] unnecessary casting, using HashMap v. Map```
ASMContentHandler casts returns to HashMap, when Map will do. Unnecessary ties
code to HashMap.
pretty trivial.
``````
ASMContentHandler casts returns to HashMap, when Map will do. Unnecessary ties
code to HashMap.
pretty trivial.
```https://gitlab.ow2.org/asm/asm/-/issues/314330[patch] make sure files get closed2017-12-26T10:49:27Zdbrosius[patch] make sure files get closed```
NameMapping leaves property file open undeterminately long. patch closes file
when done.
``````
NameMapping leaves property file open undeterminately long. patch closes file
when done.
```https://gitlab.ow2.org/asm/asm/-/issues/314486SerialVersionUIDAdder generates an incorrect serialVersionUID under 1.6 VMs f...2018-02-11T12:51:56ZcdennisSerialVersionUIDAdder generates an incorrect serialVersionUID under 1.6 VMs for anonymous classes```
Feeding the attached class (when compiled under 1.6) through an adapter chain
containing just the SerialVersionUIDAdder (and then dumping) generates the
following output:
// class version 50.0 (50)
// access flags 48
final class Tes...```
Feeding the attached class (when compiled under 1.6) through an adapter chain
containing just the SerialVersionUIDAdder (and then dumping) generates the
following output:
// class version 50.0 (50)
// access flags 48
final class Test$1 extends Test {
// compiled from: Test.java
OUTERCLASS Test null
// access flags 8
static INNERCLASS Test$1 null null
// access flags 0
<init>()V
L0
LINENUMBER 4 L0
ALOAD 0
INVOKESPECIAL Test.<init> ()V
RETURN
MAXSTACK = 1
MAXLOCALS = 1
// access flags 24
final static J serialVersionUID = -76581618747421564
}
The calculated serialVersionUID is different from the value serialver reports:
Test$1: static final long serialVersionUID = 7846639601304304217L;
The value serialver reports is the same as on 1.4 and 1.5, which ASM correctly
matches in those VMs.
The only difference between the compiled classes appears to be the access flags
of the inner class: 1.5 and 1.4 report ACC_SUPER, 1.6 reports
ACC_SUPER|ACC_FINAL. However my reading of the 1.6 Sun source
(hotspot/src/share/vm/oops/instaceKlass.cpp:compute_modifier_flags) indicates
that the current implementation is correct (i.e. the class access flags are
ignored for inner classes, and the access flags contained in the InnerClass
attribute entry are used instead).
I'm at a loss to explain this, but I've reproduced the failure on three
different 1.6 VMs on three different platforms (RHEL, Ubuntu, Mac OS X).
Thanks,
Chris
P.S. I'm aware that serializing an anonymous inner class is not generally
recommended.
```https://gitlab.ow2.org/asm/asm/-/issues/315399AnalyzerAdapter.execute() method doesn't process null array correctly for AAL...2017-12-26T10:41:26Za_glasmanAnalyzerAdapter.execute() method doesn't process null array correctly for AALOAD instruction```
AnalyzerAdapter (visitInsn(Opcodes.AALOAD)) fails on the following valid Java
construction with ClassCastException:
Object[] arr = null;
try {
Object obj = arr[0];
} catch(NullPointerException e) {
// .....```
AnalyzerAdapter (visitInsn(Opcodes.AALOAD)) fails on the following valid Java
construction with ClassCastException:
Object[] arr = null;
try {
Object obj = arr[0];
} catch(NullPointerException e) {
// ...
}
The reason is that AnalyzerAdapter.execute() method consider second stack value
as String for AALOAD instruction:
case Opcodes.AALOAD:
pop(1);
t1 = pop();
pushDesc(((String) t1).substring(1));
break;
However in this case the second value on the stack (array type) will be
Opcodes.NULL which causes ClassCastException.
I'd suggest the following fix for this issue:
case Opcodes.AALOAD:
pop(1);
t1 = pop();
if (t1 instanceof String) {
pushDesc(((String) t1).substring(1));
} else {
push("java/lang/Object");
}
break;
```https://gitlab.ow2.org/asm/asm/-/issues/314481Bug in Remapper related to annotations2018-02-24T09:39:49ZpdevaBug in Remapper related to annotations```
This bug seems to have surfaced in JarJarLinks which uses the asm framework.
It is described in a lot more detail here -
http://code.google.com/p/jarjar/issues/detail?id=21
Basically it seems that the 'Remapping' classes call ren...```
This bug seems to have surfaced in JarJarLinks which uses the asm framework.
It is described in a lot more detail here -
http://code.google.com/p/jarjar/issues/detail?id=21
Basically it seems that the 'Remapping' classes call renamer.mapType(desc) when
they should be calling renamer.mapDesc(desc).
```https://gitlab.ow2.org/asm/asm/-/issues/313997LocalVariablesSorter gets confused when dummy parameters are added to function2017-12-26T10:52:08ZianjoLocalVariablesSorter gets confused when dummy parameters are added to function```
I'm adding a dummy parameter to a method, just as a marker -- it doesn't have
any impact on the code at all, and it remains unchanged. When such a method is
visited by a LocalVariablesSorter, it gets confused and rewrites code wrong....```
I'm adding a dummy parameter to a method, just as a marker -- it doesn't have
any impact on the code at all, and it remains unchanged. When such a method is
visited by a LocalVariablesSorter, it gets confused and rewrites code wrong.
When running the attached example with "java Asmbug" this gets flagged by the
CheckClassAdapter. Running the example with "java Asmbug false" which doesn't
run the code using a LocalVariablesSorter, it checks out ok, and is accepted by
sun's JVM.
This happens both with an older version of asm I was using, and with a recent
svn snapshot.
```https://gitlab.ow2.org/asm/asm/-/issues/312464ClassReader does not ensure that NEW has a label associated with it2017-12-26T10:53:53ZorlovmClassReader does not ensure that NEW has a label associated with it```
This problem occurs in ASM 3.1.
Consider the following test case (inside some class):
public static class RegressionNew {
public static void foo(int x) {
new Integer(x == 0 ? 0 : 1);
}
}
@Test
public void asmRegressionNew() th...```
This problem occurs in ASM 3.1.
Consider the following test case (inside some class):
public static class RegressionNew {
public static void foo(int x) {
new Integer(x == 0 ? 0 : 1);
}
}
@Test
public void asmRegressionNew() throws IOException {
ClassReader cr = new ClassReader(RegressionNew.class.getName());
TraceClassVisitor tcv = new TraceClassVisitor(new PrintWriter(System.out));
cr.accept(tcv, ClassReader.SKIP_DEBUG);
}
I think it doesn't matter which Java compiler is used, but I used Eclipse 3.4.
This results in:
public static foo(I)V
NEW java/lang/Integer
ILOAD 0
IFNE L0
ICONST_0
GOTO L1
L0
FRAME SAME1 L2
ICONST_1
L1
FRAME FULL [I] [L2 I]
INVOKESPECIAL java/lang/Integer.<init> (I)V
RETURN
MAXSTACK = 2
MAXLOCALS = 1
The frame before INVOKESPECIAL is incorrect, since it should contain a label
associated with NEW (it instead contains nonexistent label L2).
The following patch alleviates the problem:
ClassReader, near line 930 ("find the labels" phase):
case ClassWriter.TYPE_INSN:
if (Opcodes.NEW == opcode)
readLabel(w, labels);
case ClassWriter.SHORT_INSN:
case ClassWriter.LDCW_INSN:
case ClassWriter.FIELDORMETH_INSN:
case ClassWriter.IINC_INSN:
v += 3;
break;
Instead of
case ClassWriter.SHORT_INSN:
case ClassWriter.LDCW_INSN:
case ClassWriter.FIELDORMETH_INSN:
case ClassWriter.TYPE_INSN:
case ClassWriter.IINC_INSN:
v += 3;
break;
Now we have:
public static foo(I)V
L0
NEW java/lang/Integer
ILOAD 0
IFNE L1
ICONST_0
GOTO L2
L1
FRAME SAME1 L0
ICONST_1
L2
FRAME FULL [I] [L0 I]
INVOKESPECIAL java/lang/Integer.<init> (I)V
RETURN
MAXSTACK = 2
MAXLOCALS = 1
The frame before INVOKESPECIAL now contains the label L0, which was associated
with NEW. A more precise test case in Jasmin:
.class public RegressionNew
.super java/lang/Object
.method public static foo()V
.limit stack 1
.limit locals 0
new java/lang/Object
goto skip
skip:
invokespecial java/lang/Object/<init>()V
return
.end method
```