Why this:
val runVersionSplicer by tasks.registering(type = JavaExec::class) {
classpath = sourceSets.main.runtimeClasspath // error
main = "com.concurnas.build.VersionSplicer"
}
returns:
Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
public val NamedDomainObjectContainer.runtimeClasspath: NamedDomainObjectProvider defined in org.gradle.kotlin.dsl
While this works fine instead?
val runVersionSplicer by tasks.registering(type = JavaExec::class) {
classpath = sourceSets["main"].runtimeClasspath
main = "com.concurnas.build.VersionSplicer"
}
I know that sourceSets.main is so defined:
val org.gradle.api.tasks.SourceSetContainer.`main`: NamedDomainObjectProvider<org.gradle.api.tasks.SourceSet>
get() = named<org.gradle.api.tasks.SourceSet>("main")
However isn't supposed to replace the sourceSets["main"] construct?
Because one of them is a provider and the other is the object.
sourceSets.main uses NamedDomainObjectCollection.named under the hood as you found out. If you look at the javadoc for named, you see that it returns the following:
A Provider that will return the object when queried. The object may be created and configured at this point, if not already
sourceSets["main"] returns the source set directly, because it uses NamedDomainObjectCollection.getByName instead, whi:
The object with the given name. Never returns null.
So these two are equivalent:
sourceSets.main.get()
sourceSets["main"]
In Groovy the following are equivalent:
sourceSets.main
sourceSets["main"]
sourceSets.getAt("main")
Which are all different syntax of the getAt method implemented by the NamedDomainObjectCollection class. This is why you don't see a lot of get() in Groovy scripts but you see a lot more in Kotlin DSL scripts.
Related
Writing some querydsl code. In Java I would do like this:
#Test
void countTest() {
NumberPath<Long> cnt = Expressions.numberPath(Long.class, "count");
NumberPath<Long> typeId = Expressions.numberPath(Long.class, "type_id");
List<Long> fetched = sql.select(typeId)
.from(SQLExpressions.select(tGroup.typeId.as(typeId), tGroup.count().as(cnt))
.from(tGroup)
.groupBy(tGroup.typeId))
.where(cnt.gt(100L)).fetch();
System.out.println(fetched);
}
Notice this Long.class in Expressions.numberPath(Long.class, ...)
If I create a .kt file and copy-paste the above Java code, it will be converted by Intellij to:
Expressions.numberPath(Long::class.java, ...).
So the resulting Kotlin code I have is:
val cnt = Expressions.numberPath(Long::class.java, "count")
val typeId = Expressions.numberPath(Long::class.java, "type_id")
val fetched = sql.select(typeId)
.from(SQLExpressions.select(QTGroup.tGroup.typeId.`as`(typeId), QTGroup.tGroup.count().`as`(cnt))
.from(QTGroup.tGroup)
.groupBy(QTGroup.tGroup.typeId))
.where(cnt.gt(100L)).fetch()
println(fetched)
Now when I run the code, I get:
java.lang.IllegalArgumentException: Unsupported target type : long
at com.querydsl.core.util.MathUtils.cast(MathUtils.java:86)
at com.querydsl.core.types.dsl.NumberExpression.cast(NumberExpression.java:178)
at com.querydsl.core.types.dsl.NumberExpression.gt(NumberExpression.java:337)
at project.dao.QuerydslKotlinCountTest.countTest(QuerydslKotlinCountTest.kt:30)
So it's not a Class<java.lang.Long> which I would expect, but some class Class<long> (never seen this before and can not get it programmatically with Class.forName("long")).
So, how do I make this simple piece of code work in Kotlin?
If I replace Long::class.java with java.lang.Long::class.java, the code does not compile:
Error:(27, 104) Kotlin: None of the following functions can be called with the arguments supplied:
public open fun `as`(p0: Path<Long!>!): NumberExpression<Long!>! defined in com.querydsl.core.types.dsl.NumberExpression
public open fun `as`(p0: String!): NumberExpression<Long!>! defined in com.querydsl.core.types.dsl.NumberExpression
The only way I made it work is using a boxed java primitive: java.lang.Long.valueOf(1).javaClass, but it looks ugly.
Try using KClass's javaObjectType property instead of java, e.g.:
1L::class.java // returns long
1L::class.javaObjectType // returns java.lang.Long
From its documentation:
[...] In case of primitive types it returns corresponding wrapper classes.
I have this code snippet in Java (this is an MCVE; actual code is more complex but has exact same issue):
enum StatusEnum { A, B, C; }
[...]
final static Set<String> names = Arrays.asList(StatusEnum.values())
.stream().map(StatusEnum::name).collect(Collectors.toSet());
IntelliJ gave me the following automated conversion to Kotlin:
internal val names = Arrays.asList(*StatusEnum.values())
.stream().map<String>(Function<StatusEnum, String> { it.name })
.collect<Set<String>, Any>(Collectors.toSet())
This unfortunately has compile errors:
Interface Function does not have constructors
Type inference failed. Expected type mismatch: inferred type is Collector!>! but Collector!>! was expected
Unresolved reference: it
This is my very first attempt at converting some code to Kotlin. I have reviewed the Functions and Lambdas section of the documentation. Still not clear what's going on here or how to fix it.
Use Kotlin methods instead of Java streams:
val names = StatusEnum.values()
.map { it.name }
.toSet()
I am trying to understand concept of inline classes - they are a simple object wrapper of single property that is being inlined during runtime.
That means, that the actual initialization of the class is not happening at runtime
I was trying to write simple test which directly will show my above explanation during JUnit test as below:
companion object {
private const val NAME = "JACK"
}
inline class NameInlineClass(val value: String)
#Test
fun unwrapping() {
val nameInlineClass = NameInlineClass(NAME)
val name = nameInlineClass
assertEquals(name, NAME)
}
This test fails unfortunately which leads me to the question why during assertEquals() the actual unwrapped String value is not being compared, but the actual inline class (which should be unwrapped during runtime)?
What you probably wanted to do was val name = nameInlineClass.value, but I'll try to explain the error.
See Representation from docs (includes code sample):
In generated code, the Kotlin compiler keeps a wrapper for each inline
class. Inline class instances can be represented at runtime either as
wrappers or as the underlying type. This is similar to how Int can be
represented either as a primitive int or as the wrapper Integer.
That means as long as you don't reference the wrapping object or its type explicitly, value will not be boxed. We can check it by inspecting bytecode (decompiled back to Java for readability):
// kotlin source
fun unwrapping() {
val nameInlineClass = NameInlineClass(NAME)
val name = nameInlineClass // this line gets dropped by compiler by the way
assertEquals(name, NAME)
}
// java representation of bytecode
public final void unwrapping() {
String nameInlineClass = NameInlineClass.constructor-impl("JACK");
Assert.assertEquals(NameInlineClass.box-impl(nameInlineClass), "JACK");
}
I won't paste entire generated NameInlineClass body, but constructor-impl is static method that only checks for null of value, and box-impl creates the wrapper object.
You can see nameInlineClass is indeed a String - that means inline works and no extra object was allocated.
Only when you reference nameInlineClass instead of nameInlineClass.value compiler determines that this object needs representation and "boxes" the value with wrapper NameInlineClass class.
We know the lambda body is lazily well, because if we don't call the lambda the code in the lambda body is never be called.
We also know in any function language that a variable can be used in a function/lambda even if it is not initialized, such as javascript, ruby, groovy and .etc, for example, the groovy code below can works fine:
def foo
def lambda = { foo }
foo = "bar"
println(lambda())
// ^--- return "bar"
We also know we can access an uninitialized variable if the catch-block has initialized the variable when an Exception is raised in try-block in Java, for example:
// v--- m is not initialized yet
int m;
try{ throw new RuntimeException(); } catch(Exception ex){ m = 2;}
System.out.println(m);// println 2
If the lambda is lazily, why does Kotlin can't use an uninitialized variable in lambda? I know Kotlin is a null-safety language, so the compiler will analyzing the code from top to bottom include the lambda body to make sure the variable is initialized. so the lambda body is not "lazily" at compile-time. for example:
var a:Int
val lambda = { a }// lambda is never be invoked
// ^--- a compile error thrown: variable is not initialized yet
a = 2
Q: But why the code below also can't be working? I don't understand it, since the variable is effectively-final in Java, if you want to change the variable value you must using an ObjectRef instead, and this test contradicts my previous conclusions:"lambda body is not lazily at compile-time" .for example:
var a:Int
run{ a = 2 }// a is initialized & inlined to callsite function
// v--- a compile error thrown: variable is not initialized yet
println(a)
So I only can think is that the compiler can't sure the element field in ObjectRef is whether initialized or not, but #hotkey has denied my thoughts. Why?
Q: why does Kotlin inline functions can't works fine even if I initializing the variable in catch-block like as in java? for example:
var a: Int
try {
run { a = 2 }
} catch(ex: Throwable) {
a = 3
}
// v--- Error: `a` is not initialized
println(a)
But, #hotkey has already mentioned that you should using try-catch expression in Kotlin to initializing a variable in his answer, for example:
var a: Int = try {
run { 2 }
} catch(ex: Throwable) {
3
}
// v--- println 2
println(a);
Q: If the actual thing is that, why I don't call the run directly? for example:
val a = run{2};
println(a);//println 2
However the code above can works fine in java, for example:
int a;
try {
a = 2;
} catch (Throwable ex) {
a = 3;
}
System.out.println(a); // println 2
Q: But why the code below also can't be working?
Because code can change. At the point where the lambda is defined the variable is not initialized so if the code is changed and the lambda is invoked directly afterwards it would be invalid. The kotlin compiler wants to make sure there is absolutely no way the uninitialized variable can be accessed before it is initialized, even by proxy.
Q: why does Kotlin inline functions can't works fine even if I initializing the variable in catch-block like as in java?
Because run is not special and the compiler can't know when the body is executed. If you consider the possibility of run not being executed then the compiler cannot guarentee that the variable will be initialized.
In the changed example it uses the try-catch expression to essentially execute a = run { 2 }, which is different from run { a = 2 } because a result is guaranteed by the return type.
Q: If the actual thing is that, why I doesn't call the run directly?
That is essentially what happens. Regarding the final Java code the fact is that Java does not follow the exact same rules of Kotlin and the same happens in reverse. Just because something is possible in Java does not mean it will be valid Kotlin.
You could make the variable lazy with the following...
val a: Int by lazy { 3 }
Obviously, you could use a function in place of the 3. But this allows the compiler to continue and guarantees that a is initialized before use.
Edit
Though the question seems to be "why can't it be done". I am in the same mind frame, that I don't see why not (within reason). I think the compiler has enough information to figure out that a lambda declaration is not a reference to any of the closure variables. So, I think it could show a different error when the lambda is used and the variables it references have not been initialized.
That said, here is what I would do if the compiler writers were to disagree with my assessment (or take too long to get around to the feature).
The following example shows a way to do a lazy local variable initialization (for version 1.1 and later)
import kotlin.reflect.*
//...
var a:Int by object {
private var backing : Int? = null
operator fun getValue(thisRef: Any?, property: KProperty<*>): Int =
backing ?: throw Exception("variable has not been initialized")
operator fun setValue(thisRef: Any?, property: KProperty<*>, value: Int) {
backing = value
}
}
var lambda = { a }
// ...
a = 3
println("a = ${lambda()}")
I used an anonymous object to show the guts of what's going on (and because lazy caused a compiler error). The object could be turned into function like lazy.
Now we are potentially back to a runtime exception if the programmer forgets to initialize the variable before it is referenced. But Kotlin did try at least to help us avoid that.
I have a Kotlin data class that I am constructing with many immutable properties, which are being fetched from separate SQL queries. If I want to construct the data class using the builder pattern, how do I do this without making those properties mutable?
For example, instead of constructing via
var data = MyData(val1, val2, val3)
I want to use
builder.someVal(val1)
// compute val2
builder.someOtherVal(val2)
// ...
var data = builder.build()
while still using Kotlin's data class feature and immutable properties.
I agree with the data copy block in Grzegorz answer, but it's essentially the same syntax as creating data classes with constructors. If you want to use that method and keep everything legible, you'll likely be computing everything beforehand and passing the values all together in the end.
To have something more like a builder, you may consider the following:
Let's say your data class is
data class Data(val text: String, val number: Int, val time: Long)
You can create a mutable builder version like so, with a build method to create the data class:
class Builder {
var text = "hello"
var number = 2
var time = System.currentTimeMillis()
internal fun build()
= Data(text, number, time)
}
Along with a builder method like so:
fun createData(action: Builder.() -> Unit): Data {
val builder = Builder()
builder.action()
return builder.build()
}
Action is a function from which you can modify the values directly, and createData will build it into a data class for you directly afterwards.
This way, you can create a data class with:
val data: Data = createData {
//execute stuff here
text = "new text"
//calculate number
number = -1
//calculate time
time = 222L
}
There are no setter methods per say, but you can directly assign the mutable variables with your new values and call other methods within the builder.
You can also make use of kotlin's get and set by specifying your own functions for each variable so it can do more than set the field.
There's also no need for returning the current builder class, as you always have access to its variables.
Addition note: If you care, createData can be shortened to this:
fun createData(action: Builder.() -> Unit): Data = with(Builder()) { action(); build() }.
"With a new builder, apply our action and build"
I don't think Kotlin has native builders. You can always compute all values and create the object at the end.
If you still want to use a builder you will have to implement it by yourself. Check this question
There is no need for creating custom builders in Kotlin - in order to achieve builder-like semantics, you can leverage copy method - it's perfect for situations where you want to get object's copy with a small alteration.
data class MyData(val val1: String? = null, val val2: String? = null, val val3: String? = null)
val temp = MyData()
.copy(val1 = "1")
.copy(val2 = "2")
.copy(val3 = "3")
Or:
val empty = MyData()
val with1 = empty.copy(val1 = "1")
val with2 = with1.copy(val2 = "2")
val with3 = with2.copy(val3 = "3")
Since you want everything to be immutable, copying must happen at every stage.
Also, it's fine to have mutable properties in the builder as long as the result produced by it is immutable.
It's possible to mechanize the creation of the builder classes with annotation processors.
I just created ephemient/builder-generator to demonstrate this.
Note that currently, kapt works fine for generated Java code, but there are some issues with generated Kotlin code (see KT-14070). For these purposes this isn't an issue, as long as the nullability annotations are copied through from the original Kotlin classes to the generated Java builders (so that Kotlin code using the generated Java code sees nullable/non-nullable types instead of just platform types).