Community
Participate
Working Groups
Now that ICU4J will be in the build for M4, we need to work on getting the required changes into the platform. Doug will submit the changes as a set of patches which I will delegate to plugin owners.
I'm going to punt this back to you to get it out of the bucket.
To update, the remaining issues are: 1. Evolve build process to be able to build using pre-jarred plugins with source 2. Build wrapper (aka stub aka base) plugin as pre-jarred plugin with source. Need to be able to interchange the stub plugin for the real ICU4J and vice-versa. 3. Change Eclipse SDK code to use ICU4J API. 4. Investigate fragmenting ICU4J to reduce footprint.
Added API to JFace (new class called ComparatorViewerSorter) for M5. We still need to complete 1-4 from comment #2.
1 is complete (for M5) but still in it's early stages of being in the builds - see bug 127495 for more details of the problems encountered. Still need to look at 2, 3, and 4 for M6. Updating target to reflect this.
FYI, while porting some of my plugins to use ICU4J, I found that ICU's StringTokenizer behaves a little differently than Java's. If you specify you want delimiters returned as tokens StringTokenizer(String, String, true), delimiters that are next to each other are grouped into 1 token, rather than separated with each delimiter being 1 token. For example: StringTokenizer(" my\r\n", " \r\n", true) ICU's tokens = [" ","my","\r\n"] Java's tokens = [" "," ","my","\r","\n"] This may effect platform code that uses StringTokenizer and expects a certain result.
Sounds like an ICU bug. You should report it through the ICU project: http://dev.icu-project.org/cgi-bin/icu-bugs
I believe someone else is already going to report it. I was just informing you guys of the bug in case you run into it during porting.
Amy, That's not the way open source development works. ICU depends on people like you logging bugs and following up to improve the quality. Doug Felt works on ICU and is cc'ed on this bug. I encourage you to go the extra step here as you've already identified the problem.
Doug Felt already opened the bug: http://dev.icu-project.org/cgi-bin/icu-bugs/strings?findid=5061
Regarding comment #3, I could not find ComparatorViewerSorter in 3.2M6. I imagine ComparatorViewerSorter is supposed to replace ViewerSorter (and not use java.text.Collator), which is used in StructuredViewer. I did find a ViewerComparator, and its JavaDoc does say it is to be used in StructuredViewer, but I could not actually tell how StructuredViewer would be using it since ViewerSorter extends ViewerComparator and not the other way around. So it's not like I could call setSorter() and pass in ViewerComparator instead.
Boris, there is an API issue here that we seem to have overlooked (see previous comment). We should discuss.
(In reply to comment #11) As I understood it, the idea was to introduce ViewerComparator into the base class hierarchy, and then sometime later update some APIs taking ViewerComparator to take ViewerComparator instead. I'm not sure who was going to do that work, or when. Subclasses of ViewerSorter, and users of ViewerSorter who expose it or its Collator (externally or to subclasses) wouldn't be able to switch over either. I'm not sure how many candidate APIs there are.
Amy, I should mention your concern in comment #10 is addressed by bug 135284.
Patches are integrated - marking fixed.
Verified in 20060425-0010
