Done at r758244. Dacapo works for me now
\Harmony\deploy\jdk\jre\bin\java.exe -jar dacapo-2006-10-MR2.jar eclipse ===== DaCapo eclipse starting ===== <setting up workspace...> <creating projects..............................................................> <running tests at level 0...> <performing build tests...> org.apache.ant (not open) opening cleaning building org.junit (not open) opening cleaning building org.eclipse.osgi (not open) opening cleaning building <performing type hierarchy tests...> Hierarchy: org.eclipse.help.internal HelpPlugin <performing AST tests...> AST creation: org.eclipse.jdt.internal.compiler.parser <performing completion tests...> Completion: Completion>Name>Empty Completion: Completion>Name>Empty>No Method <performing search tests...> Searching: indexing ===== DaCapo eclipse PASSED in 43657 msec ===== Regards, Tim Oliver Deakin wrote: > Ill second the rollback for M9. > > Regards, > Oliver > > Tim Ellison wrote: >> Regis wrote: >> >>> Tim Ellison wrote: >>> >>>> Regis wrote: >>>> >>>>> Sian January wrote: >>>>> >>>>>> 8. Dacapo benchmark failure HARMONY-6041 >>>>>> >>>>> I have found the cause of this regression, and had a initial patch, >>>>> but >>>>> still has 1 test failure in WinFileTest. So I suggest revert >>>>> r727327 if >>>>> it blocked M9. >>>>> >>>> Yes, I think that we should probably roll back r727327 and re-open >>>> HARMONY-6041. >>>> >>> Agree. We have a lot of duplicated code which dealing with path name, >>> we'll have enough time to refactor it in next milestone. >>> >>> >>>> It seems that the patch was not sufficient, and the subsequent attempts >>>> to fix things (HARMONY-6090, HARMONY-6091, HARMONY-6092) have not been >>>> applied, and may cause further disruption. >>>> >>>> Since the original problem was found by inspection, I propose we leave >>>> it as a known issue with M9 and try again after the code freeze. >>>> >>> +1 >>> >> >> Any committers second the proposal to rollback? >> >> Regards, >> Tim >> >> >> >