|[wtp-dev] ICU and other M5 related changes coming this week -- coming today!|
It it helps you get an early start, you can create a target with these downloads.
I'll put these into the build's pre-reqs Monday afternoon.
That might give you a few hours to avoid a build break, if you get your code updated in time.
I'll do only the platform change first, unless I hear from Carl he's ready with EMF changes.
What to do about ICU?
Thanks to you that have already made adjustments, but there's still 40 more.
Here's what I recommend,
in all your manifest.mf files.
Red Xs appear.
Take a moment to see if you really need ICU where those red-Xs are.
I've seen a few cases where it was not required. Once in a test plugin. Not required. (If you do, you have some pretty sophisticated tests!). Once I saw in some code that was using StringTokenizer from ICU to parse a doctype element, to get the public and system IDs. The normal Java StringTokenizer would do in this case, Doctypes can not have supplementary characters ... the only thing that StringTokenizer handles over the Java one.
To fix the red Xs, use the following in your manifest.mf files.
Import-Package: com.ibm.icu.util; version="3.8",
You may need only one of those packages.
Maybe others ... those were the only two I saw
in half a dozen cases.
Bonus Question: why no upper bound?
a. icu doesn't follow the rules we do so hard to know where an appropriate bound would be, and
b. For %99.9 of what we use from ICU we are just using the ICU version of a Java API. It will be very very ... no, extremely very ... unlikely that API would ever be broken, even in ICU version 54.
This is all my advice anyway ... I'm sure there are valid alternatives.
I'll probably touch base with the Eclipse PMC to see if this change to ICU version 4 is really needed, and if really needed now, but even if not, we should go ahead and make these changes so we'll be ready for what ever happens.
Back to the top