sbt 1.3.10


I'm happy to announce sbt 1.3.10 patch release. Full release note is here -

Normally changing the project/ to


would be ok. However, given that the release may contain fixes to scripts and also because your initial resolution would be faster with *.(zip|tgz|msi) that contains all the JAR files, we recommend you use the installer distribution. They will be available from SDKMAN etc.

Zinc 1.4.0-M1


I've just released Zinc 1.4.0-M1. Note this is a beta release and it won't be compatible with future 1.4.x, but I chose a commit fairly close to 1.3.x so it should be usable.

parallel cross building, part 3


sbt-projectmatrix 0.4.0 came pretty close, but there are some issue I ran into when I tried to use it in a real project. First is the lack of % syntax.

It's fairly common for subprojects to depend only from Test configuration, or depend on Compile from Compile, and Test from Test. 0.5.0 adds % to make this possible.

lazy val app = (projectMatrix in file("app"))
  .dependsOn(core % "compile->compile;test->test")
    name := "app"
  .jvmPlatform(scalaVersions = Seq("2.12.10"))
lazy val core = (projectMatrix in file("core"))
    name := "core"
  .jvmPlatform(scalaVersions = Seq("2.12.10", "2.13.1"))

Another feature that's available to Project is .configure(...) method. It takes a vararg of Project => Project functions, and applies them in order. Since some of the builds I deal with uses .configure(...) this helps me migrate from Project to ProjectMatrix.

6 years at Lightbend

I joined Lightbend (then Typesafe) in March, 2014. After six incredible years April 7, 2020 was my last day at Lightbend. I am grateful that I got the opportunity to work with an amazing group of people at Lightbend, partners, customers, and various people I got to meet at conferences. Looking back, before COVID-19 times, it's almost surreal that I was flying to Europe, Asia, and North America every few months to attend conferences and tech meetings.

user-land compiler warnings in Scala, part 2


Last week I wrote about #8820, my proposal to add user-land compiler warnings in Scala. The example I had was implementing ApiMayChange annotation. This was ok as a start, but a bit verbose. If we want some API status to be used frequently, it would be cool if library authors could define their own status annotation. We're going to look into doing that today.

bianlu plant-based hotpot

You know those big napa cabbage no one is probably buying?

They make a tasty stew called 扁炉 (bianlu or "pienlo") supposedly from Guangxi region in China, and has a cult following in Japan. I make a vegetarian version of it.

user-land compiler warnings in Scala


As a library author, I've been wanting to tag methods in Scala that can trigger custom warnings or compiler errors. Why would I want to intentionally cause a compiler error? One potential use case is displaying a migration message for a removed API. A week ago, I sent #8820 to scala/scala proposing the idea of @apiStatus that enables user-land compiler warnings and errors.

equal protection under Eq law


The relationship given to Int and Long should be exactly the same as the relationship third-party library like Spire can write UInt or Rational with the first-class numeric types.

  • We should make 1 == 1L an error under strictEquality
  • We should allow custom types to participate in constant expression conversion using FromDigits

liberty, equality, and boxed primitive types

  • Scala 2.x uses universal equality which allows comparison of Int and String. Dotty introduces "multiversal" strictEquality that works similar to Eq typeclass.
  • Currently both Scala 2.x and Dotty use Java's == to compare unboxed primitive types. This mixes comparison of Int with Float and Double etc.
  • Float is narrower than Int, and Double is narrower than Long.
  • Because Scala transparently boxes Int into java.lang.Integer as (1: Any), it implements cooperative equality for == and ##, but not for equals and hashCode, which emulates widening for boxed primitive types. Many people are unaware of this behavior, and this could lead to surprising bugs if people believed that equals is same as ==.
  • We might be able to remove cooperative equality if we are willing to make unboxed primitive comparison of different types 1L == 1 an error.
Syndicate content