Open serkan-ozal opened 5 years ago
Hi,
I cannot investigate this problem without the class file (or disassembled dump) for
ozal.serkan.javassist.issue.report.Runner$run$result$1
Hi @chibash ,
I have added all the class files which you can find here: https://github.com/serkan-ozal/javassist-issue-report/tree/master/target/classes/ozal/serkan/javassist/issue/report
By the way, Javassist version is 3.25.0-GA
Can you insert ctClass.debugWriteFile('./debug')
before Line 35
Class clazz = ctClass.toClass();
and upload the generated file under ./debug
?
The generated file is the bytecode after the instrumentation.
You may have to create ./debug
before running the code.
It seems that the Kotlin compiler generates somewhat nasty bytecode; it pushes an unused value onto the stack. This seems to confuse Javassist. Fixing it will take time...
Hi @chibash Is there any ETA for the fix?
Hi @chibash , Any update on this issue?
I'm working...
Can you try master:HEAD? I've added insertAfter(String,boolean,boolean)
.
You must replace insertAfter(String)
with insertAfter(soruce_code,false,true)
.
The third argument true
should generate the byte code compatible with Kotlin's.
The second argument false
specifies the code does not work as a finally clause.
This has nothing to do with your bug.
Hi @chibash ,
JvstTest5.testRedundantInsertAfter
fails on my local with JDK 11.0.3.
testRedundantInsertAfter(javassist.JvstTest5) Time elapsed: 0.008 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<93>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at javassist.JvstTest5.testRedundantInsertAfter(JvstTest5.java:559)
@chibash By the way, issue seems to be fixed with your latest commit but as I said the JvstTest5.testRedundantInsertAfter
fails as mentioned above
@chibash
Additionally, isn't it better to check whether or not the target class is Kotlin class on Javassist side?
I think, the code snipped shown above can be used in the insertAfter
method internally (without requiring 3rd argument for specifying generating the byte code compatible with Kotlin) to decide whether or not it is Kotlin class for injecting redundany byte code.
static boolean isKotlinClass(CtClass clazz) {
return clazz.hasAnnotation("kotlin.Metadata");
}
Checking kotlin.Metadata seems a good idea. Can you give us a link to the official document (or so) about that annotation?
@chibash Here it is: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-metadata/index.html
Same approach is also used by Spring framework: https://github.com/spring-projects/spring-framework/pull/1060/files#diff-244315b45582a5b7573a15644b16c373R48
@chibash I have sent this one: https://github.com/jboss-javassist/javassist/pull/276
@chibash By the way, as I said JvstTest5.testRedundantInsertAfter
still fails on my local:
testRedundantInsertAfter(javassist.JvstTest5) Time elapsed: 0.008 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<93>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at javassist.JvstTest5.testRedundantInsertAfter(JvstTest5.java:559)
I made commit 855ca00 for #276. Please also see my comments for #276.
Thanks @chibash When you are going to release 3.26.0-GA
?
I plan to release it at the end of this month.
I've just released. It'll be available from maven within several days.
Hi @chibash ,
https://github.com/serkan-ozal/javassist-issue-report/blob/master/src/main/java/ozal/serkan/javassist/issue/report/RunnerInstrumentation.java reproduces the following issue:
The problem is that while instrumenting
ozal.serkan.javassist.issue.report.Runner$run$result$1
anonymous Kotlin class, the stackmap inconsistency raises.