Bug 254190

Comment 1 Kenn Hussey 2008-12-19 10:21:32 EST

SBVR will not be on the train.

Comment 2 Christian Damus 2009-01-31 17:50:29 EST

OCL uses ICU4J as an optional dependency, now using Import-Package.

Comment 3 James Bruck 2009-02-03 11:06:31 EST

No problematic areas involving ICU4J have been identified in UML2.

Comment 4 Kenn Hussey 2009-02-03 17:27:32 EST

(In reply to comment #3)
> No problematic areas involving ICU4J have been identified in UML2.
> 

Yes, but you must provide a technical reason why ICU4J can't/isn't being used like it is in OCL (for example).

Comment 5 James Bruck 2009-02-09 13:32:11 EST

UML2 can be considered a runtime with no need for string parsing or other "heavy duty" string manipulation (unlike OCL).  The editor provided with UML2 can be considered a "sample" editor, not meant for production use.  UML2 is an EMF generated API and EMF itself does not use ICU4J.  

Comment 6 Michael Golubev 2009-02-10 11:46:21 EST

UML2Tools runtime does not use direct characters manipulation, in particular we don't use any of the methods that were proxy'fied in the OCL UnicodeSupport class (in particular, *codePoint*, toLowerCase* and toUpperCase*). 

There are a few usages of toLowerCase/toUpperCase methods in the tests (only), but I believe that we don't have to switch tests to ICU. If those methods will be used in future we will use ICU versions.

We have changed default GMF templates to generate references to com.ibm.icu.text.MessageFormat instead of java.text.MessageFormat for all of the generated code related to the text parsing. 

All of the other occurrences of MessageFormat in the manually written code were manually changed to icu version.

Regarding all other classes listed at the http://wiki.eclipse.org/index.php/ICU4J#Migration section, UML2Tools doesn't use them, so there are no additional migration required. 

<b>As a result, we believe that U2T supports ICU at the same level of compatibility as, say, OCL component.</b>

Comment 7 Kenn Hussey 2009-03-18 11:36:53 EDT

Ed, please comment on this for XSD.

Comment 8 Ed Merks 2009-03-18 11:38:34 EDT

It's used conditionally.

Comment 9 Kenn Hussey 2009-03-18 11:59:43 EDT

(In reply to comment #5)
> UML2 can be considered a runtime with no need for string parsing or other
> "heavy duty" string manipulation (unlike OCL).  The editor provided with UML2
> can be considered a "sample" editor, not meant for production use.  UML2 is an
> EMF generated API and EMF itself does not use ICU4J.  
> 

James, XSD used ICU4J conditionally; UML2 should too.

Comment 10 James Bruck 2009-03-26 13:58:05 EDT

(In reply to comment #9)
> (In reply to comment #5)
> > UML2 can be considered a runtime with no need for string parsing or other
> > "heavy duty" string manipulation (unlike OCL).  The editor provided with UML2
> > can be considered a "sample" editor, not meant for production use.  UML2 is an
> > EMF generated API and EMF itself does not use ICU4J.  
> > 
> James, XSD used ICU4J conditionally; UML2 should too.


Actually after having looked into this a little more it appears that UML2 already conditionally uses ICU4J in the exact same way as XSD does.   That is to say, UML2 makes use of the comparator in org.eclipse.emf.common/CommonPlugin
- which uses the ICU Collator.
The UMLCommandAction, UMLActionBarContributor, UMLModelWizard and UMLUtil all make use of this.

Comment 11 Kenn Hussey 2009-04-17 14:57:17 EDT

All MDT components participating in the release train are making appropriate use of ICU4J.

Comment 12 Kenn Hussey 2016-10-06 13:05:51 EDT

Closing, as this bug has been fixed for some time.