1

It's a very strange problem.

I have a simple class which can decode a base64 string and get the first part before the ::

import scala.util.{Success, Try}
import org.apache.commons.codec.binary.Base64

class IdDecoder {

  def decode(token: String): Option[String] = {
    if (token.isEmpty)
      None
    else
      Try(new String(Base64.decodeBase64(token.getBytes)).split(":")(0)) match {
        case Success(id) => Some(id)
        case _ => None
      }
  }

}

And define a method which decodes the string 

object StrangeToken {

  def main(args: Array[String]) {
    decode()
  }

  def decode() = {
    val token = "InternalServerError"
    val Some(id) = (new IdDecoder).decode(token)
    println("### StrangeToken's id len:" + id.length)
    id.toCharArray.foreach(c => println(c.toInt))
    id
  }

}

Running as plain code, id's length is 15

When I run it in sbt's console or in IDEA or in production, the result is:

### StrangeToken's id len:15
34
123
94
65533
118
65533
73
65533
65533
122
65533
43
0
0
0

Running as spec2 test, id's length is 14

But when I run it in spec2, as:

"id decoder" should {
  "get decoded string whose length is 15" in {
    val id = StrangeToken.decode()
    id.length must be equalTo 15
  }
}

This test failed and the result is:

### StrangeToken's id len:14
34
123
94
198
118
8226
73
205
212
122
177
43
198
228

I'm not sure why the result is different in spec2.

Freewind
  • 193,756
  • 157
  • 432
  • 708

1 Answers1

1

I happen to get 14 in my sbt console, where my sbt script specifies -Dfile.encoding=UTF8.

Your new String(bytes) uses the default encoding. You can supply a charset to the constructor.

Second guess:

You have different versions of the -codec library in Test configuration and otherwise.

When I bump the version back to 1.1, I also get 15.

To be honest, that was going to be my second guess originally. There is a lot of history in the -codec project, so incompatibilities or behavior changes are not amazing. Presumably the behavior that elicits the number 14 is more conforming.

It's also not amazing that a "common" dependency appears twice in dependency trees.

som-snytt
  • 39,429
  • 2
  • 47
  • 129
  • I have `-Dfile.encoding=UTF8` in my sbt file too when I see this problem. I tried to specify the charset `new String(Base64.decodeBase64(token.getBytes), "UTF-8)`, but still get `15` – Freewind Apr 08 '14 at 01:48
  • @Freewind Added the second guess. Forgive me for not bisecting for the version that changed the behavior. – som-snytt Apr 08 '14 at 03:45
  • your guess is correct! I just found in the functional code, it uses `codec-1.3`, but in the test, it uses `codec-1.6`. Now I declare it explicitly as `codec-1.9`, everything works well. Thank you! – Freewind Apr 08 '14 at 04:11