review request for 6798511/6860431: Include functionality of Surrogate in Character

[Xueming Shen]

Ulf Zibis wrote:
> Am 27.08.2009 20:03, Xueming Shen schrieb:
>> Ulf Zibis wrote:
>>> Am 26.08.2009 21:01, Xueming Shen schrieb:
>>>>
>>>> > - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see 
>>>> jdk1.7.0/src.zip)
>>>>
>>>> Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the 
>>>> code in the
>>>> generated source file have exactly the same line number as they 
>>>> appear in the
>>>> original source file.
>>>
>>> I have thought that before, but I _don't understand_ the *real 
>>> value* against having "nice" code in externally delivered src.zip.
>>> Some time ago it was always annoying to me when debugger ran in that 
>>> code, or I was just looking, how it works. (endless scrolling and 
>>> often I oversaw the tail behind numbers of blank lines (I don't have 
>>> line numbers on in my editor)).
>>> In contrast in generator output of SingleByte-X.java you don't care 
>>> about line numbers, although it's in private sun package.
>> The original tool spp.sh has the goal of keeping the line numbers in 
>> both the generated source file and the original -X.java file the
>> same, most of the time "we" read the -X.java version when debugging. 
>> My re-writing follows that design/implementation.
>>
>> In case of my SingleByte/DoubleByte-X, first those generated source 
>> files are not exported to public, second, most coding logic
>> is in SingleByte/DoubleByte.java, the generated code is "purely the 
>> holding bag of  constant string tables,
>
> Have you seen my changes to SingleByte-X on 
> https://bugs.openjdk.java.net/show_bug.cgi?id=100098 ? It's a step 
> more to "purely" the holding bag of constant string tables.
I'm reading all those 100xxx one by one. The problem is that you've 
mixed too many things together in one bag and there are
too many "dependencies" among them. There are lots of good 
idea/suggested changes, but it really takes time to figure out which
one is the real goal of one particular patch,  which one has the 
priority, and how to "extract" something out of hundreds of changes
to do it step by step. I can't not just take such huge changeset and 
throw into the JDK.

Sherman