I'm using IntelliJ IDEA 2022.1.3 on Mac 11.5.2 and trying to debug simple java method.
Each of the method steps including just declaration of variables is taking almost 10+ seconds to execute.
Normal execution is fine
You can easily reproduce this bug with simple addition of 2 numbers method as well.
I want to print some special characters(Latin, Greek alphabet, Chinese, etc) in Kotlin, but always got ??????? as the output:
>> println("Δ")
>> ??????
Also tried unicode:
>> println("\u0394")
>> ?
IDE I used: IntelliJ IDEA 2018.1.3.
Console I used: Kotlin REPL.
jdk: 9.0.4
Kotlin version: 1.2.31 (JRE 9.0.4+11)
How could I print the right string?
Update(20180512):
I also tried to install Kotlin via Homebrew and run kotlinc in my own terminal, it works as expected. It just doesn't work in Kotlin REPL of IntelliJ. Any place I can go to fix that?
Update(20180513):
Tried the followings:
Clear IntelliJ cache;
Reinstalled IntelliJ;
Make IntelliJ and Kotlin up to date;
Restart MacOS(10.12.6);
Update Java to 10.0.1.
Used println in Kotlin REPL again, ??? changed to the specific error:
println("Δ")
Internal error occurred. Please, send report to developers.
exception: java.nio.charset.MalformedInputException: Input length = 1
at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:281)
at kotlin.io.ConsoleKt.tryDecode(Console.kt:198)
at kotlin.io.ConsoleKt.readLine(Console.kt:162)
at kotlin.io.ConsoleKt.readLine(Console.kt:149)
at org.jetbrains.kotlin.cli.jvm.repl.reader.IdeReplCommandReader.readLine(IdeReplCommandReader.kt:22)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.one(ReplFromTerminal.kt:98)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.doRun(ReplFromTerminal.kt:69)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.access$doRun(ReplFromTerminal.kt:38)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal$Companion.run(ReplFromTerminal.kt:175)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:105)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:63)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:107)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:51)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:96)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:72)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:38)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit(CLITool.kt:171)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMain(CLITool.kt:162)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:329)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
Internal error occurred. Please, send report to developers.
Process finished with exit code 2
It seems the reading character encoding is different from writing encoding. But I can find no way to config the encoding of Kotlin REPL.
And also, I found 2 java processes running while I open Kotlin REPL and every time I have to kill one to run Kotlin REPL smoothly:
image: 2 java processes running
I'm not sure if they are related, so I attached the image as a reference. Already reported to IntelliJ developers, but it seems not a common bug for most people.
Try to run println("\u0394"). If that works, your file likely isn't in the UTF-8 encoding. If it doesn't, there's an issue with your terminal.
I'm in the process of learning Kotlin as an Android developer!
Out of curiosity, why didn't the JetBrains guys follow the Java style syntax (where they could have), and made it easier on developers to learn Kotlin?
For example, defining a simple function in Kotlin:
fun simpleFunc(x: Int): Int {
// do stuff
}
Why didn't they do:
fun Int simpleFunc(Int x) {
// do stuff
}
I would appreciate hearing your opinion on this
As mentioned in the Kotlin FAQ, Kotlin's syntax makes it more natural to omit type declarations when they can be inferred by the compiler (which isn't supported by Java). Also, from our experience with Kotlin, we see no evidence that Kotlin's type declaration syntax presents a difficulty for people learning Kotlin.
(Note that your suggested syntax is also different from Java, so it's not clear why you think it would be easier to learn.)
Java is like a coffee, and Kotlin means that coffee with a little bit sugar in there. In some cases, Kotlin does increase the efficiency and make the programming more enjoyable.
Comparing with Java, Kotlin is more effective and actually can work with Java pretty well.
Check the example in that picture here about Safe Calls on the official kotlinlang.org,
In Chains, when there's a null value,you need to use if function to determine whether the value is null,but there's only one sentence method needed for Kotlin.
Plus, when you are using Gradle daemon and Smart Compilation,Kotlin shows a faster compile speed than Java.
the horizontal axis means ten consecutive incremental builds with one core file changed.
You can see that the Gradle daemon still takes two or three runs to warm up, but after that the performance of both languages is very similar. With no changes, Java takes 4.6 seconds per warm build, while Kotlin averages 4.5 seconds. When we change a file that isn’t used by any other files, Java requires an average of 7.0 seconds to do a warm build, and Kotlin clocks in at 6.1. And finally, when we change a file that is imported by many other files in the project, Java requires 7.1 seconds to do an incremental build once the Gradle daemon is warmed up, while Kotlin averages 6.0 seconds.
Citations: 1. https://kotlinlang.org/docs/reference/null-safety.html
https://medium.com/#johnkorly/kotlin-vs-java-performance-drill-down-which-to-choose-2514bdf91916
The kotlin team describes here why the type declarations (like in your example) are on the right:
Why have type declarations on the right?
We believe it makes the code more readable. Besides, it enables some nice syntactic features. For instance, it is easy to leave type annotations out. Scala has also proven pretty well this is not a problem.
Using IntelliJ under Windows/Linux and Mac (13- 14 and 14.1) every time I launch the Main it takes a very long time (> 20 seconds) being completely idle before starting to compile or launch the program.
The same 1 minute block happens just editing the run configuration: it appears white for the exact period before showing the running/debug configuration.
This appear independend of the OS and the speed of the CPU/Disk I'm using, so I'm hoping it's just some "timeout" happening somewhere.
Unit tests which are doing something similar are taking a bit but not so much, and if I launch the same main from Eclipse it starts instantly.
Is there something I'm missing in configuration of IntelliJ / Run or in setup of IntelliJ to avoid this long block?
NOTE: The project has some multiple modules in it separating the spray routing in a module, the datamodel (mongodb) in another, data definition in a third one and having multiple sbt script, could it be possible that this time is related to some sbt activities or inconsistencies in dependencies?
SBT 0.13.1 and Scala 2.10.3.
We have implemented a plugin that sets the dependencyOverrides to standard artifact versions. My dependencyOverrides set is about 950 artifacts large. Not that we have all these dependencies but this is the standard versions people need to use.
After implementing the overrides, sbt update times (a reference project with 11 sub-projects) on Mac (Mac OS 10.7.5, Oracle JDK 1.7.0_45) jumped from ~30 seconds to ~140 seconds. The referenced artifacts are actually smaller as this gets rid of many duplicate artifacts of different versions.
I've run sbt under -Xprof to see what is the problem and found this major difference:
Before dependencyOverrides:
Compiled + native Method
3.2% 10 + 0 org.apache.ivy.core.module.id.ModuleRules.getRules
After dependencyOverrides:
Compiled + native Method
31.6% 136 + 2 org.apache.ivy.core.module.id.ModuleRules.getRules
Xprof doesn't give me invocation counts. But from a brief review of ModuleRules.getRules there seem to be not much complexity. That gives me a hint the invocation count may have skyrocketed. I'll have to use different profilers to get a better grip.
Unfortunately, Scala/SBT plugin for IntelliJ constantly causes a sbt resolve and the user experience is that much worse. I'd like to run this by others who may have run into this issue before or even know of a good way to fix it (short of diving into ivy code and figuring out the issue + modifying ivy code myself).
Thanks in advance for any input.