FYI. Following commits are reverted at r596044. 593469 fix the regression that we have different locale data for Europe/London, along with some fixes for other difference against RI 593024 Fix a bug that SimpleDateFormat.parse does not reload the latest timezone 592434 Apply patch Harmony-5061 which removes the duplicate locale data
On 11/17/07, Tony Wu <[EMAIL PROTECTED]> wrote: > On 11/17/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > > To be clear all these issues are not from migrating from previous > > version of ICU to 3.8. But from removing Harmony code which duplicates > > ICU code. > > So we actually need to fix ICU not Harmony to get our performance and > > other behaviors back. And the problem here could be that we are not > > ICU and we do not have ICU committers, at least as far as I know. Thus > > we can not be sure that needed patches will be integrated ASAP even if > > we will create all needed patches our selves. > yes. > > > > Moreover some patches can contradict with ICU vision. For example > > HARMONY-5085. The problem there that the Harmony method starts to > > return array of ICU classes instead of array of Harmony J2SE public > > API classes. Array scanning with ICU -> Harmony classes conversion > > will degrade performance. So the only way here to fix ICU to return > > public api classes instead of ICU classes. And I'm not sure that ICU > > project will be ready to integrate such a changes. > It is not easy for both them and us. > > > > From the other hand I agree that we do not want to reinvent the wheel > > and keep and support all this internationalization stuff in Harmony if > > we can delegate it to another suitable project. But this project need > > to fit Harmony needs :) > To my knowledge, we have no alternative project except ICU :) > > > > > I suggest the following as a result... > > 1. Revert the patch which removes Harmony code which duplicates ICU. > > 2. File all the found issues to ICU database. > > 3. Create as much patches for ICU to fit Harmony needs as we can and > > provide them to ICU. > > 4. Wait until all these patches will be integrated and new ICU release come. > > 5. Remove ICU duplicating functionality again. > > > > Thoughts? Objections? > I've thought about the reverting. Basically I agree to reverting this > patch for the coming milestone. I will record what I have modified and > revert it soon. > > Still I have some concern and want to discuss with you here. We have > to face some problem which can not be deracinated even if I recommit > the patch at the beginning of next iteration. > > One of them is about implementation detail which may contradict to > ICU's vision as you mentioned on Harmony-5085. > > Another is the performance degradations. I'm afraid that we will > suffer from the delegation even if ICU has no performance issue > itself. > > As I talked in another thread, the perfect solution is that ICU could > contribute their implementation against java SE API to harmony > directly. But I think we have a long way to go to achieve it. > > Meanwhile I suggest setting up some infrastructure on performance. > First, we can have a baseline and try to improve step by step based on > it. Then we could notice the degradation immediately when it happens. > Furthermore, we can get the detail whenever we want to analyze it. > (Sorry if there is one existing and I did not notice.) > > > > > Thanks in advance. > > > > SY, Alexey > > > > 2007/11/16, Sergey Kuksenko <[EMAIL PROTECTED]>: > > > Hi All, > > > > > > I'd like to continue discussion about migration to new ICU which was done > > > by > > > r592434 & r593469 commits. > > > This migration is a big deal and it should be done in any case. > > > However, after migration we got a set of problems like a set of failures > > > and > > > performance degradations. > > > Some of the failures were already fixed, some of them are noticed on > > > http://wiki.apache.org/harmony/MigrateToICU ,some of them are noticed in > > > JIRA like (https://issues.apache.org/jira/browse/HARMONY-5085) and I am > > > afraid that some of them are not yet detected. > > > Performance degradation you can see in JIRAs ( > > > https://issues.apache.org/jira/browse/HARMONY-5129 & > > > https://issues.apache.org/jira/browse/HARMONY-5122) > > > In general we may conclude that performance of SPECjbb2005 with DRLVM > > > decreased by 20%. > > > Moreover, according our results, performance of application servers > > > measured > > > with EAStress degraded 3x times!!! > > > Also, there are a lot of small tests which can show degradation. > > > > > > And the key problem here that we have no so much time before code freeze > > > in > > > December and it is not good to have new milestone release worse then > > > previous. > > > *I suggest to roll back ICU migration till the end of current milestone.* > > > Let's apply these patches exactly after beginning of the next milestone > > > and > > > will work on all stability and performance problems together in next > > > milestone. I hope in that case we will have more time and tune new ICU > > > more > > > efficiently. > > > > > > > > > -- > > > Best regards, > > > --- > > > Sergey Kuksenko. > > > Intel Enterprise Solutions Software Division. > > > > > > > > -- > Tony Wu > China Software Development Lab, IBM > -- Tony Wu China Software Development Lab, IBM
