Kotlin functions marked with inline keyword are, well, inlined during the compilation and it seems that code coverage tools (like JaCoCo) fail to properly calculate code coverage. What is the usual approach to overcoming this issue? Is there a way to make the test somehow avoid the inlining step and invoke the tested methods directly? Is it possible to skip report generation of all inlined methods (via Gradle task, for example) without excluding whole classes?
I don't believe it is possible to turn off inlining since some functions may not make any sense if they are not inlined. These include functions with reified types (since the inlining creates the availability of type information) and functions with lambdas as parameters, since they can affect the control flow of the method they are inlined in.
There is the bug in the JetBrains Java Coverage tools, see https://youtrack.jetbrains.com/issue/KT-12605 .
So, just wait until bug will be fixed (or vote on it, to speedup development)
Kotlin team has introduced the Kover plugin with the goal of supporting all language constructs including inline functions.
Related
I use Python, but I don't know how it works in Kotlin. This is an example
example => exec("""print("hello")""") output => hello
exec("""print("hello")""") output => hello
Kotlin supports JSR-223. You can use the jvm scripting engine to eval kts files.
val engine = ScriptEngineManager().getEngineByExtension("kts")
engine.eval("""print("hello")""")
You need JSR-223 library dependency. Refer to example
implementation("org.jetbrains.kotlin:kotlin-scripting-jsr223:$kotlinVersion")
Short answer: this isn't practical in Kotlin.
Technically, there may be ways, but they're likely to be far more trouble than they're worth; you're far better looking for a different approach to your problem.
Unlike a dynamic (‘scripting’) language like Python, Kotlin is statically-compiled. In the case of Kotlin/JVM, you run the Kotlin compiler to generate .class files with Java bytecode, which is then run by a JVM.
So if you really need to convert a string into code and run it, you'd have to find a way to ensure that a Kotlin compiler is available on the platform where your code is running (which it often won't be; compiled bytecode can run on any platform with a JVM, and most of those won't have Kotlin installed too). You'd then have to find a way to run the compiler; this will probably mean writing your source code out to a file, starting up the compiler program as a separate process (as I don't think there's an API for calling it directly), and checking the results. Then you'd have find the resulting bytecode and load into the JVM, which will probably mean setting up a separate classloader instance.
All of which is likely to be slow, fragile, and very awkward.
(See these previous questions which cover some of the same ground.)
(The details will be different for Kotlin/JS and Kotlin/Native, but I think the principles are roughly the same.)
In general, each computer language has its own approach, its own mind-set and ways of doing things, and it's best to try to understand that and accept that patterns and techniques from one language don't always translate well into another. (In the Olden Days™, it used to be said that a determined programmer could write FORTRAN programs in any language — but only in satire.)
Perhaps if you could explain why you want to do this, and what sort of problem you're trying to solve (probably as a separate question), we might be able to suggest more natural solutions in Kotlin.
I have an errors.rs file with error_chain! {}, which exports Result, ResultExt, Error and ErrorKind.
If I use self::errors::*, IntelliJ thinks that I'm using the default Result (std::result::Result, I think). However, if I explicitly import the types using use self::errors::{Result, ...}, everything works out hunky dory.
I can tell because the standard result has two type params, but the error_chain one has only one.
In either case, it still compiles.
I'm using the standard Rust IntelliJ plugin, version 0.1.0.1991.
Help! Does anyone know how to get the plugin to understand what the macro is doing?
The IntelliJ-Rust plugin uses its own code parser. It allows to leverage all the IntelliJ platform capabilities (like code navigation, formatting, refactoring, inspections, quick documentation, markers and many others) but requires implementing all the language features, which is not a simple task for Rust (you can find a more in-depth discussion of the Rust compiler parser versus IDE parser in this reddit post).
Macros expansion is probably the biggest language feature that is not supported by the plugin parser at the moment. That is, the plugin sees this error_chain! call, can resolve it to its definition, but doesn't expand it to the actual code and hence doesn't know about the new Result struct that shadows the one from stdlib. Unfortunately, in some cases it leads to such false positive error messages.
I've converted this error annotation into an inspection, so in the next plugin version you'll be able to switch it off entirely or for the particular code block. The work on macros expansion is also in progress.
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.
Section 5.2 Testing in the Rust Book says
The [tests] module allows us to group all of our tests together, and to also define helper functions if needed, that don't become a part of the rest of our crate. The cfg attribute only compiles our test code if we're currently trying to run the tests. This can save compile time, and also ensures that our tests are entirely left out of a normal build.
I presume functions marked as #[test] do not appear in release builds, even if they appear in a module that does, right? I'd expect it's just test helper functions that might waste space. And they could be hidden individually with #[cfg(test)], right?
Yes, you can hide individual functions with #[cfg(test)], and #[test] functions will be stripped in non-test builds (note that one can test in release mode as well!). And yes, in a release build unused functions will be optimized away. However:
Adding a single #[cfg(test)] to a module is easier (and thus, is more likely to actually be done) than adding it on every single test.
The compile-time difference still applies. In release builds, when the unused functions are stripped, they have already been analyzed, type-checked, and optimized before they get removed. It's quicker to throw the function's source code away early in the compilation process.
Non-test debug builds matter, too --- and there, unused functions won't be removed.
is it possible to write an AspectJ pointcut that matches the usage of a specific operator with a specific type?
Some background information: I'm working on a project where we have to use a legacy Java library (pre 5.0, before the enum keyword) which comes with several "pseudo-enum" types, i.e. normal Java classes that define static constants of its own type. Those "feel" very much like enums, but using them like enums can result in an error. Therefore I'd like AspectJ to mark uses of == with objects of one of these types as an error, if that is possible. I have googled this and consulted the normally very helpful book AspectJ in action, but so far without success. Any help is appreciated.
== is not the same as equals(), and is implemented by the JVM, and as far as I can tell cannot be modified by aspectj. Also, I don't think that AspectJ is the correct tool for this job.
A better approach would be to implement a Checkstyle rule or similar for your project to allow you indicate these points. You could have them as errors or warnings. See Writing Checks for Checkstyle for more information.
This would require some coding, but so would the aspectJ solution.
Checkstyle has an eclipse plugin as well as a maven plugin, so you could have these errors appearing as you work in the IDE.