Hi everyone! Yesterday AGP 4.2.0 was released and JDK 11 it’s now bundled with it. I just updated t...

# android

[Guilherme Lima Pereira]

Hi everyone!

Yesterday AGP 4.2.0 was released and JDK 11 it’s now bundled with it. I just updated to AGP 4.2.0 and I’m now trying to get the project to work with JDK 11. It’s compiling perfectly, but I’m having issues on unit tests when comparing two formatted strings to currency (NumberFormat.getCurrencyInstance).

Learning about some changes from JDK 8 to JDK 11, I found that on JDK 9 they’ve enhanced some things related to Locale. One of the things is the usage of CLDR.

The issue with CLDR is that is uses NBSP instead of normal whitespace. The problem with NBSP is that is not straightforward for the developers to add it during unit tests.

I tried to solve it by adding -Djava.locale.providers=COMPAT on gradle.properties (org.gradle.jvmargs), but it keeps using NBSP 😢

Does anyone has suffered with it or have any idea how to address this issue?

[Guilherme Lima Pereira]

This is how I found the usage of nbsp

[ephemient]

I expect you need to add it to your tests, not gradle:

test {
    jvmArgs '-Djava.locale.providers=COMPAT'
}

but note that IntelliJ won't use those JVM args if it's running the test classes itself, so... either manually fix the run configuration every time, or fix your tests

[ephemient]

I recall hearing that Android Studio Arctic Fox will default to running tests through Gradle, but until then...

[ephemient]

probably something like

android {
    testOptions {
        unitTests.all {
            jvmArgs '-Djava.locale.providers=COMPAT'
        }
    }
}

in an Android module

[Guilherme Lima Pereira]

Thanks for the suggestion @ephemient!

Unfortunately it didn’t work 😞 It’s still using nbsp

[ephemient]

test run from gradle or from the IDE?

[ephemient]

as I said, it won't affect the IDE's run configuration, you need to change that manually.

[ephemient]

so... really just fix the test

[Guilherme Lima Pereira]

I tested it running from the IDE

[Guilherme Lima Pereira]

Running from the cmd it worked indeed! Thanks a lot!

[ephemient]

Run » Edit Configurations… » (select test configuration) » Configuration » VM options

[ephemient]

you'll need to do that every single time the IDE automatically creates a run configuration for your test

[Guilherme Lima Pereira]

Yeah, I’ll need to find a way to fix that, cause we’re about ~40 devs working on the same code base😅

[ephemient]

so... it would really be better just fix the test. just write \u00A0 or regex match with \s?

[Guilherme Lima Pereira]

the issue is that we have about 100 tests with the issue and this number can (and probably will) grow

[Guilherme Lima Pereira]

For example:

val result = subject.mapFrom(cardResponse = cardResponse)

        val expected = PricingCatalogItemCardModel(
            unitPrice = "R$ 4,99",
            originalUnitPrice = null
        )

        assertEquals(expected, result)

[Guilherme Lima Pereira]

maybe I’d have to change "R$ 4,99", to "R$\u00A04,99", which not very straightforward for the devs

[ephemient]

you'll have to fix them eventually... Android uses CLDR too

[Guilherme Lima Pereira]

you’ve got a point

[ephemient]

assertThat(result, matchesPattern("""R\$\s4,99"""))

may be an option as well

[Guilherme Lima Pereira]

interesting!

[ephemient]

(example using hamcrest, which junit 4 already partially pulls in, but something like that should be available in every assertion framework)

[Mahmoud Mabrok]

Try using robolectric for testing
As it has some mocking classes for such files as Numberformat as I think

[ephemient]

it doesn't, and NumberFormat is a JRE class, not an Android class. it never needs to be mocked

[ephemient]

now, if you were talking about android.icu.text.NumberFormat... then yes, Robolectric does ship an implementation, because that is an Android class. but that is not affected by JDK changes