[rfc][icedtea-web] ConsoleOutputPane formatting fix & cleanup

[Jacob Wisor]

On 06/23/2014 05:07 PM, Jie Kang wrote:
> ----- Original Message -----
>> On 06/20/2014 04:29 PM, Jacob Wisor wrote:
>>> Hello!
>>>
>>> While localizing I needed to look up some code in order to understand the
>>> semantics of some
>>> messages. This cought my attention on ConsoleOutputPane. So, I provide some
>>> some formatting and typo
>>> fixes for ConsoleOutputPane.
>>>
>>> Thank you for reviewing!
>>>
>>> Jacob
>>>
>>> p.s.: There are still some easy to fix UI inconsistencies. ;-)
>> hi!
>>
>> Thanx for reformating.
>>
>>
>> Most of the fixes looks ok.
>>
>> I have found no logic change, I hope i have not missed some.
>>
>
> I read/tested the patch as well and I see no glaring logic change either, though I can't rule out missing some edge case.

Yep, no logic change intended. ;-)

>> Well Although instanceof is null-proof, I like to have it more visible by
>> explicit != null. But this
>> nvm.
>>
>>
>> The only change against which I have - just personal  - objections is the
>> move of initComponents'
>> declarations to constructor. I can see that you did it to allow variables to
>> become final. But is it
>> really worthy?
>>
>>
>> Except that, and except I overlooked some change in logic, ok to for head.
>>
>> For the final+constructor and non-final/separate method  I would like to hear
>> third party voice. Or
>> yours :)
>
>
> I think non-final/separate is okay for future code-reuse, but in this case, I prefer 'final' since these components are definitely final components. It is more 60% prefer, not really 90% or 100% prefer though since the change is so slight.

I do not really like this style either but it owes to the Java Language 
Specification that final fields are always finally assigned outside of the 
constructor. This is a little bit awkward of Java because this is not required 
by the JVM Specification. Nevertheless, these fields never get changed during 
ConsoleOutputPane's lifetime, so for the purpose of proper run time behavior 
these fields should be final, even when the resulting source code does not serve 
everyone's aesthetic feelings. ;-)
And, although I do favor design over run time, this is not a design decision but 
a mere shortcoming of the Java programming language. So, that's the way it is in 
Java.

Thank you for reviewing.

Jacob