Warnings Cleanup in java.util.<various> (more from hack day)

[Xueming Shen]

Martijn,

The proposed change is incorrect.

+  value = new String(vb, 0, 0, StandardCharsets.UTF_8);

First, shouldn't it at least be

value = new String(vb, StandardCharsets.UTF_8);

  or

value = new String(vb, 0, vb.length, StandardCharsets.UTF_8);

Second, the "value" will be written out via dos.writeBytes(String) 
later, which only
takes the low-byte of a each char of the target String object.

That "not properly" conversion is actually what we need here to make 
sure the
output will be correctly in utf8. The only "reliable" replacement might 
be to use
"iso8859-1" (not utf_8), but I would recommend keep it un-touched.

-Sherman


On 12/02/2011 03:12 PM, Martijn Verburg wrote:
> Hi Remi,
>
> Sorry, was on my phone earlier - so to clarify, I swapped:
>
> String(byte[] ascii, int hibyte, int offset, int count)
>
> to
>
> String(byte[] bytes, int offset, int length, String charsetName)
>
> The reasoning was that I didn't think the count had any actual value
> in this call and from the deprecated warning on the first constructor:
>
> "This method does not properly convert bytes into characters. As of
> JDK 1.1, the preferred way to do this is via the String constructors
> that take a Charset, charset name, or that use the platform's default
> charset."
>
> Hmm, I can't see another 'safe' constructor that takes a byte[] and a
> count.  Is there another recommended way around this?
>
> Cheers,
> Martijn
>
> On 2 December 2011 22:28, Martijn Verburg<martijnverburg at gmail.com>  wrote:
>> Hi Rémi,
>>
>> Doesn't that then use the deprecated String constructor?
>>
>> Disclaimer - I was involved in that patch :)
>>
>> Cheers,
>> Martijn
>>
>>
>> On Friday, 2 December 2011, Rémi Forax<forax at univ-mlv.fr>  wrote:
>>> On 12/02/2011 08:24 PM, Michael Barker wrote:
>>>> Hi,
>>>>
>>>> We had some late submissions from our hack day participants.  2 more
>>>> patches.  One (j.u.z.ZipEntry) is possibly a little more involved for
>>>> a warnings fix.  It removes a usage of deprecated Date APIs in favour
>>>> of Calendar.  However, the fix results in code that is very similar to
>>>> Apache Harmony implementation.  The other is a couple of fixes for
>>>> generics (j.u.j.Manifest).
>>>>
>>>> Thanks to:
>>>> - Prasannaa
>>>>
>>>> Regards,
>>>> Michael Barker
>>>> mikeb2701
>>> Hi Mickael,
>>> one change to Manifest.java introduces a bug !
>>>
>>> -                byte[] vb = value.getBytes("UTF8");
>>> -                value = new String(vb, 0, 0, vb.length);
>>> +                byte[] vb = value.getBytes(StandardCharsets.UTF_8);
>>> +                value = new String(vb, 0, 0, StandardCharsets.UTF_8);
>>>
>>>
>>> the last line should be:
>>> value = new String(vb, 0, 0, vb.length);
>>>
>>> cheers,
>>> Rémi
>>>