Kotlin script unable to instantiate class - kotlin

Attempt at Kotlin Cookbook by Ken Kousen -- 1.5 Executing a Kotlin Script produces 'unable to instantiate class' error.
$ cat southpole.kts
import java.time.*
val instant = Instant.now()
val southPole = instant.atZone(ZoneId.of("Antarctica/South_Pole"))
val dst = southPole.zone.rules.isDaylightSavings(instant)
println("It is ${southPole.toLocalTime()} (UTC${southPole.offset}) at the South Pole")
println("The South Pole ${if (dst) "is" else "is not"} on Daylight Savings Time")
$ kotlinc -script southpole.kts
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
error: unable to instantiate class Southpole (southpole.kts): java.lang.NoClassDefFoundError: kotlin/script/templates/standard/ScriptTemplateWithArgs
kotlin version 1.3.50

In order to work, println(...) needs a kotlin runtime which has to be added manually.
This issue is described here https://discuss.kotlinlang.org/t/possible-kts-bug/10162
..., it (script) takes dependencies from the module, so you need to include kotlin-script-runtime to the module dependencies explicitly.
(...) Unfortunately, it is not very obvious. We’re thinking about possible solutions.
This seems to be improved in the upcoming Kotlin 1.3.60 release
https://youtrack.jetbrains.com/issue/KT-33529
As as a work-around, use:
$ sdk use kotlin 1.3.41

Related

Jacoco Test Coverage Verification not getting executed

I am trying to add test coverage verification in my kotlin gradle project. I added a super high minimum value (0.99) to fail my build but this task is not getting executed.
tasks.jacocoTestCoverageVerification {
violationRules {
rule {
limit {
minimum = "0.99".toBigDecimal()
}
}
}
}
The test coverage report is generated successfully from the coverageReport task (details not in the post)
tasks.withType<Test> {
finalizedBy(coverageReport) // report is always generated after tests run
}
According to jacoco violation rules official documentation
Any violation of the declared rules would automatically result in a failed build when executing the check task.
So I am under the assumption that the test coverage verification should be auto triggered?
So I expected that the jacocoTestCoverageVerification would execute without I having to call it. I also added the following to the jacocoTestCoverageVerification task but still doesn't fail so not writing all the rules is not a likely issue.
rule {
isEnabled = true
element = "CLASS"
includes = listOf("org.gradle.*")
limit {
counter = "LINE"
value = "TOTALCOUNT"
maximum = "0.99".toBigDecimal()
}
}
I also tried :
tasks.jacocoTestCoverageVerification {
violationRules {
rule {
classDirectories.setFrom(sourceSets.main.get().output.asFileTree.matching {
})
isEnabled = true
limit {
minimum = "0.99".toBigDecimal()
}
}
}
}
Can anyone please help me catch what I am missing?
EDIT:
Gradle version
bin/gradle --version
------------------------------------------------------------
Gradle 7.6
------------------------------------------------------------
Kotlin: 1.7.10
Groovy: 3.0.13
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 17.0.5 (Eclipse Adoptium 17.0.5+8)
OS: Mac OS X 13.2 aarch64
The gradle build command:
bin/gradle build
Build logs
Execution optimizations have been disabled for task ':codeCoverageReport' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: '/Users/Development/myrepo/build/reports/jacoco/codeCoverageReport/codeCoverageReport.xml'. Reason: Task ':validateDependenciesKtFile' uses this output of task ':codeCoverageReport' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
- Gradle detected a problem with the following location: '/Users/Development/myrepo/build/reports/jacoco/codeCoverageReport/html'. Reason: Task ':validateDependenciesKtFile' uses this output of task ':codeCoverageReport' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
These indicate that the optimizations are disabled so doesnt seem like a red flag?

Upgrade to Java 17 throws java.lang.RuntimeException: Error creating extended parser class: Could not determine whether class has already been loaded

I am using jtwig lib and the code was working fine but when we upgraded to Java 17, I am getting the below mention runtime exception.
Below is the method and throws RuntimeException while calling template.render()
String renderDescription(String templatePath,String userId, String caseId) {
JtwigTemplate template =
JtwigTemplate.classpathTemplate(templatePath);
JtwigModel model = JtwigModel.newModel()
.with("userId", userId)
.with("caseId", caseId)
.with("statusPageUrlTemplate",
config.getStatusPageUrlTemplate());
return template.render(model);
}
java.lang.RuntimeException: Error creating extended parser class: Could not determine whether class 'org.jtwig.parser.parboiled.base.BooleanParser$$parboiled' has already been loaded
at org.parboiled.Parboiled.createParser(Parboiled.java:58)
at org.jtwig.parser.parboiled.ParserContext.instance(ParserContext.java:31)
at org.jtwig.parser.parboiled.ParboiledJtwigParser.parse(ParboiledJtwigParser.java:37)
at org.jtwig.parser.cache.InMemoryConcurrentPersistentTemplateCache.get(InMemoryConcurrentPersistentTemplateCache.java:39)
at org.jtwig.parser.CachedJtwigParser.parse(CachedJtwigParser.java:19)
at org.jtwig.JtwigTemplate.render(JtwigTemplate.java:98)
at org.jtwig.JtwigTemplate.render(JtwigTemplate.java:74)
I was facing a similar issue after upgrading JVM version, and I found that adding this environment variable helped:
JDK_JAVA_OPTIONS=--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED
I believe it has something to do with stricter default limits on reflection when trying to inspect built-in classes.

Kotlin 1.4.20 gradle kts issue in IntelliJ

I am facing constant issues with my build.gradle.kts where the whole thing is basically red since I migrated to kotlin 1.4.20. Also, the gradle version is 6.7.1.
Any one face similar issues or is it just me? any workarounds?
when run through the cli, the build works perfectly fine but in IntelliJ, the whole thing is red
Exception in IntelliJ
java.lang.IllegalArgumentException: declarationDescriptor is null for constructor = TypeVariable(K) with class org.jetbrains.kotlin.resolve.calls.inference.model.TypeVariableTypeConstructor
at org.jetbrains.kotlin.js.descriptorUtils.DescriptorUtilsKt.getJetTypeFqName(descriptorUtils.kt:23)
at org.jetbrains.kotlin.js.descriptorUtils.DescriptorUtilsKt$getJetTypeFqName$typeArgumentsAsString$joinedTypeArguments$1.fun(descriptorUtils.kt:32)
at org.jetbrains.kotlin.js.descriptorUtils.DescriptorUtilsKt$getJetTypeFqName$typeArgumentsAsString$joinedTypeArguments$1.fun(descriptorUtils.kt)
at com.intellij.openapi.util.text.StringUtil.join(StringUtil.java:1337)
at com.intellij.openapi.util.text.StringUtil.join(StringUtil.java:1327)
at com.intellij.openapi.util.text.StringUtil.join(StringUtil.java:1307)
at org.jetbrains.kotlin.js.descriptorUtils.DescriptorUtilsKt.getJetTypeFqName(descriptorUtils.kt:32)
at org.jetbrains.hdfsplugin.highlight.kotlin.KotlinSignatureCondition.getReturnTypeFqn(KotlinSignatureCondition.kt:18)
at org.jetbrains.hdfsplugin.highlight.kotlin.KotlinSignatureCondition.getReturnTypeFqn(KotlinSignatureCondition.kt:8)
at org.jetbrains.hdfsplugin.highlight.SignatureCondition.checkCondition(SignatureCondition.kt:7)
at org.jetbrains.hdfsplugin.highlight.inspection.invalidFormat.InvalidFormatInspection.visitCall(InvalidFormatInspection.kt:13)
at org.jetbrains.hdfsplugin.highlight.inspection.invalidFormat.KotlinHdfsInvalidFormatInspection$buildVisitor$1.visitCallExpression(KotlinHdfsInvalidFormatInspection.kt:15)
at org.jetbrains.kotlin.psi.KtVisitorVoid.visitCallExpression(KtVisitorVoid.java:803)
at org.jetbrains.kotlin.psi.KtVisitorVoid.visitCallExpression(KtVisitorVoid.java:21)
at org.jetbrains.kotlin.psi.KtCallExpression.accept(KtCallExpression.java:35)
at org.jetbrains.kotlin.psi.KtElementImpl.accept(KtElementImpl.java:51)
at com.intellij.codeInspection.InspectionEngine.acceptElements(InspectionEngine.java:65)
at com.intellij.codeInspection.InspectionEngine.createVisitorAndAcceptElements(InspectionEngine.java:56)
at com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.runToolOnElements(LocalInspectionsPass.java:296)
at com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.lambda$visitPriorityElementsAndInit$3(LocalInspectionsPass.java:265)
at com.intellij.util.AstLoadingFilter.forceAllowTreeLoading(AstLoadingFilter.java:155)
at com.intellij.util.AstLoadingFilter.forceAllowTreeLoading(AstLoadingFilter.java:147)
at com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.lambda$visitPriorityElementsAndInit$4(LocalInspectionsPass.java:264)
at com.intellij.util.AstLoadingFilter.disallowTreeLoading(AstLoadingFilter.java:126)
at com.intellij.util.AstLoadingFilter.disallowTreeLoading(AstLoadingFilter.java:115)
at com.intellij.codeInsight.daemon.impl.LocalInspectionsPass.lambda$visitPriorityElementsAndInit$5(LocalInspectionsPass.java:264)
at com.intellij.concurrency.ApplierCompleter.execAndForkSubTasks(ApplierCompleter.java:149)
at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1110)
at com.intellij.concurrency.ApplierCompleter.lambda$wrapInReadActionAndIndicator$1(ApplierCompleter.java:105)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:629)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:581)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
at com.intellij.concurrency.ApplierCompleter.wrapInReadActionAndIndicator(ApplierCompleter.java:117)
at com.intellij.concurrency.ApplierCompleter.lambda$compute$0(ApplierCompleter.java:96)
at com.intellij.openapi.application.impl.ReadMostlyRWLock.executeByImpatientReader(ReadMostlyRWLock.java:170)
at com.intellij.openapi.application.impl.ApplicationImpl.executeByImpatientReader(ApplicationImpl.java:182)
at com.intellij.concurrency.ApplierCompleter.compute(ApplierCompleter.java:96)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:
Try to delete IDEA cache folder:
~/Library/Caches/JetBrains/<product><version> on macOS
~/.cache/JetBrains/<product><version> on Linux
%LOCALAPPDATA%\JetBrains\<product><version> on Windows
If it doesn't help, please file an issue in Youtrack.

UnsupportedOperationException when using enum in Java 11, works fine in Java 8

I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom.
I have ASM7 as a dependency in Maven.
Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
I see that in the class org.drools.core.util.asm.ClassFieldInspector, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
ClassFieldVisitor(final Class< ? > cls,
final boolean includeFinalMethods,
final ClassFieldInspector inspector) {
super(Opcodes.ASM5);
this.clazz = cls;
this.includeFinalMethods = includeFinalMethods;
this.inspector = inspector;
}
Disclaimer: I'm one of the Drools developers
That's interesting as we might not emit valid ASM code.
Please file a bug on https://issues.redhat.com so that we can fix it
Thank you very much

Puzzling problem with latest Groovy stable release

I just started a new Gradle project. In my previous build.gradles I had been putting this:
compile 'org.codehaus.groovy:groovy-all:2.4.15'
testCompile 'org.spockframework:spock-core:1.1-groovy-2.4'
... and also these dependencies:
testCompile 'net.bytebuddy:byte-buddy:1.6.11'
testCompile 'org.objenesis:objenesis:2.6'
By a process of trial and error I had found that Groovy 2.4.15 with these Bytebuddy and Objensis dependencies enabled me to mock BufferedReader. This proved useful in a console application where I wanted to mock user input to the console. The "console handler" class thus has the following field/property:
def br = new BufferedReader( new InputStreamReader(System.in, 'UTF-8' ))
used as follows in the app class to get user console input:
String response = br.readLine().trim()
... meaning that Spock tests can do this sort of thing:
def 'prompt should show help on entering H'() {
given:
consoleHandler.br = Mock( BufferedReader )
consoleHandler.br.readLine() >> 'h'
i.e. simulate the entry of the letter h at the console.
... but it doesn't work with Groovy 2.5.3 and its matching Spock dependency: for this new project I put:
compile 'org.codehaus.groovy:groovy-all:2.5.3'
testCompile 'org.spockframework:spock-core:1.2-groovy-2.5'
... with the same ByteBuddy and Objenisis dependencies. I get the following test failure:
java.lang.IllegalArgumentException: Could not create type at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:140) at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:346)
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:161) at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:355)
at
org.spockframework.mock.runtime.ByteBuddyMockFactory.createMock(ByteBuddyMockFactory.java:41)
at
org.spockframework.mock.runtime.ProxyBasedMockFactory.create(ProxyBasedMockFactory.java:42)
at
org.spockframework.mock.runtime.JavaMockFactory.createInternal(JavaMockFactory.java:58)
at
org.spockframework.mock.runtime.JavaMockFactory.create(JavaMockFactory.java:38)
at
org.spockframework.mock.runtime.CompositeMockFactory.create(CompositeMockFactory.java:42)
at
org.spockframework.lang.SpecInternals.createMock(SpecInternals.java:46)
at
org.spockframework.lang.SpecInternals.createMockImpl(SpecInternals.java:294)
at
org.spockframework.lang.SpecInternals.createMockImpl(SpecInternals.java:284)
at
org.spockframework.lang.SpecInternals.MockImpl(SpecInternals.java:100)
at core.FirstSpec.setup(first_tests.groovy:20)Caused by:
java.lang.NoSuchMethodError:
net.bytebuddy.dynamic.loading.ClassInjector$UsingLookup.isAvailable()Z
at
org.spockframework.mock.runtime.ByteBuddyMockFactory.determineBestClassLoadingStrategy(ByteBuddyMockFactory.java:103)
at
org.spockframework.mock.runtime.ByteBuddyMockFactory.access$300(ByteBuddyMockFactory.java:27)
at
org.spockframework.mock.runtime.ByteBuddyMockFactory$1.call(ByteBuddyMockFactory.java:54)
at
org.spockframework.mock.runtime.ByteBuddyMockFactory$1.call(ByteBuddyMockFactory.java:43)
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:138)
Any Groovy über-geeks out there?
You have to upgrade byte-buddy:
testCompile 'net.bytebuddy:byte-buddy:1.8.21'
Spock version 1.1-groovy-2.4 was depending on byte-buddy:1.6.5 - https://mvnrepository.com/artifact/org.spockframework/spock-core/1.1-groovy-2.4
Spock version 1.2-groovy-2.5 depends on byte-buddy:1.8.21 - https://mvnrepository.com/artifact/org.spockframework/spock-core/1.2-groovy-2.5