Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B3881820D for ; Tue, 9 Jun 2015 15:22:40 +0000 (UTC) Received: (qmail 89426 invoked by uid 500); 9 Jun 2015 15:22:40 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 89392 invoked by uid 500); 9 Jun 2015 15:22:40 -0000 Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.incubator.apache.org Delivered-To: mailing list users@groovy.incubator.apache.org Received: (qmail 89382 invoked by uid 99); 9 Jun 2015 15:22:40 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jun 2015 15:22:40 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id D16C51A487F for ; Tue, 9 Jun 2015 15:22:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.901 X-Spam-Level: *** X-Spam-Status: No, score=3.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id VOopZlFuJJUo for ; Tue, 9 Jun 2015 15:22:25 +0000 (UTC) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id B25B22762B for ; Tue, 9 Jun 2015 15:22:24 +0000 (UTC) Received: by ykfr66 with SMTP id r66so9905281ykf.0 for ; Tue, 09 Jun 2015 08:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=eV6Zy7RZLpOvO+6I7VRykPN7VlImW8aEIX3RQvtkXRQ=; b=PnCf+rKL577TJ9Ze2/yQZHuOJwBAWAt+N8JV/wuzLBRXsxV+kJbRHxKnHh119jQDxE 93EMemH3vPiW6NzQYiWiVUGo/c/M6cqWWUjVOWq73MVEsfe1aTTwvKW+xpG4LkF79+SS UgTvf7Wx1o78UDiqtZgxo8sjT0UuGhDgpa2C2LHCVOJa3DjQoKYccdSyIgKoB5GFKfVC jkq8wVtj6PnQ6x2+fql9SvoykGuK1r6NPJqwRtDhxK7POYIW4IneEplNvYWyechLji7a PdNE5+TN+cRbKO/zmfSgMbRV/DOLWMgHWQ/jUruok0GY83kSlZqjXVnbmE2BpjiVcFdE nWfw== X-Received: by 10.13.200.67 with SMTP id k64mr23802551ywd.125.1433863337971; Tue, 09 Jun 2015 08:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.146.200 with HTTP; Tue, 9 Jun 2015 08:21:57 -0700 (PDT) In-Reply-To: References: From: Keegan Witt Date: Tue, 9 Jun 2015 11:21:57 -0400 Message-ID: Subject: Re: UTF16 BOM in new PrintWriter() vs withPrintWriter() To: users@groovy.incubator.apache.org Content-Type: multipart/alternative; boundary=001a114e4e8eea951205181752c9 --001a114e4e8eea951205181752c9 Content-Type: text/plain; charset=UTF-8 That's an excellent point, Paolo. NioGroovyMethods.newWriter claims (in the JavaDoc) it will write the BOM if needed, but it doesn't because it uses Java's implementation rather than with Groovy's writeUTF16BomIfRequired. None of the methods in NioGroovyMethods use writeUTF16BomIfRequired. Whichever we decide, we should be consistent. -Keegan On Tue, Jun 9, 2015 at 11:08 AM, Paolo Di Tommaso wrote: > I'm wondering if NioGroovyMethods that implement the write methods for > Path should do the same. > > > Cheers, > Paolo > > > On Tue, Jun 9, 2015 at 4:02 PM, Keegan Witt wrote: > >> Cool. I'll wait for PR 36 to be merged first, because I also was >> thinking the Javadoc would be changed from >> is "UTF-16BE" or "UTF-16LE" >> to >> is "UTF-16BE" or "UTF-16LE" (or an equivalent alias) >> >> -Keegan >> >> >> On Tue, Jun 9, 2015 at 9:08 AM, Guillaume Laforge >> wrote: >> >>> >>> 2015-06-09 15:04 GMT+02:00 Keegan Witt : >>> >>>> Created GROOVY-7461 >>>> and PR 36 . >>>> >>> >>> Cool! >>> >>> >>>> How would you feel about a PR to copy the Javadoc comment mentioning >>>> the UTF-16 BOM on File.newWriter to all the other methods that use >>>> writeUTF16BomIfRequired (at least until we decide we're going to >>>> change the current behavior)? >>>> >>> >>> Right, worth it! >>> >>> >>>> >>>> -Keegan >>>> >>>> On Tue, Jun 9, 2015 at 8:17 AM, Guillaume Laforge >>>> wrote: >>>> >>>>> Good point! >>>>> >>>>> 2015-06-09 14:11 GMT+02:00 Keegan Witt : >>>>> >>>>>> That's only available in Java 7. Isn't Groovy still targeting 1.6 >>>>>> for the non-indy version? >>>>>> >>>>>> -Keegan >>>>>> On Jun 9, 2015 7:56 AM, "Guillaume Laforge" >>>>>> wrote: >>>>>> >>>>>>> Well spotted! >>>>>>> >>>>>>> You could also compare with the StandardCharset, instead of going >>>>>>> through the name comparison: >>>>>>> >>>>>>> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html >>>>>>> >>>>>>> 2015-06-09 13:49 GMT+02:00 Keegan Witt : >>>>>>> >>>>>>>> No, it's a Groovy bug. >>>>>>>> >>>>>>>> private static void writeUTF16BomIfRequired(final String charset, final OutputStream stream) throws IOException { >>>>>>>> if ("UTF-16BE".equals(charset)) { >>>>>>>> writeUtf16Bom(stream, true); >>>>>>>> } else if ("UTF-16LE".equals(charset)) { >>>>>>>> writeUtf16Bom(stream, false); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> should be >>>>>>>> >>>>>>>> private static void writeUTF16BomIfRequired(final String charset, final OutputStream stream) throws IOException { >>>>>>>> if ("UTF-16BE".equals(Charset.forName(charset).name())) { >>>>>>>> writeUtf16Bom(stream, true); >>>>>>>> } else if ("UTF-16LE".equals(Charset.forName(charset).name())) { >>>>>>>> writeUtf16Bom(stream, false); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> in org.codehaus.groovy.runtime.ResourceGroovyMethods. We'll >>>>>>>> probably want to fix that regardless of what we decide on the >>>>>>>> *withPrintWriter* question. I'll open a Jira and a PR. >>>>>>>> >>>>>>>> -Keegan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 9, 2015 at 3:21 AM, Guillaume Laforge < >>>>>>>> glaforge@gmail.com> wrote: >>>>>>>> >>>>>>>>> From Groovy's point of view (ie. when you're coding in Groovy), >>>>>>>>> the BOM is automatically discarded when you use one of our reader methods >>>>>>>>> (withReader, etc), so it's transparent whether the BOM is here or not. >>>>>>>>> >>>>>>>>> I tend to think that having the BOM always is a good thing (I even >>>>>>>>> thought that was mandatory), but Groovy should guess the endianness >>>>>>>>> regardless anyway. >>>>>>>>> >>>>>>>>> Happy to hear what others think too about all this though. >>>>>>>>> >>>>>>>>> Guillaume >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-06-08 23:20 GMT+02:00 Keegan Witt : >>>>>>>>> >>>>>>>>>> The code as-is today writes the BOM regardless of platform. I >>>>>>>>>> just tested in Linux with the same results. I think there are 2 parts to >>>>>>>>>> the question of "what's the correct behavior?" >>>>>>>>>> >>>>>>>>>> 1. Should the BOM be written at all, particularly when the >>>>>>>>>> platform is Windows? >>>>>>>>>> 2. Should the behavior of *withPrintWriter* differ (even if the >>>>>>>>>> difference is to be smarter) from the behavior of *new >>>>>>>>>> PrintWriter*? >>>>>>>>>> >>>>>>>>>> *Discussion* >>>>>>>>>> 1. Strictly speaking, yes. Because RFC 2781 >>>>>>>>>> states in section 4.3 to >>>>>>>>>> assume big endian if there is no BOM. However, in practice, many >>>>>>>>>> applications disregard the RFC and assume little-endian because that's what Windows >>>>>>>>>> does >>>>>>>>>> . >>>>>>>>>> Because of this, the behavior could be changed so that when writing >>>>>>>>>> UTF-16LE on Windows, it doesn't write the BOM. But in my opinion, it's >>>>>>>>>> best practice to always write a BOM when working with UTF-16, and Java >>>>>>>>>> should have done this in their implementation of their PrintWriter. >>>>>>>>>> >>>>>>>>>> 2. This is a tough one. Arguably, *withPrintWriter* is doing >>>>>>>>>> the smarter, more correct behavior, but the typical user would assume this >>>>>>>>>> is just a shorthand convenience for newing up a PrintWriter (I certainly >>>>>>>>>> did). So the question is, is it better to just document this difference in >>>>>>>>>> the GroovyDoc? Or to change the behavior to be closer to Java? And if the >>>>>>>>>> latter, what breakages would that cause within Groovy itself? Making that >>>>>>>>>> change could break folks in production, because they could rely on that BOM >>>>>>>>>> being there, in cases for example where the file is created on Windows, but >>>>>>>>>> then processed on Linux or when working with a third party library that is >>>>>>>>>> more picky about the presence of a BOM. >>>>>>>>>> >>>>>>>>>> -Keegan >>>>>>>>>> >>>>>>>>>> On Mon, Jun 8, 2015 at 4:32 PM, Guillaume Laforge < >>>>>>>>>> glaforge@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Now... is it what should be done or not is the good question to >>>>>>>>>>> ask :-) >>>>>>>>>>> Does Windows manages to open UTF-16 files without BOMs? >>>>>>>>>>> >>>>>>>>>>> 2015-06-08 22:17 GMT+02:00 Keegan Witt : >>>>>>>>>>> >>>>>>>>>>>> I forgot to mention that. Yes, I ran the test mentioned in >>>>>>>>>>>> Windows. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 8, 2015 at 3:54 PM, Guillaume Laforge < >>>>>>>>>>>> glaforge@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> That's a good question. >>>>>>>>>>>>> I guess this is happening on Windows? (I haven't tried here, >>>>>>>>>>>>> since I'm on OS X) >>>>>>>>>>>>> I think BOMs were mandatory in text files on Windows. >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-06-08 17:53 GMT+02:00 Keegan Witt : >>>>>>>>>>>>> >>>>>>>>>>>>>> I've always taken a perverse pleasure in character encoding >>>>>>>>>>>>>> problems. I was intrigued by this SO question >>>>>>>>>>>>>> on >>>>>>>>>>>>>> UTF 16 BOMs in Java vs Groovy. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It appears using withPrintWriter(charset) produces a BOM >>>>>>>>>>>>>> whereas new PrintWriter(file, charset) does not. As >>>>>>>>>>>>>> demonstrated here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> File file = new File("tmp.txt")try { >>>>>>>>>>>>>> String text = " " >>>>>>>>>>>>>> String charset = "UTF-16LE" >>>>>>>>>>>>>> >>>>>>>>>>>>>> file.withPrintWriter(charset) { it << text } >>>>>>>>>>>>>> println "withPrintWriter" >>>>>>>>>>>>>> file.getBytes().each { System.out.format("%02x ", it) } >>>>>>>>>>>>>> >>>>>>>>>>>>>> PrintWriter w = new PrintWriter(file, charset) >>>>>>>>>>>>>> w.print(text) >>>>>>>>>>>>>> w.close() >>>>>>>>>>>>>> println "\n\nnew PrintWriter" >>>>>>>>>>>>>> file.getBytes().each { System.out.format("%02x ", it) }} finally { >>>>>>>>>>>>>> file.delete()} >>>>>>>>>>>>>> >>>>>>>>>>>>>> Outputs >>>>>>>>>>>>>> >>>>>>>>>>>>>> withPrintWriter >>>>>>>>>>>>>> ff fe 20 00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> new PrintWriter >>>>>>>>>>>>>> 20 00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this difference in behavior intentional? It seems kinda >>>>>>>>>>>>>> odd to me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Keegan >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Guillaume Laforge >>>>>>>>>>>>> Groovy Project Manager >>>>>>>>>>>>> Product Ninja & Advocate at Restlet >>>>>>>>>>>>> >>>>>>>>>>>>> Blog: http://glaforge.appspot.com/ >>>>>>>>>>>>> Social: @glaforge / Google+ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Guillaume Laforge >>>>>>>>>>> Groovy Project Manager >>>>>>>>>>> Product Ninja & Advocate at Restlet >>>>>>>>>>> >>>>>>>>>>> Blog: http://glaforge.appspot.com/ >>>>>>>>>>> Social: @glaforge / Google+ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Guillaume Laforge >>>>>>>>> Groovy Project Manager >>>>>>>>> Product Ninja & Advocate at Restlet >>>>>>>>> >>>>>>>>> Blog: http://glaforge.appspot.com/ >>>>>>>>> Social: @glaforge / Google+ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Guillaume Laforge >>>>>>> Groovy Project Manager >>>>>>> Product Ninja & Advocate at Restlet >>>>>>> >>>>>>> Blog: http://glaforge.appspot.com/ >>>>>>> Social: @glaforge / Google+ >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Guillaume Laforge >>>>> Groovy Project Manager >>>>> Product Ninja & Advocate at Restlet >>>>> >>>>> Blog: http://glaforge.appspot.com/ >>>>> Social: @glaforge / Google+ >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Guillaume Laforge >>> Groovy Project Manager >>> Product Ninja & Advocate at Restlet >>> >>> Blog: http://glaforge.appspot.com/ >>> Social: @glaforge / Google+ >>> >>> >> >> > --001a114e4e8eea951205181752c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's an excellent point, Paolo. =C2=A0NioGroovyMethods.newWriter claims (in the Java= Doc) it will write the BOM if needed, but it doesn't because it uses Ja= va's implementation rather than=C2=A0with=C2=A0Groovy's=C2=A0writeUTF16BomIfRequired.=C2=A0 None of= the methods in=C2=A0NioGro= ovyMethods=C2=A0use=C2=A0writeUTF16BomIfRequired.

Whichever we decide= , we should be consistent.

-Keegan

On Tue, Jun 9, 2015 a= t 11:08 AM, Paolo Di Tommaso <paolo.ditommaso@gmail.com> wrote:
I'm wond= ering if NioGroovyMethods that implement the write methods for Path should = do the same.=C2=A0


Cheers,
Paol= o
=C2=A0

On Tue, Jun 9, 2015 at= 4:02 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
Cool.=C2=A0 I'll wait for= PR 36 to be merged first, because I also was thinking the Javadoc would be= changed from
=C2=A0 =C2=A0 is &quo= t;UTF-16BE" or "UTF-16LE"
to
= =C2=A0 =C2=A0 is "UTF-16BE" o= r "UTF-16LE" (or an equivalent alias)

-Keegan


On Tue, Jun 9,= 2015 at 9:08 AM, Guillaume Laforge <glaforge@gmail.com> wr= ote:

2015-06-09 15:04 GMT+02:00 Kee= gan Witt <keeganwitt@gmail.com>:
Created GROOVY-7461 and PR 36= .

Cool!
=C2=A0=
How would you fe= el about a PR to copy the Javadoc comment mentioning the UTF-16 BOM on File.newWriter to all the other meth= ods that use=C2=A0writeUTF16BomIfRequir= ed=C2=A0(at least until we decide we're going to change the curr= ent behavior)?

Right, wo= rth it!
=C2=A0

-Keegan

On Tue, Jun 9, 2015 at 8:17 AM, Guillaume Laforge <glafor= ge@gmail.com> wrote:
Good point!

2015-06-09 14:11 GMT+02:00 Keegan Witt <keeganwitt= @gmail.com>:

That's only available in Java 7.=C2=A0 Isn't Groovy still targetin= g 1.6 for the non-indy version?

-Keegan

On Jun 9, 2015 7:56 AM, "Guillaume Laforge&= quot; <glaforge@= gmail.com> wrote:
Well spotted!

You could also compare wit= h the StandardCharset, instead of going through the name comparison:
<= div>http://docs.oracle.com/javase/7/docs= /api/java/nio/charset/StandardCharsets.html

2015-06-09 13:49 GMT+02= :00 Keegan Witt <keeganwitt@gmail.com>:
No, it's a Groovy bug.
<= pre style=3D"background-color:rgb(43,43,43);color:rgb(169,183,198);font-fam= ily:"Courier New";font-size:9pt">private static void wri= teUTF16BomIfRequired(final String charset, final Outp= utStream stream) throws IOExce= ption {
if ("UTF-16BE".equals(charset)) { writeUtf16Bom(stream, true);
 } <= span style=3D"color:rgb(204,120,50)">else if ("UTF-16LE".equals(charset)) {
<= span style=3D"font-style:italic">writeUtf16Bom(stream, false);
 }
}
should be
private static void writeUTF16BomIfRequired(final String charset, final OutputStream stream) throws IOException {
    if ("UTF-16BE".equals(Charset.forName(charset)=
.name())) {
        writeUtf16Bom(stream, true);
 =
   } else if ("UTF-16LE".equals(Charset.forName(charset).name())) {
      =
  writeUtf16Bom(stream, false);
    }
}in org.codehaus.groovy.runtime.ResourceGroovyMethods.=C2=A0 We'll pr=
obably want to fix that regardless of what we decide on the withPrintWri=
ter question.=C2=A0 I'll open a Jira and a PR.

-Keegan<= /font>



On Tue, Jun 9, 2015 at 3:21 AM, Guillaume Laforge <gla= forge@gmail.com> wrote:
From Groovy's point of view (ie. when = you're coding in Groovy), the BOM is automatically discarded when you u= se one of our reader methods (withReader, etc), so it's transparent whe= ther the BOM is here or not.

I tend to think that having= the BOM always is a good thing (I even thought that was mandatory), but Gr= oovy should guess the endianness regardless anyway.

Happy to hear what others think too about all this though.

Guillaume


2015-06-08 23:20 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
The code as-is today writes the BOM regardless of platform.=C2=A0= I just tested in Linux with the same results.=C2=A0 I think there are 2 pa= rts to the question of "what's the correct behavior?"

1.=C2=A0 Should the BOM be written at all, particularly wh= en the platform is Windows?
2.=C2=A0 Should the behavior of <= i>withPrintWriter differ (even if the difference is to be smarter) from= the behavior of new PrintWriter?

Di= scussion
1.=C2=A0 Strictly speaking, yes.=C2=A0 Because RFC 2781 st= ates in section 4.3 to assume big endian if there is no BOM.=C2=A0 However,= in practice, many applications disregard the RFC and assume little-endian = because that's what Windows do= es.=C2=A0 Because of this, the behavior could be changed so that when w= riting UTF-16LE on Windows, it doesn't write the BOM.=C2=A0 But in my o= pinion, it's best practice to always write a BOM when working with UTF-= 16, and Java should have done this in their implementation of their PrintWr= iter.

2.=C2=A0 This is a tough one.=C2=A0 Arguably= ,=C2=A0withPrintWriter is doing the smarter, more correct behavior, = but the typical user would assume this is just a shorthand convenience for = newing up a PrintWriter (I certainly did).=C2=A0 So the question is, is it = better to just document this difference in the GroovyDoc?=C2=A0 Or to chang= e the behavior to be closer to Java?=C2=A0 And if the latter, what breakage= s would that cause within Groovy itself?=C2=A0 Making that change could bre= ak folks in production, because they could rely on that BOM being there, in= cases for example where the file is created on Windows, but then processed= on Linux or when working with a third party library that is more picky abo= ut the presence of a BOM.

-Keegan

On Mon, Jun 8, 2015 at 4:32 PM, Guill= aume Laforge <glaforge@gmail.com> wrote:
Now... is it what shoul= d be done or not is the good question to ask :-)
Does Windows manages t= o open UTF-16 files without BOMs?

2015-06-08 22:17 GMT+02:00 Keegan Wit= t <keeganwitt@gmail.com>:
I forgot to mention that.=C2=A0 Yes,= I ran the test mentioned in Windows.

On Mon, Jun 8, 2015 at 3:54 PM, Guillau= me Laforge <glaforge@gmail.com> wrote:
That's a good questio= n.
I guess this is happening on Windows? (I haven't tried here, sin= ce I'm on OS X)
I think BOMs were mandatory in text files on = Windows.

2015-06-08 17:53 GMT+02:00 Keegan Witt <<= a href=3D"mailto:keeganwitt@gmail.com" target=3D"_blank">keeganwitt@gmail.c= om>:
I've always taken a perverse pleasure in character encodi= ng problems.=C2=A0 I was intrigued by this SO question=C2=A0on UTF 16 BOMs in Java vs Groovy.<= div>
It appears using wit= hPrintWriter(charset) produces a BOM whereas new PrintWriter(file, charset) does not.=C2=A0 As demon= strated here:

File file =3D new <=
span style=3D"margin:0px;padding:0px;border:0px none;color:rgb(43,145,175)"=
>File("tmp.txt")
try {
    String text =3D " "
    String charset =3D "UTF-16LE"

    file.withPrintWriter(charset) { it =
<< text }
    println "withPrintWriter"
    file.getBytes().each { System.=
out.format("%02x ", it) =
}PrintWriter w =3D new PrintWrit=
er(file, charset)
    w.print(text)
    w.close()
    println "\n\nnew PrintWriter"
    file.getBytes().each { System.=
out.format("%02x ", it) =
}} finally {
    file.delete()
}

Outputs

withPrintWriter
ff fe 20 00=20

new PrintWriter
20 00

Is this difference in behavior intenti= onal?=C2=A0 It seems kinda odd to me.

-Keegan



<= font color=3D"#888888">--
<= div>
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet





--
=
Guillaume= Laforge
Groovy Project Manager
Product Ninja &= ; Advocate at Restlet<= br>





--
=
Guillaume= Laforge
Groovy Project Manager
Product Ninja &= ; Advocate at Restlet<= br>





--
Guillaume Laforge
= Groovy Project Manager
Product Ninja & Advocate a= t Restlet

=



--
=
Guillaume= Laforge
Groovy Project Manager
Product Ninja &= ; Advocate at Restlet<= br>




=

--
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

Blog:=C2=A0http://glaforge.appspot.com/<= div>
Social: = @glaforge=C2=A0/ Google+



--001a114e4e8eea951205181752c9--