Community
Participate
Working Groups
In the past we needed ICU4J so Eclipse can support latest Unicode. But with the new JVM cadence Java supports ICU4J pretty much at the same time the JVM does. Keeping uptodate icu4j requires work in Orbit to get it integrated (and used to be non-trivial but this is hopefully improved now). Considering that we are not doing very good work in keeping uptodate icu4j (master has 64.2 while latest is 65.1) we may even face a case where using icu4j is holding off people that run on latest JVM from proper Unicode support. Although, I don't believe that there is anything added in either JVM or ICU4J that is of any practical use for us. Reading http://site.icu-project.org/home/why-use-icu4j most of the reasons to use it are for pre Java 6. I questioned the need for it after discussion with JDT.LS people what/why is it needed as it needlessly add 13MB which is huge size when deployed to thousands of containers. Eclipse RCP apps face the same issue for sure. I bringed this on eclipse-dev mailing list https://www.eclipse.org/lists/eclipse-dev/msg11304.html and so far not a single reason to keep it is given there.
Let's discuss it next Tue on the PMC call.
jdt.ls used to use icu.base (58.2), but since https://github.com/eclipse/eclipse.jdt.ui/commit/3e36b6b6d9c0ea96d785c73f6950915cc8b5a402, JDT requires ICU 60.x which has no base jar. That made jdt.ls size grow 25% overnight. As we're trying to keep a slim distribution, getting rid of icu altogether would be really helpful. The next best thing would be to be able to depend on the thin icu.base distribution, but someone needs to step up and build that specific binary
(In reply to Fred Bricon from comment #2) > jdt.ls used to use icu.base (58.2), but since > https://github.com/eclipse/eclipse.jdt.ui/commit/3e36b6b6d9c0ea96d785c73f6950915cc8b5a402, > JDT requires ICU 60.x which has no base jar. That made jdt.ls size grow 25% > overnight. It was done on 'org.eclipse.jdt.core.manipulation' only (no other bundle in the SDK defines 60.0.0 as minimal version) by Alex without a bug report that would describe the need for that change.
Min version is bumped to 60.0 in https://git.eclipse.org/r/#/c/155955/ (actuall error is in the comments on this gerrit) as in one dev environment that bundle ended up resolving against icu4j 58.x and failed to compile. I would chalenge anyone whoever(if anyone) claims icu4j.base 58.x is enough to build against it to try changing the target file and see for himself. I would bet there are many more places where min version is not set correctly - this is an issue not only with icu4j but a general one where our bundles don't properly specify min version of deps.
(In reply to Alexander Kurtakov from comment #0) > Reading > http://site.icu-project.org/home/why-use-icu4j most of the reasons to use it > are for pre Java 6. That exactly shows why it is still needed unless you can prove that all this is now in Java. An important point is "Updated more frequently than Java". One very good example here is the new Japanese era that got introduced last year and which is a must if you want to sell apps in Japan with Japanese UI/language. ICU implemented this before the era started and Eclipse and its products support it. This is not the case for Java < 13, which means users using one of our supported JREs (Java 8 or 11) would not be able to display the new Japanese era. Another one is "Performance". Are you sure that Java now compares with ICU4J regarding performance? I understand that when focusing on English and some other well known languages/locales one can consider to drop ICU4J.But big companies that want to sell their software in many countries all over the world need to support all those languages/locales correctly. Besides all that, removing ICU4J would break many users and products.
(In reply to Alexander Kurtakov from comment #4) > Min version is bumped to 60.0 in https://git.eclipse.org/r/#/c/155955/ > (actuall error is in the comments on this gerrit) as in one dev environment > that bundle ended up resolving against icu4j 58.x and failed to compile. Do you know which API(s) are used from ICU4J 60.0.0? > I would bet there are many more places where min version is not set correctly > - this is an issue not only with icu4j but a general one where our bundles > don't properly specify min version of deps. I fully agree with that.
(In reply to Dani Megert from comment #6) > (In reply to Alexander Kurtakov from comment #4) > > Min version is bumped to 60.0 in https://git.eclipse.org/r/#/c/155955/ > > (actuall error is in the comments on this gerrit) as in one dev environment > > that bundle ended up resolving against icu4j 58.x and failed to compile. > Do you know which API(s) are used from ICU4J 60.0.0? Compilation failure: [ERROR] /home/akurtakov/git/eclipse.platform.releng.aggregator/eclipse.jdt.ui/org.eclipse.jdt.core.manipulation/common/org/eclipse/jdt/internal/ui/text/JavaWordIterator.java:[216] [ERROR] public void setText(CharSequence newText) { [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] The method setText(CharSequence) of type JavaWordIterator must override or implement a supertype method [ERROR] /home/akurtakov/git/eclipse.platform.releng.aggregator/eclipse.jdt.ui/org.eclipse.jdt.core.manipulation/common/org/eclipse/jdt/internal/ui/text/JavaBreakIterator.java:[426] [ERROR] public void setText(CharSequence newText) { [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] The method setText(CharSequence) of type JavaBreakIterator must override or implement a supertype method [ERROR] 2 problems (2 errors) From my workspace containing very minimal set of bungles. Haven't tried with everything. > > > I would bet there are many more places where min version is not set correctly > > - this is an issue not only with icu4j but a general one where our bundles > > don't properly specify min version of deps. > I fully agree with that.
(In reply to Dani Megert from comment #5) > (In reply to Alexander Kurtakov from comment #0) > > Reading > > http://site.icu-project.org/home/why-use-icu4j most of the reasons to use it > > are for pre Java 6. > That exactly shows why it is still needed unless you can prove that all this > is now in Java. > > An important point is "Updated more frequently than Java". One very good > example here is the new Japanese era that got introduced last year and which > is a must if you want to sell apps in Japan with Japanese UI/language. ICU > implemented this before the era started and Eclipse and its products support > it. This is not the case for Java < 13, which means users using one of our > supported JREs (Java 8 or 11) would not be able to display the new Japanese > era. Pardon me, but how is Japanese era relevant with JDT depending on ICU4J? The fact that e.g. JDT doesn't depend on ICU4J doesn't mean that anyone building apps on top of it can't use it. On the other side http://cldr.unicode.org/index/downloads/cldr-36 is supported in soon to be released Java 14 but not on the ICU4J we are going to ship in March. So people running Java 14 can be holded back by ICU4J version we ship although their JVM is fine. (I have to admit it's as likely as the Japanese era issue if I look at JDT usage of ICU4j.) Now we have examples of the two extremes. What do they prove? IMHO only that every decision have pros and cons. > > Another one is "Performance". Are you sure that Java now compares with ICU4J > regarding performance? Well performance is exactly the reason to try getting rid of it. All containerized apps are paying heavy price in terms of network trafic, memory usage, storage and so on. > > > I understand that when focusing on English and some other well known > languages/locales one can consider to drop ICU4J.But big companies that want > to sell their software in many countries all over the world need to support > all those languages/locales correctly. Nothing prevent companies from using ICU4J where they need it. Even right now there is mixture of ICU4J and JVM features usage in the ecosystem. > > > Besides all that, removing ICU4J would break many users and products. How will it break users? I can envision products failing to build expecting icu4j to be there for them. But users not at all if we go the equinox.ds path - keep shipping it in our update site but nothing requires it from our side.
(In reply to Alexander Kurtakov from comment #8) > Pardon me, but how is Japanese era relevant with JDT depending on ICU4J? This is more relevant in Resources and Team not JDT.
(In reply to Alexander Kurtakov from comment #8) > > > > Another one is "Performance". Are you sure that Java now compares with ICU4J > > regarding performance? > > Well performance is exactly the reason to try getting rid of it. All > containerized apps are paying heavy price in terms of network trafic, memory > usage, storage and so on. Well that's another aspect of "performance". > > I understand that when focusing on English and some other well known > > languages/locales one can consider to drop ICU4J.But big companies that want > > to sell their software in many countries all over the world need to support > > all those languages/locales correctly. > > Nothing prevent companies from using ICU4J where they need it. Even right > now there is mixture of ICU4J and JVM features usage in the ecosystem. If the underlying Platform does not use ICU4J then it won't help to include ICU4J except for their custom code. > > Besides all that, removing ICU4J would break many users and products. > How will it break users? I can envision products failing to build expecting > icu4j to be there for them. But users not at all if we go the equinox.ds > path - keep shipping it in our update site but nothing requires it from our > side. That means more work for all of them. I suggest we discuss this in our next PMC meeting.
(In reply to Dani Megert from comment #9) > (In reply to Alexander Kurtakov from comment #8) > > Pardon me, but how is Japanese era relevant with JDT depending on ICU4J? > This is more relevant in Resources and Team not JDT. We have two separate issues here one is containerized apps using JDT.ls and the other is RCP/headless+containerized. If we can help one of the usecases we should do it and continue discussion for the other one.
(In reply to Alexander Kurtakov from comment #7) > Compilation failure: JDT does not use any API from 60.0.0. JDT had public void setText(CharSequence newText) since 2004. ICU added that method in 60.0.0. No harm yet using 60.0.0 or older ICU4J. However, Lars added @Override last December which now results in compile errors for all ICU4J versions < 60.0.0.
I checked the platform code and we are currently using a mixture of icu4j API and java.text. API. For example, in my big workspace I count: 24 usages of com.ibm.icu.text.SimpleDateFormat 51 usages of java.text.SimpleDateFormat; This is inconsistent and is IMHO a strong argument to move completely to standard java api. I think and inconsistent API usage is dangerous and likely to contain "interesting" bugs. Also lots of other projects have moved already to java.text. (EGit and JGIt) for example and m2e recently. +2 for moving to standard Java.
Regarding Japanese new Era thing: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202088 Even ibm jdk inherited it https://www.ibm.com/support/pages/japanese-era-changes-ibm-sdk-java-technology-edition So even this single reason to ship ICU4J is not needed as this has went down to even Java 7 - and even ancient versions that didn't had requirement on Java 8 would have got this feature for free while now they are locked on icu4j version which doesn't support it.
(In reply to Alexander Kurtakov from comment #14) > Regarding Japanese new Era thing: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202088 > Even ibm jdk inherited it > https://www.ibm.com/support/pages/japanese-era-changes-ibm-sdk-java-technology-edition > > So even this single reason to ship ICU4J is not needed as this has went down > to even Java 7 - and even ancient versions that didn't had requirement on > Java 8 would have got this feature for free while now they are locked on > icu4j version which doesn't support it. Are you talking about ancient Eclipse versions?
(In reply to Dani Megert from comment #15) > (In reply to Alexander Kurtakov from comment #14) > > Regarding Japanese new Era thing: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202088 > > Even ibm jdk inherited it > > https://www.ibm.com/support/pages/japanese-era-changes-ibm-sdk-java-technology-edition > > > > So even this single reason to ship ICU4J is not needed as this has went down > > to even Java 7 - and even ancient versions that didn't had requirement on > > Java 8 would have got this feature for free while now they are locked on > > icu4j version which doesn't support it. > Are you talking about ancient Eclipse versions? Yes.
(In reply to Alexander Kurtakov from comment #16) > (In reply to Dani Megert from comment #15) > > (In reply to Alexander Kurtakov from comment #14) > > > Regarding Japanese new Era thing: > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202088 > > > Even ibm jdk inherited it > > > https://www.ibm.com/support/pages/japanese-era-changes-ibm-sdk-java-technology-edition > > > > > > So even this single reason to ship ICU4J is not needed as this has went down > > > to even Java 7 - and even ancient versions that didn't had requirement on > > > Java 8 would have got this feature for free while now they are locked on > > > icu4j version which doesn't support it. > > Are you talking about ancient Eclipse versions? > > Yes. Thanks for pointing to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8202088. Note though that we had to fix bugs around Japanese Era in Eclipse itself, so no, it would not have worked in older versions of Eclipse for free. Anyway, I agree that the argument itself is void.
I'm a project member of ICU and have been helping to providing support for ICU4J plugin in Eclipse. I don't have any strong opinion that Eclipse platform should use ICU4J or not. I think it's purely depending on whether Eclipse platform needs it or not. I do understand "cons" of including ICU4J in Eclipse platform - mostly size and extra efforts for updates. I just explain some "pros" part here. - Latest Unicode support ICU publishes 2 releases per year and its spring release is aligned to new Unicode release schedule. Unicode.org is trying to make the reference implementation (ICU) available at the time when new Unicode release is published. For example, Unicode 13.0 is the latest Unicode release (March 10, 2020) and ICU 66.1 (March 11, 2020) is the ICU release including Unicode 13.0 data. JDK 14 was released on March 17, 2020, but its Unicode standard level is 12.1, and probably need to wait for JDK 15 for Unicode 13.0 support. - ICU only functionalities There are a bunch of i18n functionalities available in ICU, but not in JDK. Following features are example of some popular ones in ICU, but not available in JDK. -- Plural message formatting -- IDNA2008 compatible international domain name encoding/decoding -- Date/time pattern generator -- Collation implementing Unicode Collation Algorithm -- Advanced locale matcher If Eclipse platform still see the value, but the size of plugin is an issue, we might be able to slice data into core and language packs. For example, ICU project team helped NodeJS/V8 team to integrate ICU4C by slicing data.
The PMC decided to remove it piece by piece from projects where possible and where someone is interested to do it. The ICU bundle itself will stay, and we will follow the API removal process when we are ready to remove it, i.e. no usage in the SDK anymore. https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes
