asm issueshttps://gitlab.ow2.org/asm/asm/-/issues2017-12-26T10:03:36Zhttps://gitlab.ow2.org/asm/asm/-/issues/317539TypePath not adequately supporting types w/ >10 type arguments2017-12-26T10:03:36Zjhumphries131TypePath not adequately supporting types w/ >10 type arguments```
In ASM 5.0.3:
TypePath.fromString() and TypePath.toString() both describe path elements for navigating type arguments
of a parameterized type as a single decimal digit. This doesn't adequately support types that have > 10
type arg...```
In ASM 5.0.3:
TypePath.fromString() and TypePath.toString() both describe path elements for navigating type arguments
of a parameterized type as a single decimal digit. This doesn't adequately support types that have > 10
type arguments.
Looking at the javadoc and even the source doesn't reveal anything obvious about how values > 10th (e.g.
> '9') should be handled.
The source for TypePath.fromString() looks like it reads a sequence of decimal digits as a single "type
argument" path element. But then there's no obvious separator between multiple type argument path
elements (though the code looks like it would accept anything other than a decimal digit or ".", "*", or "]").
The source for TypePath.toString(), on the other hand, looks like it will not correctly handle values for type
argument indices > '9'. It simply concatenates adjacent path elements. So a path of:
type_argument(1), type_argument(0)
of a nested generic type is indistinguishable from the path:
type_argument(10)
of a generic type with >10 type arguments.
When using ASMifier to generate source code for a class, it looks like it is trying to use adjacent single
decimal digits for each path step (which won't actually work since fromString() will combine them into a
single step). If any single step has value > '9', then it inserts period separators (e.g. ".10.1" is the type
argument at index 11 and then 1 where as "101" is the type argument at index 1 then 0 then 1). However,
periods are defined in the toString() doc (and in the actual implementation code) to mean
nested/enclosed type path elements, not type arguments.
We can see the above ambiguity in action with the following sample code:
----
import java.io.PrintWriter;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.util.List;
import java.util.Map;
import org.objectweb.asm.ClassReader;
import org.objectweb.asm.util.ASMifier;
import org.objectweb.asm.util.TraceClassVisitor;
public class TypePathBug {
@Target(ElementType.TYPE_USE)
@Retention(RetentionPolicy.RUNTIME)
@interface A {
}
class T<P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12> {
}
class U<X, Y, Z> extends T<X, Map<@A Y, Z>, X, Y, Z, X, Y, Z, X, Y, @A Z, X> {
}
public static void main(String args[]) throws Exception {
new ClassReader(U.class.getName().replace('.', '/')).accept(
new TraceClassVisitor(null, new ASMifier(),
new PrintWriter(System.out)), 0);
}
}
----
The resulting output generates code for the two @A annotations that is identical and thus
indistinguishable -- which means it cannot be correct since they are distinct/different type paths. Here is
the code generated for both type annotations:
{
av0 = cw.visitTypeAnnotation(285212416, TypePath.fromString(".10"), "LTypePathBug$A;", true);
av0.visitEnd();
}
----
Were I propose a fix: decimal path elements that indicate type parameter indices are terminated with a
semicolon. All of TypePath.toString(), TypePath.fromString(), and ASMifier would need to be updated. The
above ambiguous type path, ".10" would instead be represented as "1;0;" for the first occurrence of @A
and "10;" for the second. TypePath.fromString() can be lenient and not require ";" termination if it instead
encounters end-of-string, ".", "[", or "*".
```https://gitlab.ow2.org/asm/asm/-/issues/317538AnnotationNode in ASM 5.0.3 does not handle null returned from AnnotationVisi...2018-01-21T08:20:17ZLubomir BulejAnnotationNode in ASM 5.0.3 does not handle null returned from AnnotationVisitor correctly.```
AnnotationNode in ASM 5.0.3 does not handle null returned from
AnnotationVisitor correctly. While the documentation says that
AnnotationVisitor.visitArray(String) can return null , the
AnnotationNode.accept(AnnotationVisitor, String,...```
AnnotationNode in ASM 5.0.3 does not handle null returned from
AnnotationVisitor correctly. While the documentation says that
AnnotationVisitor.visitArray(String) can return null , the
AnnotationNode.accept(AnnotationVisitor, String, Object) method calls
AnnotationVisitor.visitEnd() on a potentially null visitor in the part that
handles List values.
Suggested fix to AnnotationNode.accept(AnnotationVisitor, String, Object):
...
} else if (value instanceof List) {
AnnotationVisitor v = av.visitArray(name);
if (v != null) {
List array = (List) value;
for (int j = 0; j < array.size(); ++j) {
accept(v, null, array.get(j));
}
v.visitEnd();
}
} else {
...
```https://gitlab.ow2.org/asm/asm/-/issues/317537Wrong tryCatch block sorting2017-12-26T10:04:02ZkammererWrong tryCatch block sorting```
TryCatchBlockSorter:
Comparator<TryCatchBlockNode> comp = new Comparator<TryCatchBlockNode>() {
public int compare(TryCatchBlockNode t1, TryCatchBlockNode t2) {
int len1 = blockLength(t1);
...```
TryCatchBlockSorter:
Comparator<TryCatchBlockNode> comp = new Comparator<TryCatchBlockNode>() {
public int compare(TryCatchBlockNode t1, TryCatchBlockNode t2) {
int len1 = blockLength(t1);
int len2 = blockLength(t2);
return len1 - len2;
}
private int blockLength(TryCatchBlockNode block) {
int startidx = instructions.indexOf(block.start);
int endidx = instructions.indexOf(block.end);
return endidx - startidx;
}
};
after node sorting node for default catch handler could occur before non
default one, same problem with hierarchy of exceptions more specified could
occur after general one in tryCatchBlock list.
Maybe best to compare hander indexies?
```https://gitlab.ow2.org/asm/asm/-/issues/317531Invalid lambda deserialization error after relocation of packages2018-05-19T16:08:14ZzarzykInvalid lambda deserialization error after relocation of packages```
Hi,
I'm having an issue with serializing & deserializing lambdas that were processed by asm: "Invalid lambda deserialization"
My environment:
I'm using java 8, version :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (buil...```
Hi,
I'm having an issue with serializing & deserializing lambdas that were processed by asm: "Invalid lambda deserialization"
My environment:
I'm using java 8, version :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
I'm using shadow plugin for gradle that uses asm for relocating packages and references in jars and/or class files.
I'm using the official version 0.8 from the link:
https://github.com/johnrengelman/shadow/tree/0.8
This version uses asm in version 3, but I overrode the asm dependency and set it to the freshest on Maven, which is 5.0.3:
org.ow2.asm:asm:5.0.3, org.ow2.asm:asm-commons:5.0
I created a sample project to easily reproduce the problem:
https://github.com/kzarzycki/asm-lambda-deserialization-error-test
When I run my test, I get an exception:
Exception in thread "main" java.io.IOException: unexpected exception type
at java.io.ObjectStreamClass.throwMiscException(ObjectStreamClass.java:1538)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1110)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1810)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at AsmTest.deserialize(AsmTest.java:36)
at AsmTest.main(AsmTest.java:21)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at java.lang.invoke.SerializedLambda.readResolve(SerializedLambda.java:230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1104)
... 5 more
Caused by: java.lang.IllegalArgumentException: Invalid lambda deserialization
at AsmTest.$deserializeLambda$(AsmTest.java:11)
... 15 more
I'll be grateful for your help with this issue!
```Remi ForaxRemi Foraxhttps://gitlab.ow2.org/asm/asm/-/issues/317532invalidFrames in ClassWriter.toByteArray() causes trouble on older bytecode. ...2017-12-26T10:04:55ZztandresinvalidFrames in ClassWriter.toByteArray() causes trouble on older bytecode. Frames should be ignored?```
Added the reproduction app. Can be run with:
mvn clean package exec:java
It will get exception:
Caused by: java.lang.RuntimeException: JSR/RET are not supported with
computeFrames option
It should not get this exception.
Some olde...```
Added the reproduction app. Can be run with:
mvn clean package exec:java
It will get exception:
Caused by: java.lang.RuntimeException: JSR/RET are not supported with
computeFrames option
It should not get this exception.
Some older javac (java4) and byte code generation libraryes (Jboss4 JSP
compiler for example) generate JSR/RET bytecode instructions and the bytecode
level of those files will be older then Java 6+.
Now if you have a generic method processor that uses the a visitFrame
instruction then this will affect some the state the transformation will fail
on ClassWriter.toByteArray becasue it will re-read the soruce bytecode with
it's own flags and tryes to generate some stackframes althouh this bytecode
does not support it anyway.
I think visitFrame should be ignored on older bytecode transformations.
```https://gitlab.ow2.org/asm/asm/-/issues/317534Modernize ASM code: replace new WrapperType() by autoboxing2017-12-26T10:04:19ZRemi ForaxModernize ASM code: replace new WrapperType() by autoboxing```
ASM source code while being compatible with Java 1.5 doesn't uses autoboxing
feature.
This request was asked by Oracle.
``````
ASM source code while being compatible with Java 1.5 doesn't uses autoboxing
feature.
This request was asked by Oracle.
```https://gitlab.ow2.org/asm/asm/-/issues/317533MethodInsnNode.accept() doesn't call acceptAnnotations()2018-01-21T09:02:55ZaarongMethodInsnNode.accept() doesn't call acceptAnnotations()```
As the summary says, MethodInsnNode.accept9) needs to call acceptAnnotations(), but it does not.
``````
As the summary says, MethodInsnNode.accept9) needs to call acceptAnnotations(), but it does not.
```https://gitlab.ow2.org/asm/asm/-/issues/317217CheckMethodAdapter.visitMaxs() doesn't take ClassWriter.COMPUTE_FRAMES into a...2017-12-26T10:06:32Zpdeva1CheckMethodAdapter.visitMaxs() doesn't take ClassWriter.COMPUTE_FRAMES into account```
If you use a ClassWriter with ClassWriter.COMPUTE_FRAMES to auto calculate the
max stack size, and you have code like this:
ClassWriter classWriter = new ClassWriter(classReader,
ClassWriter.COMPUTE_FRAMES);
...```
If you use a ClassWriter with ClassWriter.COMPUTE_FRAMES to auto calculate the
max stack size, and you have code like this:
ClassWriter classWriter = new ClassWriter(classReader,
ClassWriter.COMPUTE_FRAMES);
classReader.accept(new MyClassInstrumentor(new
CheckClassAdapter(classWriter)), ClassReader.EXPAND_FRAMES);
return classWriter.toByteArray();
in your custom method instrumentor when you do this:
@Override
public void visitMaxs(int maxStack, int maxLocals)
{
//perfectly valid, since due to expand_frames i can pass in anything
here
super.visitMaxs(0, 0);
}
the CheckMethodAdapater will throw an exception, because it does expect the
exact stack size.
com.chronon.apm.libs.org.objectweb.asm.tree.analysis.AnalyzerException: Error
at instruction 0: Insufficient maximum stack size.
at
com.chronon.apm.libs.org.objectweb.asm.tree.analysis.Analyzer.analyze(Unknown
Source)
at
com.chronon.apm.libs.org.objectweb.asm.util.CheckMethodAdapter$1.visitEnd(Unkno
wn Source)
at
com.chronon.apm.libs.org.objectweb.asm.MethodVisitor.visitEnd(Unknown Source)
at
com.chronon.apm.libs.org.objectweb.asm.util.CheckMethodAdapter.visitEnd(Unknown
Source)
at
com.chronon.apm.libs.org.objectweb.asm.MethodVisitor.visitEnd(Unknown Source)
at com.chronon.apm.libs.org.objectweb.asm.ClassReader.b(Unknown Source)
```https://gitlab.ow2.org/asm/asm/-/issues/317528Add toString implementation to the AbstractInsnNode subclasses2017-12-26T10:05:20ZjhaltermanAdd toString implementation to the AbstractInsnNode subclasses```
It would be great to have a toString implementation in the various AbstractInsnNode subclasses. This
would help with debugging.
``````
It would be great to have a toString implementation in the various AbstractInsnNode subclasses. This
would help with debugging.
```https://gitlab.ow2.org/asm/asm/-/issues/317257StringIndexOutOfBoundsException thrown when using TraceClassVisitor with lamb...2017-12-26T10:05:47ZjhaltermanStringIndexOutOfBoundsException thrown when using TraceClassVisitor with lambda expression```
Using TraceClassVisitor with lambda expressions can result in a StringIndexOutOfBoundsException. See
the attached failing test.
java.lang.StringIndexOutOfBoundsException: String index out of range: 21
at java.lang.String.charAt(S...```
Using TraceClassVisitor with lambda expressions can result in a StringIndexOutOfBoundsException. See
the attached failing test.
java.lang.StringIndexOutOfBoundsException: String index out of range: 21
at java.lang.String.charAt(String.java:646)
at org.objectweb.asm.signature.SignatureReader.a(Unknown Source)
at org.objectweb.asm.signature.SignatureReader.accept(Unknown Source)
at org.objectweb.asm.util.Textifier.visitMethod(Unknown Source)
at org.objectweb.asm.util.Textifier.visitMethod(Unknown Source)
at org.objectweb.asm.util.TraceClassVisitor.visitMethod(Unknown Source)
at org.objectweb.asm.ClassReader.b(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.modelmapper.TraceClassVisitorTest.maps(TraceClassVisitorTest.java:24)
at org.modelmapper.TraceClassVisitorTest.test(TraceClassVisitorTest.java:34)
```https://gitlab.ow2.org/asm/asm/-/issues/317200Fix for 317127 eliminates some non-duplicate InnerClass attributes2017-12-26T10:06:50ZLukas RytzFix for 317127 eliminates some non-duplicate InnerClass attributes```
The fix for 317127 ([1]) is buggy. When COMPUTE_FRAMES is enabled, the invocation of
`MethodWriter.visitMaxs` calls `ClassWriter.getMergetTypes`, which changes the value of
`ClassWriter.key2.intVal` (see [2])
A subsequent invocati...```
The fix for 317127 ([1]) is buggy. When COMPUTE_FRAMES is enabled, the invocation of
`MethodWriter.visitMaxs` calls `ClassWriter.getMergetTypes`, which changes the value of
`ClassWriter.key2.intVal` (see [2])
A subsequent invocation of `ClassWriter.visitInnerClass` calls `newClassItem`, which creates a `new
Item(index++, key2)` ([3]). The `intVal` is copied from `key2`, therefore non-zero. However, the new
implementation of `visitInnerClass` expects it to be zero.
It works if `visitInnerClass` is invoked before emitting any methods. Test showing the difference is
available here: [4].
javac -cp /path/to/asm-all-5.0.2.jar PositionsClassDump.java -d .
java -cp /path/to/asm-all-5.0.2.jar:. test.PositionsClassDump
[1] http://websvn.ow2.org/comp.php?repname=asm&compare[]=%2F@1725&compare[]=%2F@1726
[2] https://github.com/lrytz/asm/blob/master/src/org/objectweb/asm/ClassWriter.java#L1654
[3] https://github.com/lrytz/asm/blob/master/src/org/objectweb/asm/ClassWriter.java#L1114
[4] https://gist.github.com/lrytz/32ead88e0024553d5584
```https://gitlab.ow2.org/asm/asm/-/issues/317191NullPointerException when using incompletely initialized objects2017-12-26T10:08:41ZcarthoNullPointerException when using incompletely initialized objects```
There are many possible sequences through which a NullPointerException can be
generated, because most constructors do not initialize their data completely.
It is usually necessary to use a different constructor, or set data through
...```
There are many possible sequences through which a NullPointerException can be
generated, because most constructors do not initialize their data completely.
It is usually necessary to use a different constructor, or set data through
setters (in some cases). Given constructors are sometimes marked as not
suitable for subclasses but public otherwise. For example:
org.objectweb.asm.Label var2 = new org.objectweb.asm.Label();
new org.objectweb.asm.util.ASMifier().visitLineNumber(0, var2);
or
org.objectweb.asm.ClassWriter var2 = new org.objectweb.asm.ClassWriter(0);
new
org.objectweb.asm.tree.ClassNode().accept((org.objectweb.asm.ClassVisitor)var2);
We found a number of such cases using a modified Randoop. Some longer sequences
are perhaps more meaningful, perhaps not.
A fix would entail deprecating a constructor, making it non-public, or adding
information that it does not fully initialize all data. In some cases an
IllegalStateException, or a NullPointerException with a message "don't do that"
or similar would also clarify that this is the user's fault.
Is there an interest in modifying the code to reflect correct usage? If so, I
will try to isolate some test cases that are not overly complex.
```https://gitlab.ow2.org/asm/asm/-/issues/317195Method with 32 or 64 try finallys failes with asm2018-01-13T13:50:38ZztandresMethod with 32 or 64 try finallys failes with asm```
When I make a java class with a method with 32 or 64 (I didn't try 128) try {}
finally {} blocks ASM fails on Java 4 (jsr instructions).
The example program can be run with:
mvn clean package exec:java
For me the problem first appe...```
When I make a java class with a method with 32 or 64 (I didn't try 128) try {}
finally {} blocks ASM fails on Java 4 (jsr instructions).
The example program can be run with:
mvn clean package exec:java
For me the problem first appeared from a JSP compilation.
```https://gitlab.ow2.org/asm/asm/-/issues/317164ArrayOutOfBoundsException in ClassReader.readFrameType()2017-12-26T10:10:04ZlysergideArrayOutOfBoundsException in ClassReader.readFrameType()```
I am using a tool (jar2xml) that is built on top of ASM.
I am experiencing an ArrayOutOfBoundsException in this method -
ClassReader.readFrameType() when parsing a JAR using the tool (internally reads
all classes from jar using a ...```
I am using a tool (jar2xml) that is built on top of ASM.
I am experiencing an ArrayOutOfBoundsException in this method -
ClassReader.readFrameType() when parsing a JAR using the tool (internally reads
all classes from jar using a ClassReader).
I am using ASM latest available version (5.0.1).
the issue is that the following code:
int n = readUnsignedShort(stackMap); // line 2083
initializes the number of locals in the method, however somehow in this
scenario the number is 7, whereas the correct number is 6 (as seen by javap
output -- attached to this case).
1. How can i further diagnose this case?
2. Is this a bug in ASM? a faulty .class file?
Attaching the javap output + the .class file.
Also, here's the stack trace (right before the exception):
main@1, prio=5, in group 'main', status: 'RUNNING'
at org.objectweb.asm.ClassReader.readFrameType(ClassReader.java:2152)
at org.objectweb.asm.ClassReader.readFrame(ClassReader.java:2090)
at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1309)
at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
at jar2xml.JavaArchive.getPackages(JavaArchive.java:81)
at jar2xml.JavaArchive.getPackages(JavaArchive.java:62)
at jar2xml.Start.main(Start.java:122)
```https://gitlab.ow2.org/asm/asm/-/issues/317168CheckAnnotationAdapter.visit() should accept values of type Class and Enum2017-12-26T10:09:22Zarchie172CheckAnnotationAdapter.visit() should accept values of type Class and Enum```
I got this exception trying to run Cobertura 2.0.3:
java.lang.IllegalArgumentException: Invalid annotation value
at org.objectweb.asm.util.CheckAnnotationAdapter.visit(Unknown Source)
at org.objectweb.asm.ClassRe...```
I got this exception trying to run Cobertura 2.0.3:
java.lang.IllegalArgumentException: Invalid annotation value
at org.objectweb.asm.util.CheckAnnotationAdapter.visit(Unknown Source)
at org.objectweb.asm.ClassReader.a(Unknown Source)
at org.objectweb.asm.ClassReader.b(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
net.sourceforge.cobertura.instrument.CoberturaInstrumenter.instrumentClass(CoberturaInstrumenter.java:153)
at
net.sourceforge.cobertura.instrument.CoberturaInstrumenter.instrumentClass(CoberturaInstrumenter.java:121)
at
net.sourceforge.cobertura.instrument.CoberturaInstrumenter.addInstrumentationToSingleClass(CoberturaInstrumenter.java:234)
at
net.sourceforge.cobertura.instrument.Main.addInstrumentationToSingleClass(Main.java:298)
at
net.sourceforge.cobertura.instrument.Main.addInstrumentation(Main.java:307)
at net.sourceforge.cobertura.instrument.Main.parseArguments(Main.java:399)
at net.sourceforge.cobertura.instrument.Main.main(Main.java:421)
This was running on a normally compiled class - nothing fancy about it.
The corresponding code in CheckAnnotationAdapter looks suspicious:
public void visit(final String name, final Object value) {
checkEnd();
checkName(name);
if (!(value instanceof Byte || value instanceof Boolean
|| value instanceof Character || value instanceof Short
|| value instanceof Integer || value instanceof Long
|| value instanceof Float || value instanceof Double
|| value instanceof String || value instanceof Type
|| value instanceof byte[] || value instanceof boolean[]
|| value instanceof char[] || value instanceof short[]
|| value instanceof int[] || value instanceof long[]
|| value instanceof float[] || value instanceof double[]))
{
throw new IllegalArgumentException("Invalid annotation value");
}
Shouldn't this code also allow values of type Enum and Class?
```https://gitlab.ow2.org/asm/asm/-/issues/317163MethodNode#getLabelNode could return empty node now2017-12-26T10:10:21ZakozlovaMethodNode#getLabelNode could return empty node now```
org.objectweb.asm.tree.MethodNode#getLabelNode
changed from
protected LabelNode getLabelNode(final Label l) {
if (!(l.info instanceof LabelNode)) {
l.info = new LabelNode(l);
}
return (LabelNode) l.info;
}
to
protected...```
org.objectweb.asm.tree.MethodNode#getLabelNode
changed from
protected LabelNode getLabelNode(final Label l) {
if (!(l.info instanceof LabelNode)) {
l.info = new LabelNode(l);
}
return (LabelNode) l.info;
}
to
protected LabelNode getLabelNode(final Label l) {
if (!(l.info instanceof LabelNode)) {
l.info = new LabelNode(); //please note that l is not passed the node anymore
}
return (LabelNode) l.info;
}
For us this means that we see new labels in MethodVisitor#visitEnd instead of
old ones.
```https://gitlab.ow2.org/asm/asm/-/issues/317166Is the exported package list complete in the 5.0.1 release jar?2017-12-26T10:09:45ZmrennieIs the exported package list complete in the 5.0.1 release jar?```
In 5.0.1 ASM provided some OSGi headers in their release jar
(http://forge.ow2.org/project/shownotes.php?release_id=5424), but not all of the
API packages appear in there.
For example, in Eclipse Orbit we provide a bundled versio...```
In 5.0.1 ASM provided some OSGi headers in their release jar
(http://forge.ow2.org/project/shownotes.php?release_id=5424), but not all of the
API packages appear in there.
For example, in Eclipse Orbit we provide a bundled version of ASM that exports
all of the API packages listed below:
Export-Package: org.objectweb.asm;version="5.0.1",
org.objectweb.asm.commons;version="5.0.1",
org.objectweb.asm.signature;version="5.0.1",
org.objectweb.asm.tree;version="5.0.1",
org.objectweb.asm.tree.analysis;version="5.0.1",
org.objectweb.asm.util;version="5.0.1",
org.objectweb.asm.xml;version="5.0.1"
Is it intentional that you do not export all of the same ones?
This is causing a build problem for Red Hat that ends up making a jar that
cannot be directly consumed by Eclipse (while they are building Eclipse).
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431820
Or perhaps the addition of exported package headers is a mistake?
```https://gitlab.ow2.org/asm/asm/-/issues/317135Textifier prints bridge methods to be volatile2017-12-26T10:11:25ZraphwTextifier prints bridge methods to be volatile```
The bit masks for volatile are identical:
VOLATILE = 0x00000040;
BRIDGE = 0x00000040;
and the ASM textifier cannot distinguish between the two and prints methods
therefore to be both a bridge and a volatile method where the latter ...```
The bit masks for volatile are identical:
VOLATILE = 0x00000040;
BRIDGE = 0x00000040;
and the ASM textifier cannot distinguish between the two and prints methods
therefore to be both a bridge and a volatile method where the latter does not
make sense for methods.
```https://gitlab.ow2.org/asm/asm/-/issues/317151fix for 316545 is incorrect2017-12-26T10:10:41Ztkrodrigfix for 316545 is incorrect```
The fix for 316545 corrected Object[] meeting byte[][] but broke byte[] meeting byte[][]. I've attached a
test case based on the testcase from 316545. The problem is that if the dimensionailty is 1 then you
have to go to Object i...```
The fix for 316545 corrected Object[] meeting byte[][] but broke byte[] meeting byte[][]. I've attached a
test case based on the testcase from 316545. The problem is that if the dimensionailty is 1 then you
have to go to Object instead of Object[]. A possible fix looks like this:
Index: Frame.java
=================================================================
==
--- Frame.java (revision 1736)
+++ Frame.java (working copy)
@@ -1435,8 +1435,12 @@
// and t have different array dimensions
int tdim = t & DIM;
int udim = u & DIM;
- v = (udim != tdim ? Math.min(tdim, udim) : 0) | OBJECT
+ if (((u & BASE_KIND) == OBJECT || udim > 0x10000000) && ((t & BASE_KIND) == OBJECT ||
tdim > 0x10000000)) {
+ v = (udim != tdim ? Math.min(tdim, udim) : 0) | OBJECT
| cw.addType("java/lang/Object");
+ } else {
+ v = OBJECT | cw.addType("java/lang/Object");
+ }
} else {
// if t is any other type, merge(u,t)=TOP
v = TOP;
```https://gitlab.ow2.org/asm/asm/-/issues/317136ASMifier 5.0.1 output references package org.objectweb.asm.attrs2017-12-26T10:10:56ZctrimbleASMifier 5.0.1 output references package org.objectweb.asm.attrs```
The output of ASMifier imports the package org.objectweb.asm.attrs, but this package has been removed
in ASM 5.0.
``````
The output of ASMifier imports the package org.objectweb.asm.attrs, but this package has been removed
in ASM 5.0.
```