gcj 3.0/unicode

Mon Jun 25 21:13:00 GMT 2001

> Maybe the problem is that we are using the 3.x Unicode, but the JDK is
> using the 2.x Unicode. Hmm. Is this lame of us? It seemed
> reasonable when I did it.

Methinks "early", not "lame". Rollout for 3.x (lots of new characters, and
in 3.1 the first officially assigned surrogate pairs) looks tricky, at least
from a macro perspective. Those ducks aren't yet lined up ... :)
> And I seem to remember that when I used the
> 2.x tables I found errors in them. OTOH the online docs pretty clear
> say "Unicode 2.0" (something they didn't say before JDK 1.3, at least
> as far as I remember). Maybe we ought to downgrade. Comments?

I'd say "downgrade". I seem to recall the Unicode revision being part
of the JLS, though that might be wrong. If it's in the language spec,
it's expected that apps will rely on it. And Javadoc specs 2.0 any
place it says more than "Unicode". Re errors -- I've not looked at
the details, maybe they applied various "2.x" errata.
> I must say I'm a bit suprised that anybody relies on this.

Well, when one must rely on "something" ... :)
> It would
> be better not to rely on the precise details if possible. Otherwise
> if Sun ever does move to a newer Unicode standard, your program will
> break. This is true even if all you want is interoperability, because
> everybody isn't going to upgrade their Java implementations at the
> same time.

On the other hand, that logic would say that applications can't ever
rely on java.lang.Character to baseline their own Unicode conformance,
since they couldn't expect that behavior to be stable. I don't expect
many would want their own copies of the Unicode tables, or get them
very consistently right/fast if they did choose to incorporate them.
If/when the JLS gets updated, and the main JVMs follow, that would
seem to be the right time for apps to upgrade. If it doesn't, then at least
they'll have a stable base to build against, and can apply known deltas
when needed.
- Dave