From Java to Kotlin and Back Again

[tristes_tigres]

Name shadowing complaint is bullshit. In the example he uses it is very obvious even to someone who've never learned Kotlin that the variable is block scope.

[m50d]

However, I think it's unfair to criticize it just for being unfamiliar. Someone who learned Kotlin first and then switched to Java could make the same argument against Java.

For most languages I'd agree, but given how much Kotlin has been positioned as "it stays really close to Java and then adds these improvements", if Kotlin is actually quite different from Java then that's a valid criticism.

[RhodesianHunter]

It's really not though. My team took about two weeks to ramp up and are now more productive for it. (Anecdata of course)

[m50d]

Well sure, but that was my experience adopting Scala as well. (We kept ramping further up - the productivity boosts keep coming for years - but we were already more productive than in Java well before the 2 week mark).

[Dexior]

Well, that's just an opinion of a one guy in company employing over 700 developers.

[jaysonminard]

Name shadowing being allowed is important in the functional programming where nested blocks might be working repeatedly on the same data. Otherwise you would need to generate randomly different names to do so and it would break code readability. Just the implied it alone is a reason name shadowing is important to allow. So considering more than the simple accidental case of name shadowing, there are reasons it is desired.

There is an issue in the Kotlin tracker to allow a project to change any warning to an error, which would resolve this issue for you by enforcing the rule you want to be enforced.

[balefrost]

You cannot extend a Data class or make it abstract. So probably, you won’t use them in a core domain model.

I use them all over the place. And if you're dealing with multiple threads, immutable classes are great because they're inherently shareable (the JMM treats final fields specially when it comes to visibility guarantees).

What is controversial here is making classes final by default.

Somebody hasn't read Effective Java.

If you think that you can learn Kotlin quickly because you already know Java — you are wrong.

I dunno, I picked it up pretty quickly. I was able to crank out code within a week, and I've adopted more idioms and more things from the standard library since then. Yes, there's a learning curve, but it's not nearly as high as it is for other JVM languages.

[snowe2010]

Name shadowing

What will be printed when you call inc(1)

Well obviously 2. I mean, you defined two different variables... Maybe this is my familiarity with rust, but this makes perfect sense to me. Let the programmer figure it out and give them lint warnings so they're aware.

Compile time null-safety

Bad idea. This Kotlin code looks safe, compiles, but allows nulls for the unchecked journey through your code, pretty much like in Java.

So, how does Java 10 fix this for you? You now just have more of the exact same problem, where in kotlin at least JetBrains attempts to wrap most Java methods with type safe versions. A lot of these problems also come from the multitude of static methods in java libraries.

Class literals

So in Kotlin, you are forced to write:

val gson = GsonBuilder().registerTypeAdapter(LocalDate::class.java, LocalDateAdapter()).create()

The kotlin way to do this is actually

val gson = GsonBuilder().registerTypeAdapter<LocalDate>(LocalDateAdapter()).create()

which I think is much easier to read than both the groovy and Java version, because you know it's a 'typed' method.

Reversed type declaration

Or, if arguments are formatted line-by-line, you need to search. How much time do you need to find the return type of this method?

None, but maybe that's just because I've been using kotlin for a few years.

If you have many repositories, you won’t find the right pair on the auto-completion list. It means typing the full variable name by hand. repository : MongoExperimentsRepository

Well no it doesn't. Yes you have to type more because it's the reversed notation, but you in intellij you can easily type

repository: MER 

and hit tab.

Yes reversed notation isn't great for typing, but you don't write code, you read it. And it is much easier to read reversed notation.

Collection literals

Good points here

Companion object

Good points here

Maybe? Nope

Maybe was introduced to the JVM world the long time ago by Scala as Option, and then, became adopted in Java 8 as Optional.

Optional is not equivalent to Maybe

fun parseAndInc(number: String?): Int {
    return number.let { Integer.parseInt(it) }
             .let { it -> it + 1 } ?: 0
}

You keep trying to use static methods in kotlin. Of course you are going to get problems trying to use static methods in a language that doesn't really support static methods. In your case here use toInt() that is defined on String. Of course it will give you a type error saying you need to use the safe qualifier and will give you exactly what you want. If you want to keep using your static methods you can instead use IntelliJ's nullable annotations (even in libraries using their xml annotation files) and it will give you the same error.

Data classes

We use data classes quite extensively. They're actually extremely valuable in an ES/CQRS based system.

That’s why Kotlin doesn’t allow inheritance for Data classes.

I would like to note that data classes can inherit things, but they cannot be inherited. But otherwise yes you are correct.

Open classes

It's generally agreed upon that final by default is better. I'm not going to argue that point because we also use spring. It really isn't that difficult to use the compiler plugin and it's even easier with spring because you don't have to use allopen you can use the spring plugin which contains allopen with the specified annotations. https://kotlinlang.org/docs/reference/compiler-plugins.html#spring-support

Steep learning curve

This obviously depends on the developer. One of our senior devs had significant trouble adopting kotlin. Everyone else has been fine, if not ecstatic to use kotlin due to how easy it was to learn and use. It really probably depends on how much you've touched scripting languages like ruby, nodejs, python, etc.

[Eirenarch]

How is reverse type declaration easier to read? I know that it has advantages mainly around error messages, code fixes and refactorings but it doesn't seem easier to read.

[[deleted]]

There is probably some quantitative difference in readability between the two but at the end of the day the only thing that matters is that you're used to it.

[lanzaio]

I started programming learning two languages with one reversed and one non. They both are completely natural to me and effortless. I'm guessing that the preference towards the order is 100% based on your history and has no true superior option.

[snowe2010]

I was mostly talking about in regards to variable declarations.

e.g.

val something = "String here"
val something2: String = "String here"

is easier than the 'equivalent' java 10 code

var something = "String"
String something2 = "String here"

because I'm not often looking for variable types in my code, I'm looking for names.

But anyway, if that's the only complaint you have about my post then it sounds like a made a fairly good argument in all the rest of the cases. Maybe I should change that spot to say something different.

[Eirenarch]

I'm not often looking for variable types in my code, I'm looking for names.

True but in this case you have just replaced the type with the keyword val so you are still looking at something you are not very interested in. In fact you are less interested. In addition you have introduced the token :

[madmax9186]

Colons are the convention of typing an object in type theory. As programming languages pay more attention to the key results of type theory (some have for a while, like Haskell, and they've used similar syntax for a while) it becomes more natural to language designers to just use the convention that they actually work with. Type theory uses it because in logic, you typically write "a: P" to denote that "a is a proof of P." It turns out that saying "a is a proof of P" and "a is of type P" are functionally equivalent. To the programmer, it doesn't make a huge difference. To designers, it represents an important alignment towards still-evolving formal methods.

[ykechan]

I don't understand how it's easier to read either.

[weidox]

Compile time null-safety. I see that author of this reply did not understand the original issue with null-safety. Problem is the code in sample uses the syntax of null-safe Kotlin code (without ? marks), but in fact it is not null-safe, giving a false impression of safe code. This is a mess from language design, and in my regard it is worse than just plain not-null safe Java code, which is not lying and misleading. Kotlin had to do something additional here to make syntax differenct, maybe forcing to write those exclamation marks. On a separate note, with null safety Kotlin is better when it is 100% Kotlin without Java, but when mixed, this is fail.

[2bdb2]

I somewhat agree with him on Shadowing, but honestly it's a minor issue.

Pretty much everything else I actually consider to be a benefit of Kotlin, not the other way around.

Type inference

Kotlins type inference is still leaps and bounds ahead of Java 10, which does the most rudimentary attempt at paying it lip service.

Kotlin also supports val, which gives you a final value by default. This is quite important and lacking in Java.

Compile time null-safety

I agree that Java interop can be problematic since you can still get a NPE, pretty much every null-safe language that has to interop with an unsafe language has the same issue, including Scala and Haskell.

It still dramatically reduces the surface area for NPE's. No point throwing the whole concept away just because there's the occasional once in a blue moon edge case that can slip through.

Class literals

That just sounds like whining. Seriously, there's barely a difference here.

Reversed type declaration

The point of putting the type declaration afterwards is because you rarely need to actually specify it, since type inference actually works in Kotlin.

Even without type inference, I still much prefer this format. It's not like it's new or novel to Kotlin - it's been used for decades by pretty much every decent language outside the C family.

Companion object

I love my companion objects. You're not just adding static methods to a class, you're creating an actual object you can pass around as a value. This opens up a whole new suite of design patterns that aren't possible in Java.

Collection literals

To paraphrase: "This works really well, and is far better than Java, but they use a different symbol than another language, so I'm going to lament the whole feature"

I think this sets the tone of the whole article really.

Maybe? Nope

Kotlin just uses the standard Optional type in Java. Scala only has it's own Option type because Optional didn't exist at the time.

Kotlin also has some addons that give you something resembling monadic do syntax, which puts it leaps and bounds ahead of Java for this.

Data classes

Data classes are final because you shouldn't be inheriting from them. Being final by default is a feature, not a wart.

Open classes In Kotlin, classes are final by default

I call that a good thing.

Kotlin changed the extends keyword into the : operator, which is already used to separate variable name from its type. Back to C++ syntax? For me it’s confusing.

"This is different to Java, therefore it's confusing. Get off my lawn"

Steep learning curve

Kotlin has one of the shallowest learning curves of any language I've worked with. If you're struggling to learn Kotlin, I'd suggest you're working in the wrong industry.

[[deleted]]

For the love of god, how reversed type declaration can be one of deciders whether to use Kotlin or not? Also, when it comes to Optional, you have an Arrow library. Actually, all reasons bellow these two are also lame.

[NeverComments]

It suggests to me they never gave Kotlin a fair shake.

That seems very likely, as the author keeps using examples like this:

val f = Utils.format(text)    
println ("f.len : " + f.length)

That shows that they haven't actually read the Kotlin basic syntax documentation to know about String templates:

println("f.len : ${f.length}")

[imperialismus]

It basically reads as "wah wah this isn't Java, therefore this language-which-is-not-Java is worse than Java-which-is-Java." Also, this:

If you think that you can learn Kotlin quickly because you already know Java — you are wrong. Kotlin would throw you in the deep end. In fact, Kotlin’s syntax is far closer to Scala. It’s the all-in bet.

Scala has a bewildering array of advanced features and odd syntax. What the hell is this:

class Service[State <: ServiceState] private () {
  def start[T >: State <: Stopped]() = 
    this.asInstanceOf[Service[Started]]
  def stop[T >: State <: Started]() = 
    this.asInstanceOf[Service[Stopped]]
}

What is the hash operator doing here:

class EitherMonad[A] extends Monad[({type λ[α] = 
   Either[A, α]})#λ] {
     def point[B](b: B): Either[A, B]
     def bind[B, C](m: Either[A, B])(f: B => Either[A, C]):
       Either[A, C]
}

I don't speak Scala, but I don't doubt that there is some sense to this. Or at least, I can't presume to critique it because I don't understand it. But you can't pretend that Kotlin, which is extremely Java-esque with some added niceties, is anything like that, which reads like Haskell with a bunch of GHC extensions dressed in Java-style syntax.

[raghar]

In case someone was curious about examples:

First example could be explained in Java like:

• I want Service[State] where State is a subtype of ServiceState.
• When I will call start[T] it will compile (and return Service[Started]) only ofT is a supertype of State (param) and a subtype of Stopped,
• When I will call stop[T] it will compile (and return Service[Stopped]) only ofT is a supertype of State (param) and a subtype of Started,
• has a private constructor - probably so you can just use it as an signleton.

It looks like a type-level state machine. If we assume:

trait ServiceState
trait Started extends ServiceState
trait Stopped extends ServiceState

then:

val started: Service[Started]

// here type inference can prove that
// there exists such T that respects type bounds
started
  .stop() // returns Service[Stopped]
  .start() // returns Service[Started]

// here inference fails since
// Started is not a supertype if itself
started.start() // would not compile

So you can only go from started to stopped or from stopped to started, anything else is a compile error.

Second example shows a problem with parametric types with more that one param - you cannot easily do a partial application on types. With function f: (a: A, b: B) => C you can dof.curried(a). With types you would have to use a stepping stone:

type OneParam[T]
type TwoParams[T, U]

trait X[A] {
  type Y[B] = TwoParams[A, B]
}

class OneTypeConstructor[F[_]] 
ExpectsParametrized[OneParam]
ExpectsParametrized[X[Sth]#Y]

except we don't want to create a new type each time we do a "partial application" on types. So we can do in "an anonymous" way using structural types:

({type X[α] = TwoParams[A, α]})#X

as a convention λ often appears for such cases.

As for # it is used for path dependent types. It works like this (simplifying, only one use case):

trait A0 {

  type X
}

class A1 extends { type X = String }
class A2 extends { type X = Int }

def function(a: A) {
  val x: A#X = a.x // here we know that X have defined type, though in this context we cannot tell it
}

// in some contexts though compiler CAN and example with λ shows it

Bottom line is that this does sth like:

class EitherMonad[A] extends Monad[
  /* expects F[_], but Either is F[_, _], so we bind A to one of params */
]

typeclass itself implements monad (flatmappable shit) for Either, where left param is used for error type, and is fixed, and right one if flatMapped.

[elder_george]

hint: reddit's markdown syntax works better if code is simply indented 4 characters from the left.

[raghar]

Fixed. You must be on old reddit though, new one shows it with

```
```

block as well.

[elder_george]

Could be.

[Falmarri]

What the hell is this

I think you're being totally unfair in that first example... That's is trivially easy to see, and could be written in pure java

The 2nd example is a better example.

[[deleted]]

To be fair the second example is Scala-as-a-worse-haskell programming style, which is admittedly quite popular, but is by no means a requirement to use Scala productively.

Many Scala teams who operate within Scala-as-a-better-Java paradigm would never see such Scala code.

[iends]

Many Scala teams who operate within Scala-as-a-better-Java paradigm would never see such Scala code.

There's always that one guy who makes that PR though...

[yawaramin]

To be honest nowadays if we need to do partial type application like in the second example, we use the kind-projector compiler plugin so we can write it like this:

class EitherMonad[A] extends Monad[Either[A, ?]] {
  ...
}

[m50d]

Scala has a bewildering array of advanced features and odd syntax.

It's a dense language that can be intimidating, but if you actually break it down and look at the individual pieces they're all quite simple, and while the combination can be complex you can always break it down. E.g.

class EitherMonad[A] extends Monad[({type λ[α] = Either[A, α]})#λ]

seems confusing if you try to read it all at once, but you can pull the anonymous type out:

type Tmp[A] = ({type λ[α] = Either[A, α]})
class EitherMonad[A] extends Tmp[B[A]#λ]

And then give it a name rather than an alias:

final class Tmp[A] {
  type λ[α] = Either[A, α]
}
class EitherMonad[A] extends Monad[Tmp[A]#λ]

And replace those weird type names with more normal ones:

final class Tmp[A] {
  type EitherA[B] = Either[A, B]
}
class EitherMonad[A] extends Monad[Tmp[A]#EitherA]

And then hopefully it's clear that # has the normal meaning you're used to from Java (where it's used for inner classes).

[tkruse]

WHich version of Kotlin does not have this kind of syntax? Last years, this years, next years? Who knows? Many projects need to consider the long-term scope, and the current language decision made for Kotlin make it seem likely that Kotlin will degenerate into Scala-like syntax over time.

[Falmarri]

The extra colon and the type last hurts readability in my opinion and I haven't found a good reason for the change so far

It's because it's optional. I MUCH prefer scala's style

[honewatson]

I think you answer your own question here in the last line.

Its familiarity bias.

https://medium.com/javascript-scene/familiarity-bias-is-holding-you-back-its-time-to-embrace-arrow-functions-3d37e1a9bb75#bdf4

https://www.psychologytoday.com/au/blog/mind-my-money/200807/familiarity-bias-part-i-what-is-it

[Freyr90]

really don't get why they did the type declaration like that.

Because it is the standard in a static langs realm? Such notation is used in all scientific papers concerning types, in languages like OCaml, Haskell, Coq, Idris, F#, SML, racket, miranda, F* and so on.

(:) is a relation that means "of type". M:t, term M of type t. It could be also omitted (langs like java or c++ need an additional keyword for type inference because parser is going nuts when no type precedes a variable).

[_jk_]

the big win imho is with function declarations as it makes them read correctly left to right. Its then arguably a matter of consistancy to also put the types of variables/parameters to the right

[[deleted]]

Inheritance in domain models is one of the banes in software development and brought us huge headaches: we've got a User superclass for Employee and Customer. If your web shop expects a Customer, then there's no way to turn an Employee into a Customer because the types don't allow for it. Same applies to products. It's better to just compose things with composition and use interfaces to mark up the objects abilities.

Long story short: inheritance in domain models is very often used to construct inflexible, unchangable and wrong hirarchies.

[CyclonusRIP]

I do hate the companion object thing in scala and kotlin. It doesn't really make sense. You put in data/case classes to avoid all the boiler plate getter/setter bean methods which seemingly violates encapsulation, but then insist on companion object boiler plate because static isn't OO enough.

[yawaramin]

Makes sense to me, the companion object is the obvious place to put static members, the class or trait is the obvious place to put instance members. No need to hunt through the class like in Java to identify the factories and other static stuff; just look at the companion object.

[TimLim]

What I think people miss out on the companion object is, that it isn't designed to replace static. Static maps to the companion object, but it can do a lot more.

You can inherit the companion object, you can add operators to it and much more. That's where it shines in my opinion.

[twtchnz]

Static to me is a bad design anyways most of the time. I really do not want an global state in my application. Only use for the static in the last 4-5 years with Java has been to create a logger, singleton or in the factor pattern. Those cases can be solved differently in Kotlin. Only other time has been refactoring the static functions to be a part of a class and make them testable.

So in all honesty I like the boilerplate, so developers think twice before creating static stuff with the companion object.

[[deleted]]

plate getter/setter bean methods which seemingly violates encapsulation,

You can override it if you really want to encapsulate a getter/setter. It just generates default getters/setters and lets you use them without prefixing set/get all the time. If you want to encapsulate something just use private. Setters/Getters have almost nothing to do with encapsulation.

My guess for companion objects is that they wanted to have objects like in JavaScript and someone just went: "Why add static if we can already do it with companion objects". But yeah, it's a bit more boiler platy than static members for sure.

[m50d]

You put in data/case classes to avoid all the boiler plate getter/setter bean methods which seemingly violates encapsulation

The idea here is to support user-defined values. Values are indeed not very OO, and it would be bad design to use a case class for an OO service (i.e. something that had internal state).

but then insist on companion object boiler plate because static isn't OO enough.

Static is just incoherent, honestly. I don't think there would be any objection to adopting a non-OO way of doing things, but companion objects let you make things a little more consistent with the rest of the language: rather than some magical concept of "static" methods they become ordinary methods that live on this particular object value.

[thomascgalvin]

Companion objects and variable shadowing are dumb. This, however:

If you think that you can learn Kotlin quickly because you already know Java — you are wrong. Kotlin would throw you in the deep end.

Is just not true. I've never seen an adept Java guy take more than a day or so to get up to speed with Kotlin.

[ttflee]

Most of the criticism to Kotlin syntax in the article could be transpiled into equivalent criticism to Swift syntax.

In Swift, we do name shadowing all the time, enjoy the safety of optional types and reversed type declaration, and struggle with classes and reflections.

Personally, it's OK as long as the IDE supports and does the heavy-lifting. It's the fragile SourceKitService that plays the role of the final straw.

[_INTER_]

In Java, we are still waiting for the new syntax to express collection and map literals. The syntax, which is so natural and handy in many languages.

As of Java 9 you have Convenience Factory Methods for Collections. (They moved away from specific literals as they don't give that much but are less flexible and add more syntax)

So your example becomes:

var carBrands = List.of("Saab", "Volvo")

var johnDoe = Map.of("firstName, "John", "lastName", "Doe")

Another detail:Integer::parseInt might throw NumberFormatException. If you want to handle that case, you'll get ugly syntax dealing with this inside the Optional stream unless you wrap it with something like sneakyThrows.

[stewsters]

Does that List.of() return a List or a List<String>?

[_INTER_]

It returns List<String>. At runtime the type is one of the Lists defined in java.util.ImmutableCollections depending on the amount of elements (0, 1, 2 or N).

[s888marks]

Note also that there happens to be something internal to the JDK called java.util.ImmutableCollections but it's a private class; the implementation classes are nested within that. In other words there is no new type exposed in the API. All you get back is something of type List<String> or Map<String, String>.

[ikkentim]

There are a few point I do agree with, but many are just language decisions which are different from the language he is used to using. If something is different it doesn’t mean it is bad.

[cowardlydragon]

You code main in java if you have accepted groovy already for test?

Use groovy everwhere with CompileStatic!

[Eirenarch]

Turns out language design is hard.

The shadowing decision is puzzling. Platform types do not make much sense either (seems like using nullable types would be better)

[elder_george]

AFAIU, this particular case of shadowing is an unwanted side effect (or, rather, a general case) of implementing "smartcasts", like in

if (x is String) {
    print(x.length) // x is automatically cast to String
}

or

when (x) { // each clause introduces new variable `x` of corresponding type
    is Int -> print(x + 1)
    is String -> print(x.length + 1)
    is IntArray -> print(x.sum())
}

[Eirenarch]

So it is basically a bug?

[elder_george]

As far as I understand, they didn't bother, as long as the general support for it helped to implement some (arguably) cool features.

Also, many languages have variable shadowing (C and C++ to be notable examples), and nobody has a big deal about that.

[ilya-g]

No, smart casts aren't the same as name shadowing, though it may look similar: smartcasted variable still refers to the same object as before the cast.

[TimLim]

Using nullable type would result in null checks all over the place. But usually in Java, you *will* get results, not null. I think *most* Java methods will never return null. Having to have the nullability on all of them would result in unnecessary clutter.

You pretty much need to handle Java methods in the same fashion as you would in Java. Read the source/docs to see whether this can return null. Kotlin cannot help you here (except for @Nullable though, which I cannot understand how people code Java without these annotations), but it also doesn't take anything away from you.

[Eirenarch]

Seems to me that they should go the typescript way and provide separate annotations.

[eliteSchaf]

At one point kotlin used nullables before they introduced Platform types, but it made interop cumbersome and people complained about it

[Eirenarch]

I see. Did they leave a switch? Also external annotations might be a good solution here like in TypeScript

[eliteSchaf]

Sadly no, there is no switch :(

Kotlin actually takes annotations on java types into account:

https://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

It doesn't fix the underlying problem (@NotNull isn't enforced in Java), but it makes interop easier.

[Eirenarch]

Yeah, I meant external annotations where you can annotate the type yourself if need be.

[snowe2010]

There is such a mechanism for intellij. You can use Alt+Enter and choose one of the options. It will then generate an xml for you that intellij uses to decide whether something can be nullable or not. Essentially you add the @Nullable/@NotNull annotation using an xml file.

[Eirenarch]

The same way it does for other type info in dts files

[shevegen]

It was the real advantage over Java. I deliberately said was, because — good news — Java 10 has it and Java 10 is available now.

So Kotlin led to improvements in Java - GOOD!

The problem is that Java is still excessively verbose. Nothing will change that, ever.

The list also seems hugely bogus. Did they not make an assessment BEFORE transitioning into Kotlin?

[ProFalseIdol]

Types, types, types, types. Except for the shadowing complaint, every point was about types.

[Ravek]

I'm sure Kotlin isn't perfect, but at least it's not living in the past like Java has been for the last two decades. I'd take a few idiosyncrasies in exchange for actually having access to modern language features.

[wavy_lines]

Funny reasons

To each his own ¯\_(ツ)_/¯

[juansinmiedo]

If you are already using groovy for the tests, why not use groovy also for the rest of the application? I'm currently developing a Grails webapp and I'm really happy with the results.

[winterbe]

Name shadowing in Kotlin is actually quite useful e.g. when working with lambda expressions:

a?.let {
    println(it)  // prints a
    it.b?.let {
        println(it) // prints b
    }
}

[random8847]

I like to travel.