LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Jun 20 17:32:00 UTC 2016
Hi Alexander,
You will need to file a WebBug at http://bugreport.java.com/ .
The other failures are likely due to an out-of-date libjfxwebkit.dylib.
The native webkit build isn't enabled by default and most developers
don't build it, so when you build FX it will take it from your boot JDK.
You can either download the latest JDK 9 EA build and copy
libjfxwebkit.dylib from there, or you can build webkit:
gradle -PCOMPILE_WEBKIT=true
-- Kevin
Alexander Nyssen wrote:
> Hi Kevin,
>
>> Am 17.06.2016 um 17:44 schrieb Kevin Rushforth
>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>:
>>
>> It seems like the test is not written to handle multiple Locales, so
>> if you could file a bug, we'll fix it (I note that it could probably
>> be in a "BeforeClass" block as one-time setup rather than setting it
>> before each test).
>
> of course, a ‚BeforeClass' is more appropriate here. I just wanted to
> point out that its an invalid assumption regarding the default locale
> that causes the tests to fail. Will I be able to do that via JIRA
> directly after the OCA has been processed, or will ‚WebBug‘ still be
> the way to go?
>
>>
>> As for your other test failures, I presume you are using FX 9-dev?
>> Are you running in "legacy" mode (building and testing with jdk-9+109
>> with no JIGSAW_HOME being set)? If so, I haven't seen that error
>> before. We continuously run tests in this mode with no failures. Did
>> you remove (and not just rename) jfxrt.jar from your jdk-9 boot JDK?
>
> Yes, I am targeting FX-9-dev. Following the instructions
> at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables,
> I setup JAVA_HOME and JDK_HOME to point to jdk-9_ea109 (without
> jfxrt.jar) as well as JIGSAW_HOME to point to jdk-9_ea122. The
> instructions do not seem to mention something as „legacy“ mode. Maybe
> you should update them (at least the ’Testing’ section) to make that
> clear, especially if all control tests fail in ‚non-legacy‘ mode.
>
> If I remove the JIGSAW_HOME and apply the above mentioned fix
> to LocalDateTimeStringConverterTest, all tests pass successfully,
> except the following three web tests:
>
> test.javafx.scene.web.JavaScriptBridgeTest >
> testMethodCallWithWrapperObjects FAILED
> java.lang.NullPointerException
> at
> test.javafx.scene.web.JavaScriptBridgeTest.lambda$testMethodCallWithWrapperObjects$8(JavaScriptBridgeTest.java:385)
>
> test.javafx.scene.web.JavaScriptBridgeTest >
> testJSStringToJavaCharSpecilization FAILED
> java.lang.AssertionError: expected:<111> but was:<0>
> at org.junit.Assert.fail(Assert.java:91)
> at org.junit.Assert.failNotEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:126)
> at org.junit.Assert.assertEquals(Assert.java:470)
> at org.junit.Assert.assertEquals(Assert.java:454)
> at
> test.javafx.scene.web.JavaScriptBridgeTest.lambda$testJSStringToJavaCharSpecilization$9(JavaScriptBridgeTest.java:404)
>
> test.javafx.scene.web.LoadTest > loadJarFile FAILED
> java.lang.AssertionError: netscape.javascript.JSException:
> ReferenceError: Can't find variable: jsr0
> at test.javafx.scene.web.TestBase.submit(TestBase.java:205)
> at test.javafx.scene.web.TestBase.executeScript(TestBase.java:216)
> at test.javafx.scene.web.LoadTest.loadJarFile(LoadTest.java:285)
>
> Caused by:
> netscape.javascript.JSException: ReferenceError: Can't find
> variable: jsr0
>
> Any idea about these? I am running Mac OS X El Capitan on my machine.
> Maybe that’s important.
>
> Regards,
> Alexander
>
>
>>
>> -- Kevin
>>
>>
>> Alexander Nyssen wrote:
>>> Hi,
>>>
>>> I could resolve this by changing the setup method of LocalDateTimeStringConverterTest to the following:
>>>
>>> @Before public void setup() {
>>> // tests require that default locale is English
>>> Locale.setDefault(Locale.ENGLISH);
>>> }
>>> Maybe that should be added to make it robust.
>>>
>>> Unfortunately, I am now stuck, because the succeeding controls tests fail, as it seems all with the following NoClassDefFoundError:
>>>
>>> test.javafx.scene.control.TreeViewTest > test_rt_31200_tableRow FAILED
>>> java.lang.NoClassDefFoundError: javafx.scene.control.Control
>>> at test.javafx.scene.control.TreeViewTest.setup(TreeViewTest.java:121)
>>>
>>> 7133 tests completed, 6326 failed, 239 skipped
>>> :controls:test FAILED
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> The build succeeded (using gradle). Any idea what might be wrong?
>>>
>>> Regards,
>>> Alexander
>>>
>>>
>>>> Am 17.06.2016 um 07:56 schrieb Alexander Nyssen <alexander at nyssen.org>:
>>>>
>>>> Hi,
>>>>
>>>> in order to be able to contribute to OpenJFX, I am currently trying to set up my development environment. After checking out the latest head from hg clone http://hg.openjdk.java.net/openjfx/9-dev/rt <http://hg.openjdk.java.net/openjfx/9-dev/rt>, compilation succeeds, but tests fail with the following:
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_parser[0] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_null_parser[0] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_parser[1] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_null_parser[1] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_parser[2] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
>>>>
>>>> test.javafx.util.converter.LocalDateTimeStringConverterTest > converter_with_specified_formatter_and_null_parser[2] FAILED
>>>> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but was:<12 Januar[] 1985, 12:34:56>
>>>> at org.junit.Assert.assertEquals(Assert.java:123)
>>>> at org.junit.Assert.assertEquals(Assert.java:145)
>>>> at test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
>>>>
>>>> It seems they are not robust against having a default locale different to en_US (Januar is the correct German translation for January; my default locale seems to be de_DE).
>>>>
>>>> Regards,
>>>> Alexander
>>>>
>>>>
>>>
>
More information about the openjfx-dev
mailing list