POJO class mismatch
up vote
0
down vote
favorite
I have the following class User that extends the BaseResponse
class. I
am getting a type mismatch error:
Required => String
Found => String.Companion
for return apiKey
package com.touchsides.rxjavanetworking.network.model
import com.google.gson.annotations.SerializedName
class User: BaseResponse()
{
@SerializedName("api_key")
val apiKey = String
fun getApiKey(): String
{
return apiKey
}
}
abstract class BaseResponse(var error: String?=null)
{
}
How is the current implementation of this wrong
kotlin
add a comment |
up vote
0
down vote
favorite
I have the following class User that extends the BaseResponse
class. I
am getting a type mismatch error:
Required => String
Found => String.Companion
for return apiKey
package com.touchsides.rxjavanetworking.network.model
import com.google.gson.annotations.SerializedName
class User: BaseResponse()
{
@SerializedName("api_key")
val apiKey = String
fun getApiKey(): String
{
return apiKey
}
}
abstract class BaseResponse(var error: String?=null)
{
}
How is the current implementation of this wrong
kotlin
Simple typoval apiKey = String
where you meantval apiKey: String
.
– weston
Nov 19 at 19:14
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have the following class User that extends the BaseResponse
class. I
am getting a type mismatch error:
Required => String
Found => String.Companion
for return apiKey
package com.touchsides.rxjavanetworking.network.model
import com.google.gson.annotations.SerializedName
class User: BaseResponse()
{
@SerializedName("api_key")
val apiKey = String
fun getApiKey(): String
{
return apiKey
}
}
abstract class BaseResponse(var error: String?=null)
{
}
How is the current implementation of this wrong
kotlin
I have the following class User that extends the BaseResponse
class. I
am getting a type mismatch error:
Required => String
Found => String.Companion
for return apiKey
package com.touchsides.rxjavanetworking.network.model
import com.google.gson.annotations.SerializedName
class User: BaseResponse()
{
@SerializedName("api_key")
val apiKey = String
fun getApiKey(): String
{
return apiKey
}
}
abstract class BaseResponse(var error: String?=null)
{
}
How is the current implementation of this wrong
kotlin
kotlin
edited Nov 19 at 15:08
Jayson Minard
36.3k15104170
36.3k15104170
asked Nov 19 at 11:56
George
378
378
Simple typoval apiKey = String
where you meantval apiKey: String
.
– weston
Nov 19 at 19:14
add a comment |
Simple typoval apiKey = String
where you meantval apiKey: String
.
– weston
Nov 19 at 19:14
Simple typo
val apiKey = String
where you meant val apiKey: String
.– weston
Nov 19 at 19:14
Simple typo
val apiKey = String
where you meant val apiKey: String
.– weston
Nov 19 at 19:14
add a comment |
3 Answers
3
active
oldest
votes
up vote
2
down vote
accepted
A complete answer is that your code should look like this:
class User: BaseResponse()
{
@SerializedName("api_key")
lateinit var apiKey: String // must be set by something before being read
}
abstract class BaseResponse(var error: String?=null) {
}
You do not need a default value for the apiKey
property if you intend to set it via deserialization later, if not then you should also add a default value as below. The getApiKey()
method is removed because you do not need that in Kotlin, all properties have automatically generated getters built-in and by adding your own you would end up with a conflict between the generated getter and the one you manually created (two methods with the same name, same signature).
If you do need a default value for apiKey
then stay with a var
so that deserialization can work (if you intend to do that) and add a default empty string or make it a nullable string and set it to null
.
class User: BaseResponse()
{
@SerializedName("api_key")
var apiKey: String = "" // if you want a default regardless, or make it nullable and null
}
abstract class BaseResponse(var error: String?=null) {}
add a comment |
up vote
2
down vote
You used =
instead :
while declaration of api_key
(apiKey = String)
. Which actually means you are initialising api_key
with String.Companion
Object.
And you don't need to create getApiKey()
(getter) method as by default you will have getter method for your properties.
class User : BaseResponse() {
@SerializedName("api_key")
var apiKey: String? = null
private set
}
abstract class BaseResponse(var error: String? = null)
in fact you can use data class
for this purposes
data class User(@SerializedName("api_key") val apiKey: String):BaseResponse()
fun main(args: Array<String>) {
Gson().fromJson<User>("{"api_key":"my api key"}", User::class.java).let {
println(it.apiKey)
}
}
add a comment |
up vote
-1
down vote
You're stuck with the way Java do things. In kotlin when defining Getter
and Setter
, you don't have to write them yourself. Once you declare a variable, both methods would be automatically created.
EDIT: So delete the getter in your POJO class.
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make itlateinit var apiKey: String
and use the mechanism intended for this specific use case.
– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
A complete answer is that your code should look like this:
class User: BaseResponse()
{
@SerializedName("api_key")
lateinit var apiKey: String // must be set by something before being read
}
abstract class BaseResponse(var error: String?=null) {
}
You do not need a default value for the apiKey
property if you intend to set it via deserialization later, if not then you should also add a default value as below. The getApiKey()
method is removed because you do not need that in Kotlin, all properties have automatically generated getters built-in and by adding your own you would end up with a conflict between the generated getter and the one you manually created (two methods with the same name, same signature).
If you do need a default value for apiKey
then stay with a var
so that deserialization can work (if you intend to do that) and add a default empty string or make it a nullable string and set it to null
.
class User: BaseResponse()
{
@SerializedName("api_key")
var apiKey: String = "" // if you want a default regardless, or make it nullable and null
}
abstract class BaseResponse(var error: String?=null) {}
add a comment |
up vote
2
down vote
accepted
A complete answer is that your code should look like this:
class User: BaseResponse()
{
@SerializedName("api_key")
lateinit var apiKey: String // must be set by something before being read
}
abstract class BaseResponse(var error: String?=null) {
}
You do not need a default value for the apiKey
property if you intend to set it via deserialization later, if not then you should also add a default value as below. The getApiKey()
method is removed because you do not need that in Kotlin, all properties have automatically generated getters built-in and by adding your own you would end up with a conflict between the generated getter and the one you manually created (two methods with the same name, same signature).
If you do need a default value for apiKey
then stay with a var
so that deserialization can work (if you intend to do that) and add a default empty string or make it a nullable string and set it to null
.
class User: BaseResponse()
{
@SerializedName("api_key")
var apiKey: String = "" // if you want a default regardless, or make it nullable and null
}
abstract class BaseResponse(var error: String?=null) {}
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
A complete answer is that your code should look like this:
class User: BaseResponse()
{
@SerializedName("api_key")
lateinit var apiKey: String // must be set by something before being read
}
abstract class BaseResponse(var error: String?=null) {
}
You do not need a default value for the apiKey
property if you intend to set it via deserialization later, if not then you should also add a default value as below. The getApiKey()
method is removed because you do not need that in Kotlin, all properties have automatically generated getters built-in and by adding your own you would end up with a conflict between the generated getter and the one you manually created (two methods with the same name, same signature).
If you do need a default value for apiKey
then stay with a var
so that deserialization can work (if you intend to do that) and add a default empty string or make it a nullable string and set it to null
.
class User: BaseResponse()
{
@SerializedName("api_key")
var apiKey: String = "" // if you want a default regardless, or make it nullable and null
}
abstract class BaseResponse(var error: String?=null) {}
A complete answer is that your code should look like this:
class User: BaseResponse()
{
@SerializedName("api_key")
lateinit var apiKey: String // must be set by something before being read
}
abstract class BaseResponse(var error: String?=null) {
}
You do not need a default value for the apiKey
property if you intend to set it via deserialization later, if not then you should also add a default value as below. The getApiKey()
method is removed because you do not need that in Kotlin, all properties have automatically generated getters built-in and by adding your own you would end up with a conflict between the generated getter and the one you manually created (two methods with the same name, same signature).
If you do need a default value for apiKey
then stay with a var
so that deserialization can work (if you intend to do that) and add a default empty string or make it a nullable string and set it to null
.
class User: BaseResponse()
{
@SerializedName("api_key")
var apiKey: String = "" // if you want a default regardless, or make it nullable and null
}
abstract class BaseResponse(var error: String?=null) {}
answered Nov 19 at 15:13
Jayson Minard
36.3k15104170
36.3k15104170
add a comment |
add a comment |
up vote
2
down vote
You used =
instead :
while declaration of api_key
(apiKey = String)
. Which actually means you are initialising api_key
with String.Companion
Object.
And you don't need to create getApiKey()
(getter) method as by default you will have getter method for your properties.
class User : BaseResponse() {
@SerializedName("api_key")
var apiKey: String? = null
private set
}
abstract class BaseResponse(var error: String? = null)
in fact you can use data class
for this purposes
data class User(@SerializedName("api_key") val apiKey: String):BaseResponse()
fun main(args: Array<String>) {
Gson().fromJson<User>("{"api_key":"my api key"}", User::class.java).let {
println(it.apiKey)
}
}
add a comment |
up vote
2
down vote
You used =
instead :
while declaration of api_key
(apiKey = String)
. Which actually means you are initialising api_key
with String.Companion
Object.
And you don't need to create getApiKey()
(getter) method as by default you will have getter method for your properties.
class User : BaseResponse() {
@SerializedName("api_key")
var apiKey: String? = null
private set
}
abstract class BaseResponse(var error: String? = null)
in fact you can use data class
for this purposes
data class User(@SerializedName("api_key") val apiKey: String):BaseResponse()
fun main(args: Array<String>) {
Gson().fromJson<User>("{"api_key":"my api key"}", User::class.java).let {
println(it.apiKey)
}
}
add a comment |
up vote
2
down vote
up vote
2
down vote
You used =
instead :
while declaration of api_key
(apiKey = String)
. Which actually means you are initialising api_key
with String.Companion
Object.
And you don't need to create getApiKey()
(getter) method as by default you will have getter method for your properties.
class User : BaseResponse() {
@SerializedName("api_key")
var apiKey: String? = null
private set
}
abstract class BaseResponse(var error: String? = null)
in fact you can use data class
for this purposes
data class User(@SerializedName("api_key") val apiKey: String):BaseResponse()
fun main(args: Array<String>) {
Gson().fromJson<User>("{"api_key":"my api key"}", User::class.java).let {
println(it.apiKey)
}
}
You used =
instead :
while declaration of api_key
(apiKey = String)
. Which actually means you are initialising api_key
with String.Companion
Object.
And you don't need to create getApiKey()
(getter) method as by default you will have getter method for your properties.
class User : BaseResponse() {
@SerializedName("api_key")
var apiKey: String? = null
private set
}
abstract class BaseResponse(var error: String? = null)
in fact you can use data class
for this purposes
data class User(@SerializedName("api_key") val apiKey: String):BaseResponse()
fun main(args: Array<String>) {
Gson().fromJson<User>("{"api_key":"my api key"}", User::class.java).let {
println(it.apiKey)
}
}
edited Nov 19 at 16:46
answered Nov 19 at 16:17
I Don't Exist
2,32511418
2,32511418
add a comment |
add a comment |
up vote
-1
down vote
You're stuck with the way Java do things. In kotlin when defining Getter
and Setter
, you don't have to write them yourself. Once you declare a variable, both methods would be automatically created.
EDIT: So delete the getter in your POJO class.
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make itlateinit var apiKey: String
and use the mechanism intended for this specific use case.
– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
add a comment |
up vote
-1
down vote
You're stuck with the way Java do things. In kotlin when defining Getter
and Setter
, you don't have to write them yourself. Once you declare a variable, both methods would be automatically created.
EDIT: So delete the getter in your POJO class.
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make itlateinit var apiKey: String
and use the mechanism intended for this specific use case.
– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
add a comment |
up vote
-1
down vote
up vote
-1
down vote
You're stuck with the way Java do things. In kotlin when defining Getter
and Setter
, you don't have to write them yourself. Once you declare a variable, both methods would be automatically created.
EDIT: So delete the getter in your POJO class.
You're stuck with the way Java do things. In kotlin when defining Getter
and Setter
, you don't have to write them yourself. Once you declare a variable, both methods would be automatically created.
EDIT: So delete the getter in your POJO class.
edited Nov 19 at 15:55
answered Nov 19 at 12:06
DevMike
556617
556617
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make itlateinit var apiKey: String
and use the mechanism intended for this specific use case.
– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
add a comment |
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make itlateinit var apiKey: String
and use the mechanism intended for this specific use case.
– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
this would not work with the deserialization.
– Jayson Minard
Nov 19 at 15:14
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
@Jayson Minard You're wrong. I used it in one of my projects and it works fine. On second thought, explain why it won't work for the OP.
– DevMike
Nov 19 at 15:23
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
It depends on how the deserialization works, if it uses reflection and grabs the field and does something dangerous without going through a setter then it might stuff a value in there. Many deserializers will not, they will see it as read-only and not set it. Kotlin specific ones sure won't. Serialization would work fine, which is going the other direction.
– Jayson Minard
Nov 19 at 15:32
1
1
So you can rely on luck of some Java code doing reflection stuffing, or you could make it
lateinit var apiKey: String
and use the mechanism intended for this specific use case.– Jayson Minard
Nov 19 at 15:33
So you can rely on luck of some Java code doing reflection stuffing, or you could make it
lateinit var apiKey: String
and use the mechanism intended for this specific use case.– Jayson Minard
Nov 19 at 15:33
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
You're right. Thanks for the explanation.
– DevMike
Nov 19 at 15:57
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53374137%2fpojo-class-mismatch%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Simple typo
val apiKey = String
where you meantval apiKey: String
.– weston
Nov 19 at 19:14