then it's ok

I updated the SO answer, too

Does anybody know if kapt is expected to work in IDEA? It works in Gradle, but we have some issues on running tests in the IDE where annotation processing seems not to be taken in account.

http://pastebin.com/0b9qM6P6 does synchronization work in same way in this example? at least In Kotlin you can't specify synchronized (Class.this)

@vgimbutas: See https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/synchronized.html

and yes, it works in the same way

i see, thanks!

the one thing i hate about Kotlin is having to go back and maintain my old Java code

i immediately want to think “oh, i’ll just map() this list, add a anonymous function here” and then i realize i can’t do it.

i have to think more when writing/reading java code becuase of things like that and variable/type order differences.

WHAT’S THE RETURN TYPE OF THIS METH… oh. there it is.

I forgot semicolons all the time, and also I miss a lot declaring function types like

(String) -> Int

. Instead I need to use Java8 Functional Interfaces

I, for once, converted the remaining 20% or so Java code in my app to kotlin and threw out retrolambda. 😋

Has there been any consideration to adding parentheses-free invocation for arity-1 methods? It makes writing DSLs much nicer.

@jeff Have you looked at the infix keyword for functions? https://kotlinlang.org/docs/reference/functions.html

@dalexander: Yes. Still need the receiver before the infix function, though. I don't think you can write something like

bind myObj to { ... }

with an infix function.

bind

being the arity-1 method.

That’s the order of operations supposed to be for that?

bind (myObj to { … })

or

(bind myObj) to { … }

?

The first, assuming you could mix infix functions. Invoke

bind

with a

Pair

containing

myObj

and

{...}

Why can't you have named parameters when calling a Java method?

I could be wrong, but I don’t think there’s a way to specify order of operations for infix functions, so even if they added that feature you’d likely need to use parens to get what you wanted. You might be able to convince the JB people to allow an implict

this

with infix functions though. ie. it’s currently possible to do

this bind myObj

, but there might be naming conflicts I haven’t thought of.

Is it deliberate, or a known issue, that boolean properties generate Java getters with a name of "getX" instead of "isX"?

I'm working with a library that assumes that boolean fields are always "isX" and am having to use "@get:JvmName" on all my boolean properties to make it work, which is a bit ugly...

Just Jackson things?

It's GraphQL-Java, not Jackson

It's got explicit code that says "If the field type is boolean then the accessor is 'isX', otherwise it's 'getX'"

that’s the bean spec

Ok - Reading the spec again, I see that it does allow "getX" for booleans. Its just that it also allows "isX" in that case...

I've always thought that booleans should be "isX" and non-booleans should be "getX"

How does one require a subclass' companion object to inherit from the superclass'