And in the category of “Strangest Things I Never Knew About Java,” I give you ... CAFEBABE.
What def, val, and var fields in Scala traits look like after they’re compiled (including the classes that extend them)
I generally have a pretty good feel for how Scala traits work, and how they can be used for different needs. As one example, a few years ago I learned that it’s best to define abstract fields in traits using
def. But there are still a few things I wonder about.
Today I had a few free moments and I decided to look at what happens under the covers when you use
var fields in traits, and then mix-in or extend those traits with classes. So I created some examples, compiled them with
scalac -Xprint:all, and then decompiled them with JAD to see what everything looks like under the covers.
I was initially going to write a summary here, but if you want to know how things work under the hood, I think it helps to work through the examples, so for today I’ll leave that as an exercise for the reader.
As a brief note today, here’s an example of stackable modifications in Scala.
Lately I was curious about what
super means when you mix Scala traits into a class or object. A simplified answer is that
super refers to the last trait that’s mixed in, though I should be careful and note that this is an oversimplification.
This can be demonstrated in an example that uses both inheritance and mixins with traits. Given this combination of traits and classes:
This scala-lang.org documentation page shares a good reason to use “sealed” traits and classes: When you created sealed traits, the compiler can easily tell all of the subtypes of your class or trait, and as just one benefit, you don’t need to add a default, “catch-all” case in your Scala
contributors.scala-lang.org has become my favorite website this past week. It’s very interesting to read through the debates about new language features for Scala 3 (Dotty). For instance, in the Make concrete classes final by default discussion I think everyone agrees they wish they had gone that way with Scala 2, but it would cause too many problems if they tried to make this a new standard in Scala 3. The discussion — in addition to reading Effective Java — makes me wish I had used
final before all of my classes.
In another discussion titled, Why does Scala need its own build tool (SBT), someone makes a claim that Martin Odersky and his team created SBT as a build tool solution, and Mr. Odersky replies, “Definitely not my answer. I was always very skeptical of SBT’s approach and remain so.”
I just read a short chapter in the book Effective Java, and realized I was doing something pretty dumb in my own code by always creating my own custom exceptions instead of using other exceptions already intended to be reused in the Java API.
This page is a work in progress, but if you need to create a secondary class constructor in Kotlin, I hope it’s helpful.
If you need to see the data type (or class) of an instance in the Kotlin REPL, you can use the
javaClass method to see that type. Here are a few examples:
Java Design Patterns FAQ: Can you provide an example of the Factory Pattern in Java?
Sure. In this article we'll look at a small-but-complete example of the Factory Pattern ("Factory Design Pattern") implemented in Java.