I think Nullables and sensible closure syntax (without the trouble of retrolambda) are what I find most useful on Android.

And of course, driving home the point that "new language != rewriting everything", since Kotlin interops with Java perfectly. You could rewrite one class in the program in Kotlin and show that it works perfectly to start with

^ those too, especially if you use RxJava, where everything is a functional interface

Kevin - that point was raised by almost everyone - about interop. For some who were totally new to Kotlin they didn’t realize that you could gradually write new code in Kotlin while keeping all of the Java code.

What I want to present to the banks and investment banks that I work with is that I believe Kotlin is the path to reducing technological and business risk. I don’t hear many people talking about that, but it is pretty clear to me.

I think the change is a risk, but that risk will continue to go down over time.

it's a lot easier to write correct code in Kotlin than in Java (due to things like, as you mentioned, compile-time awareness of nullity). Pushing them to write new code in Kotlin that interops with their legacy Java codebase might be the solution

Someone last night mentioned the path of writing tests in Kotlin to test existing a new Java code. I’m not so sure of that. I have not tested using Kotlin with Spock - I don’t anticipate any issues, but I’ve not tested it.

I don’t think I’m sold on the idea of writing tests as a gateway. Thoughts?

I think it could be useful to introduce it to wary people. They'll be exposed to the syntax without it ever being in code that goes into prod. Of course, this is an irrational fear; Kotlin is stable, JB is committed to supporting it, and IDE support is great. But enterprise and rationality rarely go hand-in-hand simple smile

I think writing tests as a gateway is a reasonable idea if people aren’t convinced. Tests are much more expendable if it turns out that the team doesn’t actually want to use Kotlin than business logic is.

I don’t think you get to see a lot of the real value of Kotlin in tests though, most test logic in my experience is pretty simple so you probably won’t be able to take advantage of smart casting or nullability in a particularly meaningful way.

I agree that tests are probably not the best way to introduce Kotlin in a code base, especially since the annotation notation in Kotlin is more verbose than Java and doesn’t support most of its syntactic shortcuts, e.g.

@Test(groups = arrayOf(“a”, “b”))

or

default

attributes.

To me, the best way to introduce it is to sneak one Kotlin source file in the Java code base and tell everyone “Hey, look at this source, works just fine!"

Instant Run explained May be useful

sounds like it'll be a painful transition for anything using a lib

i havent heard much at all about jigsaw, but i cant imagine it'll break backwards compatibility

Java's been compatible since the first release AFAIK

Nope

My dad has worked with several softwares that require old versions of Java

It's why he hates it lmao

What versions of java?

I started around 1.5 and i dont recall any breaking changes

@douglarek has left the channel

compat's been broken to some extent before

there's some corner cases if you build with a diff jdk -- target version and what not can only get you so far

also there was something i ran into recently, when generics were introduced it would break stuff that passes a Class

Mmm not sure, the furthest I got to with bad java version was one of the earliest stable releases of 1.8 not compiling properly because it didn't interpret valid syntax as valid. From what I've read, people say that code (maybe some?) written since 1.1 works just fine.

@supaham: java.sql.Connection (an interface) gained methods in 1.4, 1.6, and 1.7. And I’m sure there’s more if you were to look.

What does that prove?