yes, I think old Kara code deser had this wrong at some point.

it worked because it checked the simple name too, but compared against wrong class.

boolean.class does not exist

Class<Boolean> and Boolean.TYPE are two different classes. one doesn't really exist yes.

which one exists in kotlin??

same as Java.

you need to check for both if you have an unknown class being given to you (because it could come from anything)

(incomplete code in progress, but shows you some type mappings)

-.java

and?

you are comparing a KCLass to a Class again, see discussion about about that

they are NOT the same

T::class

vs.

T::class.java

are not the same. so

Boolean::class.java

cannot be

T::class

write test cases to confirm your understanding of code, easier to view than code that has no assertions or outcome.

I think showing us anything more than 10 lines of code is excessive and asking us to debug, or be your dev lead. more help comes to short exact questions with all of the information needed and nothing extra we have to wade through.

releasing the updated converters referenced above in Klutter 0.7.2 that has some helpful things about reflection / data conversion for primitives. Will be available in 15-20 minutes on maven central. #C0AQF9VNC for more, but it looks like you are trying to do what the conversion module there already does. (just pushed to maven central, that version will show up soon even if search engines don't show it... update: there now in maven central)

https://github.com/klutter/klutter/tree/master/reflect-core-jdk6/src/main/kotlin/uy/klutter/reflect this module does not use reflect library of kotlin. reflect-full adds things that use reflect library. And there are separate versions for different JDK 6, 7, and 8. so types like Path from JDK 7 obviously require JDK 7 module. Temporal, Instant, etc JDK 8 module.

pokes @User

grumbles

so whats the main motivation of putting klutter out there

@nickst: useful things for Kotlin people that we like to share. also acts as samples to people about extending other libraries. it'll get bigger and more developed over time. what causes you to ask that question?

i am thinking if to include it or just be inspired from it

either way. some parts are bigger like the in-memory graph. others save you time on integration with kovenant (vertx3, elasticsearch). others fix things broken in the Java libraries (URL encoder/decoder, URI Builder) are much more correct modern and accurate. others are uselessly small (aws-s3, aws-core). Others make things tolerable (typesafe config with controlled loading, subverts the magic that people don't understand or want, a nicer API). elasticsearch will build out a lot over upcoming few weeks to improve the xson building. and maybe a full codegen REST api since things like Amazon ElasticSearch only support REST and JEST isn't the best implementation.

it is all small modules, and if you don't use Injekt then exclude it from those that have prebuilt Injekt modules. @nickst

where did this type come from: kotlin.jvm.internal.ClassReference@3a70ee08

it does not match well is == Boolean::class or anything like it(java.lang.Boolean::class)

seems like a facade on wrapper. what did you do to get to that class?

I think #C0AVAB92L is better place to ask about comparing Classes, people there are generally more knowledgable, and @apatrida is also there simple smile

not now he isn't, futbol game, Uruguay vs. Boliva!