You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "lucas theisen (JIRA)" <ji...@apache.org> on 2014/11/07 18:54:33 UTC

[jira] [Created] (DIRSERVER-2015) Build of xdbm fails when using java 8

lucas theisen created DIRSERVER-2015:
----------------------------------------

             Summary: Build of xdbm fails when using java 8
                 Key: DIRSERVER-2015
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-2015
             Project: Directory ApacheDS
          Issue Type: Bug
    Affects Versions: 2.0.0-M18
         Environment: Windows 7, Java 8
            Reporter: lucas theisen


When attempting to build using:

{code}
$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
{code}

It fails with:

{code}
testAndCursorWithCursorBuilder(org.apache.directory.server.xdbm.search.impl.AndCursorTest)  Time elapsed: 0.034 sec  <<< FAILURE!
org.junit.ComparisonFailure: expected:<...000-0000-00000000000[5]> but was:<...000-0000-00000000000[8]>
        at org.junit.Assert.assertEquals(Assert.java:115)
        at org.junit.Assert.assertEquals(Assert.java:144)
        at org.apache.directory.server.xdbm.search.impl.AndCursorTest.testAndCursorWithCursorBuilder(AndCursorTest.java:183)

testAndCursorWithManualFilter(org.apache.directory.server.xdbm.search.impl.AndCursorTest)  Time elapsed: 0.004 sec  <<< FAILURE!
org.junit.ComparisonFailure: expected:<...000-0000-00000000000[5]> but was:<...000-0000-00000000000[8]>
        at org.junit.Assert.assertEquals(Assert.java:115)
        at org.junit.Assert.assertEquals(Assert.java:144)
        at org.apache.directory.server.xdbm.search.impl.AndCursorTest.testAndCursorWithManualFilter(AndCursorTest.java:218)
{code}

Discussion on this issue over irc:

{quote}
\[11:07] <lucastheisen> xdbm unit tests fail on windows
\[11:08] <lucastheisen> testNestedAndnOr(org.apache.directory.server.xdbm.search.impl.NestedFilterTest)  Time elapsed: 0.004 sec  <<< FAILURE! org.junit.ComparisonFailure: expected:<...000-0000-00000000000\[5]> but was:<...000-0000-00000000000\[9]>         at org.junit.Assert.assertEquals(Assert.java:115)         at org.junit.Assert.assertEquals(Assert.java:144)         at org.apache.directory.server.xdbm.search.impl.NestedFilterTest.testNestedAndnOr(NestedFilterTest.java:193)
\[11:28] <elecharny> hmmm
\[11:30] <elecharny> same failure for me :/
\[11:35] <lucastheisen> i dont know what xdbm is...
\[11:35] <elecharny> lucastheisen: that's extratordinary, it fails when run in eclipse, not when I run the tests in the CL
\[11:36] <lucastheisen> mine failed on CL, though i run from cygwin, so that could add more fuzziness to the mix
\[11:36] <elecharny> Running org.apache.directory.server.xdbm.search.impl.NestedFilterTest
\[11:36] <elecharny> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.217 sec - in org.apache.directory.server.xdbm.search.impl.NestedFilterTest
\[11:37] <elecharny> what Java version are you using ?
\[11:37] <elecharny> mine is 1.7.0_55
\[11:38] <lucastheisen> ltheisen@MM206678-PC ~/svn/apacheds-trunk-with-dependencies/apacheds $ java -version java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
\[11:50] <elecharny> this is another fucking JVM issue
\[11:50] <elecharny> when I run the test with 1.7, it passes
\[11:50] <elecharny> when I switch to 1.8, it fails
\[11:50] <elecharny> now to understand why...
\[11:54] <lucastheisen> dam.
\[11:55] <elecharny> there is another issue : the candidate count seems wrong
\[11:55] <elecharny> (|:\[5](&:\[3](cn=j*:\[3])(sn=w*:\[∞]))(ou=apache:\[2]))
\[11:55] <elecharny> should be
\[11:55] <elecharny> (|:\[5](&:\[3](cn=j*:\[6])(sn=w*:\[∞]))(ou=apache:\[2]))
\[11:57] <elecharny> ah, no
\[12:04] <elecharny> damn it…
\[12:04] <elecharny> I see at least 2 problems here
\[12:04] <elecharny> - the count for cn=j* is wrong, it should be 6
\[12:05] <elecharny> - there is most certainly an issue with some internal java class we use to store the candidates, it has probably changed between Java 7 and Java 8
\[12:05] <elecharny> so you get the entries in a different order
\[12:06] <elecharny> that requires some investigation
\[12:06] <elecharny> I don't think the API is in cause here, it's really an ApacheDS issue
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)