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