July 2012 - core-libs-dev

RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException
by Joe Wang 12 Jul '12

12 Jul '12

Hi Paul, This is now for 7u8, so I started a new thread. As we discussed, I've removed the hack of using escapeNonUSAscii. In this regard, we're now in sync with the source code in Xerces. Here's the webrev: http://cr.openjdk.java.net/~joehw/7u8/7166896/webrev/ Thanks, Joe

3 3

[PATCH] Sunbug 6358355: Rounding error in Float.parseFloat
by Louis Wasserman 12 Jul '12

12 Jul '12

Float.parseFloat doesn't currently round correctly, or even monotonically, in certain cases. In particular, the following test program prints false: public class Foo { public static void main(String[] args) { System.out.println(144115196665790480f <= 144115196665790481f); } } A patch is attached, and can also be found at https://bugs.openjdk.java.net/show_bug.cgi?id=100208. There was a comment in sun.misc.FloatingDecimal claiming this would take 400 lines of code, but by eliminating the (fallacious) "sticky rounding" logic, and just duplicating the double-parsing logic, it only ends up costing ~40 net lines of code added. The added code is mostly identical to the preexisting double-parsing code. This is a prerequisite for the separate, previously sent patch improving the performance of BigInteger.doubleValue() and floatValue(). (Testing for that patch revealed this bug.) Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

Re: Code Review Request: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node
by Chris Hegarty 12 Jul '12

12 Jul '12

Thanks Kurchi, looks fine. -Chris Kurchi Hazra <kurchi.subhra.hazra(a)oracle.com> wrote: >On 7/11/12 4:24 PM, Chris Hegarty wrote: >> On 12 Jul 2012, at 00:15, Kurchi Hazra<kurchi.subhra.hazra(a)oracle.com> wrote: >> >>> Thanks for the review Alan. Updated webrev: >>> http://cr.openjdk.java.net/~khazra/7160252/webrev.01/ >> Looks fine. >> >> Trivially, is there an opportunity to make any fields final since initFields is replaced with a constructor? > >Thanks for pointing that out. How about: >http://cr.openjdk.java.net/~khazra/7160252/webrev.02/ > >- Kurchi > >> >> -Chris. >> >>> - Kurchi >>> >>> On 7/11/12 5:45 AM, Alan Bateman wrote: >>>> On 26/06/2012 22:57, Kurchi Hazra wrote: >>>>> Hi, >>>>> >>>>> On Mac OS X, for Preferences, a new child added event was not being >>>>> delivered to a NodeChangeListener since the existing code depended on the >>>>> return value of addNode() in the native code, which returns true if a new >>>>> node is added. However, since addNode() was being called erroneously after >>>>> a child node is already added to an existing node, addNode() would always >>>>> return false, resulting in thw new node event never being delivered. >>>>> >>>>> This fix propagates the required information of whether a node is added from >>>>> the method adding the child node itself. In addition, I cleaned up the >>>>> constructors in MacOSXPreferences.java and added a test >>>>> (AddNodeChangeListener.java) to cover this case. >>>>> >>>>> Finally, there were two prefs tests in ProblemList.txt which are now passing, >>>>> I have removed these from the ProblemList too. >>>>> >>>>> >>>>> >>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7160252 >>>>> Webrev: http://cr.openjdk.java.net/~khazra/7160252/webrev.00/ >>>>> >>>>> Thanks, >>>>> Kurchi >>>> It doesn't look you got a reviewer for this one. >>>> >>>> I looked at the changes and the fix seems okay to me. The only odd thing is that now that you have the 5-arg constructor then it can initialize all the fields allowing you to get rid of initFields and also setNew. Also I assume it means you can close 7150557. >>>> >>>> -Alan. >>>> >

1 0

Request for approval for bug# 7177216 - native2ascii changes file permissions of input file
by Mala Bankal 11 Jul '12

11 Jul '12

HI, Request approval for : 7177216 - native2ascii changes file permissions of input file for 6-open webrev : http://cr.openjdk.java.net/~mbankal/7177216/webrev.00/ This webrev fixes bug# 7177216 (regression reported in jdk6u33.) Native2ascii tool changes permission of file. Caused due to 7143606. sun.misc.IOUtils.createTempFile creates the temporary file with more restrictions which is causing this issue. Fix is to revert changes in sun.tools.native2ascii.Main. JDK8 and JDK7 integrations : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/819258b5002e http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/e50c9a5f001c rgds mala

1 0

Request for approval for bug# 7175845 - "jar uf" changes file permissions unexpectedly
by Mala Bankal 11 Jul '12

11 Jul '12

HI, Request approval for : 7175845 - "jar uf" changes file permissions unexpectedly for 6-open webrev : http://cr.openjdk.java.net/~mbankal/7175845/webrev.00/ This webrev fixes bug# 7175845 (regression reported in jdk6u33.) Jar command changes permission of file. Caused due to 7143606. sun.misc.IOUtils.createTempFile creates the temporary file with more restrictions which is causing this issue. Fix is to revert changes in sun.tools.jar.Main. JDK8 and JDK7 integrations : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/819258b5002e http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/c735836c2355 rgds mala

1 0

classlist.* and jar_reorder ?
by David Holmes 11 Jul '12

11 Jul '12

Can someone explain to me, or point me to docs, regarding the make/tools/sharing/classlist.* files, how they are used and maintained and what jar_reorder does with them? Thanks, David

3 2

Request for review : 7181793 FileDescriptor keeps its own hard reference to Closeables causing a memory leak
by Seán Coffey 11 Jul '12

11 Jul '12

7105952 fix introduced some improvements for finalization strategy around FileInputStream/FileOutputStream/RandomAccessFile. However a recently reported issue has highlighted an issue where memory heap can be consumed with SocketOutputStream objects as a result of clients repeatedly calling socket.getOutputStream() on a common socket (shared fd). http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181793 Use of weakreferences was considered at 7105952 fix time but hard references was considered a cleaner approach. Altering that design at this late stage in the 7u6 plan could be risky and I'm suggesting that we back out the 7105952 fix and concentrate on this area again in 7u8. The changeset is basically a backout of the original changeset plus the addition of a new testcase (FDStrongReference.java) http://cr.openjdk.java.net/~coffeys/webrev.7181793.jdk7u6/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7181793.jdk7u6/> Once reviewed, I'll ping 7u openjdk alias to start the critical fix approval process. regards, Sean.

4 5

hg: jdk8/tl/jdk: 6966259: Make PrincipalName and Realm immutable
by weijun.wang＠oracle.com 11 Jul '12

11 Jul '12

Changeset: 79b63e8eceda Author: weijun Date: 2012-07-11 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79b63e8eceda 6966259: Make PrincipalName and Realm immutable Reviewed-by: xuelei ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAppMessage.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java - src/share/classes/sun/security/krb5/ServiceName.java ! src/share/classes/sun/security/krb5/internal/ASRep.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTGSRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTicketPart.java ! src/share/classes/sun/security/krb5/internal/KDCRep.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/TGSRep.java ! src/share/classes/sun/security/krb5/internal/Ticket.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/native/sun/security/krb5/NativeCreds.c - test/sun/security/krb5/ServiceNameClone.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/name/Constructors.java + test/sun/security/krb5/name/empty.conf + test/sun/security/krb5/name/krb5.conf

1 0

Re: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale)
by Jonathan Lu 11 Jul '12

11 Jul '12

Hello Max, Thanks a lot for review, here's the updated patch, http://cr.openjdk.java.net/~luchsh/7163483_5/ On 07/10/2012 08:54 AM, Weijun Wang wrote: > Hi Jonathon > > This is better. Two minor comments, you can decide what to do or we > can see what core-lib-devs think: I was proposing my solution for this issue and I'd like to hear more from core-lib-devs list. :) > > 1. Current output uses "zzz" for timezones, you're using "ZZZ". It > might be more of an ISO flavor. Changed to "zzz" format which seems to be more readable for me. > > 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite > advanced. If it's me, I'll use the simpler format(Data) method. Updated in the new patch. > > Since the jar command also uses the same output format, can you also > make the same change there (that's sun.tools.jar.Main) and ask > core-libs-dev(a)openjdk.java.net for a review? Sherman > (xueming.shen(a)oracle.com) owns the jar tool. I've included sun.tools.jar.Main in the latest patch and CCed Sherman. Could you please help to take another look? Many thanks Jonathan > > Thanks > Max > > > On 07/09/2012 03:24 PM, Jonathan Lu wrote: >> Hi Max, >> >> Thanks for reviewing. >> >> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>> Hi Jonathan >>> >>> I have these questions: >>> >>> 1. Why always CAPITAL letters for month and weekday? >> >> This is a fault of the patch, which can be easily fixed by updating the >> format string. >> >>> >>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>> "." instead of ":" as times delimiters. >>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >> >> For question #2 and #3, I was just trying to follow the original format >> of Date.toString(). >> >>> >>> Well, if you really think the current "Fri Jul" output is too English, >>> instead of localizing the string, how about we de-localize it totally >>> and choose a neutral format? >>> >>> There are several flavors of ISO date/time format at >>> >>> http://www.w3.org/TR/NOTE-datetime >>> >>> or we can just choose >>> >>> YYYY-MM-dd HH:mm:ss zzz >> >> Good idea, how about a patch in this way? >> http://cr.openjdk.java.net/~luchsh/7163483_4/ >> >> And I prefer to your format since it looks more readable to me. >> >> Thanks and best regards! >> Jonathan >> >>> >>> BTW, the jar command is using the same format, therefore I'm adding >>> core-libs-dev. >>> >>> Thanks >>> Max >>> >>> >>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>> Hello Max, >>>> >>>> I's been a long time since my last mail, I did some investigation and >>>> had some discussion with i18n developers, but still did not see a >>>> nice >>>> solution for the alignment problem. There does not seem be an existing >>>> API to do this job in JDK scope. So I implemented a simple format >>>> function, and use it to format under different locales. >>>> >>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>> >>>> The patch is trying to format the code in the same way as >>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>> yyyy", except for using names of month and DOW in localized format. So >>>> far, it works good for me under all supported locales. >>>> >>>> Here's a test case to verify the vertical alignment, which I has been >>>> posted to i18n mailing list before, >>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>> >>>> It may still fail under "vi_VN" locale with this solution due to test >>>> case limit, but I do not think it is a real failure since the result >>>> fields still get aligned except for multiple words in one field. >>>> >>>> Could you please take a look at the patch? >>>> >>>> Many thanks & best regards >>>> Jonathan >>>> >>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>> Hi Jonathan >>>>> >>>>> I'm using English. >>>>> >>>>> In your test all the files have a similar modified time so you cannot >>>>> see the difference. However, in my example, you can see that the >>>>> widths for date and hour are not zero-padded so the width can be >>>>> either 1 or 2. >>>>> >>>>> French is even worse >>>>> >>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>> smk 671 8 févr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>> >>>>> So here even the width of month abbr can be different. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>> Hello Max, >>>>>> >>>>>> Terribly sorry for my misunderstanding! >>>>>> >>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>> Hi Weijun, >>>>>>>>>> >>>>>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>>>>> take a >>>>>>>>>> look? >>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>> >>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>> Hi Jonathan >>>>>>>>>>> >>>>>>>>>>> Some comments: >>>>>>>>>>> >>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>> length? >>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>> should be >>>>>>>>>>> aligned. >>>>>>>>>> >>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>> the >>>>>>>>>> first >>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>> in the >>>>>>>>>> expression of date time. >>>>>>>>> >>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>> afraid of >>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>> >>>>>>>> >>>>>>>> I think that would not be a problem in the new test case which >>>>>>>> compares >>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>> String#equals. >>>>>>>> Does >>>>>>>> that make sense? >>>>>>> >>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>> looking >>>>>>> ugly. >>>>>>> >>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>> >>>>>>> Compare with the current output: >>>>>>> >>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>> >>>>>> I did not see unaligned format in my testing, did you get these >>>>>> unaligned output after applying the patch? From above lines, I >>>>>> see the >>>>>> starting indices of date string in each line are always the same, >>>>>> which >>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>> not the >>>>>> same, which locale were you testing on? >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>>>>> into 80 >>>>>>>>>>> characters width. >>>>>>>>>>> >>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>> >>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>>>> take a >>>>>>>>>>>> look? >>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>> >>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>> my.jar" >>>>>>>>>>>> does not >>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>> simple >>>>>>>>>>>> test >>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>>>>> reserved. >>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>> HEADER. >>>>>>>>>>>> * >>>>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>>>> modify it >>>>>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>>>>> only, as >>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>> * >>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>> useful, but >>>>>>>>>>>> WITHOUT >>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>>>>> License >>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>> LICENSE >>>>>>>>>>>> file >>>>>>>>>>>> that >>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>> * >>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>> License >>>>>>>>>>>> version >>>>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>>>> Foundation, >>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>> USA. >>>>>>>>>>>> * >>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>> Shores, CA >>>>>>>>>>>> 94065 >>>>>>>>>>>> USA >>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>> information or >>>>>>>>>>>> have any >>>>>>>>>>>> * questions. >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>> >>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>> >>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>> >>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>> >>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>> js.run(arg); >>>>>>>>>>>> >>>>>>>>>>>> out.flush(); >>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>> stream.reset(); >>>>>>>>>>>> >>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>> js.run(arg); >>>>>>>>>>>> >>>>>>>>>>>> out.flush(); >>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>> >>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>> locale!!"); >>>>>>>>>>>> } else { >>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards! >>>>>>>>>> - Jonathan >>>>>>>>>> >>>>>>>>> >>>>>>>> Thanks & regards! >>>>>>>> - Jonathan >>>>>>>> >>>>>>> >>>>>> >>>>>> Thanks >>>>>> - Jonathan >>>>>> >>>>> >>>> >>>> >>> >> >> >

3 4

Re: [8] Review request for 7162111 change tests run in headless mode [macosx]
by Alan Bateman 11 Jul '12

11 Jul '12

On 23/06/2012 02:01, Jason Uh wrote: > Hi, > > This fix was for regression tests failing on Mac OS X on remotely > executed environments. The changed tests now run in headless mode and > have been taken off the Problem List. > > Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ > The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 > > Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here > because headless mode is not supported for JFrame. A separate CR will > be created for this. > > Thanks, > Jason It's good to see these tests changed to run headless and will make the test execution much more reliable. Aside from the mtrace demo there are a couple of other tests that periodically hang initializing AWT, at least when running via ssh and then depending on whether someone is logged in and other configuration settings. Some of the shell tests for serialization come to mind (BTW: no problem doing that via a separate bug, just mentioning that there are other tests that are problems too). One question, and this may be a question for Artem or others, is that in CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? -Alan.

3 4