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

[Ulf Zibis]

Am 27.08.2009 18:44, Kelly O'Hair 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.
>>
>> -Ulf
>>
>>
>
> Regardless of the outcome of this discussion, could we please consider
> separating the changes to the make/tools files from the rest, unless
> there is some dependency between the two.
> So if at all possible, could we get separate changesets on these changes?

No problem, agreed!

>
> ---
>
> As I recall on the line numbers, the issue is that the classfiles will
> permanently record line numbers for the source, so the goal was to make
> sure that regardless where the classfiles came from (open or closed jdk)
> and where the src.zip came from (open or closed jdk), it would all work
> and any debugger will have a fighting chance of showing you the right
> line in the source.
> So these extra blank lines might not look 'nice', but having a debugger
> point you at the wrong lines is much worse.
>

Well, I never had this problem, as I always used matching .class <-> 
.java files, but I can see the point if others had that problem.
Anyway, if (open or closed jdk) sources are different in any other 
matter, the developer would have the same problem (think about different 
copyright headers), and should use matching .class <-> .java file pairs.

OK, next time I don't touch Spp.java, and try to live with blank areas 
on my screen. :-\

-Ulf