Community
Participate
Working Groups
Must use ICU4J.
Here's a requirement cast in black and white. Unfortunately EMF cannot build dependencies on libraries larger than EMF itself. It must work stand alone without Eclispe dependencies, so it cannot meet this requirement in the black and white form in which it's stated.
I don't think the size issue alone is valid because there is a 100KB implementation of the ICU4J API that forwards to java.* classes (com.ibm.icu.base). I'm not sure I get the "no Eclipse dependencies" part... isn't EMF Eclipse? ICU4J on the other hand isn't an Eclipse dependency. However I agree that the wording of this requirement is a bit black and white and could use some elaboration. ICU4J is only really needed for collating and assembling translated messages containing certain locale-dependent data such as numbers, dates, currency, etc. This is mostly a concern in GUI code that is presenting such translated strings. The Equinox project, for example, has never found a need for ICU4J's capabilities and doesn't currently use it. EMF might fall into the same boat here if it doesn't currently use java.text.*, or the locale-sensitive classes in java.util (Calendar, TimeZone, Currency, Locale, etc). I would minimally suggest wording like "Must use ICU4J where appropriate" or some such.
Yes, EMF is part of Eclipse, but it also has a long history of running stand alone outside of Eclipse with only EMF plugins/jars on the classpath so that the runtime, models, and even the item providers can be used in any runtime environment. Some of the issues for which ICU4J was needed were also addressed with Java 5.0. E.g., the handling of unicode code points.
Part of SWTBot runs on top of plain SWT/JFace. SWTBot does not use any locale sensitive classes, as such this rather stringent requirement cannot be met by SWTBot. Please advice on how this can be resolved.
Ketan, I think it is safe to assume that "must use ICU4J" implies using ICU4J when required. Specifically, to use ICU4J to replace certain java.* APIs as described on: http://wiki.eclipse.org/ICU4J. If you are not using those classes then there isn't really any way that you *can* use ICU4J. It would be useful to get clarification from the planning council on this point though.
(In reply to comment #5) > Ketan, I think it is safe to assume that "must use ICU4J" implies using ICU4J > when required. Specifically, to use ICU4J to replace certain java.* APIs as > described on: http://wiki.eclipse.org/ICU4J. If you are not using those classes > then there isn't really any way that you *can* use ICU4J. It would be useful to > get clarification from the planning council on this point though. Thanks for the clarification. I did read the page before, and it seems that ICU4J is a drop in replacement for some of java's localization stuff. SWTBot does use the Calendar class, but given that the SWTBot core (that tests plain SWT) is just 432Kb in size(including sources), it does not seem worth bundling ICU4j which is a massive 4.3MB dependency. I'm looking for advice on exception cases where it's OK to *not* use ICU4j. SWTBot core is built on top of plain SWT/junit, and needs to run with a minimum footprint. This also seems to be point that Ed is trying to make in comment #1. The rest of SWTBot that builds on the core does not use the listed classes, and will therefore not be needing ICU4j at all.
THis is a routine mass closing of the previous release umbrella tracking bugs.
