review request for 7022624, convert java.io test to use try-with-resources

Stuart Marks stuart.marks at oracle.com
Tue Mar 1 22:26:44 UTC 2011


On 3/1/11 7:28 AM, Rémi Forax wrote:
>   Le 01/03/2011 10:46, Alan Bateman a écrit :
>> Stuart Marks wrote:
>>> Here's a small webrev with changes to a handful of java.io tests to use TWR.
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/7022624/webrev.0/
>>>
>>> * test/java/io/OutputStreamWriter/Encode.java
>>>
>>> Pretty clearly a ServerSocket is a distinct resource from a Socket returned
>>> from the accept() call. However, does Socket.getInputStream() represent a
>>> distinct resource from the Socket? In this case it seemed most sensible to
>>> unroll them into separate resource variables, but again I could go either
>>> way on this.
>> I wouldn't bother but would instead reduce this down to three resources, maybe:
>>
>> try (ServerSocket listener = ss;
>>      Socket s = listener.accept();
>>      BufferedReader reader = new BufferedReader(new
>> InputStreamReader(s.getInputStream()))
>> {
>>    ...
>> }
>>
>> While you are there, I assume ss should be final.
>
> Local variables declared in a try-with resources are implicitly final.

Alan means the field ss, which is a mutable field written by one thread and 
read by another. I don't think the code as it stands is incorrect, but you have 
to do a fair bit of reading before you can figure out what it's trying to do 
and to verify that it's doing it correctly. Making ss final would help, as the 
field doesn't really need to be mutable. Moving the declaration of ss before 
the constructor would help too. As it stands it looks like the run() method 
reads an uninitialized ss.

s'marks



More information about the core-libs-dev mailing list