error

Git error: Your local changes to the following files would be overwritten by checkout

When you get the Git checkout error, “Your local changes to the following files would be overwritten by checkout,” one likely cause is that files in the master branch are indeed newer than the files in your feature branch.

But another possibility that I just learned about is that you did a git add, but forgot to do a git commit before trying to switch branches. My current wrong/accidental workflow looks like this:

Fixing the Scala error: java.lang.NoSuchMethodError: scala.Product.$init$

As a note to self, when you see a Scala error message that looks like this:

java.lang.NoSuchMethodError: scala.Product.$init$(Lscala/Product;)V

it probably means that you have a mismatch in the Scala versions you’re using in your project. For instance, I just tried to use a library I compiled with Scala 2.12 with Spark, which was compiled with Scala 2.11, and I got that error message. In this case I was able to resolve the problem by recompiling my library with Scala 2.11.

The `f` string interpolator does not work with Dotty (Scala 3)

If you happen to be using Dotty (Scala 3) and find that the f string interpolator isn’t working, it’s a known bug. (It was implemented with a macro, and the old, experimental macro system has been dropped.) I’m writing this in January, 2019; I don’t know when it will work again. You can use the Java/Scala String.format method until it’s fixed:

val pi = scala.math.Pi
println( "%1.5f".format(pi) )

MacOS/Java AppBundler error: NoSuchFileException: Info.plist

If you’re using the Oracle AppBundler to build a Mac/MacOS application bundle from a Java application and run into this error when running Ant:

NoSuchFileException: <directory path here> Info.plist

I have found that the problem is that I have not set and exported JAVA_HOME. To set and export JAVA_HOME on MacOS 10.12, I use this command in the shell script I use to build my Mac/Java app:

An example of Android StrictMode output (with improper database access)

I was just working with an example of how to use Android’s new Room Persistence Library, and the example I was working with ran some of its code on the main Android thread, also known as its “UI thread.” I knew this was bad, but I wanted to start with someone’s example, and then figure out a good way to get the Room method calls to run on a background thread, such as using an AsyncTask. (The Android docs don’t specify a “best practice” for this atm.)