I wanted to be sure everyone was aware of 3 changes coming to ICU4J,
shipped with Eclipse SDK, that will be in Kepler M4 (more specifically,
our I-build on 11/27). [1]
1. The largest change is the major version number. The ICU project has
changed the system by which they do versioning, so this cycle the major
version jumps from 4 to 50. The code itself is (still) just a minor
increment, but for their own (non-Eclipse, non-OSGi) reasons decided to
change the way they do versioning.
In the past we have always recommended people leave the prereq range for
this bundle or imported packages open ended (no upper bound) ... just for
reasons like this ... but if anyone did not heed that advice, you will
need to react now, before M4. Not only would it still be appropriate to
not specify an upper bound, it is far better to leave your lower bound as
low as you can (as low as it currently is) ... you only need to increment
lower bounds, if your code uses something that is only in the higher
version of a bundle (e.g. a new API -- if you only need a fix in a higher
version, not new API, a good technique is to have your bundle specify the
version of API you need (low) but have your feature "require" the bundle
at the fixed version). A good technique for bundles to consume ICU4J is to
use "import package", (because there are actually two bundles the packages
might come from). Hence, your manifest might contain something like:
Import-Package: com.ibm.icu.text;version="3.6.1",
com.ibm.icu.util;version="3.6.1"
But there are some projects that prefer to (or, have to) require the
actual bundle
Require-Bundle: com.ibm.icu;bundle-version="3.4.4"
Note that 4.2.2 was in both Juno and its predecessor Indigo; Helios used
4.2.1. Leaving your lower bound as low as you can, means you will be most
compatible for everyone that "mixes and matches" bundles to create their
own products; they (and you) can avoid split streams if you have no
concrete need to increment lower bound.
2. A change that sounds large, but is believed not, is that there is
technically some API changes in 50.1. These are not due to a change in
ICU4J, per se, but instead in how we in Orbit take the "standard version"
of ICU4J and provide it for Eclipse. Long ago, there were a few tweaks to
the standard ICU4J made specifically for the Eclipse version, so it would
be compatible with "CDC Foundation" libraries. But, that has not been
required for a release or two, and it is dangerous to have two versions of
third-party code "in the wild" that are not perfectly compatible. If you
are recompiling, you there is only one method that's not compatible,
involving "BigDecimal" which we suspect is not in wide spread use, if at
all. If you are interested in binary compatibility, there are 4 other
methods that changed with respect to method arguments, changing "String"
to "CharSequence". If anyone finds issues with these 5 cases, please let
us know in the Orbit bug [2] so we better understand the impact of this
standardization. Attached to the Orbit bug [2] is a table that details the
changes [3]. It provides full signatures, if you wanted to search your
code for the methods involved.
3. There is a special, reduced "implementation" of the full ICU bundle
("com.ibm.icu") which is named "com.ibm.icu.base" that does not actually
implement most of its function, but provides places holders for the APIs
(i.e. packages are the same name so "import package" is still satisfied).
This is for people/projects who a) mostly only care about supporting
English or very simple NL support, and b) are concerned about having a
small footprint, such as for an RCP App, and c) still need a "place
holder" for the dependency packages due to other bundles they require.
(This use assumes use of "import package")
The change that is coming, is that this special packaging will no longer
be provided on the Eclipse Platform download page nor in the Eclipse
repository, but will still be available from Orbit where it has always
been available [4]. We in the platform are trying to reduce/streamline our
builds and packaging and us providing this bundle is redundant with the
Orbit bundle. The current plan is to remove this in both Kepler and in
Juno SR2, but of course the same 4.4.2 version will still be there in the
Juno (composite) repository, just not on DL page. For Kepler, the 50.1
bundle will only be available from Orbit. Again, let us know if this has
impacts we have not anticipated. This should impact hardly anyone in the
release train, but I did notice that "rap examples" appears to use it, so
depending on RAP does their build, they might have to switch to Orbit
repo, if you were not already using that.
Thanks for reading this long note and reacting to any changes required. We
will all be better off over the years ahead. Please say if there are
questions or concerns.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=386766
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=386657
[3] https://bugs.eclipse.org/bugs/attachment.cgi?id=223578
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=395003
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
