[
https://issues.apache.org/jira/browse/OOZIE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198847#comment-14198847
]
Robert Kanter commented on OOZIE-2043:
--------------------------------------
I've also been looking into JDK8 problems in Hadoop, and many of the causes are
that the iteration order of {{HashMap}} has changed (it was never guaranteed to
remain consistent to begin with). An easy fix is to replace it with a
{{LinkedHashMap}} (which does guarantee a consistent, though possibly
different, ordering).
For {{TestHCatELFunctions.testDataOutPartitions}}, I was figuring the order
changed, and based on similar assert statements, it seemed like the order could
be different even in Java 6/7, so I just added the other order here. Does that
sound okay?
For {{TestLiteWorkflowAppParser.testForkJoinMismatch}}, the forkjoin code goes
through the entire workflow anyway, and the order shouldn't matter; so I
allowed both orders in the error message check.
> Misc test failures against JDK8
> -------------------------------
>
> Key: OOZIE-2043
> URL: https://issues.apache.org/jira/browse/OOZIE-2043
> Project: Oozie
> Issue Type: Bug
> Components: tests
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-2043.patch
>
>
> Using the below procedure, I built Oozie with Java 7 and then built and ran
> the tests with Java 8:
> - set java 7
> - {{mvn clean test -DskipTests}}
> - {{find . -name test-classes | grep target/test-classes | xargs rm -rf}}
> // Delete test classes
> - set java 8
> - {{mvn test -DtargetJavaVersion=1.8}}
> There were 3 test failures:
> - org.apache.oozie.coord.TestHCatELFunctions.testDataOutPartitions
> -- it was expecting {{'region=euro,datastamp=20130230'}} but now got
> {{'datastamp=20130230,region=euro'}}
> - org.apache.oozie.util.TestELConstantsFunctions.testAppendAll
> -- Java 8 changes the behavior of the String.split method to not include a
> leading empty String if the pattern matches the front of the String. To
> remain backwards compatible, the solution here was to emulate this behavior
> so the appendAll method behaves the same as it did with Java 6 and 7.
> -
> org.apache.oozie.workflow.lite.TestLiteWorkflowAppParser.testForkJoinMismatch
> -- it was checking a parameterized error message where the order of the
> parameters switched
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
