Subversive doesn't use Hebrew Calendar. You are right
that NLS support is simple in Subversive, we just use icu4j classes for dates
formatting and simple work with Calendar. Do you mean that Subversive can
completely remove dependency on icu4j and use standard Java
You can safely fall back to using the
Character.isWhitespace(). From all I know, there is in fact no difference
between UCharacter and Character in that particular method. They both fall back
on Unicode and a special set of Java rules.
Also, to my knowledge, the
NLS support provided by the Subversion libraries that you are on top of is
rudimentary. I doubt very much that it goes beyond whats provided by the
standard Java platform which would make the use of ICU4J completely redundant
for all your bundles. Does Subversion support a Hebrew
Igor V. Burilo wrote:
We reviewed Subversive's UI plugin
(org.eclipse.team.svn.ui) and found that it also uses UCharacter class which
is the only one class which makes it impossible to use com.ibm.use.base. We
use only UCharacter.isWhitespace method. Is there any workaround to
replace its usage in order not to have dependency to com.ibm.icu plugin,
probably we can use java.lang.Character instead of it? Is it acceptable that
Subversive has direct dependecy on com.ibm.icu plugin?
Yes, that's the problem. One exampel is the Subversive
adapter. As a response to the new requirement, Subversive now has a direct
bundle requirement to the com.ibm.icu bundle. They have also some code that
uses the UCharacter class which makes it impossible to use the
com.ibm.icu.base bundle even if we'd like to. I have submitted a patch for
this already to the Subversive project that rectifies the problem and
hopefully they will accept it.
I agree you should be able to
avoid using ICU4J in headless applications, if you don't need to build
locale-specific representations of dates, times, etc. We don't use ICU4J at
all in non-UI bundles in Equinox, and the Platform core bundles also don't
use it for the most part. Maybe the answer for you is to avoid the
problematic classes mentioned on http://wiki.eclipse.org/ICU4J altogether, which
would remove any need for ICU4J in Buckminster. Is the problem for you that
you have dependencies that in turn pull in the dependency on ICU4J?
I file that under
yet another time consuming effort made to satisfy the new requirements that
nobody was asking for.
cross-project-issues-dev mailing list