5 ms·

Lombok and Kotlin are both much easier to integrate into existing Java applications and libraries than Scala.

krzyk 5y ago
Lombok is the problem not a solution (see https://github.com/projectlombok/lombok/issues/2681 https://github.com/projectlombok/lombok/issues/2681 regarding support for JDK 16 to understand why) and a ticking time bomb in every project that wants to move past JDK 15/16. But why do you think Kotlin is easier to integrate than Scala? Both work on JVM.
- gher-shyu3i 5y ago
  It's been resolved though.
kelnos 5y ago
I don't see how Kotlin is easier to integrate into an existing Java app than Scala is. They both require adding new dependencies and changing your project build config, and require developers who know the respective new language. That's... about it. They both offer similar levels of interop with Java libraries. If you want to assert that finding Kotlin developers is easier or that Kotlin is an easier language to learn, sure, that might be the case (I really don't know), but that's not really an integration task.
- throwpupper 5y ago
  What about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.
  - halfmatthalfcat 5y ago
    I believe Scala's are as well, this seems to be a pretty complete list: https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/CollectionConverters$.html https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/Coll...
    - balefrost 5y ago
      Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost. One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.
      - darksaints 5y ago
        Scala has the full suite of Java collections without any conversion or overhead whatsoever. But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements. The Scala adapters are merely ways of converting java collections to scala collections and vice versa.
        joshlemer 5y ago
        I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
        esarbe 5y ago
        It's only a problem if you can't decide which part of your project to write with which language. If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.
        joshlemer 5y ago
        What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. On the other hand you have Kotlin which just directly, frictionlessly deals with Kotlin/Java collections the same way (in fact, they literally are the same). We're comparing "some small-to-medium cost" against "zero-cost". Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."
  - lmm 5y ago
    You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin. The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficult to the point that essentially no-one does it. IMO that's a bad tradeoff in the long term, but you can absolutely take the same approach in Scala if you really want to.
    - lolinder 5y ago
      I write Kotlin all day and almost exclusively use immutable types. What difficulties with using them are are you referring to?
      - lmm 5y ago
        Kotlin doesn't have immutable collection types in the standard library (it lets you use a read-only interface but the collection is really still mutable and will be seen as such by any Java code), so if you want actually immutable collections you have to use non-standard collections, and since Kotlin doesn't have typeclasses or implicit conversions it's difficult to interoperate between any non-standard collection library and other Kotlin code.
        lolinder 5y ago
        Ah, fair. I've never actually seen that become a problem, but I can see how it would be if I were doing more extensive Java interop.
        lmm 5y ago
        Yeah, if all your code and libraries are Kotlin then there's less risk of a collection being mutated under you (though even then, Kotlin gives you no way to write a method that only accepts an immutable collection - you can write a method that accepts a view-only interface, but it will always be possible to pass a mutable collection and mutate it in parallel while that method is running). But of course in that scenario there's also zero benefit from having compatibility with the Java collections.
lmm 5y ago
Not so IME. Kotlin's nullable types don't play nice with option-oriented APIs (e.g. Java Streams), and you can't make Java types transparently implement Kotlin interfaces (and there's no equivalent to typeclasses), so using Java types with Kotlin libraries is harder than with Scala libraries.
jillesvangurp 5y ago
Exactly. Kotlin was actually explicitly designed to be like this and is directly competing with Java as a drop in replacement for it. Consider e.g. the seamless integration into Spring and Android, which both continue to support Java as well. Writing Android applications in Scala is a bit of an uphill battle (but I've heard of people attempting it). Writing Spring applications in Scala is possible in principle, I guess, but it's just not a thing that is very common or that is supported by Spring. Spring and Android have documentation with code samples in both Java and Kotlin, and extensive Kotlin specific stuff in the form of e.g. extension functions. At this point Kotlin is the preferred language for both even though they both maintain compatibility with Java as well and will for years to come. Spring is about half the server side JVM ecosystem. Android represents a good chunk of frontend usage. Kotlin is a first class citizen for both; Scala just isn't. It has its own frameworks of course but they are kind of niche in comparison. I think it's great that Java is slowly evolving to have features that other languages have. Kotlin supports Java's records as of this week's 1.5.0 release via an annotation. Meaning that if you have Java code that needs to interact with Kotlin code, you can write a data class that from the Java side looks like a record if you put the right annotation on it. It's a compatibility feature that's only relevant if you are planning to use or support Java. Another notable feature that landed with this week's release include sealed interfaces (it already had sealed classes). You can use both with data classes of course.

Lombok is the problem not a solution (see https://github.com/projectlombok/lombok/issues/2681 https://github.com/projectlombok/lombok/issues/2681 regarding support for JDK 16 to understand why) and a ticking time bomb in every project that wants to move past JDK 15/16. But why do you think Kotlin is easier to integrate than Scala? Both work on JVM.

gher-shyu3i 5y ago
It's been resolved though.

kelnos 5y ago

I don't see how Kotlin is easier to integrate into an existing Java app than Scala is. They both require adding new dependencies and changing your project build config, and require developers who know the respective new language. That's... about it. They both offer similar levels of interop with Java libraries. If you want to assert that finding Kotlin developers is easier or that Kotlin is an easier language to learn, sure, that might be the case (I really don't know), but that's not really an integration task.

throwpupper 5y ago
What about the fact that Kotlin collections are fully interoperable with Java collection? That makes the transition significantly easier.
- halfmatthalfcat 5y ago
  I believe Scala's are as well, this seems to be a pretty complete list: https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/CollectionConverters$.html https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/Coll...
  - balefrost 5y ago
    Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost. One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.
    - darksaints 5y ago
      Scala has the full suite of Java collections without any conversion or overhead whatsoever. But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements. The Scala adapters are merely ways of converting java collections to scala collections and vice versa.
      - joshlemer 5y ago
        I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
        esarbe 5y ago
        It's only a problem if you can't decide which part of your project to write with which language. If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.
        joshlemer 5y ago
        What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. On the other hand you have Kotlin which just directly, frictionlessly deals with Kotlin/Java collections the same way (in fact, they literally are the same). We're comparing "some small-to-medium cost" against "zero-cost". Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."
- lmm 5y ago
  You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin. The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficult to the point that essentially no-one does it. IMO that's a bad tradeoff in the long term, but you can absolutely take the same approach in Scala if you really want to.
  - lolinder 5y ago
    I write Kotlin all day and almost exclusively use immutable types. What difficulties with using them are are you referring to?
    - lmm 5y ago
      Kotlin doesn't have immutable collection types in the standard library (it lets you use a read-only interface but the collection is really still mutable and will be seen as such by any Java code), so if you want actually immutable collections you have to use non-standard collections, and since Kotlin doesn't have typeclasses or implicit conversions it's difficult to interoperate between any non-standard collection library and other Kotlin code.
      - lolinder 5y ago
        Ah, fair. I've never actually seen that become a problem, but I can see how it would be if I were doing more extensive Java interop.
        lmm 5y ago
        Yeah, if all your code and libraries are Kotlin then there's less risk of a collection being mutated under you (though even then, Kotlin gives you no way to write a method that only accepts an immutable collection - you can write a method that accepts a view-only interface, but it will always be possible to pass a mutable collection and mutate it in parallel while that method is running). But of course in that scenario there's also zero benefit from having compatibility with the Java collections.

lmm 5y ago

Not so IME. Kotlin's nullable types don't play nice with option-oriented APIs (e.g. Java Streams), and you can't make Java types transparently implement Kotlin interfaces (and there's no equivalent to typeclasses), so using Java types with Kotlin libraries is harder than with Scala libraries.

jillesvangurp 5y ago

Exactly. Kotlin was actually explicitly designed to be like this and is directly competing with Java as a drop in replacement for it. Consider e.g. the seamless integration into Spring and Android, which both continue to support Java as well. Writing Android applications in Scala is a bit of an uphill battle (but I've heard of people attempting it). Writing Spring applications in Scala is possible in principle, I guess, but it's just not a thing that is very common or that is supported by Spring. Spring and Android have documentation with code samples in both Java and Kotlin, and extensive Kotlin specific stuff in the form of e.g. extension functions. At this point Kotlin is the preferred language for both even though they both maintain compatibility with Java as well and will for years to come. Spring is about half the server side JVM ecosystem. Android represents a good chunk of frontend usage. Kotlin is a first class citizen for both; Scala just isn't. It has its own frameworks of course but they are kind of niche in comparison. I think it's great that Java is slowly evolving to have features that other languages have. Kotlin supports Java's records as of this week's 1.5.0 release via an annotation. Meaning that if you have Java code that needs to interact with Kotlin code, you can write a data class that from the Java side looks like a record if you put the right annotation on it. It's a compatibility feature that's only relevant if you are planning to use or support Java. Another notable feature that landed with this week's release include sealed interfaces (it already had sealed classes). You can use both with data classes of course.