From martijnverburg at gmail.com  Sun Jul  1 11:05:33 2012
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 1 Jul 2012 12:05:33 +0100
Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util)
	from Adopt OpenJDK
In-Reply-To: <4FEE12C5.8080700@oracle.com>
References: <CAP7YuAQarsJQiCn-htD9H65pLkcVa692QEsgP=XbdajubMMn9A@mail.gmail.com>
	<CAP7YuASAfqDCZ3a0=mWPkgQNsoBOHiNtu1fvua9v4Tx8jxZFMA@mail.gmail.com>
	<4FE1D95C.3030108@univ-mlv.fr>
	<CAP7YuARBo-4WD1FL0VPicaak65ULcLvade3TbcvfJZObKGcUbA@mail.gmail.com>
	<4FE1F559.5070802@oracle.com>
	<CAP7YuATSO-H6dgp9wL+yvTFkdgb6jTrm63qsW=keykuagHVJfw@mail.gmail.com>
	<CAP7YuAT2dTW0MpfLOPf01Ajfx8CfLu_cE+dd+xok89W4ckAO8A@mail.gmail.com>
	<4FE9FF91.3010400@oracle.com>
	<CAP7YuATUsYia+37e-iv_FPZj=dbgvFyQVC6RrrEA2AXC1pcCTQ@mail.gmail.com>
	<CAP7YuATofhnnEMMZw1PUsNBL10cA8hJOe9H8rgDb3-D595LZDg@mail.gmail.com>
	<4FEE12C5.8080700@oracle.com>
Message-ID: <CAP7YuATbvVF3CaFUgqMFqb2++E0THFB=NrFeepXt1ke2yofX2Q@mail.gmail.com>

Hi Stuart,

> <snip>
>
> The java.util patches look good and are almost ready to go in. The only
> issue is how to format the Contributed-by line in the changeset comment.
> What I have so far for the comment is:
>
> 7176907: additional warnings cleanup in java.util, java.util.regexp,
> java.util.zip
> Reviewed-by: forax, khazra, smarks
> Contributed-by: ???
>
> The contributed-by line takes one or more email addresses or email/name
> pairs. For an earlier contribution from LJC, see here [1]. This isn't a
> terribly big deal but I want to make sure that credit goes where it's due.
> Can you tell me what I should put for the contributed-by line?

Main Sarkar - sadhak001ATgmail.DOTcom

> The warnings in java.text have already been fixed by Deepak Bhole's
> changeset [2]. Not a problem, this took two minutes to figure out.

Cool, we've adjusted our workflow to take this into account.

> There were a couple questions from earlier in the thread.
>
> On the discussion of when the compiler issues switch fallthrough warnings,
> from what I can tell, the compiler issues a warning whenever there is actual
> code in a case that doesn't end with break, continue, return, or throw. This
> seems independent of whether what follows is another case or the 'default'
> case. If there are several case clauses together with no intervening code,
> this isn't considered a fallthrough and thus there is no warning. This make
> sense, as sometimes you want several different cases to be handled by the
> same code. For example,
>
>     switch (ch) {
>         case 'a':
>             // no warning here
>         case 'b':
>             someActualWork();
>             break;
>         // ...
>     }

Understood, made sense to us as well.

> Regarding whether there is a style checker for indentation and spacing, I'm
> not aware of a good one that I can recommend. We generally adhere to the
> (very old) Java Coding Conventions [3]. I think most people just deal with
> style issues manually by hand and by eye; I know I do. We do run jcheck [4]
> on every incoming changeset, but the only things it checks in files'
> contents are for trailing whitespace, and CR (as opposed to LF) and TAB
> characters.

OK, we've added jcheck to the list of things to run going forwards.
Perhaps in the
future one of our folks can put together a checkstyle ruleset for
core-lib (controversial!)...
:-)

Thanks for getting this patch merged!


From david.holmes at oracle.com  Mon Jul  2 00:39:05 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 02 Jul 2012 10:39:05 +1000
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FEE2570.9090602@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
Message-ID: <4FF0EDA9.9090101@oracle.com>

On 30/06/2012 8:00 AM, Stuart Marks wrote:
> Thanks for updating this. I've posted the revised webrev:
>
> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.1/
>
> It's good that this is getting simpler in that we don't have to deal
> with finalization. But it can still get simpler.... The code is in the
> webrev but I'll also paste it here for convenience:
>
> 81 while(true) {
> 82 System.gc();
> 83 Thread.sleep(20);
> 84 if(ref.get() == null) {
> 85 break;
> 86 }
> 87 }
> 88
> 89 if (ref.get() != null) {
> 90 throw new Error("TEST FAILED: impl not garbage collected");
> 91 }
>
> The only way we the loop can terminate normally is if ref.get() returns
> null, so it's pointless to test ref.get() again after the loop. I'd just
> take out this second test of ref.get().

Agreed. The test can no longer "fail", it either completes or hangs. So 
lines 89/90 are useless in terms of testing what this test is supposed 
to be testing.

> Now, how can the test fail? If ref is never cleared, the while loop will
> never terminate, and we rely on jtreg to timeout and kill this test. It
> would be good to have a brief comment above the while loop that explains
> this.

Agreed. Something like

// Might require multiple calls to System.gc() for weak-references 
processing to be complete.
// If the weak-reference is not cleared as expected we will hang here
// until timed out by the test harness

Though now I write that I'm unhappy that this will only behave nicely if 
run from jtreg. We do use explicit timeouts in other tests.

David
-----


> Finally, a style nitpick: there should be a space before the ( for the
> while and if statements. That's the prevailing style we use in the JDK.
>
> s'marks
>
>
> On 6/29/12 1:31 AM, Eric Wang wrote:
>> Hi David,
>>
>> I have made changes by following your suggestion. Can you please help
>> to review
>> again? Thanks a lot!
>> I also change the code of 7123972 which is sent in another mail.
>>
>> Regards,
>> Eric
>>
>> On 2012/6/29 11:04, David Holmes wrote:
>>> On 29/06/2012 12:10 PM, Eric Wang wrote:
>>>> Hi Stuart,
>>>>
>>>> Thank you, The fix looks simpler than the previous one, it shoud be
>>>> better to add a Thread.sleep(20) in the loop to avoid multiple calls on
>>>> System.gc();
>>>
>>> Oops I missed the sleep out of my suggestion too.
>>>
>>>> Here is a small question if it is possible that after GC, the strong
>>>> ref
>>>> remains but somehow weakref is broken?so the loop will terminate and
>>>> the test will fake pass.
>>>
>>> As I said previously this isn't trying to test the GC. Broken
>>> weakrefs should
>>> be detected by weakref tests.
>>>
>>> David
>>> -----
>>>
>>>>
>>>> while(!finalized) {
>>>> System.gc();
>>>> Thread.sleep(20);
>>>> if(ref.get() == null) { //strong ref remains but somehow weakref broken
>>>> break;
>>>> }
>>>> }
>>>>
>>>> if (ref.get() != null) { //if weakref broken, test will fake pass
>>>> throw new Error("TEST FAILED: impl not garbage collected");
>>>> }
>>>>
>>>> Thanks,
>>>> Eric
>>>> On 2012/6/29 5:54, David Holmes wrote:
>>>>> Hi Stuart,
>>>>>
>>>>> I don't think finalization or reference queues are needed in this
>>>>> case. We could simply do:
>>>>>
>>>>> while(true) {
>>>>> System.gc();
>>>>> if (weakRef.get() == null)
>>>>> break;
>>>>> }
>>>>>
>>>>> We have to remember that this is not testing the correct operation of
>>>>> weak references, nor of finalization, but simply that no unintended
>>>>> strong references remain to the object referenced via the
>>>>> WeakReference.
>>>>>
>>>>> So if a strong ref remains, or somehow weakrefs are broken, then the
>>>>> loop will not terminate on its own and we rely on the test harness
>>>>> timing it out.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 29/06/2012 7:20 AM, Stuart Marks wrote:
>>>>>> And here's the webrev for this one:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/
>>>>>>
>>>>>> Also looks good to me. It's pretty similar to the other fix
>>>>>> (7123972).
>>>>>> If there are no further comments I'll push this in the next day or
>>>>>> so.
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> Some further comments, mainly aimed at the likes of David Holmes. I'm
>>>>>> mostly "thinking out loud" at the moment.
>>>>>>
>>>>>> While I'm glad to see the reliability of these tests improved and
>>>>>> to see
>>>>>> them come off the problem list, it would be nice to see something
>>>>>> more
>>>>>> general that could be shared among other tests, and possibly more
>>>>>> abstract so that things can be tuned to different VM
>>>>>> characteristics if
>>>>>> necessary.
>>>>>>
>>>>>> Basically what these tests want to do is to make sure that a certain
>>>>>> object gets garbage collected. I think this is pretty common.
>>>>>> There are
>>>>>> several dozen tests in the jdk repo that have the word "leak" in
>>>>>> them. I
>>>>>> bet they all use different techniques to detect leaks. :-(
>>>>>>
>>>>>> The technique used here is to get a weak reference to the object, and
>>>>>> then use the object's finalizer to set a bit telling us when
>>>>>> finalization has occurred. At this point we can assert that the
>>>>>> weak ref
>>>>>> has been cleared. In addition to being somewhat roundabout, this also
>>>>>> seems like we're merely cross-checking the garbage collector. We
>>>>>> could
>>>>>> easily poll for the weak ref being cleared, and then assert that
>>>>>> the bit
>>>>>> set by finalization has indeed been set.
>>>>>>
>>>>>> It seems to me we could avoid finalization entirely and just use weak
>>>>>> refs and reference queues. Would it have the same effect and
>>>>>> semantics
>>>>>> as the current test if we were to do the following?
>>>>>>
>>>>>> - with a target object, make a weak reference registered with a ref
>>>>>> queue
>>>>>> - clear all references to the target object
>>>>>> - request gc
>>>>>> - request finalization (is this necessary?)
>>>>>> - wait or poll on the ref queue
>>>>>>
>>>>>> If we get our weak ref from the queue, success. If we time out, fail.
>>>>>> Note that there is a timeout mechanism
>>>>>> ReferenceQueue.remove(timeout),
>>>>>> so we could set some timeout without waiting the full jtreg
>>>>>> timeout if
>>>>>> we don't want to. Or we could call System.gc() in a loop using
>>>>>> remove()
>>>>>> with a short timeout (instead of sleep), similar to the current test,
>>>>>> although it's not clear to me this is necessary.
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>>
>>>>>> On 6/27/12 1:20 AM, Eric Wang wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Thank you for review!
>>>>>>>
>>>>>>> Hi Stuart,
>>>>>>>
>>>>>>> Can you please help to review and post the webrev, Thanks a lot!
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> On 2012/6/27 15:32, David Holmes wrote:
>>>>>>>> On 27/06/2012 4:57 PM, Eric Wang wrote:
>>>>>>>>> Hi David & Stuart,
>>>>>>>>>
>>>>>>>>> Thank you for the help! please review the in webrev 6948101.zip in
>>>>>>>>> attachment.
>>>>>>>>
>>>>>>>> Thanks Eric. That fix also seems fine to me.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>> On 2012/6/27 9:14, Stuart Marks wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>>
>>>>>>>>>> Alan Bateman asked me to help you out with this since he's going
>>>>>>>>>> to be
>>>>>>>>>> unavailable for a couple weeks.
>>>>>>>>>>
>>>>>>>>>> I didn't see you on the OpenJDK census [1] so you might not
>>>>>>>>>> have an
>>>>>>>>>> Author role and thus the ability to post webrevs. If indeed you
>>>>>>>>>> don't,
>>>>>>>>>> I can post a webrev for you. I can also post a webrev for your
>>>>>>>>>> other
>>>>>>>>>> review (7123972) if it's still necessary.
>>>>>>>>>>
>>>>>>>>>> Finally, I can push the fixes for you when the reviews are
>>>>>>>>>> complete.
>>>>>>>>>>
>>>>>>>>>> s'marks
>>>>>>>>>>
>>>>>>>>>> [1] http://openjdk.java.net/census
>>>>>>>>>>
>>>>>>>>>> On 6/26/12 2:56 PM, David Holmes wrote:
>>>>>>>>>>> Hi Eric,
>>>>>>>>>>>
>>>>>>>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote:
>>>>>>>>>>>> Please help to review the fix attached for test bug 6948101
>>>>>>>>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=6948101> which is
>>>>>>>>>>>> same
>>>>>>>>>>>> root
>>>>>>>>>>>> cause as bug 7123972
>>>>>>>>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=7123972>.
>>>>>>>>>>>> The test makes wrong assumption that GC is started
>>>>>>>>>>>> immediately to
>>>>>>>>>>>> recycle unused objects after System.gc() called.
>>>>>>>>>>>> The proposed fix is to make sure objects have been recycled
>>>>>>>>>>>> by GC
>>>>>>>>>>>> before
>>>>>>>>>>>> checking if the weak reference is null.
>>>>>>>>>>>
>>>>>>>>>>> Again I really need to see a webrev to see the fix in context.
>>>>>>>>>>> Do you
>>>>>>>>>>> have
>>>>>>>>>>> Author role and an OpenJDK user name so you can post webrevs on
>>>>>>>>>>> cr.openjdk.java.net?
>>>>>>>>>>>
>>>>>>>>>>> I suspect this may have the same issues as the other fix and
>>>>>>>>>>> require
>>>>>>>>>>> a timeout
>>>>>>>>>>> for when the original problem is still present.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>
>>>>
>>


From youdwei at linux.vnet.ibm.com  Mon Jul  2 09:04:37 2012
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Mon, 02 Jul 2012 17:04:37 +0800
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <4FE81ED6.7020909@linux.vnet.ibm.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
Message-ID: <4FF16425.9070308@linux.vnet.ibm.com>

Hi All,
Could anyone notice this problem?

Thanks a lot!
On 06/25/2012 04:18 PM, Deven You wrote:
> Hi All,
>
> First of all, if the jdbc problem has a better mailing list to post 
> please tell me.
>
> I find that javax.sql.rowset.serial.SerialBlob is not fully 
> implemented in OpenJDK 8. Methods
>
>     public InputStream getBinaryStream(long pos,long length) throws 
> SQLException
>     public void free() throws SQLException
>
> only throw UnsupportedOperationException.
>
> I have made a patch[1] to implement these 2 methods. Could anyone take 
> a look to review it.
>
> BTW: I think the spec for SerialBlob is not very clear like it doesn't 
> mention if all method rather than free() need throw any exception 
> after free() is invoked. However that behavior seems reasonable.
>
> [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev
>
> Thanks a lot.
>


-- 
Best Regards,

Deven



From Lance.Andersen at oracle.com  Mon Jul  2 10:25:42 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 2 Jul 2012 06:25:42 -0400
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <4FF16425.9070308@linux.vnet.ibm.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
	<4FF16425.9070308@linux.vnet.ibm.com>
Message-ID: <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>

Hi Deven,

Thanks for the email and the proposed patch.  I will look at this later today or tomorrow.  I actually have made these changes in my workspace for JDK 8 but will compare your changes to mine.

Best
Lance
On Jul 2, 2012, at 5:04 AM, Deven You wrote:

> Hi All,
> Could anyone notice this problem?
> 
> Thanks a lot!
> On 06/25/2012 04:18 PM, Deven You wrote:
>> Hi All,
>> 
>> First of all, if the jdbc problem has a better mailing list to post please tell me.
>> 
>> I find that javax.sql.rowset.serial.SerialBlob is not fully implemented in OpenJDK 8. Methods
>> 
>>    public InputStream getBinaryStream(long pos,long length) throws SQLException
>>    public void free() throws SQLException
>> 
>> only throw UnsupportedOperationException.
>> 
>> I have made a patch[1] to implement these 2 methods. Could anyone take a look to review it.
>> 
>> BTW: I think the spec for SerialBlob is not very clear like it doesn't mention if all method rather than free() need throw any exception after free() is invoked. However that behavior seems reasonable.
>> 
>> [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev
>> 
>> Thanks a lot.
>> 
> 
> 
> -- 
> Best Regards,
> 
> Deven
> 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From anthony.petrov at oracle.com  Mon Jul  2 14:33:52 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 02 Jul 2012 18:33:52 +0400
Subject: [8] Review request for 7162111 change tests run in headless mode
	[macosx]
In-Reply-To: <4FF1ADB1.9020508@oracle.com>
References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com>
	<4FE86576.8020407@oracle.com> <4FF1ADB1.9020508@oracle.com>
Message-ID: <4FF1B150.80406@oracle.com>

Looks fine to me.

--
best regards,
Anthony

On 07/02/12 18:18, Jason Uh wrote:
> Anthony and Alan,
>
> Thanks for your comments. I've reverted the changes to CommonSetup.sh so
> that XToolkit is no longer forced. Tests still pass.
>
> Please see the new webrev:
> http://cr.openjdk.java.net/~juh/7162111/webrev.01/
>
> Thanks,
> Jason
>
> On 06/25/2012 06:19 AM, Anthony Petrov wrote:
>> Hi Alan and Jason,
>>
>> On 06/23/12 11:28, Alan Bateman wrote:
>>> On 23/06/2012 02:01, Jason Uh wrote:
>>>> 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.
>>>>
>>> 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?
>>
>> I don't think we need to force XToolkit on the Mac. We don't quite
>> support it on that platform actually. The normal headless CToolkit
>> should work just fine. Could you please revert the changes to
>> CommonSetup.sh and verify if the tests pass?
>>
>> --
>> best regards,
>> Anthony


From rob.mckenna at oracle.com  Mon Jul  2 18:31:13 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Mon, 02 Jul 2012 18:31:13 +0000
Subject: hg: jdk8/tl/jdk: 7174887: Deadlock in jndi ldap connection cleanup
Message-ID: <20120702183131.4FCF647C41@hg.openjdk.java.net>

Changeset: ecc5dd3790a1
Author:    robm
Date:      2012-07-02 19:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecc5dd3790a1

7174887: Deadlock in jndi ldap connection cleanup
Reviewed-by: xuelei

! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java



From stuart.marks at oracle.com  Mon Jul  2 21:08:46 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 02 Jul 2012 14:08:46 -0700
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF0EDA9.9090101@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com>
Message-ID: <4FF20DDE.5030900@oracle.com>

On 7/1/12 5:39 PM, David Holmes wrote:
>> Now, how can the test fail? If ref is never cleared, the while loop will
>> never terminate, and we rely on jtreg to timeout and kill this test. It
>> would be good to have a brief comment above the while loop that explains
>> this.
>
> Agreed. Something like
>
> // Might require multiple calls to System.gc() for weak-references processing
> to be complete.
> // If the weak-reference is not cleared as expected we will hang here
> // until timed out by the test harness
>
> Though now I write that I'm unhappy that this will only behave nicely if run
> from jtreg. We do use explicit timeouts in other tests.

So, are you unhappy enough that we should ask Eric to add an explicit timeout?

I don't think it would be that difficult. Perhaps a technique like the 
following would suffice. Get System.currentTimeMillis() before the loop, and 
call it again each time through the loop, and fail if the difference is greater 
than the timeout (e.g., 60 sec). Doesn't involve other threads or even 
Timer/TimerTask.

On the other hand if one is running this test directly instead of through 
jtreg, one can just ^C it if it's taking an unexpectedly long time.

s'marks


From stuart.marks at oracle.com  Mon Jul  2 21:33:13 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Mon, 02 Jul 2012 21:33:13 +0000
Subject: hg: jdk8/tl/jdk: 7176907: additional warnings cleanup in java.util,
	java.util.regexp, java.util.zip
Message-ID: <20120702213335.F20FA47C53@hg.openjdk.java.net>

Changeset: b2fc66012451
Author:    smarks
Date:      2012-07-02 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2fc66012451

7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip
Reviewed-by: forax, khazra, smarks
Contributed-by: Mani Sarkar <sadhak001 at gmail.com>

! src/share/classes/java/util/InvalidPropertiesFormatException.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/zip/GZIPInputStream.java



From stuart.marks at oracle.com  Mon Jul  2 21:55:41 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 02 Jul 2012 14:55:41 -0700
Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util)
	from Adopt OpenJDK
In-Reply-To: <CAP7YuATbvVF3CaFUgqMFqb2++E0THFB=NrFeepXt1ke2yofX2Q@mail.gmail.com>
References: <CAP7YuAQarsJQiCn-htD9H65pLkcVa692QEsgP=XbdajubMMn9A@mail.gmail.com>
	<CAP7YuASAfqDCZ3a0=mWPkgQNsoBOHiNtu1fvua9v4Tx8jxZFMA@mail.gmail.com>
	<4FE1D95C.3030108@univ-mlv.fr>
	<CAP7YuARBo-4WD1FL0VPicaak65ULcLvade3TbcvfJZObKGcUbA@mail.gmail.com>
	<4FE1F559.5070802@oracle.com>
	<CAP7YuATSO-H6dgp9wL+yvTFkdgb6jTrm63qsW=keykuagHVJfw@mail.gmail.com>
	<CAP7YuAT2dTW0MpfLOPf01Ajfx8CfLu_cE+dd+xok89W4ckAO8A@mail.gmail.com>
	<4FE9FF91.3010400@oracle.com>
	<CAP7YuATUsYia+37e-iv_FPZj=dbgvFyQVC6RrrEA2AXC1pcCTQ@mail.gmail.com>
	<CAP7YuATofhnnEMMZw1PUsNBL10cA8hJOe9H8rgDb3-D595LZDg@mail.gmail.com>
	<4FEE12C5.8080700@oracle.com>
	<CAP7YuATbvVF3CaFUgqMFqb2++E0THFB=NrFeepXt1ke2yofX2Q@mail.gmail.com>
Message-ID: <4FF218DD.5020709@oracle.com>

Pushed:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2fc66012451

Thanks for your contributions to OpenJDK!

s'marks

On 7/1/12 4:05 AM, Martijn Verburg wrote:
> Hi Stuart,
>
>> <snip>
>>
>> The java.util patches look good and are almost ready to go in. The only
>> issue is how to format the Contributed-by line in the changeset comment.
>> What I have so far for the comment is:
>>
>> 7176907: additional warnings cleanup in java.util, java.util.regexp,
>> java.util.zip
>> Reviewed-by: forax, khazra, smarks
>> Contributed-by: ???
>>
>> The contributed-by line takes one or more email addresses or email/name
>> pairs. For an earlier contribution from LJC, see here [1]. This isn't a
>> terribly big deal but I want to make sure that credit goes where it's due.
>> Can you tell me what I should put for the contributed-by line?
>
> Main Sarkar - sadhak001ATgmail.DOTcom
>
>> The warnings in java.text have already been fixed by Deepak Bhole's
>> changeset [2]. Not a problem, this took two minutes to figure out.
>
> Cool, we've adjusted our workflow to take this into account.
>
>> There were a couple questions from earlier in the thread.
>>
>> On the discussion of when the compiler issues switch fallthrough warnings,
>> from what I can tell, the compiler issues a warning whenever there is actual
>> code in a case that doesn't end with break, continue, return, or throw. This
>> seems independent of whether what follows is another case or the 'default'
>> case. If there are several case clauses together with no intervening code,
>> this isn't considered a fallthrough and thus there is no warning. This make
>> sense, as sometimes you want several different cases to be handled by the
>> same code. For example,
>>
>>      switch (ch) {
>>          case 'a':
>>              // no warning here
>>          case 'b':
>>              someActualWork();
>>              break;
>>          // ...
>>      }
>
> Understood, made sense to us as well.
>
>> Regarding whether there is a style checker for indentation and spacing, I'm
>> not aware of a good one that I can recommend. We generally adhere to the
>> (very old) Java Coding Conventions [3]. I think most people just deal with
>> style issues manually by hand and by eye; I know I do. We do run jcheck [4]
>> on every incoming changeset, but the only things it checks in files'
>> contents are for trailing whitespace, and CR (as opposed to LF) and TAB
>> characters.
>
> OK, we've added jcheck to the list of things to run going forwards.
> Perhaps in the
> future one of our folks can put together a checkstyle ruleset for
> core-lib (controversial!)...
> :-)
>
> Thanks for getting this patch merged!


From david.holmes at oracle.com  Tue Jul  3 02:38:00 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 03 Jul 2012 12:38:00 +1000
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF20DDE.5030900@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
Message-ID: <4FF25B08.9070009@oracle.com>

On 3/07/2012 7:08 AM, Stuart Marks wrote:
> On 7/1/12 5:39 PM, David Holmes wrote:
>>> Now, how can the test fail? If ref is never cleared, the while loop will
>>> never terminate, and we rely on jtreg to timeout and kill this test. It
>>> would be good to have a brief comment above the while loop that explains
>>> this.
>>
>> Agreed. Something like
>>
>> // Might require multiple calls to System.gc() for weak-references
>> processing
>> to be complete.
>> // If the weak-reference is not cleared as expected we will hang here
>> // until timed out by the test harness
>>
>> Though now I write that I'm unhappy that this will only behave nicely
>> if run
>> from jtreg. We do use explicit timeouts in other tests.
>
> So, are you unhappy enough that we should ask Eric to add an explicit
> timeout?

No. But I'm not the authoritive voice in this area :)

> I don't think it would be that difficult. Perhaps a technique like the
> following would suffice. Get System.currentTimeMillis() before the loop,
> and call it again each time through the loop, and fail if the difference
> is greater than the timeout (e.g., 60 sec). Doesn't involve other
> threads or even Timer/TimerTask.

Or simply limit the number of loops so that N*sleepTime = timeout. This 
then requires adding back the check for null outside the loop.

> On the other hand if one is running this test directly instead of
> through jtreg, one can just ^C it if it's taking an unexpectedly long time.

True.

David
-----


> s'marks


From yiming.wang at oracle.com  Tue Jul  3 03:28:26 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Tue, 03 Jul 2012 11:28:26 +0800
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF25B08.9070009@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com>
Message-ID: <4FF266DA.2070305@oracle.com>

Hi Stuart and David,

Thanks for the suggestion about the timeout. so there are three ways to 
handle the timeout.

1. Add comment to explain that test failed due to default timeout
2. Specify the the timeout option
3. Timeout programly

Is it ok for you that i'd like to choose the second way "explict 
timeout" as the test looks simply and lucid?

Regards,
Eric

On 2012/7/3 10:38, David Holmes wrote:
> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>> Now, how can the test fail? If ref is never cleared, the while loop 
>>>> will
>>>> never terminate, and we rely on jtreg to timeout and kill this 
>>>> test. It
>>>> would be good to have a brief comment above the while loop that 
>>>> explains
>>>> this.
>>>
>>> Agreed. Something like
>>>
>>> // Might require multiple calls to System.gc() for weak-references
>>> processing
>>> to be complete.
>>> // If the weak-reference is not cleared as expected we will hang here
>>> // until timed out by the test harness
>>>
>>> Though now I write that I'm unhappy that this will only behave nicely
>>> if run
>>> from jtreg. We do use explicit timeouts in other tests.
>>
>> So, are you unhappy enough that we should ask Eric to add an explicit
>> timeout?
>
> No. But I'm not the authoritive voice in this area :)
>
>> I don't think it would be that difficult. Perhaps a technique like the
>> following would suffice. Get System.currentTimeMillis() before the loop,
>> and call it again each time through the loop, and fail if the difference
>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>> threads or even Timer/TimerTask.
>
> Or simply limit the number of loops so that N*sleepTime = timeout. 
> This then requires adding back the check for null outside the loop.
>
>> On the other hand if one is running this test directly instead of
>> through jtreg, one can just ^C it if it's taking an unexpectedly long 
>> time.
>
> True.
>
> David
> -----
>
>
>> s'marks




From david.holmes at oracle.com  Tue Jul  3 04:22:30 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 03 Jul 2012 14:22:30 +1000
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF266DA.2070305@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
Message-ID: <4FF27386.3010707@oracle.com>

Hi Eric,

On 3/07/2012 1:28 PM, Eric Wang wrote:
> Hi Stuart and David,
>
> Thanks for the suggestion about the timeout. so there are three ways to
> handle the timeout.
>
> 1. Add comment to explain that test failed due to default timeout
> 2. Specify the the timeout option
> 3. Timeout programly
>
> Is it ok for you that i'd like to choose the second way "explict
> timeout" as the test looks simply and lucid?

If by #2 you mean add something like:

@run main/timeout=10

then no. Earlier this year there were changes to a bunch of tests that 
set timeouts shorter than the jtreg default, to delete the timeouts. 
Given that, my misgivings about relying on the harness are not relevant 
so we need only do #1 and add a comment to make it clear that a failing 
test will be indicated via the harness timeout.

David
-----

> Regards,
> Eric
>
> On 2012/7/3 10:38, David Holmes wrote:
>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>> Now, how can the test fail? If ref is never cleared, the while loop
>>>>> will
>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>> test. It
>>>>> would be good to have a brief comment above the while loop that
>>>>> explains
>>>>> this.
>>>>
>>>> Agreed. Something like
>>>>
>>>> // Might require multiple calls to System.gc() for weak-references
>>>> processing
>>>> to be complete.
>>>> // If the weak-reference is not cleared as expected we will hang here
>>>> // until timed out by the test harness
>>>>
>>>> Though now I write that I'm unhappy that this will only behave nicely
>>>> if run
>>>> from jtreg. We do use explicit timeouts in other tests.
>>>
>>> So, are you unhappy enough that we should ask Eric to add an explicit
>>> timeout?
>>
>> No. But I'm not the authoritive voice in this area :)
>>
>>> I don't think it would be that difficult. Perhaps a technique like the
>>> following would suffice. Get System.currentTimeMillis() before the loop,
>>> and call it again each time through the loop, and fail if the difference
>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>> threads or even Timer/TimerTask.
>>
>> Or simply limit the number of loops so that N*sleepTime = timeout.
>> This then requires adding back the check for null outside the loop.
>>
>>> On the other hand if one is running this test directly instead of
>>> through jtreg, one can just ^C it if it's taking an unexpectedly long
>>> time.
>>
>> True.
>>
>> David
>> -----
>>
>>
>>> s'marks
>
>


From yiming.wang at oracle.com  Tue Jul  3 06:41:03 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Tue, 03 Jul 2012 14:41:03 +0800
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF27386.3010707@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com>
Message-ID: <4FF293FF.1050307@oracle.com>

David,

I have added the comments before the loop, please help to review. If it 
is OK, I'll update the 7123972 as well.

Thanks,
Eric

On 2012/7/3 12:22, David Holmes wrote:
> Hi Eric,
>
> On 3/07/2012 1:28 PM, Eric Wang wrote:
>> Hi Stuart and David,
>>
>> Thanks for the suggestion about the timeout. so there are three ways to
>> handle the timeout.
>>
>> 1. Add comment to explain that test failed due to default timeout
>> 2. Specify the the timeout option
>> 3. Timeout programly
>>
>> Is it ok for you that i'd like to choose the second way "explict
>> timeout" as the test looks simply and lucid?
>
> If by #2 you mean add something like:
>
> @run main/timeout=10
>
> then no. Earlier this year there were changes to a bunch of tests that 
> set timeouts shorter than the jtreg default, to delete the timeouts. 
> Given that, my misgivings about relying on the harness are not 
> relevant so we need only do #1 and add a comment to make it clear that 
> a failing test will be indicated via the harness timeout.
>
> David
> -----
>
>> Regards,
>> Eric
>>
>> On 2012/7/3 10:38, David Holmes wrote:
>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>> Now, how can the test fail? If ref is never cleared, the while loop
>>>>>> will
>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>> test. It
>>>>>> would be good to have a brief comment above the while loop that
>>>>>> explains
>>>>>> this.
>>>>>
>>>>> Agreed. Something like
>>>>>
>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>> processing
>>>>> to be complete.
>>>>> // If the weak-reference is not cleared as expected we will hang here
>>>>> // until timed out by the test harness
>>>>>
>>>>> Though now I write that I'm unhappy that this will only behave nicely
>>>>> if run
>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>
>>>> So, are you unhappy enough that we should ask Eric to add an explicit
>>>> timeout?
>>>
>>> No. But I'm not the authoritive voice in this area :)
>>>
>>>> I don't think it would be that difficult. Perhaps a technique like the
>>>> following would suffice. Get System.currentTimeMillis() before the 
>>>> loop,
>>>> and call it again each time through the loop, and fail if the 
>>>> difference
>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>> threads or even Timer/TimerTask.
>>>
>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>> This then requires adding back the check for null outside the loop.
>>>
>>>> On the other hand if one is running this test directly instead of
>>>> through jtreg, one can just ^C it if it's taking an unexpectedly long
>>>> time.
>>>
>>> True.
>>>
>>> David
>>> -----
>>>
>>>
>>>> s'marks
>>
>>


-------------- next part --------------
--- old/test/ProblemList.txt	2012-07-03 14:21:56.063520415 +0800
+++ new/test/ProblemList.txt	2012-07-03 14:21:54.846424695 +0800
@@ -271,9 +271,6 @@
 # 7140992
 java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java generic-all
 
-# 6948101
-java/rmi/transport/pinLastArguments/PinLastArguments.java	generic-all
-
 # 7146541
 java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java	linux-all
 
-------------- next part --------------
--- old/test/java/rmi/transport/pinLastArguments/PinLastArguments.java	2012-07-03 14:22:04.443420594 +0800
+++ new/test/java/rmi/transport/pinLastArguments/PinLastArguments.java	2012-07-03 14:22:02.403420591 +0800
@@ -78,10 +78,15 @@
         }
         impl = null;
 
-        System.gc();
-
-        if (ref.get() != null) {
-            throw new Error("TEST FAILED: impl not garbage collected");
+        // Might require multiple calls to System.gc() for weak-references
+        // processing to be complete. If the weak-reference is not cleared as
+        // expected we will hang here until timed out by the test harness. 
+        while (true) {
+            System.gc();
+            Thread.sleep(20);
+            if(ref.get() == null) {
+                break;
+            }
         }
 
         System.err.println("TEST PASSED");

From david.holmes at oracle.com  Tue Jul  3 06:54:58 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 03 Jul 2012 16:54:58 +1000
Subject: classlist.* and jar_reorder ?
Message-ID: <4FF29742.2040204@oracle.com>

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


From stuart.marks at oracle.com  Tue Jul  3 07:20:27 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Jul 2012 00:20:27 -0700
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF293FF.1050307@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
Message-ID: <4FF29D3B.60005@oracle.com>

This approach looks good to me. Please go ahead and update 7123972 as well, and 
I'll post these webrevs tomorrow (my time).

Thanks.

s'marks

On 7/2/12 11:41 PM, Eric Wang wrote:
> David,
>
> I have added the comments before the loop, please help to review. If it is OK,
> I'll update the 7123972 as well.
>
> Thanks,
> Eric
>
> On 2012/7/3 12:22, David Holmes wrote:
>> Hi Eric,
>>
>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>> Hi Stuart and David,
>>>
>>> Thanks for the suggestion about the timeout. so there are three ways to
>>> handle the timeout.
>>>
>>> 1. Add comment to explain that test failed due to default timeout
>>> 2. Specify the the timeout option
>>> 3. Timeout programly
>>>
>>> Is it ok for you that i'd like to choose the second way "explict
>>> timeout" as the test looks simply and lucid?
>>
>> If by #2 you mean add something like:
>>
>> @run main/timeout=10
>>
>> then no. Earlier this year there were changes to a bunch of tests that set
>> timeouts shorter than the jtreg default, to delete the timeouts. Given that,
>> my misgivings about relying on the harness are not relevant so we need only
>> do #1 and add a comment to make it clear that a failing test will be
>> indicated via the harness timeout.
>>
>> David
>> -----
>>
>>> Regards,
>>> Eric
>>>
>>> On 2012/7/3 10:38, David Holmes wrote:
>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>> Now, how can the test fail? If ref is never cleared, the while loop
>>>>>>> will
>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>> test. It
>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>> explains
>>>>>>> this.
>>>>>>
>>>>>> Agreed. Something like
>>>>>>
>>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>>> processing
>>>>>> to be complete.
>>>>>> // If the weak-reference is not cleared as expected we will hang here
>>>>>> // until timed out by the test harness
>>>>>>
>>>>>> Though now I write that I'm unhappy that this will only behave nicely
>>>>>> if run
>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>
>>>>> So, are you unhappy enough that we should ask Eric to add an explicit
>>>>> timeout?
>>>>
>>>> No. But I'm not the authoritive voice in this area :)
>>>>
>>>>> I don't think it would be that difficult. Perhaps a technique like the
>>>>> following would suffice. Get System.currentTimeMillis() before the loop,
>>>>> and call it again each time through the loop, and fail if the difference
>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>> threads or even Timer/TimerTask.
>>>>
>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>> This then requires adding back the check for null outside the loop.
>>>>
>>>>> On the other hand if one is running this test directly instead of
>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly long
>>>>> time.
>>>>
>>>> True.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> s'marks
>>>
>>>
>
>


From yiming.wang at oracle.com  Tue Jul  3 10:37:49 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Tue, 03 Jul 2012 18:37:49 +0800
Subject: Patch review request - Test bug 7123972
	test/java/lang/annotation/loaderLeak/Main.java fails intermittently
In-Reply-To: <4FEE25C0.2040900@oracle.com>
References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com>
	<4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com>
	<4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com>
	<4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com>
	<4FEBE02D.6010406@oracle.com> <4FED6908.7080405@oracle.com>
	<4FEE25C0.2040900@oracle.com>
Message-ID: <4FF2CB7D.201@oracle.com>

Hi Stuart,

I have made updates which is same as 6948101, please help to review, 
Thanks a lot!

Regards,
Eric
On 2012/6/30 6:01, Stuart Marks wrote:
> I've posted the updated webrev here:
>
> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.1/
>
> This code is pretty much the same as 6948101 and the same comments I 
> had on that bug apply here as well, so please make similar updates to 
> this one.
>
> Thanks.
>
> s'marks
>
> On 6/29/12 1:36 AM, Eric Wang wrote:
>> Hi Stuart & David?
>>
>> Attachment is the new changes to make code simply by following David
>> suggestion, Can you help please review again, Thanks a lot!
>>
>> Regards,
>> Eric
>> On 2012/6/28 12:40, Stuart Marks wrote:
>>> I've posted the webrev here:
>>>
>>> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/
>>>
>>> I've looked at the changes and they seem fine.
>>>
>>> It's interesting that the run times take 30-60 sec in your 
>>> experience. I've
>>> run them on my system (Linux in a virtual machine) and they usually 
>>> run in
>>> 10-20 sec. In any case, as you say, if the test times out it 
>>> indicates there
>>> really was a failure.
>>>
>>> I'll give people a chance to look at the webrev and if there aren't 
>>> any more
>>> comments in another day or so I'll push in the changeset.
>>>
>>> Thanks for developing this!
>>>
>>> s'marks
>>>
>>> On 6/26/12 11:50 PM, Eric Wang wrote:
>>>> Hi David,
>>>>
>>>> Thank you! I run the test several times on 3 platforms (windows, 
>>>> solaris and
>>>> linux), the average execution time is 30secs to 60secs. if the test 
>>>> hang 2
>>>> minutes, there should be something wrong.
>>>>
>>>> Hi Marks,
>>>>
>>>> I don't have the author role, Can you please help to review and 
>>>> post the webrev
>>>> 7123972.zip in attachment if it is OK, Thanks a lot!
>>>>
>>>> Regards,
>>>> Eric
>>>>
>>>> On 2012/6/27 14:19, David Holmes wrote:
>>>>> Eric,
>>>>>
>>>>> Ignore my comment about adding the timeouts. As Alan reminded me 
>>>>> if the test
>>>>> would hang then jtreg will time it out after two minutes anyway.
>>>>>
>>>>> So this is good to go as far as I am concerned.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 27/06/2012 7:51 AM, David Holmes wrote:
>>>>>> Thanks Eric.
>>>>>>
>>>>>> So to summarize:
>>>>>>
>>>>>> - we create a custom classloader, load a class through it and 
>>>>>> store a
>>>>>> reference to that Class in a WeakReference
>>>>>> - we then drop the reference to the loader
>>>>>>
>>>>>> At this point the only reference to the loader is from the Class 
>>>>>> loaded,
>>>>>> which in turn is only weakly reachable.
>>>>>>
>>>>>> I must confess that I'm unclear why this test should be failing 
>>>>>> in its
>>>>>> original form. The first gc() should remove the strong reference 
>>>>>> to the
>>>>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> 
>>>>>> Class.
>>>>>> The second gc() should detect the cycle and clear the WeakRef. I 
>>>>>> guess
>>>>>> the problem is that depending on which gc is in use the actual gc()
>>>>>> calls may not in fact induce every possible GC action.
>>>>>>
>>>>>> The fix seems reasonable in that regard - keep gc'ing and finalizing
>>>>>> till we see the loader is gone, and so the WeakReference should be
>>>>>> cleared. The original bug would cause a ref to the Class to 
>>>>>> remain (from
>>>>>> the annotation) and hence the WeakRef would not be cleared. 
>>>>>> However, in
>>>>>> that case the loader would also be strongly referenced and so never
>>>>>> become finalizable. So if this test was now run against a JDK 
>>>>>> with the
>>>>>> original bug, the test would hang. So I think we need to add a 
>>>>>> timeout
>>>>>> in there as well.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 25/06/2012 6:06 PM, Eric Wang wrote:
>>>>>>> On 2012/6/21 20:16, David Holmes wrote:
>>>>>>>> Hi Eric,
>>>>>>>>
>>>>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> Thanks for your review, I have updated the code by following your
>>>>>>>>> suggestion. please see the attachment.
>>>>>>>>> I'm not sure whether there's a better way to guarantee object 
>>>>>>>>> finalized
>>>>>>>>> by GC definitely within the given time. The proposed fix may 
>>>>>>>>> work in
>>>>>>>>> most cases but may still throw InterruptException if execution is
>>>>>>>>> timeout (2 minutes of JTreg by default).
>>>>>>>>
>>>>>>>> There is no way to guarantee finalization in a specific 
>>>>>>>> timeframe, but
>>>>>>>> if a simple test hasn't executed finalizers in 2 minutes then 
>>>>>>>> that in
>>>>>>>> itself indicates a problem.
>>>>>>>>
>>>>>>>> Can you post a full webrev for this patch? I don't like seeing 
>>>>>>>> it out
>>>>>>>> of context and am wondering exactly what we are trying to GC here.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>> On 2012/6/21 14:32, David Holmes wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>>
>>>>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote:
>>>>>>>>>>> I come from Java SQE team who are interested in regression 
>>>>>>>>>>> test bug
>>>>>>>>>>> fix.
>>>>>>>>>>> Here is the first simple fix for bug 7123972
>>>>>>>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=7123972>, Can you 
>>>>>>>>>>> please
>>>>>>>>>>> help
>>>>>>>>>>> to review and comment? Attachment is the patch Thanks!
>>>>>>>>>>>
>>>>>>>>>>> This bug is caused by wrong assumption that the GC is started
>>>>>>>>>>> immediately to recycle un-referenced objects after 
>>>>>>>>>>> System.gc() called
>>>>>>>>>>> one or two times.
>>>>>>>>>>>
>>>>>>>>>>> The proposed solution is to make sure the un-referenced 
>>>>>>>>>>> object is
>>>>>>>>>>> recycled by GC before checking if the reference is null.
>>>>>>>>>>
>>>>>>>>>> Your patch makes its own assumptions - specifically that 
>>>>>>>>>> finalization
>>>>>>>>>> must eventually run. At a minimum you should add
>>>>>>>>>> System.runFinalization() calls after the System.gc() inside 
>>>>>>>>>> the loop.
>>>>>>>>>> Even that is no guarantee in a general sense, though it 
>>>>>>>>>> should work
>>>>>>>>>> for hotspot.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Eric
>>>>>>>>>
>>>>>>> Hi Alan & David,
>>>>>>>
>>>>>>> Thank you for your comments, sorry for reply this mail late as i 
>>>>>>> was
>>>>>>> just back from the dragon boat holiday.
>>>>>>> I have updated the code again based on your suggestions: rename 
>>>>>>> the flag
>>>>>>> variable, increase the sleep time and remove it from problem list.
>>>>>>> The attachment is the full webrev for this patch, Can you please 
>>>>>>> review
>>>>>>> again? Thanks a lot!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eric
>>>>
>>


-------------- next part --------------
--- old/test/ProblemList.txt	2012-07-03 18:25:07.707507490 +0800
+++ new/test/ProblemList.txt	2012-07-03 18:25:06.901427388 +0800
@@ -122,9 +122,6 @@
 
 # jdk_lang
 
-# 7123972
-java/lang/annotation/loaderLeak/Main.java			generic-all
-
 # 6944188
 java/lang/management/ThreadMXBean/ThreadStateTest.java          generic-all
 
-------------- next part --------------
--- old/test/java/lang/annotation/loaderLeak/Main.java	2012-07-03 18:25:10.784495232 +0800
+++ new/test/java/lang/annotation/loaderLeak/Main.java	2012-07-03 18:25:09.996408765 +0800
@@ -57,9 +57,17 @@
         System.gc();
         System.gc();
         loader = null;
-        System.gc();
-        System.gc();
-        if (c.get() != null) throw new AssertionError();
+
+        // Might require multiple calls to System.gc() for weak-references
+        // processing to be complete. If the weak-reference is not cleared as
+        // expected we will hang here until timed out by the test harness.
+        while (true) {
+            System.gc();
+            Thread.sleep(20);
+            if (c.get() == null) {
+                break;
+            }
+        }
     }
 }
 

From kelly.ohair at oracle.com  Tue Jul  3 15:00:29 2012
From: kelly.ohair at oracle.com (Kelly Ohair)
Date: Tue, 3 Jul 2012 08:00:29 -0700
Subject: classlist.* and jar_reorder ?
In-Reply-To: <4FF29742.2040204@oracle.com>
References: <4FF29742.2040204@oracle.com>
Message-ID: <5EDC6E36-B21D-4328-841E-1A145F83F9C5@oracle.com>

not sure anyone ever created docs on it

it lists the hot classes as i recall and the intention was to force a particular class order in rt.jar for performance reasons, like the mapfiles forced hot native functions into fewer pages on solaris

There is a JarReorder class or build tool in the make directory that gets this list and the actual  list creates a new one to supply jar when rt.jar gets made in Release.gmk

it was created around the time of class data sharing in hotspot  and might be related to that

i worked on the JarReorder tool  but that is just a tool

hope this helps

my thumb is tired now :(

Sent from my iPhone

On Jul 2, 2012, at 23:54, David Holmes <david.holmes at oracle.com> wrote:

> 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


From sean.mullan at oracle.com  Tue Jul  3 18:57:34 2012
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 03 Jul 2012 18:57:34 +0000
Subject: hg: jdk8/tl/jdk: 7133344: Document the java.security.properties
	system property feature in the java.security file
Message-ID: <20120703185805.837DD47C70@hg.openjdk.java.net>

Changeset: d375ea39ce9c
Author:    mullan
Date:      2012-07-03 14:56 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d375ea39ce9c

7133344: Document the java.security.properties system property feature in the java.security file
Reviewed-by: hawtin, mullan, weijun
Contributed-by: jason.uh at oracle.com

! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows



From stuart.marks at oracle.com  Tue Jul  3 21:04:08 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Jul 2012 14:04:08 -0700
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF29D3B.60005@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com>
Message-ID: <4FF35E48.909@oracle.com>

Webrev now posted at

http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/

The changes look good to me. If there's no further discussion, I'll push them 
in a couple days (U.S. holiday coming up).

s'marks

On 7/3/12 12:20 AM, Stuart Marks wrote:
> This approach looks good to me. Please go ahead and update 7123972 as well, and
> I'll post these webrevs tomorrow (my time).
>
> Thanks.
>
> s'marks
>
> On 7/2/12 11:41 PM, Eric Wang wrote:
>> David,
>>
>> I have added the comments before the loop, please help to review. If it is OK,
>> I'll update the 7123972 as well.
>>
>> Thanks,
>> Eric
>>
>> On 2012/7/3 12:22, David Holmes wrote:
>>> Hi Eric,
>>>
>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>> Hi Stuart and David,
>>>>
>>>> Thanks for the suggestion about the timeout. so there are three ways to
>>>> handle the timeout.
>>>>
>>>> 1. Add comment to explain that test failed due to default timeout
>>>> 2. Specify the the timeout option
>>>> 3. Timeout programly
>>>>
>>>> Is it ok for you that i'd like to choose the second way "explict
>>>> timeout" as the test looks simply and lucid?
>>>
>>> If by #2 you mean add something like:
>>>
>>> @run main/timeout=10
>>>
>>> then no. Earlier this year there were changes to a bunch of tests that set
>>> timeouts shorter than the jtreg default, to delete the timeouts. Given that,
>>> my misgivings about relying on the harness are not relevant so we need only
>>> do #1 and add a comment to make it clear that a failing test will be
>>> indicated via the harness timeout.
>>>
>>> David
>>> -----
>>>
>>>> Regards,
>>>> Eric
>>>>
>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>> Now, how can the test fail? If ref is never cleared, the while loop
>>>>>>>> will
>>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>>> test. It
>>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>>> explains
>>>>>>>> this.
>>>>>>>
>>>>>>> Agreed. Something like
>>>>>>>
>>>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>>>> processing
>>>>>>> to be complete.
>>>>>>> // If the weak-reference is not cleared as expected we will hang here
>>>>>>> // until timed out by the test harness
>>>>>>>
>>>>>>> Though now I write that I'm unhappy that this will only behave nicely
>>>>>>> if run
>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>
>>>>>> So, are you unhappy enough that we should ask Eric to add an explicit
>>>>>> timeout?
>>>>>
>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>
>>>>>> I don't think it would be that difficult. Perhaps a technique like the
>>>>>> following would suffice. Get System.currentTimeMillis() before the loop,
>>>>>> and call it again each time through the loop, and fail if the difference
>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>>> threads or even Timer/TimerTask.
>>>>>
>>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>>> This then requires adding back the check for null outside the loop.
>>>>>
>>>>>> On the other hand if one is running this test directly instead of
>>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly long
>>>>>> time.
>>>>>
>>>>> True.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> s'marks
>>>>
>>>>
>>
>>


From stuart.marks at oracle.com  Tue Jul  3 21:04:57 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Jul 2012 14:04:57 -0700
Subject: Patch review request - Test bug 7123972
	test/java/lang/annotation/loaderLeak/Main.java fails intermittently
In-Reply-To: <4FF2CB7D.201@oracle.com>
References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com>
	<4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com>
	<4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com>
	<4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com>
	<4FEBE02D.6010406@oracle.com> <4FED6908.7080405@oracle.com>
	<4FEE25C0.2040900@oracle.com> <4FF2CB7D.201@oracle.com>
Message-ID: <4FF35E79.2070500@oracle.com>

Webrev posted here:

http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.2/

The changes look good. If there's no further discussion, I'll push them in a 
couple days.

s'marks

On 7/3/12 3:37 AM, Eric Wang wrote:
> Hi Stuart,
>
> I have made updates which is same as 6948101, please help to review, Thanks a lot!
>
> Regards,
> Eric
> On 2012/6/30 6:01, Stuart Marks wrote:
>> I've posted the updated webrev here:
>>
>> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.1/
>>
>> This code is pretty much the same as 6948101 and the same comments I had on
>> that bug apply here as well, so please make similar updates to this one.
>>
>> Thanks.
>>
>> s'marks
>>
>> On 6/29/12 1:36 AM, Eric Wang wrote:
>>> Hi Stuart & David?
>>>
>>> Attachment is the new changes to make code simply by following David
>>> suggestion, Can you help please review again, Thanks a lot!
>>>
>>> Regards,
>>> Eric
>>> On 2012/6/28 12:40, Stuart Marks wrote:
>>>> I've posted the webrev here:
>>>>
>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/
>>>>
>>>> I've looked at the changes and they seem fine.
>>>>
>>>> It's interesting that the run times take 30-60 sec in your experience. I've
>>>> run them on my system (Linux in a virtual machine) and they usually run in
>>>> 10-20 sec. In any case, as you say, if the test times out it indicates there
>>>> really was a failure.
>>>>
>>>> I'll give people a chance to look at the webrev and if there aren't any more
>>>> comments in another day or so I'll push in the changeset.
>>>>
>>>> Thanks for developing this!
>>>>
>>>> s'marks
>>>>
>>>> On 6/26/12 11:50 PM, Eric Wang wrote:
>>>>> Hi David,
>>>>>
>>>>> Thank you! I run the test several times on 3 platforms (windows, solaris and
>>>>> linux), the average execution time is 30secs to 60secs. if the test hang 2
>>>>> minutes, there should be something wrong.
>>>>>
>>>>> Hi Marks,
>>>>>
>>>>> I don't have the author role, Can you please help to review and post the
>>>>> webrev
>>>>> 7123972.zip in attachment if it is OK, Thanks a lot!
>>>>>
>>>>> Regards,
>>>>> Eric
>>>>>
>>>>> On 2012/6/27 14:19, David Holmes wrote:
>>>>>> Eric,
>>>>>>
>>>>>> Ignore my comment about adding the timeouts. As Alan reminded me if the test
>>>>>> would hang then jtreg will time it out after two minutes anyway.
>>>>>>
>>>>>> So this is good to go as far as I am concerned.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 27/06/2012 7:51 AM, David Holmes wrote:
>>>>>>> Thanks Eric.
>>>>>>>
>>>>>>> So to summarize:
>>>>>>>
>>>>>>> - we create a custom classloader, load a class through it and store a
>>>>>>> reference to that Class in a WeakReference
>>>>>>> - we then drop the reference to the loader
>>>>>>>
>>>>>>> At this point the only reference to the loader is from the Class loaded,
>>>>>>> which in turn is only weakly reachable.
>>>>>>>
>>>>>>> I must confess that I'm unclear why this test should be failing in its
>>>>>>> original form. The first gc() should remove the strong reference to the
>>>>>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class.
>>>>>>> The second gc() should detect the cycle and clear the WeakRef. I guess
>>>>>>> the problem is that depending on which gc is in use the actual gc()
>>>>>>> calls may not in fact induce every possible GC action.
>>>>>>>
>>>>>>> The fix seems reasonable in that regard - keep gc'ing and finalizing
>>>>>>> till we see the loader is gone, and so the WeakReference should be
>>>>>>> cleared. The original bug would cause a ref to the Class to remain (from
>>>>>>> the annotation) and hence the WeakRef would not be cleared. However, in
>>>>>>> that case the loader would also be strongly referenced and so never
>>>>>>> become finalizable. So if this test was now run against a JDK with the
>>>>>>> original bug, the test would hang. So I think we need to add a timeout
>>>>>>> in there as well.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 25/06/2012 6:06 PM, Eric Wang wrote:
>>>>>>>> On 2012/6/21 20:16, David Holmes wrote:
>>>>>>>>> Hi Eric,
>>>>>>>>>
>>>>>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Thanks for your review, I have updated the code by following your
>>>>>>>>>> suggestion. please see the attachment.
>>>>>>>>>> I'm not sure whether there's a better way to guarantee object finalized
>>>>>>>>>> by GC definitely within the given time. The proposed fix may work in
>>>>>>>>>> most cases but may still throw InterruptException if execution is
>>>>>>>>>> timeout (2 minutes of JTreg by default).
>>>>>>>>>
>>>>>>>>> There is no way to guarantee finalization in a specific timeframe, but
>>>>>>>>> if a simple test hasn't executed finalizers in 2 minutes then that in
>>>>>>>>> itself indicates a problem.
>>>>>>>>>
>>>>>>>>> Can you post a full webrev for this patch? I don't like seeing it out
>>>>>>>>> of context and am wondering exactly what we are trying to GC here.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>> On 2012/6/21 14:32, David Holmes wrote:
>>>>>>>>>>> Hi Eric,
>>>>>>>>>>>
>>>>>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote:
>>>>>>>>>>>> I come from Java SQE team who are interested in regression test bug
>>>>>>>>>>>> fix.
>>>>>>>>>>>> Here is the first simple fix for bug 7123972
>>>>>>>>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=7123972>, Can you please
>>>>>>>>>>>> help
>>>>>>>>>>>> to review and comment? Attachment is the patch Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> This bug is caused by wrong assumption that the GC is started
>>>>>>>>>>>> immediately to recycle un-referenced objects after System.gc() called
>>>>>>>>>>>> one or two times.
>>>>>>>>>>>>
>>>>>>>>>>>> The proposed solution is to make sure the un-referenced object is
>>>>>>>>>>>> recycled by GC before checking if the reference is null.
>>>>>>>>>>>
>>>>>>>>>>> Your patch makes its own assumptions - specifically that finalization
>>>>>>>>>>> must eventually run. At a minimum you should add
>>>>>>>>>>> System.runFinalization() calls after the System.gc() inside the loop.
>>>>>>>>>>> Even that is no guarantee in a general sense, though it should work
>>>>>>>>>>> for hotspot.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>> Hi Alan & David,
>>>>>>>>
>>>>>>>> Thank you for your comments, sorry for reply this mail late as i was
>>>>>>>> just back from the dragon boat holiday.
>>>>>>>> I have updated the code again based on your suggestions: rename the flag
>>>>>>>> variable, increase the sleep time and remove it from problem list.
>>>>>>>> The attachment is the full webrev for this patch, Can you please review
>>>>>>>> again? Thanks a lot!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eric
>>>>>
>>>
>
>


From david.holmes at oracle.com  Tue Jul  3 23:53:39 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Jul 2012 09:53:39 +1000
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF35E48.909@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com> <4FF35E48.909@oracle.com>
Message-ID: <4FF38603.3010804@oracle.com>

Please fix the missing space in

if(ref.get()

before pushing.

Thanks,
David

On 4/07/2012 7:04 AM, Stuart Marks wrote:
> Webrev now posted at
>
> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/
>
> The changes look good to me. If there's no further discussion, I'll push
> them in a couple days (U.S. holiday coming up).
>
> s'marks
>
> On 7/3/12 12:20 AM, Stuart Marks wrote:
>> This approach looks good to me. Please go ahead and update 7123972 as
>> well, and
>> I'll post these webrevs tomorrow (my time).
>>
>> Thanks.
>>
>> s'marks
>>
>> On 7/2/12 11:41 PM, Eric Wang wrote:
>>> David,
>>>
>>> I have added the comments before the loop, please help to review. If
>>> it is OK,
>>> I'll update the 7123972 as well.
>>>
>>> Thanks,
>>> Eric
>>>
>>> On 2012/7/3 12:22, David Holmes wrote:
>>>> Hi Eric,
>>>>
>>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>>> Hi Stuart and David,
>>>>>
>>>>> Thanks for the suggestion about the timeout. so there are three
>>>>> ways to
>>>>> handle the timeout.
>>>>>
>>>>> 1. Add comment to explain that test failed due to default timeout
>>>>> 2. Specify the the timeout option
>>>>> 3. Timeout programly
>>>>>
>>>>> Is it ok for you that i'd like to choose the second way "explict
>>>>> timeout" as the test looks simply and lucid?
>>>>
>>>> If by #2 you mean add something like:
>>>>
>>>> @run main/timeout=10
>>>>
>>>> then no. Earlier this year there were changes to a bunch of tests
>>>> that set
>>>> timeouts shorter than the jtreg default, to delete the timeouts.
>>>> Given that,
>>>> my misgivings about relying on the harness are not relevant so we
>>>> need only
>>>> do #1 and add a comment to make it clear that a failing test will be
>>>> indicated via the harness timeout.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Regards,
>>>>> Eric
>>>>>
>>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>>> Now, how can the test fail? If ref is never cleared, the while
>>>>>>>>> loop
>>>>>>>>> will
>>>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>>>> test. It
>>>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>>>> explains
>>>>>>>>> this.
>>>>>>>>
>>>>>>>> Agreed. Something like
>>>>>>>>
>>>>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>>>>> processing
>>>>>>>> to be complete.
>>>>>>>> // If the weak-reference is not cleared as expected we will hang
>>>>>>>> here
>>>>>>>> // until timed out by the test harness
>>>>>>>>
>>>>>>>> Though now I write that I'm unhappy that this will only behave
>>>>>>>> nicely
>>>>>>>> if run
>>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>>
>>>>>>> So, are you unhappy enough that we should ask Eric to add an
>>>>>>> explicit
>>>>>>> timeout?
>>>>>>
>>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>>
>>>>>>> I don't think it would be that difficult. Perhaps a technique
>>>>>>> like the
>>>>>>> following would suffice. Get System.currentTimeMillis() before
>>>>>>> the loop,
>>>>>>> and call it again each time through the loop, and fail if the
>>>>>>> difference
>>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>>>> threads or even Timer/TimerTask.
>>>>>>
>>>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>>>> This then requires adding back the check for null outside the loop.
>>>>>>
>>>>>>> On the other hand if one is running this test directly instead of
>>>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly
>>>>>>> long
>>>>>>> time.
>>>>>>
>>>>>> True.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> s'marks
>>>>>
>>>>>
>>>
>>>


From stuart.marks at oracle.com  Wed Jul  4 00:58:28 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Jul 2012 17:58:28 -0700
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF38603.3010804@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com> <4FF35E48.909@oracle.com>
	<4FF38603.3010804@oracle.com>
Message-ID: <4FF39534.2080500@oracle.com>

Sure, I can take care of that.

If this is the only change, no need to generate another webrev, Eric.

s'marks


On 7/3/12 4:53 PM, David Holmes wrote:
> Please fix the missing space in
>
> if(ref.get()
>
> before pushing.
>
> Thanks,
> David
>
> On 4/07/2012 7:04 AM, Stuart Marks wrote:
>> Webrev now posted at
>>
>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/
>>
>> The changes look good to me. If there's no further discussion, I'll push
>> them in a couple days (U.S. holiday coming up).
>>
>> s'marks
>>
>> On 7/3/12 12:20 AM, Stuart Marks wrote:
>>> This approach looks good to me. Please go ahead and update 7123972 as
>>> well, and
>>> I'll post these webrevs tomorrow (my time).
>>>
>>> Thanks.
>>>
>>> s'marks
>>>
>>> On 7/2/12 11:41 PM, Eric Wang wrote:
>>>> David,
>>>>
>>>> I have added the comments before the loop, please help to review. If
>>>> it is OK,
>>>> I'll update the 7123972 as well.
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>> On 2012/7/3 12:22, David Holmes wrote:
>>>>> Hi Eric,
>>>>>
>>>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>>>> Hi Stuart and David,
>>>>>>
>>>>>> Thanks for the suggestion about the timeout. so there are three
>>>>>> ways to
>>>>>> handle the timeout.
>>>>>>
>>>>>> 1. Add comment to explain that test failed due to default timeout
>>>>>> 2. Specify the the timeout option
>>>>>> 3. Timeout programly
>>>>>>
>>>>>> Is it ok for you that i'd like to choose the second way "explict
>>>>>> timeout" as the test looks simply and lucid?
>>>>>
>>>>> If by #2 you mean add something like:
>>>>>
>>>>> @run main/timeout=10
>>>>>
>>>>> then no. Earlier this year there were changes to a bunch of tests
>>>>> that set
>>>>> timeouts shorter than the jtreg default, to delete the timeouts.
>>>>> Given that,
>>>>> my misgivings about relying on the harness are not relevant so we
>>>>> need only
>>>>> do #1 and add a comment to make it clear that a failing test will be
>>>>> indicated via the harness timeout.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Regards,
>>>>>> Eric
>>>>>>
>>>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>>>> Now, how can the test fail? If ref is never cleared, the while
>>>>>>>>>> loop
>>>>>>>>>> will
>>>>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>>>>> test. It
>>>>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>>>>> explains
>>>>>>>>>> this.
>>>>>>>>>
>>>>>>>>> Agreed. Something like
>>>>>>>>>
>>>>>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>>>>>> processing
>>>>>>>>> to be complete.
>>>>>>>>> // If the weak-reference is not cleared as expected we will hang
>>>>>>>>> here
>>>>>>>>> // until timed out by the test harness
>>>>>>>>>
>>>>>>>>> Though now I write that I'm unhappy that this will only behave
>>>>>>>>> nicely
>>>>>>>>> if run
>>>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>>>
>>>>>>>> So, are you unhappy enough that we should ask Eric to add an
>>>>>>>> explicit
>>>>>>>> timeout?
>>>>>>>
>>>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>>>
>>>>>>>> I don't think it would be that difficult. Perhaps a technique
>>>>>>>> like the
>>>>>>>> following would suffice. Get System.currentTimeMillis() before
>>>>>>>> the loop,
>>>>>>>> and call it again each time through the loop, and fail if the
>>>>>>>> difference
>>>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>>>>> threads or even Timer/TimerTask.
>>>>>>>
>>>>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>>>>> This then requires adding back the check for null outside the loop.
>>>>>>>
>>>>>>>> On the other hand if one is running this test directly instead of
>>>>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly
>>>>>>>> long
>>>>>>>> time.
>>>>>>>
>>>>>>> True.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>> s'marks
>>>>>>
>>>>>>
>>>>
>>>>


From dbelfer at gmail.com  Wed Jul  4 01:14:52 2012
From: dbelfer at gmail.com (Diego Belfer)
Date: Tue, 3 Jul 2012 22:14:52 -0300
Subject: Concurrent formatters
Message-ID: <CAHers=nXiF3fXkZzG7sjTHZuFpxD5f6jnUQYjjK8zh2n+kOA-g@mail.gmail.com>

Hello,

I was thinking of working on trying to convert the code of some of the
formatters DecimalFormatter, SimpleDateFormatter, etc to allow concurrent
calls to the format and parse methods.
I know it has been discussed many times in the forums and I understand they
were not initially designed for that, but it does not seem very difficult
at first glance to attempt to make this enhancement.

What do you think? Have you already tried to accomplish this and found some
blocking issues?
Do you think this change would make the API documentation confusing ?

Best,
Diego Belfer [muralx]


From yiming.wang at oracle.com  Wed Jul  4 01:54:17 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Wed, 04 Jul 2012 09:54:17 +0800
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF39534.2080500@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com> <4FF35E48.909@oracle.com>
	<4FF38603.3010804@oracle.com> <4FF39534.2080500@oracle.com>
Message-ID: <4FF3A249.60109@oracle.com>

Opps, It is my carelessness, I will be more careful in the next bug fixes.
Thank you to review and change it.

Regards,
Eric

On 2012/7/4 8:58, Stuart Marks wrote:
> Sure, I can take care of that.
>
> If this is the only change, no need to generate another webrev, Eric.
>
> s'marks
>
>
> On 7/3/12 4:53 PM, David Holmes wrote:
>> Please fix the missing space in
>>
>> if(ref.get()
>>
>> before pushing.
>>
>> Thanks,
>> David
>>
>> On 4/07/2012 7:04 AM, Stuart Marks wrote:
>>> Webrev now posted at
>>>
>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/
>>>
>>> The changes look good to me. If there's no further discussion, I'll 
>>> push
>>> them in a couple days (U.S. holiday coming up).
>>>
>>> s'marks
>>>
>>> On 7/3/12 12:20 AM, Stuart Marks wrote:
>>>> This approach looks good to me. Please go ahead and update 7123972 as
>>>> well, and
>>>> I'll post these webrevs tomorrow (my time).
>>>>
>>>> Thanks.
>>>>
>>>> s'marks
>>>>
>>>> On 7/2/12 11:41 PM, Eric Wang wrote:
>>>>> David,
>>>>>
>>>>> I have added the comments before the loop, please help to review. If
>>>>> it is OK,
>>>>> I'll update the 7123972 as well.
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>> On 2012/7/3 12:22, David Holmes wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>>>>> Hi Stuart and David,
>>>>>>>
>>>>>>> Thanks for the suggestion about the timeout. so there are three
>>>>>>> ways to
>>>>>>> handle the timeout.
>>>>>>>
>>>>>>> 1. Add comment to explain that test failed due to default timeout
>>>>>>> 2. Specify the the timeout option
>>>>>>> 3. Timeout programly
>>>>>>>
>>>>>>> Is it ok for you that i'd like to choose the second way "explict
>>>>>>> timeout" as the test looks simply and lucid?
>>>>>>
>>>>>> If by #2 you mean add something like:
>>>>>>
>>>>>> @run main/timeout=10
>>>>>>
>>>>>> then no. Earlier this year there were changes to a bunch of tests
>>>>>> that set
>>>>>> timeouts shorter than the jtreg default, to delete the timeouts.
>>>>>> Given that,
>>>>>> my misgivings about relying on the harness are not relevant so we
>>>>>> need only
>>>>>> do #1 and add a comment to make it clear that a failing test will be
>>>>>> indicated via the harness timeout.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Regards,
>>>>>>> Eric
>>>>>>>
>>>>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>>>>> Now, how can the test fail? If ref is never cleared, the while
>>>>>>>>>>> loop
>>>>>>>>>>> will
>>>>>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>>>>>> test. It
>>>>>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>>>>>> explains
>>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> Agreed. Something like
>>>>>>>>>>
>>>>>>>>>> // Might require multiple calls to System.gc() for 
>>>>>>>>>> weak-references
>>>>>>>>>> processing
>>>>>>>>>> to be complete.
>>>>>>>>>> // If the weak-reference is not cleared as expected we will hang
>>>>>>>>>> here
>>>>>>>>>> // until timed out by the test harness
>>>>>>>>>>
>>>>>>>>>> Though now I write that I'm unhappy that this will only behave
>>>>>>>>>> nicely
>>>>>>>>>> if run
>>>>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>>>>
>>>>>>>>> So, are you unhappy enough that we should ask Eric to add an
>>>>>>>>> explicit
>>>>>>>>> timeout?
>>>>>>>>
>>>>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>>>>
>>>>>>>>> I don't think it would be that difficult. Perhaps a technique
>>>>>>>>> like the
>>>>>>>>> following would suffice. Get System.currentTimeMillis() before
>>>>>>>>> the loop,
>>>>>>>>> and call it again each time through the loop, and fail if the
>>>>>>>>> difference
>>>>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>>>>>> threads or even Timer/TimerTask.
>>>>>>>>
>>>>>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>>>>>> This then requires adding back the check for null outside the 
>>>>>>>> loop.
>>>>>>>>
>>>>>>>>> On the other hand if one is running this test directly instead of
>>>>>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly
>>>>>>>>> long
>>>>>>>>> time.
>>>>>>>>
>>>>>>>> True.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>
>>>>>>>>> s'marks
>>>>>>>
>>>>>>>
>>>>>
>>>>>




From lana.steuck at oracle.com  Wed Jul  4 02:20:43 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:20:43 +0000
Subject: hg: jdk8/tl: Added tag jdk8-b45 for changeset 633f2378c904
Message-ID: <20120704022043.899B747C8C@hg.openjdk.java.net>

Changeset: 27fa766a2298
Author:    katleman
Date:      2012-06-28 09:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/27fa766a2298

Added tag jdk8-b45 for changeset 633f2378c904

! .hgtags



From lana.steuck at oracle.com  Wed Jul  4 02:20:41 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:20:41 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20120704022046.7064847C8F@hg.openjdk.java.net>

Changeset: 30141e598d72
Author:    katleman
Date:      2012-06-28 09:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/30141e598d72

Added tag jdk8-b45 for changeset 747dad9e9d37

! .hgtags

Changeset: 666efea2df67
Author:    lana
Date:      2012-07-03 18:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/666efea2df67

Merge




From lana.steuck at oracle.com  Wed Jul  4 02:20:51 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:20:51 +0000
Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b45 for changeset e80ac58b5ba9
Message-ID: <20120704022100.92DD747C92@hg.openjdk.java.net>

Changeset: ae368a83c240
Author:    katleman
Date:      2012-06-28 09:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ae368a83c240

Added tag jdk8-b45 for changeset e80ac58b5ba9

! .hgtags



From lana.steuck at oracle.com  Wed Jul  4 02:20:51 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:20:51 +0000
Subject: hg: jdk8/tl/langtools: Added tag jdk8-b45 for changeset e111e4587cca
Message-ID: <20120704022100.E21CF47C95@hg.openjdk.java.net>

Changeset: 4ca599497172
Author:    katleman
Date:      2012-06-28 09:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ca599497172

Added tag jdk8-b45 for changeset e111e4587cca

! .hgtags



From lana.steuck at oracle.com  Wed Jul  4 02:21:00 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:21:00 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20120704022111.DCFA847C99@hg.openjdk.java.net>

Changeset: 300f45e99064
Author:    katleman
Date:      2012-06-28 09:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/300f45e99064

Added tag jdk8-b45 for changeset 57476f66e13c

! .hgtags

Changeset: 9cb8be5e6119
Author:    lana
Date:      2012-07-03 18:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9cb8be5e6119

Merge




From lana.steuck at oracle.com  Wed Jul  4 02:21:02 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:21:02 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120704022123.331DC47C9C@hg.openjdk.java.net>

Changeset: 8d2ed9d58453
Author:    katleman
Date:      2012-06-28 09:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d2ed9d58453

Added tag jdk8-b45 for changeset b92353a01aa0

! .hgtags

Changeset: 8ccbd5aabeab
Author:    lana
Date:      2012-07-03 18:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ccbd5aabeab

Merge




From lana.steuck at oracle.com  Wed Jul  4 02:21:09 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 04 Jul 2012 02:21:09 +0000
Subject: hg: jdk8/tl/hotspot: 33 new changesets
Message-ID: <20120704022217.B693047C9F@hg.openjdk.java.net>

Changeset: a8b9798c1d45
Author:    katleman
Date:      2012-06-28 09:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a8b9798c1d45

Added tag jdk8-b45 for changeset 9d5f20961bc5

! .hgtags

Changeset: 1c280e5b8d31
Author:    amurillo
Date:      2012-06-15 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c280e5b8d31

7175515: new hotspot build - hs24-b15
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: e9140bf80b4a
Author:    coleenp
Date:      2012-06-13 19:52 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9140bf80b4a

7158800: Improve storage of symbol tables
Summary: Use an alternate version of hashing algorithm for symbol string tables and after a certain bucket size to improve performance
Reviewed-by: pbk, kamg, dlong, kvn, fparain

+ src/share/vm/classfile/altHashing.cpp
+ src/share/vm/classfile/altHashing.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/hashtable.inline.hpp
+ test/runtime/7158800/BadUtf8.java
+ test/runtime/7158800/InternTest.java
+ test/runtime/7158800/badstrings.txt

Changeset: b87e5a681416
Author:    poonam
Date:      2012-06-14 02:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b87e5a681416

6310967: SA: jstack -m produce failures in output
Summary: While looking for the sender frame check that the frame pointer should not be less than the stack pointer.
Reviewed-by: dholmes, sla

! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/sparc/LinuxSPARCCFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcCFrame.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java

Changeset: e16bc4ad5f20
Author:    poonam
Date:      2012-06-14 22:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e16bc4ad5f20

Merge


Changeset: 86e17e45019d
Author:    coleenp
Date:      2012-06-15 07:51 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86e17e45019d

7177307: fix fo CR7158800 doesn't contain Test7158800.sh
Summary: forgot to hg add it
Reviewed-by: pbk, kamg, dlong, kvn, fparain

+ test/runtime/7158800/Test7158800.sh

Changeset: 58ad5f22317e
Author:    sla
Date:      2012-06-18 11:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58ad5f22317e

Merge

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/runtime/globals.hpp

Changeset: d1b0644d6acf
Author:    dcubed
Date:      2012-06-20 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1b0644d6acf

7175255: symlinks are wrong, which caused jdk8-promote-2 to fail (client/64/64 directories in debuginfo zips)
Summary: Fix bad paths in client/64 and server/64 debug info and symlink creation
Reviewed-by: ohair, dholmes

! make/solaris/makefiles/add_gnu_debuglink.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/fix_empty_sec_hdr_flags.make

Changeset: 7de1d3b57419
Author:    dcubed
Date:      2012-06-20 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7de1d3b57419

Merge

! make/solaris/makefiles/defs.make

Changeset: cfa2c82f4c04
Author:    minqi
Date:      2012-06-22 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfa2c82f4c04

7175133: jinfo failed to get system properties after 6924259
Summary: String offset and count fields as fix of 6924259 were removed, and become optional. SA still use offset and count fields to read String contents and failed. Fix if they exist, use them other then use value field only to read, this keeps consistent with the changes in 6924259.
Reviewed-by: dholmes, mikael
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java

Changeset: d8a240abb23a
Author:    minqi
Date:      2012-06-22 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8a240abb23a

7177128: SA cannot get correct system properties after 7126277
Summary: Bug fix of 7126277 changed hashing algorithm and also changed key as final field, this led SA unable to set correct value for key. Solution by reading key/value and insert them into the new table.
Reviewed-by: dholmes, mikael
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java

Changeset: 588f559105c1
Author:    sla
Date:      2012-06-25 14:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/588f559105c1

7178846: IterateThroughHeap: heap_iteration_callback passes a negative size
Summary: Missing cast caused integer overflow
Reviewed-by: rbackman, dholmes

! src/share/vm/prims/jvmtiTagMap.cpp

Changeset: 246d977b51f2
Author:    coleenp
Date:      2012-06-25 21:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/246d977b51f2

7178670: runtime/7158800/BadUtf8.java fails in SymbolTable::rehash_table
Summary: Cannot delete _buckets and HashtableEntries in shared space (CDS)
Reviewed-by: acorn, kvn, dlong, dcubed, kamg

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp

Changeset: 36b2d4cfcf03
Author:    coleenp
Date:      2012-06-25 18:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36b2d4cfcf03

Merge


Changeset: 74533f63b116
Author:    sla
Date:      2012-06-27 15:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74533f63b116

7178667: ALT_EXPORT_PATH does not export server jvm on macosx
Summary: Missing .PHONY targets in makefile
Reviewed-by: dholmes, dsamersoff

! make/bsd/makefiles/universal.gmk

Changeset: f7baf26515fc
Author:    collins
Date:      2012-06-19 21:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7baf26515fc

7178113: build environment change
Summary: Simple change to enable proper builds of arm target
Reviewed-by: ohair, dholmes

! make/jprt.properties

Changeset: 634b8615a6ba
Author:    jiangli
Date:      2012-06-22 14:00 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/634b8615a6ba

7177409: Perf regression in JVM_GetClassDeclaredFields after generic signature changes.
Summary: In fieldDescriptor::generic_signature() returns NULL immediately if the field has no generic signature.
Reviewed-by: dholmes, coleenp, jcoomes

! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/reflection.cpp

Changeset: 06320b1578cb
Author:    dlong
Date:      2012-06-25 15:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06320b1578cb

7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC
Summary: build powerpc with -fPIC
Reviewed-by: mikael, vladidan, roland
Contributed-by: dean.long at oracle.com

! make/pic.make

Changeset: 7d5f65916db0
Author:    bdelsart
Date:      2012-06-28 04:21 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d5f65916db0

Merge


Changeset: 8c92982cbbc4
Author:    kvn
Date:      2012-06-15 01:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c92982cbbc4

7119644: Increase superword's vector size up to 256 bits
Summary: Increase vector size up to 256-bits for YMM AVX registers on x86.
Reviewed-by: never, twisti, roland

! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/register_x86.cpp
! src/cpu/x86/vm/register_x86.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vmreg_x86.cpp
! src/cpu/x86/vm/vmreg_x86.inline.hpp
! src/cpu/x86/vm/x86.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formsopt.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/code/vmreg.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/mulnode.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/opcodes.cpp
! src/share/vm/opto/opcodes.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/regmask.cpp
! src/share/vm/opto/regmask.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! src/share/vm/runtime/vmStructs.cpp
+ test/compiler/7119644/TestBooleanVect.java
+ test/compiler/7119644/TestByteDoubleVect.java
+ test/compiler/7119644/TestByteFloatVect.java
+ test/compiler/7119644/TestByteIntVect.java
+ test/compiler/7119644/TestByteLongVect.java
+ test/compiler/7119644/TestByteShortVect.java
+ test/compiler/7119644/TestByteVect.java
+ test/compiler/7119644/TestCharShortVect.java
+ test/compiler/7119644/TestCharVect.java
+ test/compiler/7119644/TestDoubleVect.java
+ test/compiler/7119644/TestFloatDoubleVect.java
+ test/compiler/7119644/TestFloatVect.java
+ test/compiler/7119644/TestIntDoubleVect.java
+ test/compiler/7119644/TestIntFloatVect.java
+ test/compiler/7119644/TestIntLongVect.java
+ test/compiler/7119644/TestIntVect.java
+ test/compiler/7119644/TestLongDoubleVect.java
+ test/compiler/7119644/TestLongFloatVect.java
+ test/compiler/7119644/TestLongVect.java
+ test/compiler/7119644/TestShortDoubleVect.java
+ test/compiler/7119644/TestShortFloatVect.java
+ test/compiler/7119644/TestShortIntVect.java
+ test/compiler/7119644/TestShortLongVect.java
+ test/compiler/7119644/TestShortVect.java

Changeset: eeb819cf36e5
Author:    roland
Date:      2012-06-18 09:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eeb819cf36e5

7174363: Arrays.copyOfRange leads to VM crash with -Xcomp -server if executed by testing framework
Summary: Arrays.copyOfRange(original, from, to) with from > original.length tries to do a copy with a negative length.
Reviewed-by: kvn, twisti

! src/share/vm/opto/library_call.cpp
+ test/compiler/7174363/Test7174363.java

Changeset: f8de958e5b2c
Author:    twisti
Date:      2012-06-18 12:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8de958e5b2c

7176856: add the JRE name to the error log
Reviewed-by: coleenp, jrose, kvn, twisti
Contributed-by: Krystal Mok <sajia at taobao.com>

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 765ee2d1674b
Author:    twisti
Date:      2012-06-18 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/765ee2d1674b

7157365: jruby/bench.bench_timeout crashes with JVM internal error
Reviewed-by: jrose, kvn

! src/share/vm/memory/universe.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/type.cpp

Changeset: 6f8f439e247d
Author:    kvn
Date:      2012-06-19 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f8f439e247d

7177923: SIGBUS on sparc in compiled code for java.util.Calendar.clear()
Summary: disable vectorization of a memory access with more elements per vector than one which is used for alignment on sparc
Reviewed-by: twisti

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp

Changeset: 40782a131183
Author:    roland
Date:      2012-06-21 09:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40782a131183

7129715: MAC: SIGBUS in nsk stress test
Summary: StackOverflowError may get lost on OSX.
Reviewed-by: kvn, dcubed

! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp

Changeset: 424142833d10
Author:    kvn
Date:      2012-06-22 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/424142833d10

7178280: Failed new vector regression tests
Summary: When looking for the same value in an other register check that all parts of that register has the same value.
Reviewed-by: johnc, twisti

! src/share/vm/opto/postaloc.cpp

Changeset: 751bd303aa45
Author:    kvn
Date:      2012-06-26 09:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/751bd303aa45

7179138: Incorrect result with String concatenation optimization
Summary: check for and skip diamond shaped NULL check code for the result of toString()
Reviewed-by: twisti, roland

! src/share/vm/opto/stringopts.cpp
+ test/compiler/7179138/Test7179138_1.java
+ test/compiler/7179138/Test7179138_2.java

Changeset: de2f17add1fb
Author:    kvn
Date:      2012-06-28 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2f17add1fb

Merge


Changeset: 7994a5a35fcf
Author:    johnc
Date:      2012-06-25 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7994a5a35fcf

6921087: G1: remove per-GC-thread expansion tables from the fine-grain remembered sets
Summary: Remove the per-thread expansion tables (PosParPRT) and associated expansion and compaction from the fine grain RSet entries. This code has been unused for a while.
Reviewed-by: johnc, brutisso
Contributed-by: Thomas Schatzl <thomas.schatzl at jku.at>

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp

Changeset: 22de825d6faf
Author:    jcoomes
Date:      2012-06-29 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22de825d6faf

Merge


Changeset: 61a94c2da7c4
Author:    coleenp
Date:      2012-06-29 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61a94c2da7c4

7179759: ENV: Nightly fails during jdk copiyng for solaris platforms after FDS unzipping
Summary: libjvm_g_db.so and libjvm_g_dtrace.so links in .diz file still had 64 directory
Reviewed-by: kamg, dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make

Changeset: 40e5a3f2907e
Author:    amurillo
Date:      2012-06-29 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40e5a3f2907e

Merge


Changeset: cf37a594c38d
Author:    amurillo
Date:      2012-06-29 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf37a594c38d

Added tag hs24-b15 for changeset 40e5a3f2907e

! .hgtags



From xuelei.fan at oracle.com  Wed Jul  4 03:30:00 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 04 Jul 2012 03:30:00 +0000
Subject: hg: jdk8/tl/jdk: 7180038: regression test failure,
	SSLEngineBadBufferArrayAccess.java
Message-ID: <20120704033019.3BDAE47CB8@hg.openjdk.java.net>

Changeset: 3ae91286f313
Author:    xuelei
Date:      2012-07-03 20:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ae91286f313

7180038: regression test failure, SSLEngineBadBufferArrayAccess.java
Reviewed-by: weijun

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java



From dawid.weiss at gmail.com  Wed Jul  4 12:43:52 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 4 Jul 2012 14:43:52 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
Message-ID: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>

Hi folks.

Run the following with -Dfile.encoding=UTF-16:

public class TestBlah {
  public static void main(String []) throws Exception {
    TimeZone.getDefault();
  }
}

This on linux (and any unixish system I think) will result in:

java.lang.ExceptionInInitializerError
	at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
...

There is an encoding-sensitive part calling getBytes on the initial
path (and this screws it up):

    // package-private
    UnixFileSystem(UnixFileSystemProvider provider, String dir) {
        this.provider = provider;
        this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes();
        if (this.defaultDirectory[0] != '/') {
            throw new RuntimeException("default directory must be absolute");
        }

Filed a bug for this but don't have the ID yet.

Dawid


From Ulf.Zibis at CoSoCo.de  Wed Jul  4 13:24:01 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 04 Jul 2012 15:24:01 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
Message-ID: <4FF443F1.40502@CoSoCo.de>

Hi,

There is a similar bug:
Bug 6795536 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795536> - No system start for 
file.encoding=x-SJIS_0213

In this case on Windows.

-Ulf


Am 04.07.2012 14:43, schrieb Dawid Weiss:
> Hi folks.
>
> Run the following with -Dfile.encoding=UTF-16:
>
> public class TestBlah {
>    public static void main(String []) throws Exception {
>      TimeZone.getDefault();
>    }
> }
>
> This on linux (and any unixish system I think) will result in:
>
> java.lang.ExceptionInInitializerError
> 	at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
> ...
>
> There is an encoding-sensitive part calling getBytes on the initial
> path (and this screws it up):
>
>      // package-private
>      UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>          this.provider = provider;
>          this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes();
>          if (this.defaultDirectory[0] != '/') {
>              throw new RuntimeException("default directory must be absolute");
>          }
>
> Filed a bug for this but don't have the ID yet.
>
> Dawid
>




From dawid.weiss at gmail.com  Wed Jul  4 20:21:59 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 4 Jul 2012 22:21:59 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <4FF443F1.40502@CoSoCo.de>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
Message-ID: <CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>

> There is a similar bug:
> Bug 6795536 - No system start for file.encoding=x-SJIS_0213

Yeah... I looked at the sources in that package and there is at least
one more place which converts a String to bytes using getBytes(). This
seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
this is:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721

Dawid

>
> In this case on Windows.
>
> -Ulf
>
>
> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>
> Hi folks.
>
> Run the following with -Dfile.encoding=UTF-16:
>
> public class TestBlah {
>   public static void main(String []) throws Exception {
>     TimeZone.getDefault();
>   }
> }
>
> This on linux (and any unixish system I think) will result in:
>
> java.lang.ExceptionInInitializerError
> 	at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
> ...
>
> There is an encoding-sensitive part calling getBytes on the initial
> path (and this screws it up):
>
>     // package-private
>     UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>         this.provider = provider;
>         this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes();
>         if (this.defaultDirectory[0] != '/') {
>             throw new RuntimeException("default directory must be
> absolute");
>         }
>
> Filed a bug for this but don't have the ID yet.
>
> Dawid
>
>
>


From xueming.shen at oracle.com  Thu Jul  5 01:09:44 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 04 Jul 2012 18:09:44 -0700
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
Message-ID: <4FF4E958.2020103@oracle.com>

-Dfile.encoding=xyz is NOT a supported configuration. file.encoding is 
supposed to be a
read-only informative system property.

-Sherman

On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>> There is a similar bug:
>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
> Yeah... I looked at the sources in that package and there is at least
> one more place which converts a String to bytes using getBytes(). This
> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
> this is:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>
> Dawid
>
>> In this case on Windows.
>>
>> -Ulf
>>
>>
>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>
>> Hi folks.
>>
>> Run the following with -Dfile.encoding=UTF-16:
>>
>> public class TestBlah {
>>    public static void main(String []) throws Exception {
>>      TimeZone.getDefault();
>>    }
>> }
>>
>> This on linux (and any unixish system I think) will result in:
>>
>> java.lang.ExceptionInInitializerError
>> 	at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>> 	at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>> ...
>>
>> There is an encoding-sensitive part calling getBytes on the initial
>> path (and this screws it up):
>>
>>      // package-private
>>      UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>          this.provider = provider;
>>          this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes();
>>          if (this.defaultDirectory[0] != '/') {
>>              throw new RuntimeException("default directory must be
>> absolute");
>>          }
>>
>> Filed a bug for this but don't have the ID yet.
>>
>> Dawid
>>
>>
>>


From Ulf.Zibis at CoSoCo.de  Thu Jul  5 01:26:02 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 05 Jul 2012 03:26:02 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <4FF4E958.2020103@oracle.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
Message-ID: <4FF4ED2A.1040206@CoSoCo.de>

Am 05.07.2012 03:09, schrieb Xueming Shen:
> -Dfile.encoding=xyz is NOT a supported configuration. file.encoding is supposed to be a
> read-only informative system property.
Hm, but if one would build the JDK with e.g. x-SJIS_0213 set as default encoding, would it work?

I don't understand the resistance to fix the problem at it's source. There is already a patch: 
https://bugs.openjdk.java.net/show_bug.cgi?id=100091

-Ulf


>
> -Sherman
>
> On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>>> There is a similar bug:
>>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
>> Yeah... I looked at the sources in that package and there is at least
>> one more place which converts a String to bytes using getBytes(). This
>> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
>> this is:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>>
>> Dawid
>>
>>> In this case on Windows.
>>>
>>> -Ulf
>>>
>>>
>>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>>
>>> Hi folks.
>>>
>>> Run the following with -Dfile.encoding=UTF-16:
>>>
>>> public class TestBlah {
>>>    public static void main(String []) throws Exception {
>>>      TimeZone.getDefault();
>>>    }
>>> }
>>>
>>> This on linux (and any unixish system I think) will result in:
>>>
>>> java.lang.ExceptionInInitializerError
>>>     at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>>>     at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>>>     at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>>> ...
>>>
>>> There is an encoding-sensitive part calling getBytes on the initial
>>> path (and this screws it up):
>>>
>>>      // package-private
>>>      UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>>          this.provider = provider;
>>>          this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes();
>>>          if (this.defaultDirectory[0] != '/') {
>>>              throw new RuntimeException("default directory must be
>>> absolute");
>>>          }
>>>
>>> Filed a bug for this but don't have the ID yet.
>>>
>>> Dawid
>>>
>>>
>>>
>




From dawid.weiss at gmail.com  Thu Jul  5 06:00:00 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 5 Jul 2012 08:00:00 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <4FF4E958.2020103@oracle.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
Message-ID: <CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>

Well, what's the "right" way to enforce an initial encoding for
charset-less string-to-byte conversions and legacy streams? I still
think that snippet of code is buggy, no matter if file.encoding is or
isn't a supported settable property.

Besides, from what I see in JDK code base everything seems to be code
in a way to allow external definition of file.encoding (comments
inside System.c for example). Where is it stated that file.encoding is
read-only?

Dawid

On Thu, Jul 5, 2012 at 3:09 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> -Dfile.encoding=xyz is NOT a supported configuration. file.encoding is
> supposed to be a read-only informative system property.
>
> -Sherman
>
>
> On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>>>
>>> There is a similar bug:
>>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
>>
>> Yeah... I looked at the sources in that package and there is at least
>> one more place which converts a String to bytes using getBytes(). This
>> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
>> this is:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>>
>> Dawid
>>
>>> In this case on Windows.
>>>
>>> -Ulf
>>>
>>>
>>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>>
>>> Hi folks.
>>>
>>> Run the following with -Dfile.encoding=UTF-16:
>>>
>>> public class TestBlah {
>>>    public static void main(String []) throws Exception {
>>>      TimeZone.getDefault();
>>>    }
>>> }
>>>
>>> This on linux (and any unixish system I think) will result in:
>>>
>>> java.lang.ExceptionInInitializerError
>>>         at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>>>         at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>>>         at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>>> ...
>>>
>>> There is an encoding-sensitive part calling getBytes on the initial
>>> path (and this screws it up):
>>>
>>>      // package-private
>>>      UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>>          this.provider = provider;
>>>          this.defaultDirectory =
>>> UnixPath.normalizeAndCheck(dir).getBytes();
>>>          if (this.defaultDirectory[0] != '/') {
>>>              throw new RuntimeException("default directory must be
>>> absolute");
>>>          }
>>>
>>> Filed a bug for this but don't have the ID yet.
>>>
>>> Dawid
>>>
>>>
>>>
>


From youdwei at linux.vnet.ibm.com  Thu Jul  5 06:26:44 2012
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Thu, 05 Jul 2012 14:26:44 +0800
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
	<4FF16425.9070308@linux.vnet.ibm.com>
	<40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>
Message-ID: <4FF533A4.80808@linux.vnet.ibm.com>

Hi Lance,

Did you review the patch and compare it to yours. I just have some more 
words for the patch.

1. I think the current spec for free() is not clear, how about add below 
comments:

     After free has been called, any attempt to invoke a method other 
than free will result in a SerialException being thrown.

2. getBinaryStream(long pos,long length)

     add a javadoc:
     * @throws SerialException if this SerialBlob already be freed.

     add throws SerialException from this method

Any suggestions?

Thanks a lot!
On 07/02/2012 06:25 PM, Lance Andersen - Oracle wrote:
> Hi Deven,
>
> Thanks for the email and the proposed patch.  I will look at this 
> later today or tomorrow.  I actually have made these changes in my 
> workspace for JDK 8 but will compare your changes to mine.
>
> Best
> Lance
> On Jul 2, 2012, at 5:04 AM, Deven You wrote:
>
>> Hi All,
>> Could anyone notice this problem?
>>
>> Thanks a lot!
>> On 06/25/2012 04:18 PM, Deven You wrote:
>>> Hi All,
>>>
>>> First of all, if the jdbc problem has a better mailing list to post 
>>> please tell me.
>>>
>>> I find that javax.sql.rowset.serial.SerialBlob is not fully 
>>> implemented in OpenJDK 8. Methods
>>>
>>>    public InputStream getBinaryStream(long pos,long length) throws 
>>> SQLException
>>>    public void free() throws SQLException
>>>
>>> only throw UnsupportedOperationException.
>>>
>>> I have made a patch[1] to implement these 2 methods. Could anyone 
>>> take a look to review it.
>>>
>>> BTW: I think the spec for SerialBlob is not very clear like it 
>>> doesn't mention if all method rather than free() need throw any 
>>> exception after free() is invoked. However that behavior seems 
>>> reasonable.
>>>
>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev 
>>> <http://cr.openjdk.java.net/%7Elittlee/OJDK-576/webrev>
>>>
>>> Thanks a lot.
>>>
>>
>>
>> -- 
>> Best Regards,
>>
>> Deven
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>


-- 
Best Regards,

Deven



From xueming.shen at oracle.com  Thu Jul  5 07:52:59 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Jul 2012 00:52:59 -0700
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
	<CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
Message-ID: <4FF547DB.10400@oracle.com>

The code cited is a little shortcut, if there is locale over there is 
indeed using
utf-16, or any encoding that needs to switch/shift into ASCII (or its 
single byte
charset area) with a shift/in/out character.. So far I'm not aware of 
any such
a locale on any our supported platform. Historically, this kind of 
assumption
might run into trouble when being ported to other platform, such as ebcdic
based system (but I don't think it's a problem in this case). Ideally, 
the code
probably should be coded to be able to deal with a mb type of "/", but 
obviously
it was decided to take the short-cut for better performance here.

"We" have been taking the stand that file.encoding is an 
informative/read-only
system property for a long time, mainly because of two reasons. First this
property is really defined/implemented/used as the default encoding that 
the jvm
uses to communicated with the underlying platform for local/encoding 
sensitive
stuff, the default encoding of the file content, the encoding of the 
file path and
the "text" encoding when use the platform APIs, for example. It's like a 
"contract"
between the jvm and the underlying platform, it needs to be understood 
by both
and agreed on by both. So it needs to be set based on what your 
underlying system
is using,  not something you want to set via either -D or 
System.setProperty. If
your underlying locale is not UTF-16, I don't think you should expect 
the jvm
could work correctly if it keeps "talking" in UTF-16 to the underlying 
system,
for example, pass in a file name in utf-16, when your are running on a utf-8
locale (it is more complicated on a windows platform, when you have system
locale and user locale, and historically file.encoding was used for 
both, consider
if your system locale and user locale are set differently...).

The property sun.jnu.encoding introduced in jdk6 (this is mainly
to address the issue we have with file.encoding on windows platform though)
somehow helps remove some "pressure" from the file.encoding, so in theory
file.encoding should be used to only for the encoding of "file content", and
the sun.jnu.encoding should be used when you need the encoding to talk to
those  platform APIs, so something might be done here (currently 
file.encoding
and sun.jnu.encoding are set to the same thing on non-Windows platform).

The other reason is the timing of how the file.encoding is being 
initialized and
how it is being used during the "complicated" system initialization 
stage, almost
everyone touched System. initializeSystemClass() got burned here and there
in the past:-)  So sometime you want to ask if it is worth the risk to 
change
something work for a use scenario that is not "supported". That said, as
I said above,  something might be done  to address this issue, but obviously
not a priority for now.

-Sherman

if you want to do -Dfile.encoding=xyz, you
are on your own, it might work, it might not work.

On 7/4/2012 11:00 PM, Dawid Weiss wrote:
> Well, what's the "right" way to enforce an initial encoding for
> charset-less string-to-byte conversions and legacy streams? I still
> think that snippet of code is buggy, no matter if file.encoding is or
> isn't a supported settable property.
>
> Besides, from what I see in JDK code base everything seems to be code
> in a way to allow external definition of file.encoding (comments
> inside System.c for example). Where is it stated that file.encoding is
> read-only?
>
> Dawid
>
> On Thu, Jul 5, 2012 at 3:09 AM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> -Dfile.encoding=xyz is NOT a supported configuration. file.encoding is
>> supposed to be a read-only informative system property.
>>
>> -Sherman
>>
>>
>> On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>>>> There is a similar bug:
>>>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
>>> Yeah... I looked at the sources in that package and there is at least
>>> one more place which converts a String to bytes using getBytes(). This
>>> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
>>> this is:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>>>
>>> Dawid
>>>
>>>> In this case on Windows.
>>>>
>>>> -Ulf
>>>>
>>>>
>>>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>>>
>>>> Hi folks.
>>>>
>>>> Run the following with -Dfile.encoding=UTF-16:
>>>>
>>>> public class TestBlah {
>>>>     public static void main(String []) throws Exception {
>>>>       TimeZone.getDefault();
>>>>     }
>>>> }
>>>>
>>>> This on linux (and any unixish system I think) will result in:
>>>>
>>>> java.lang.ExceptionInInitializerError
>>>>          at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>>>>          at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>>>>          at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>>>> ...
>>>>
>>>> There is an encoding-sensitive part calling getBytes on the initial
>>>> path (and this screws it up):
>>>>
>>>>       // package-private
>>>>       UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>>>           this.provider = provider;
>>>>           this.defaultDirectory =
>>>> UnixPath.normalizeAndCheck(dir).getBytes();
>>>>           if (this.defaultDirectory[0] != '/') {
>>>>               throw new RuntimeException("default directory must be
>>>> absolute");
>>>>           }
>>>>
>>>> Filed a bug for this but don't have the ID yet.
>>>>
>>>> Dawid
>>>>
>>>>
>>>>


From dawid.weiss at gmail.com  Thu Jul  5 08:04:57 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 5 Jul 2012 10:04:57 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <4FF547DB.10400@oracle.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
	<CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
	<4FF547DB.10400@oracle.com>
Message-ID: <CAM21Rt_pJ5cZo+54W2DsFau58HhqCNymYykuHH1NfMtdFXhWeQ@mail.gmail.com>

Thanks for the explanation, it helps.

Maybe I should follow-up with the rationale of why we want to override
it in the first place. We randomize file.encoding to a small subset of
JVM-supported encodings to make sure there are no hidden
encoding-specific issues in Lucene/ Solr. This is actually a great way
of catching calls to String.getBytes() and such which typically work
fine but once moved to actual user environment start to break because
of different encodings.

Maybe I'm missing something but -Dfile.encoding seems to be the only
way to change the defaults used for String.getBytes(), new
String(byte[]) and such, correct? Sure, it's legacy APIs that are
broken/ problematic from the very beginning but they're there and
there should be a way to externally say "use this and that charset for
the default"...

Yes, we could do static analysis to catch these but the problem remains.

Dawid

On Thu, Jul 5, 2012 at 9:52 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> The code cited is a little shortcut, if there is locale over there is indeed
> using
> utf-16, or any encoding that needs to switch/shift into ASCII (or its single
> byte
> charset area) with a shift/in/out character.. So far I'm not aware of any
> such
> a locale on any our supported platform. Historically, this kind of
> assumption
> might run into trouble when being ported to other platform, such as ebcdic
> based system (but I don't think it's a problem in this case). Ideally, the
> code
> probably should be coded to be able to deal with a mb type of "/", but
> obviously
> it was decided to take the short-cut for better performance here.
>
> "We" have been taking the stand that file.encoding is an
> informative/read-only
> system property for a long time, mainly because of two reasons. First this
> property is really defined/implemented/used as the default encoding that the
> jvm
> uses to communicated with the underlying platform for local/encoding
> sensitive
> stuff, the default encoding of the file content, the encoding of the file
> path and
> the "text" encoding when use the platform APIs, for example. It's like a
> "contract"
> between the jvm and the underlying platform, it needs to be understood by
> both
> and agreed on by both. So it needs to be set based on what your underlying
> system
> is using,  not something you want to set via either -D or
> System.setProperty. If
> your underlying locale is not UTF-16, I don't think you should expect the
> jvm
> could work correctly if it keeps "talking" in UTF-16 to the underlying
> system,
> for example, pass in a file name in utf-16, when your are running on a utf-8
> locale (it is more complicated on a windows platform, when you have system
> locale and user locale, and historically file.encoding was used for both,
> consider
> if your system locale and user locale are set differently...).
>
> The property sun.jnu.encoding introduced in jdk6 (this is mainly
> to address the issue we have with file.encoding on windows platform though)
> somehow helps remove some "pressure" from the file.encoding, so in theory
> file.encoding should be used to only for the encoding of "file content", and
> the sun.jnu.encoding should be used when you need the encoding to talk to
> those  platform APIs, so something might be done here (currently
> file.encoding
> and sun.jnu.encoding are set to the same thing on non-Windows platform).
>
> The other reason is the timing of how the file.encoding is being initialized
> and
> how it is being used during the "complicated" system initialization stage,
> almost
> everyone touched System. initializeSystemClass() got burned here and there
> in the past:-)  So sometime you want to ask if it is worth the risk to
> change
> something work for a use scenario that is not "supported". That said, as
> I said above,  something might be done  to address this issue, but obviously
> not a priority for now.
>
> -Sherman
>
> if you want to do -Dfile.encoding=xyz, you
> are on your own, it might work, it might not work.
>
>
> On 7/4/2012 11:00 PM, Dawid Weiss wrote:
>>
>> Well, what's the "right" way to enforce an initial encoding for
>> charset-less string-to-byte conversions and legacy streams? I still
>> think that snippet of code is buggy, no matter if file.encoding is or
>> isn't a supported settable property.
>>
>> Besides, from what I see in JDK code base everything seems to be code
>> in a way to allow external definition of file.encoding (comments
>> inside System.c for example). Where is it stated that file.encoding is
>> read-only?
>>
>> Dawid
>>
>> On Thu, Jul 5, 2012 at 3:09 AM, Xueming Shen<xueming.shen at oracle.com>
>> wrote:
>>>
>>> -Dfile.encoding=xyz is NOT a supported configuration. file.encoding is
>>> supposed to be a read-only informative system property.
>>>
>>> -Sherman
>>>
>>>
>>> On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>>>>>
>>>>> There is a similar bug:
>>>>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
>>>>
>>>> Yeah... I looked at the sources in that package and there is at least
>>>> one more place which converts a String to bytes using getBytes(). This
>>>> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
>>>> this is:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>>>>
>>>> Dawid
>>>>
>>>>> In this case on Windows.
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>>>>
>>>>> Hi folks.
>>>>>
>>>>> Run the following with -Dfile.encoding=UTF-16:
>>>>>
>>>>> public class TestBlah {
>>>>>     public static void main(String []) throws Exception {
>>>>>       TimeZone.getDefault();
>>>>>     }
>>>>> }
>>>>>
>>>>> This on linux (and any unixish system I think) will result in:
>>>>>
>>>>> java.lang.ExceptionInInitializerError
>>>>>          at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>>>>>          at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>>>>>          at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>>>>> ...
>>>>>
>>>>> There is an encoding-sensitive part calling getBytes on the initial
>>>>> path (and this screws it up):
>>>>>
>>>>>       // package-private
>>>>>       UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>>>>           this.provider = provider;
>>>>>           this.defaultDirectory =
>>>>> UnixPath.normalizeAndCheck(dir).getBytes();
>>>>>           if (this.defaultDirectory[0] != '/') {
>>>>>               throw new RuntimeException("default directory must be
>>>>> absolute");
>>>>>           }
>>>>>
>>>>> Filed a bug for this but don't have the ID yet.
>>>>>
>>>>> Dawid
>>>>>
>>>>>
>>>>>
>


From yiming.wang at oracle.com  Thu Jul  5 08:18:37 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Thu, 05 Jul 2012 16:18:37 +0800
Subject: [Patch] Review request - bug 7147060
	com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java
	doesn't run in agentvm mode
Message-ID: <4FF54DDD.3070907@oracle.com>

Hi David & Stuart,

Can you please help to review the fix for the bug 7147060 
<http://monaco.us.oracle.com/detail.jsf?cr=7147060>, Thanks you!

The test reports ClassNotFoundException which is caused by below reasons:
1. Class can be found in "test.classes" instead of "test.src".
2. In agentvm mode, the MyTransform.class is loaded by the child of the 
context ClassLoader of current thread, however, The method 
Transform.register(String, String) tries to use context ClassLoader to 
load class MyTransform.class which is not found.

The proposed fix is:
1. Replace "test.src" to "test.classes".
2. Replace the current thread ClassLoader to its child.

Regards,
Eric
-------------- next part --------------
--- old/test/ProblemList.txt	2012-07-05 15:57:49.477164126 +0800
+++ new/test/ProblemList.txt	2012-07-05 15:57:45.177070426 +0800
@@ -290,9 +290,6 @@
 # 7177556
 com/sun/crypto/provider/KeyFactory/TestProviderLeak.java        generic-all
 
-# 7147060
-com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java	generic-all
-
 # Failing on Solaris i586, 3/9/2010, not a -samevm issue (jdk_security3)
 sun/security/pkcs11/Secmod/AddPrivateKey.java                   solaris-i586
 sun/security/pkcs11/ec/ReadCertificates.java                    generic-all
-------------- next part --------------
--- old/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java	2012-07-05 15:57:56.799140287 +0800
+++ new/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java	2012-07-05 15:57:54.790043435 +0800
@@ -39,7 +39,7 @@
 
 public class ClassLoaderTest {
 
-    private final static String BASE = System.getProperty("test.src", "./");
+    private final static String BASE = System.getProperty("test.classes", "./");
 
     public static void main(String[] args) throws Exception {
 
@@ -50,15 +50,26 @@
         URLClassLoader ucl = new URLClassLoader(urls);
         Class c = ucl.loadClass("MyTransform");
         Constructor cons = c.getConstructor();
-        Object o = cons.newInstance();
-        // Apache code swallows the ClassNotFoundExc, so we need to
-        // check if the Transform has already been registered by registering
-        // it again and catching an AlgorithmAlreadyRegisteredExc
+
+        Thread curThread = Thread.currentThread();
+        ClassLoader ctxLoader = curThread.getContextClassLoader();
+        ClassLoader loader = MyTransform.class.getClassLoader();
         try {
+            // In agentvm mode, the class MyTransform is loaded by the child of
+            // context ClassLoader of this thread. Replace context ClassLoader
+            // with its child to avoid ClassNotFoundException thrown from
+            // Transform.register(String, String) method.
+            curThread.setContextClassLoader(loader);
+            Object o = cons.newInstance();
+            // Apache code swallows the ClassNotFoundExc, so we need to
+            // check if the Transform has already been registered by registering
+            // it again and catching an AlgorithmAlreadyRegisteredExc
             Transform.register(MyTransform.URI, "MyTransform");
             throw new Exception("ClassLoaderTest failed");
         } catch (AlgorithmAlreadyRegisteredException e) {
             // test passed
+        } finally {
+            curThread.setContextClassLoader(ctxLoader);
         }
     }
 }

From xueming.shen at oracle.com  Thu Jul  5 08:38:27 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Jul 2012 01:38:27 -0700
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <CAM21Rt_pJ5cZo+54W2DsFau58HhqCNymYykuHH1NfMtdFXhWeQ@mail.gmail.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
	<CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
	<4FF547DB.10400@oracle.com>
	<CAM21Rt_pJ5cZo+54W2DsFau58HhqCNymYykuHH1NfMtdFXhWeQ@mail.gmail.com>
Message-ID: <4FF55283.5010705@oracle.com>

Given you are using -Dfile.encoding=xyz from command line, guess you might
not have problem to do something like (on a bash for example)

export LC_ALL=en_US.UTF-8; java Foo
export LC_ALL=ja_JP.SJIS; java Foo

you might need to install all those supported locales on you system 
though, but
isn't it something you are trying to test on? some actual users run on some
actual user environment. You only need to test the locales (with various 
supported
encodings) that really exist on your platform. In fact -Dfile.encoding 
actually
is not a good testing methodology here.

  I would assume there is no en_US.UTF-16 locale there :-)

-Sherman

On 7/5/2012 1:04 AM, Dawid Weiss wrote:
> Thanks for the explanation, it helps.
>
> Maybe I should follow-up with the rationale of why we want to override
> it in the first place. We randomize file.encoding to a small subset of
> JVM-supported encodings to make sure there are no hidden
> encoding-specific issues in Lucene/ Solr. This is actually a great way
> of catching calls to String.getBytes() and such which typically work
> fine but once moved to actual user environment start to break because
> of different encodings.
>
> Maybe I'm missing something but -Dfile.encoding seems to be the only
> way to change the defaults used for String.getBytes(), new
> String(byte[]) and such, correct? Sure, it's legacy APIs that are
> broken/ problematic from the very beginning but they're there and
> there should be a way to externally say "use this and that charset for
> the default"...
>
> Yes, we could do static analysis to catch these but the problem remains.
>
> Dawid
>
> On Thu, Jul 5, 2012 at 9:52 AM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> The code cited is a little shortcut, if there is locale over there is indeed
>> using
>> utf-16, or any encoding that needs to switch/shift into ASCII (or its single
>> byte
>> charset area) with a shift/in/out character.. So far I'm not aware of any
>> such
>> a locale on any our supported platform. Historically, this kind of
>> assumption
>> might run into trouble when being ported to other platform, such as ebcdic
>> based system (but I don't think it's a problem in this case). Ideally, the
>> code
>> probably should be coded to be able to deal with a mb type of "/", but
>> obviously
>> it was decided to take the short-cut for better performance here.
>>
>> "We" have been taking the stand that file.encoding is an
>> informative/read-only
>> system property for a long time, mainly because of two reasons. First this
>> property is really defined/implemented/used as the default encoding that the
>> jvm
>> uses to communicated with the underlying platform for local/encoding
>> sensitive
>> stuff, the default encoding of the file content, the encoding of the file
>> path and
>> the "text" encoding when use the platform APIs, for example. It's like a
>> "contract"
>> between the jvm and the underlying platform, it needs to be understood by
>> both
>> and agreed on by both. So it needs to be set based on what your underlying
>> system
>> is using,  not something you want to set via either -D or
>> System.setProperty. If
>> your underlying locale is not UTF-16, I don't think you should expect the
>> jvm
>> could work correctly if it keeps "talking" in UTF-16 to the underlying
>> system,
>> for example, pass in a file name in utf-16, when your are running on a utf-8
>> locale (it is more complicated on a windows platform, when you have system
>> locale and user locale, and historically file.encoding was used for both,
>> consider
>> if your system locale and user locale are set differently...).
>>
>> The property sun.jnu.encoding introduced in jdk6 (this is mainly
>> to address the issue we have with file.encoding on windows platform though)
>> somehow helps remove some "pressure" from the file.encoding, so in theory
>> file.encoding should be used to only for the encoding of "file content", and
>> the sun.jnu.encoding should be used when you need the encoding to talk to
>> those  platform APIs, so something might be done here (currently
>> file.encoding
>> and sun.jnu.encoding are set to the same thing on non-Windows platform).
>>
>> The other reason is the timing of how the file.encoding is being initialized
>> and
>> how it is being used during the "complicated" system initialization stage,
>> almost
>> everyone touched System. initializeSystemClass() got burned here and there
>> in the past:-)  So sometime you want to ask if it is worth the risk to
>> change
>> something work for a use scenario that is not "supported". That said, as
>> I said above,  something might be done  to address this issue, but obviously
>> not a priority for now.
>>
>> -Sherman
>>
>> if you want to do -Dfile.encoding=xyz, you
>> are on your own, it might work, it might not work.
>>
>>
>> On 7/4/2012 11:00 PM, Dawid Weiss wrote:
>>> Well, what's the "right" way to enforce an initial encoding for
>>> charset-less string-to-byte conversions and legacy streams? I still
>>> think that snippet of code is buggy, no matter if file.encoding is or
>>> isn't a supported settable property.
>>>
>>> Besides, from what I see in JDK code base everything seems to be code
>>> in a way to allow external definition of file.encoding (comments
>>> inside System.c for example). Where is it stated that file.encoding is
>>> read-only?
>>>
>>> Dawid
>>>
>>> On Thu, Jul 5, 2012 at 3:09 AM, Xueming Shen<xueming.shen at oracle.com>
>>> wrote:
>>>> -Dfile.encoding=xyz is NOT a supported configuration. file.encoding is
>>>> supposed to be a read-only informative system property.
>>>>
>>>> -Sherman
>>>>
>>>>
>>>> On 7/4/2012 1:21 PM, Dawid Weiss wrote:
>>>>>> There is a similar bug:
>>>>>> Bug 6795536 - No system start for file.encoding=x-SJIS_0213
>>>>> Yeah... I looked at the sources in that package and there is at least
>>>>> one more place which converts a String to bytes using getBytes(). This
>>>>> seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for
>>>>> this is:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721
>>>>>
>>>>> Dawid
>>>>>
>>>>>> In this case on Windows.
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>>
>>>>>> Am 04.07.2012 14:43, schrieb Dawid Weiss:
>>>>>>
>>>>>> Hi folks.
>>>>>>
>>>>>> Run the following with -Dfile.encoding=UTF-16:
>>>>>>
>>>>>> public class TestBlah {
>>>>>>      public static void main(String []) throws Exception {
>>>>>>        TimeZone.getDefault();
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>> This on linux (and any unixish system I think) will result in:
>>>>>>
>>>>>> java.lang.ExceptionInInitializerError
>>>>>>           at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
>>>>>>           at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482)
>>>>>>           at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477)
>>>>>> ...
>>>>>>
>>>>>> There is an encoding-sensitive part calling getBytes on the initial
>>>>>> path (and this screws it up):
>>>>>>
>>>>>>        // package-private
>>>>>>        UnixFileSystem(UnixFileSystemProvider provider, String dir) {
>>>>>>            this.provider = provider;
>>>>>>            this.defaultDirectory =
>>>>>> UnixPath.normalizeAndCheck(dir).getBytes();
>>>>>>            if (this.defaultDirectory[0] != '/') {
>>>>>>                throw new RuntimeException("default directory must be
>>>>>> absolute");
>>>>>>            }
>>>>>>
>>>>>> Filed a bug for this but don't have the ID yet.
>>>>>>
>>>>>> Dawid
>>>>>>
>>>>>>
>>>>>>


From dawid.weiss at gmail.com  Thu Jul  5 08:40:12 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 5 Jul 2012 10:40:12 +0200
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <4FF55283.5010705@oracle.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
	<CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
	<4FF547DB.10400@oracle.com>
	<CAM21Rt_pJ5cZo+54W2DsFau58HhqCNymYykuHH1NfMtdFXhWeQ@mail.gmail.com>
	<4FF55283.5010705@oracle.com>
Message-ID: <CAM21Rt-tX8NJNcQ=hFf9NSiZDtPMac5oS63jcPQu7cv8KepJpw@mail.gmail.com>

> export LC_ALL=en_US.UTF-8; java Foo

Not really, the shell won't let you use a multibyte locale (because of
issues with null-terminated strings). And multibyte (with BOM) is most
fun when you're trying to find buggy code ;)

>  I would assume there is no en_US.UTF-16 locale there :-)

I wish there were. It'd make people care more ;)

Dawid


From xueming.shen at oracle.com  Thu Jul  5 18:02:11 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Jul 2012 11:02:11 -0700
Subject: A bug in filesystem bootstrap (unix/ linux) prevents
In-Reply-To: <CAM21Rt-tX8NJNcQ=hFf9NSiZDtPMac5oS63jcPQu7cv8KepJpw@mail.gmail.com>
References: <CAM21Rt8LB2T9qxxcVCNLq7chbZy-ZU7Wydisa0cnYKNXRw_oKw@mail.gmail.com>
	<4FF443F1.40502@CoSoCo.de>
	<CAM21Rt-07HQuGBHGnbuYqGiHSybZQDUMDDj+As=uu0rr1VcebQ@mail.gmail.com>
	<4FF4E958.2020103@oracle.com>
	<CAM21Rt-CE_=B2WfdgB7cmJwKZ=8ji=+unX4MZp5EVLvZjcSvoQ@mail.gmail.com>
	<4FF547DB.10400@oracle.com>
	<CAM21Rt_pJ5cZo+54W2DsFau58HhqCNymYykuHH1NfMtdFXhWeQ@mail.gmail.com>
	<4FF55283.5010705@oracle.com>
	<CAM21Rt-tX8NJNcQ=hFf9NSiZDtPMac5oS63jcPQu7cv8KepJpw@mail.gmail.com>
Message-ID: <4FF5D6A3.1030101@oracle.com>

On 07/05/2012 01:40 AM, Dawid Weiss wrote:
>> export LC_ALL=en_US.UTF-8; java Foo
> Not really, the shell won't let you use a multibyte locale (because of
> issues with null-terminated strings). And multibyte (with BOM) is most
> fun when you're trying to find buggy code ;)

Encodings for those Chinese, Japnese, Korean locales are all "multibyte" 
. UTF-8
is a multibyte encoding, most recent unix/linux platform should have no 
problem
to work with "multibyte" locale. In fact UTF-16 is normally not 
categorized as
multibye (mb), but wide char, as "wc". There are reason(s) why you 
(normally)
only see utf-8 locale but no utf-16 locale on Unix/Linux based platforms 
and why
you have "W" version of APIs and "A" version of APIs (and even "T" 
version for
some APIs) on Windows platfrom.

I agree it might be helpful if there is mechanism that you can change 
the "default
charset" used by various Java APIs, similar to what you do with 
Locale.setDefault().
With the introduction of sun.jnu.encoding (which takes over the 
responsibility of
the encoding jvm used to talk to the underlying OS APIs) it might be 
possible to
reduce the scope of system property file.encoding to only for the 
default encoding
of the "file content" and do something here, but it is not on the 
priority list for now.

-Sherman

Btw, I need to make it clear here that sun.jnu.encoding is purely an 
implementation
detail, app is not supposed to use it for whatever purpose.

>>   I would assume there is no en_US.UTF-16 locale there :-)
> I wish there were. It'd make people care more ;)
>
> Dawid



From Lance.Andersen at oracle.com  Thu Jul  5 20:46:44 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 5 Jul 2012 16:46:44 -0400
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <4FF533A4.80808@linux.vnet.ibm.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
	<4FF16425.9070308@linux.vnet.ibm.com>
	<40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>
	<4FF533A4.80808@linux.vnet.ibm.com>
Message-ID: <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com>

Hi Deven,

We had a holiday here on Weds,  so I am still catching up.

First, thank you for taking the time to propose a patch.

 Here are a few comments based on the changes I have made in my workspace and  comparing to your proposed changes 

- The same issue applies to SerialClob
- instead of duplicating all of the code to check if free has been called in each method, I created a private method which does the validation
- I do not see a reason to make the flag isFree transient, if the object has been freed, it has been freed
- free() needs to call blob.free if the blob object is not null prior to nulling out the object
- Your 2nd if statement in getBinaryStream() duplicates part of the check in the 1st if statement
- All of the public methods need to have their javadocs indicate that if called after free has been called, a SerialException will be thrown.  additional calls to free is a no-op
- The test case is is a good start.    I would change this a bit though:
  + create separate test classes for free and getbinarystream
  + each individual test  be a method
  + If you catch the expected Exception, print that the test has passed
  + Each test needs a comment as to what it is trying to validate (just a simple comment is fine)
  + return 0 if the test passed, 1 if it fails  and then print the number of failed tests at the end after running through all of them


As I need to change the javadocs, I have create  a ccc request which I will do as part of the JDBC 4.2 work and will put the change back at that time.

If you would like to change your test and then create similar tests for SerialClob I will add those as part of the put-back.

Again, thank you for your input and time.

Best
Lance




On Jul 5, 2012, at 2:26 AM, Deven You wrote:

> Hi Lance,
> 
> Did you review the patch and compare it to yours. I just have some more words for the patch.
> 
> 1. I think the current spec for free() is not clear, how about add below comments:
> 
>     After free has been called, any attempt to invoke a method other than free will result in a  SerialException being thrown.
> 
> 2. getBinaryStream(long pos,long length)
> 
>     add a javadoc:
>     * @throws SerialException if this SerialBlob already be freed.
> 
>     add throws SerialException from this method
> 
> Any suggestions?
> 
> Thanks a lot!
> On 07/02/2012 06:25 PM, Lance Andersen - Oracle wrote:
>> Hi Deven,
>> 
>> Thanks for the email and the proposed patch.  I will look at this later today or tomorrow.  I actually have made these changes in my workspace for JDK 8 but will compare your changes to mine.
>> 
>> Best
>> Lance
>> On Jul 2, 2012, at 5:04 AM, Deven You wrote:
>> 
>>> Hi All,
>>> Could anyone notice this problem?
>>> 
>>> Thanks a lot!
>>> On 06/25/2012 04:18 PM, Deven You wrote:
>>>> Hi All,
>>>> 
>>>> First of all, if the jdbc problem has a better mailing list to post please tell me.
>>>> 
>>>> I find that javax.sql.rowset.serial.SerialBlob is not fully implemented in OpenJDK 8. Methods
>>>> 
>>>>    public InputStream getBinaryStream(long pos,long length) throws SQLException
>>>>    public void free() throws SQLException
>>>> 
>>>> only throw UnsupportedOperationException.
>>>> 
>>>> I have made a patch[1] to implement these 2 methods. Could anyone take a look to review it.
>>>> 
>>>> BTW: I think the spec for SerialBlob is not very clear like it doesn't mention if all method rather than free() need throw any exception after free() is invoked. However that behavior seems reasonable.
>>>> 
>>>> [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev
>>>> 
>>>> Thanks a lot.
>>>> 
>>> 
>>> 
>>> -- 
>>> Best Regards,
>>> 
>>> Deven
>>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
> 
> 
> -- 
> Best Regards,
> 
> Deven


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From darryl.mocek at oracle.com  Thu Jul  5 21:22:29 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Thu, 05 Jul 2012 14:22:29 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
Message-ID: <4FF60595.3020607@oracle.com>

Hello core-libs.  Please review this webrev to fix Bugs #7142596 and 
7161503.  Webrev can be found here: 
http://cr.openjdk.java.net/~dmocek/7142596/webrev.02. This commit fixes 
concurrency issues with the RMI tests.

- Added TestLibrary.createRegistryOnUnusedPort method.  This creates an 
RMIRegistry on an unused port. It will try up to 10 times before giving up.
- Added a TestLibrary.getRegistryPort(Registry) method to get the port 
number of the registry.
- Changed almost all tests from using hard port numbers to using random 
port numbers for running the RMI Registry and RMID.
- Removed othervm from those tests which don't need it.
- Added parameters for tests which spawn a separate VM to pass RMI 
Registry and RMID ports in cases where needed.
- Added PropertyPermission to security policy files where needed.
- Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
- Added java/rmi/Naming to list of tests which cannot be run concurrently.

Thanks,
Darryl



From stuart.marks at oracle.com  Thu Jul  5 22:10:37 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 05 Jul 2012 22:10:37 +0000
Subject: hg: jdk8/tl/jdk: 6948101:
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
Message-ID: <20120705221056.E6DAA47D18@hg.openjdk.java.net>

Changeset: 97eb7a4b1fdd
Author:    smarks
Date:      2012-07-05 15:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd

6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently
Reviewed-by: dholmes, smarks
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/ProblemList.txt
! test/java/rmi/transport/pinLastArguments/PinLastArguments.java



From stuart.marks at oracle.com  Thu Jul  5 22:15:01 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 05 Jul 2012 22:15:01 +0000
Subject: hg: jdk8/tl/jdk: 7123972:
	test/java/lang/annotation/loaderLeak/Main.java fails intermittently
Message-ID: <20120705221511.D9FF647D1B@hg.openjdk.java.net>

Changeset: 4ad204cc7433
Author:    smarks
Date:      2012-07-05 15:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433

7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently
Reviewed-by: dholmes, smarks
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/ProblemList.txt
! test/java/lang/annotation/loaderLeak/Main.java



From stuart.marks at oracle.com  Thu Jul  5 22:19:22 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 05 Jul 2012 15:19:22 -0700
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF3A249.60109@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com> <4FF35E48.909@oracle.com>
	<4FF38603.3010804@oracle.com> <4FF39534.2080500@oracle.com>
	<4FF3A249.60109@oracle.com>
Message-ID: <4FF612EA.6090200@oracle.com>

Pushed:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd

s'marks

On 7/3/12 6:54 PM, Eric Wang wrote:
> Opps, It is my carelessness, I will be more careful in the next bug fixes.
> Thank you to review and change it.
>
> Regards,
> Eric
>
> On 2012/7/4 8:58, Stuart Marks wrote:
>> Sure, I can take care of that.
>>
>> If this is the only change, no need to generate another webrev, Eric.
>>
>> s'marks
>>
>>
>> On 7/3/12 4:53 PM, David Holmes wrote:
>>> Please fix the missing space in
>>>
>>> if(ref.get()
>>>
>>> before pushing.
>>>
>>> Thanks,
>>> David
>>>
>>> On 4/07/2012 7:04 AM, Stuart Marks wrote:
>>>> Webrev now posted at
>>>>
>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/
>>>>
>>>> The changes look good to me. If there's no further discussion, I'll push
>>>> them in a couple days (U.S. holiday coming up).
>>>>
>>>> s'marks
>>>>
>>>> On 7/3/12 12:20 AM, Stuart Marks wrote:
>>>>> This approach looks good to me. Please go ahead and update 7123972 as
>>>>> well, and
>>>>> I'll post these webrevs tomorrow (my time).
>>>>>
>>>>> Thanks.
>>>>>
>>>>> s'marks
>>>>>
>>>>> On 7/2/12 11:41 PM, Eric Wang wrote:
>>>>>> David,
>>>>>>
>>>>>> I have added the comments before the loop, please help to review. If
>>>>>> it is OK,
>>>>>> I'll update the 7123972 as well.
>>>>>>
>>>>>> Thanks,
>>>>>> Eric
>>>>>>
>>>>>> On 2012/7/3 12:22, David Holmes wrote:
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>>>>>> Hi Stuart and David,
>>>>>>>>
>>>>>>>> Thanks for the suggestion about the timeout. so there are three
>>>>>>>> ways to
>>>>>>>> handle the timeout.
>>>>>>>>
>>>>>>>> 1. Add comment to explain that test failed due to default timeout
>>>>>>>> 2. Specify the the timeout option
>>>>>>>> 3. Timeout programly
>>>>>>>>
>>>>>>>> Is it ok for you that i'd like to choose the second way "explict
>>>>>>>> timeout" as the test looks simply and lucid?
>>>>>>>
>>>>>>> If by #2 you mean add something like:
>>>>>>>
>>>>>>> @run main/timeout=10
>>>>>>>
>>>>>>> then no. Earlier this year there were changes to a bunch of tests
>>>>>>> that set
>>>>>>> timeouts shorter than the jtreg default, to delete the timeouts.
>>>>>>> Given that,
>>>>>>> my misgivings about relying on the harness are not relevant so we
>>>>>>> need only
>>>>>>> do #1 and add a comment to make it clear that a failing test will be
>>>>>>> indicated via the harness timeout.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eric
>>>>>>>>
>>>>>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>>>>>> Now, how can the test fail? If ref is never cleared, the while
>>>>>>>>>>>> loop
>>>>>>>>>>>> will
>>>>>>>>>>>> never terminate, and we rely on jtreg to timeout and kill this
>>>>>>>>>>>> test. It
>>>>>>>>>>>> would be good to have a brief comment above the while loop that
>>>>>>>>>>>> explains
>>>>>>>>>>>> this.
>>>>>>>>>>>
>>>>>>>>>>> Agreed. Something like
>>>>>>>>>>>
>>>>>>>>>>> // Might require multiple calls to System.gc() for weak-references
>>>>>>>>>>> processing
>>>>>>>>>>> to be complete.
>>>>>>>>>>> // If the weak-reference is not cleared as expected we will hang
>>>>>>>>>>> here
>>>>>>>>>>> // until timed out by the test harness
>>>>>>>>>>>
>>>>>>>>>>> Though now I write that I'm unhappy that this will only behave
>>>>>>>>>>> nicely
>>>>>>>>>>> if run
>>>>>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>>>>>
>>>>>>>>>> So, are you unhappy enough that we should ask Eric to add an
>>>>>>>>>> explicit
>>>>>>>>>> timeout?
>>>>>>>>>
>>>>>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>>>>>
>>>>>>>>>> I don't think it would be that difficult. Perhaps a technique
>>>>>>>>>> like the
>>>>>>>>>> following would suffice. Get System.currentTimeMillis() before
>>>>>>>>>> the loop,
>>>>>>>>>> and call it again each time through the loop, and fail if the
>>>>>>>>>> difference
>>>>>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve other
>>>>>>>>>> threads or even Timer/TimerTask.
>>>>>>>>>
>>>>>>>>> Or simply limit the number of loops so that N*sleepTime = timeout.
>>>>>>>>> This then requires adding back the check for null outside the loop.
>>>>>>>>>
>>>>>>>>>> On the other hand if one is running this test directly instead of
>>>>>>>>>> through jtreg, one can just ^C it if it's taking an unexpectedly
>>>>>>>>>> long
>>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>> True.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> s'marks
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>
>


From stuart.marks at oracle.com  Thu Jul  5 22:19:54 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 05 Jul 2012 15:19:54 -0700
Subject: Patch review request - Test bug 7123972
	test/java/lang/annotation/loaderLeak/Main.java fails intermittently
In-Reply-To: <4FF35E79.2070500@oracle.com>
References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com>
	<4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com>
	<4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com>
	<4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com>
	<4FEBE02D.6010406@oracle.com> <4FED6908.7080405@oracle.com>
	<4FEE25C0.2040900@oracle.com> <4FF2CB7D.201@oracle.com>
	<4FF35E79.2070500@oracle.com>
Message-ID: <4FF6130A.2020003@oracle.com>

Pushed:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433

s'marks

On 7/3/12 2:04 PM, Stuart Marks wrote:
> Webrev posted here:
>
> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.2/
>
> The changes look good. If there's no further discussion, I'll push them in a
> couple days.
>
> s'marks
>
> On 7/3/12 3:37 AM, Eric Wang wrote:
>> Hi Stuart,
>>
>> I have made updates which is same as 6948101, please help to review, Thanks a
>> lot!
>>
>> Regards,
>> Eric
>> On 2012/6/30 6:01, Stuart Marks wrote:
>>> I've posted the updated webrev here:
>>>
>>> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.1/
>>>
>>> This code is pretty much the same as 6948101 and the same comments I had on
>>> that bug apply here as well, so please make similar updates to this one.
>>>
>>> Thanks.
>>>
>>> s'marks
>>>
>>> On 6/29/12 1:36 AM, Eric Wang wrote:
>>>> Hi Stuart & David?
>>>>
>>>> Attachment is the new changes to make code simply by following David
>>>> suggestion, Can you help please review again, Thanks a lot!
>>>>
>>>> Regards,
>>>> Eric
>>>> On 2012/6/28 12:40, Stuart Marks wrote:
>>>>> I've posted the webrev here:
>>>>>
>>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/
>>>>>
>>>>> I've looked at the changes and they seem fine.
>>>>>
>>>>> It's interesting that the run times take 30-60 sec in your experience. I've
>>>>> run them on my system (Linux in a virtual machine) and they usually run in
>>>>> 10-20 sec. In any case, as you say, if the test times out it indicates there
>>>>> really was a failure.
>>>>>
>>>>> I'll give people a chance to look at the webrev and if there aren't any more
>>>>> comments in another day or so I'll push in the changeset.
>>>>>
>>>>> Thanks for developing this!
>>>>>
>>>>> s'marks
>>>>>
>>>>> On 6/26/12 11:50 PM, Eric Wang wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Thank you! I run the test several times on 3 platforms (windows, solaris and
>>>>>> linux), the average execution time is 30secs to 60secs. if the test hang 2
>>>>>> minutes, there should be something wrong.
>>>>>>
>>>>>> Hi Marks,
>>>>>>
>>>>>> I don't have the author role, Can you please help to review and post the
>>>>>> webrev
>>>>>> 7123972.zip in attachment if it is OK, Thanks a lot!
>>>>>>
>>>>>> Regards,
>>>>>> Eric
>>>>>>
>>>>>> On 2012/6/27 14:19, David Holmes wrote:
>>>>>>> Eric,
>>>>>>>
>>>>>>> Ignore my comment about adding the timeouts. As Alan reminded me if the
>>>>>>> test
>>>>>>> would hang then jtreg will time it out after two minutes anyway.
>>>>>>>
>>>>>>> So this is good to go as far as I am concerned.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 27/06/2012 7:51 AM, David Holmes wrote:
>>>>>>>> Thanks Eric.
>>>>>>>>
>>>>>>>> So to summarize:
>>>>>>>>
>>>>>>>> - we create a custom classloader, load a class through it and store a
>>>>>>>> reference to that Class in a WeakReference
>>>>>>>> - we then drop the reference to the loader
>>>>>>>>
>>>>>>>> At this point the only reference to the loader is from the Class loaded,
>>>>>>>> which in turn is only weakly reachable.
>>>>>>>>
>>>>>>>> I must confess that I'm unclear why this test should be failing in its
>>>>>>>> original form. The first gc() should remove the strong reference to the
>>>>>>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class.
>>>>>>>> The second gc() should detect the cycle and clear the WeakRef. I guess
>>>>>>>> the problem is that depending on which gc is in use the actual gc()
>>>>>>>> calls may not in fact induce every possible GC action.
>>>>>>>>
>>>>>>>> The fix seems reasonable in that regard - keep gc'ing and finalizing
>>>>>>>> till we see the loader is gone, and so the WeakReference should be
>>>>>>>> cleared. The original bug would cause a ref to the Class to remain (from
>>>>>>>> the annotation) and hence the WeakRef would not be cleared. However, in
>>>>>>>> that case the loader would also be strongly referenced and so never
>>>>>>>> become finalizable. So if this test was now run against a JDK with the
>>>>>>>> original bug, the test would hang. So I think we need to add a timeout
>>>>>>>> in there as well.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 25/06/2012 6:06 PM, Eric Wang wrote:
>>>>>>>>> On 2012/6/21 20:16, David Holmes wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>>
>>>>>>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your review, I have updated the code by following your
>>>>>>>>>>> suggestion. please see the attachment.
>>>>>>>>>>> I'm not sure whether there's a better way to guarantee object finalized
>>>>>>>>>>> by GC definitely within the given time. The proposed fix may work in
>>>>>>>>>>> most cases but may still throw InterruptException if execution is
>>>>>>>>>>> timeout (2 minutes of JTreg by default).
>>>>>>>>>>
>>>>>>>>>> There is no way to guarantee finalization in a specific timeframe, but
>>>>>>>>>> if a simple test hasn't executed finalizers in 2 minutes then that in
>>>>>>>>>> itself indicates a problem.
>>>>>>>>>>
>>>>>>>>>> Can you post a full webrev for this patch? I don't like seeing it out
>>>>>>>>>> of context and am wondering exactly what we are trying to GC here.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>>>>> On 2012/6/21 14:32, David Holmes wrote:
>>>>>>>>>>>> Hi Eric,
>>>>>>>>>>>>
>>>>>>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote:
>>>>>>>>>>>>> I come from Java SQE team who are interested in regression test bug
>>>>>>>>>>>>> fix.
>>>>>>>>>>>>> Here is the first simple fix for bug 7123972
>>>>>>>>>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=7123972>, Can you please
>>>>>>>>>>>>> help
>>>>>>>>>>>>> to review and comment? Attachment is the patch Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> This bug is caused by wrong assumption that the GC is started
>>>>>>>>>>>>> immediately to recycle un-referenced objects after System.gc() called
>>>>>>>>>>>>> one or two times.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proposed solution is to make sure the un-referenced object is
>>>>>>>>>>>>> recycled by GC before checking if the reference is null.
>>>>>>>>>>>>
>>>>>>>>>>>> Your patch makes its own assumptions - specifically that finalization
>>>>>>>>>>>> must eventually run. At a minimum you should add
>>>>>>>>>>>> System.runFinalization() calls after the System.gc() inside the loop.
>>>>>>>>>>>> Even that is no guarantee in a general sense, though it should work
>>>>>>>>>>>> for hotspot.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>>> Hi Alan & David,
>>>>>>>>>
>>>>>>>>> Thank you for your comments, sorry for reply this mail late as i was
>>>>>>>>> just back from the dragon boat holiday.
>>>>>>>>> I have updated the code again based on your suggestions: rename the flag
>>>>>>>>> variable, increase the sleep time and remove it from problem list.
>>>>>>>>> The attachment is the full webrev for this patch, Can you please review
>>>>>>>>> again? Thanks a lot!
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eric
>>>>>>
>>>>
>>
>>


From stuart.marks at oracle.com  Thu Jul  5 23:51:50 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 05 Jul 2012 16:51:50 -0700
Subject: [Patch] Review request - bug 7147060
	com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java
	doesn't run in agentvm mode
In-Reply-To: <4FF54DDD.3070907@oracle.com>
References: <4FF54DDD.3070907@oracle.com>
Message-ID: <4FF62896.30805@oracle.com>

(Note to core-libs-dev: further review and discussion of this bugfix is 
occurring on security-dev.)

On 7/5/12 1:18 AM, Eric Wang wrote:
> Hi David & Stuart,
>
> Can you please help to review the fix for the bug 7147060
> <http://monaco.us.oracle.com/detail.jsf?cr=7147060>, Thanks you!
>
> The test reports ClassNotFoundException which is caused by below reasons:
> 1. Class can be found in "test.classes" instead of "test.src".
> 2. In agentvm mode, the MyTransform.class is loaded by the child of the context
> ClassLoader of current thread, however, The method Transform.register(String,
> String) tries to use context ClassLoader to load class MyTransform.class which
> is not found.
>
> The proposed fix is:
> 1. Replace "test.src" to "test.classes".
> 2. Replace the current thread ClassLoader to its child.
>
> Regards,
> Eric


From luchsh at linux.vnet.ibm.com  Fri Jul  6 02:38:27 2012
From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com)
Date: Fri, 06 Jul 2012 02:38:27 +0000
Subject: hg: jdk8/tl/jdk: 7181353: Update error message to distinguish native
	OOM and java OOM in net
Message-ID: <20120706023846.83B1847D34@hg.openjdk.java.net>

Changeset: 15a6b0bceb1e
Author:    zhouyx
Date:      2012-07-06 10:36 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15a6b0bceb1e

7181353: Update error message to distinguish native OOM and java OOM in net
Reviewed-by: chegar

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c



From yiming.wang at oracle.com  Fri Jul  6 06:28:28 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Fri, 06 Jul 2012 14:28:28 +0800
Subject: [PATCH] Review Request - Test bug: 6948101
	java/rmi/transport/pinLastArguments/PinLastArguments.java
	failing intermittently
In-Reply-To: <4FF612EA.6090200@oracle.com>
References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com>
	<4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com>
	<4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com>
	<4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com>
	<4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com>
	<4FED67C6.1070504@oracle.com> <4FEE2570.9090602@oracle.com>
	<4FF0EDA9.9090101@oracle.com> <4FF20DDE.5030900@oracle.com>
	<4FF25B08.9070009@oracle.com> <4FF266DA.2070305@oracle.com>
	<4FF27386.3010707@oracle.com> <4FF293FF.1050307@oracle.com>
	<4FF29D3B.60005@oracle.com> <4FF35E48.909@oracle.com>
	<4FF38603.3010804@oracle.com> <4FF39534.2080500@oracle.com>
	<4FF3A249.60109@oracle.com> <4FF612EA.6090200@oracle.com>
Message-ID: <4FF6858C.60502@oracle.com>

Hi Marks,

Thanks for your great help to review and push my first fix.:-)

Regards,
Eric
On 2012/7/6 6:19, Stuart Marks wrote:
> Pushed:
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd
>
> s'marks
>
> On 7/3/12 6:54 PM, Eric Wang wrote:
>> Opps, It is my carelessness, I will be more careful in the next bug 
>> fixes.
>> Thank you to review and change it.
>>
>> Regards,
>> Eric
>>
>> On 2012/7/4 8:58, Stuart Marks wrote:
>>> Sure, I can take care of that.
>>>
>>> If this is the only change, no need to generate another webrev, Eric.
>>>
>>> s'marks
>>>
>>>
>>> On 7/3/12 4:53 PM, David Holmes wrote:
>>>> Please fix the missing space in
>>>>
>>>> if(ref.get()
>>>>
>>>> before pushing.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 4/07/2012 7:04 AM, Stuart Marks wrote:
>>>>> Webrev now posted at
>>>>>
>>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.2/
>>>>>
>>>>> The changes look good to me. If there's no further discussion, 
>>>>> I'll push
>>>>> them in a couple days (U.S. holiday coming up).
>>>>>
>>>>> s'marks
>>>>>
>>>>> On 7/3/12 12:20 AM, Stuart Marks wrote:
>>>>>> This approach looks good to me. Please go ahead and update 
>>>>>> 7123972 as
>>>>>> well, and
>>>>>> I'll post these webrevs tomorrow (my time).
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>> On 7/2/12 11:41 PM, Eric Wang wrote:
>>>>>>> David,
>>>>>>>
>>>>>>> I have added the comments before the loop, please help to 
>>>>>>> review. If
>>>>>>> it is OK,
>>>>>>> I'll update the 7123972 as well.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Eric
>>>>>>>
>>>>>>> On 2012/7/3 12:22, David Holmes wrote:
>>>>>>>> Hi Eric,
>>>>>>>>
>>>>>>>> On 3/07/2012 1:28 PM, Eric Wang wrote:
>>>>>>>>> Hi Stuart and David,
>>>>>>>>>
>>>>>>>>> Thanks for the suggestion about the timeout. so there are three
>>>>>>>>> ways to
>>>>>>>>> handle the timeout.
>>>>>>>>>
>>>>>>>>> 1. Add comment to explain that test failed due to default timeout
>>>>>>>>> 2. Specify the the timeout option
>>>>>>>>> 3. Timeout programly
>>>>>>>>>
>>>>>>>>> Is it ok for you that i'd like to choose the second way "explict
>>>>>>>>> timeout" as the test looks simply and lucid?
>>>>>>>>
>>>>>>>> If by #2 you mean add something like:
>>>>>>>>
>>>>>>>> @run main/timeout=10
>>>>>>>>
>>>>>>>> then no. Earlier this year there were changes to a bunch of tests
>>>>>>>> that set
>>>>>>>> timeouts shorter than the jtreg default, to delete the timeouts.
>>>>>>>> Given that,
>>>>>>>> my misgivings about relying on the harness are not relevant so we
>>>>>>>> need only
>>>>>>>> do #1 and add a comment to make it clear that a failing test 
>>>>>>>> will be
>>>>>>>> indicated via the harness timeout.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>> On 2012/7/3 10:38, David Holmes wrote:
>>>>>>>>>> On 3/07/2012 7:08 AM, Stuart Marks wrote:
>>>>>>>>>>> On 7/1/12 5:39 PM, David Holmes wrote:
>>>>>>>>>>>>> Now, how can the test fail? If ref is never cleared, the 
>>>>>>>>>>>>> while
>>>>>>>>>>>>> loop
>>>>>>>>>>>>> will
>>>>>>>>>>>>> never terminate, and we rely on jtreg to timeout and kill 
>>>>>>>>>>>>> this
>>>>>>>>>>>>> test. It
>>>>>>>>>>>>> would be good to have a brief comment above the while loop 
>>>>>>>>>>>>> that
>>>>>>>>>>>>> explains
>>>>>>>>>>>>> this.
>>>>>>>>>>>>
>>>>>>>>>>>> Agreed. Something like
>>>>>>>>>>>>
>>>>>>>>>>>> // Might require multiple calls to System.gc() for 
>>>>>>>>>>>> weak-references
>>>>>>>>>>>> processing
>>>>>>>>>>>> to be complete.
>>>>>>>>>>>> // If the weak-reference is not cleared as expected we will 
>>>>>>>>>>>> hang
>>>>>>>>>>>> here
>>>>>>>>>>>> // until timed out by the test harness
>>>>>>>>>>>>
>>>>>>>>>>>> Though now I write that I'm unhappy that this will only behave
>>>>>>>>>>>> nicely
>>>>>>>>>>>> if run
>>>>>>>>>>>> from jtreg. We do use explicit timeouts in other tests.
>>>>>>>>>>>
>>>>>>>>>>> So, are you unhappy enough that we should ask Eric to add an
>>>>>>>>>>> explicit
>>>>>>>>>>> timeout?
>>>>>>>>>>
>>>>>>>>>> No. But I'm not the authoritive voice in this area :)
>>>>>>>>>>
>>>>>>>>>>> I don't think it would be that difficult. Perhaps a technique
>>>>>>>>>>> like the
>>>>>>>>>>> following would suffice. Get System.currentTimeMillis() before
>>>>>>>>>>> the loop,
>>>>>>>>>>> and call it again each time through the loop, and fail if the
>>>>>>>>>>> difference
>>>>>>>>>>> is greater than the timeout (e.g., 60 sec). Doesn't involve 
>>>>>>>>>>> other
>>>>>>>>>>> threads or even Timer/TimerTask.
>>>>>>>>>>
>>>>>>>>>> Or simply limit the number of loops so that N*sleepTime = 
>>>>>>>>>> timeout.
>>>>>>>>>> This then requires adding back the check for null outside the 
>>>>>>>>>> loop.
>>>>>>>>>>
>>>>>>>>>>> On the other hand if one is running this test directly 
>>>>>>>>>>> instead of
>>>>>>>>>>> through jtreg, one can just ^C it if it's taking an 
>>>>>>>>>>> unexpectedly
>>>>>>>>>>> long
>>>>>>>>>>> time.
>>>>>>>>>>
>>>>>>>>>> True.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> s'marks
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>
>>




From weijun.wang at oracle.com  Fri Jul  6 10:37:31 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 06 Jul 2012 18:37:31 +0800
Subject: Fwd: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FF6BD8A.4080500@oracle.com>
References: <4FF6BD8A.4080500@oracle.com>
Message-ID: <4FF6BFEB.3020007@oracle.com>

Oh, did I BCC to core-libs-dev? "Message has implicit destination" 
received. Send again.


-------- Original Message --------
Subject: Time format in jar and jarsigner output (was Re: Code review 
request: 7163483 JarSigner -verify -verbose does not format date string 
according to locale)
Date: Fri, 06 Jul 2012 18:27:22 +0800
From: Weijun Wang <weijun.wang at oracle.com>
To: Jonathan Lu <luchsh at linux.vnet.ibm.com>
CC: security-dev at openjdk.java.net

Hi Jonathan

I have these questions:

1. Why always CAPITAL letters for month and weekday?

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.

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

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
>>>
>>
>
>





From rob.mckenna at oracle.com  Fri Jul  6 13:09:40 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 06 Jul 2012 14:09:40 +0100
Subject: Request for review: 7179305: (fs) Method name
	sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled
Message-ID: <4FF6E394.4000606@oracle.com>

http://cr.openjdk.java.net/~robm/7179305/webrev.01/ 
<http://cr.openjdk.java.net/%7Erobm/7179305/webrev.01/>

Thanks,

     -Rob


From stuart.marks at oracle.com  Fri Jul  6 18:47:54 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 06 Jul 2012 11:47:54 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FF60595.3020607@oracle.com>
References: <4FF60595.3020607@oracle.com>
Message-ID: <4FF732DA.9060704@oracle.com>

Hi,

I've reviewed the first half of the files, thru 
test/java/rmi/registry/reexport/Reexport.java. Basically things look good and 
make sense, but there are some details to be ironed out and some cleanups to be 
done. Nothing major, I think, with the exception of SetChildEnv. See discussion 
below.

Second half to follow later.

s'marks


-------

*** ProblemList.txt


The comment for UnbindIdempotent says "Need to be marked othervm, or changed to 
be samevm safe" but the test isn't marked /othervm. Does the test need to be 
updated, or is this comment misleading, and the problem really is the port 
conflict?


*** ContextWithNullProperties.java


(Nitpick: import lines are out of order)

The comment says, "Create registry if one is not already running." This is 
mostly left over from the earlier version which also mentioned port 1099. But, 
aren't we changing things so that this tests always creates its own registry on 
a unique port? If so, I'd just remove the comment and remove the catch/ignore 
of RemoteException (which was suspect in the first place). If for some reason 
we can't create our own registry, we should just throw the exception out to the 
caller and let the test error out. If we ignored RemoteException we'd leave 
registryPort as -1 which would presumably cause some obscure failure later on.

We probably also don't need to declare/initialize registryPort separately 
anymore, so we can just replace the first 8 lines or so of main() with the 
following:

     Registry registry = TestLibrary.createRegistryOnUnusedPort();
     int registryPort = TestLibrary.getRegistryPort(registry);

This same pattern occurs in these other tests and so a similar fix should be 
applied to them as well:

  - UnbindIdempotent
  - LookupNameWithColon.java


*** LookupNameWithColon.java


This test is missing an @run tag, thus it won't actually get run! Since you've 
specified an @build tag, you have to specify a separate @run tag to run the 
test. It's possible to deduce this with a careful reading of the jtreg tag spec:

http://openjdk.java.net/jtreg/tag-spec.txt

(IMHO this is a terrible usability problem.) I've looked at the other tests in 
this webrev for similar issues, and I didn't see any, but I might have missed them.

Regarding the registry, this test is somewhat different from the others in that 
it was originally coded to use an existing registry if it couldn't create its 
own. If it were to find a registry running on 1099, it was probably created by 
some other test, and no assumptions can reliably be made about it. So, I'd just 
take out this logic and have the test unconditionally create its own registry.


*** StubClassesPermitted.java


(Nitpick.) It looks like REGISTRY_PORT is a constant, but it's a static field. 
It should be renamed to have a conventional field name (i.e., mixed case).


*** UnregisterGroup.java


Similar to above, rename PORT.


*** SetChildEnv.java


The testing of the message string from the IOException causes me great concern. 
This message is defined all the way over in java.io.PipedInputStream, and while 
it's not localized, it does seem like a pretty fragile dependency. I mean, 
changing some exception message in java.io might cause an RMI Activation test 
to fail??!? (Sorry.)

Certainly we want to ignore spurious errors, and it sounds from the comment 
like normal termination of rmid causes these exceptions to be thrown. But I'm 
wondering if rmid crashes, won't we get the same exception and ignore it, 
improperly?

I don't know what the right thing to do is here. It seems like there ought to 
be a more definitive way to distinguish between normal termination and pipe 
closure from an error.


*** AltSecurityManager.java


The registry and rmid fields probably should be final. Maybe all caps too, 
except that RMID is the name of a class....

In run() it should probably bomb if utilityToStart equals neither registry nor 
rmid.

The ensureExit() method has a local variable port, which hides the field named 
port (well, not really, since ensureExit is static and port is an instance 
field) but still, this is kind of confusing.

If the port field is required to be initialized properly, make it a blank final 
(i.e., declare it final but without an initializer) and error-check it at the 
point where it's assigned in the constructor.


*** MultipleRegistries.java


Not really a big deal, but the way the second registry is created seems 
somewhat roundabout. It's not clear to me why the code can't just do this:

     Registry registryImpl1 = TestLibrary.createRegistryOnUnusedPort();
     Registry registryImpl2 = TestLibrary.createRegistryOnUnusedPort();
     int port1 = TestLibrary.getRegistryPort(registryImpl1);
     int port2 = TestLibrary.getRegistryPort(registryImpl2);


-------



On 7/5/12 2:22 PM, Darryl Mocek wrote:
> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 7161503.
> Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
> This commit fixes concurrency issues with the RMI tests.
>
> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
> RMIRegistry on an unused port. It will try up to 10 times before giving up.
> - Added a TestLibrary.getRegistryPort(Registry) method to get the port number
> of the registry.
> - Changed almost all tests from using hard port numbers to using random port
> numbers for running the RMI Registry and RMID.
> - Removed othervm from those tests which don't need it.
> - Added parameters for tests which spawn a separate VM to pass RMI Registry and
> RMID ports in cases where needed.
> - Added PropertyPermission to security policy files where needed.
> - Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>
> Thanks,
> Darryl
>


From chris.hegarty at oracle.com  Sat Jul  7 07:13:19 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 7 Jul 2012 08:13:19 +0100
Subject: Request for review: 7179305: (fs) Method name
	sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled
In-Reply-To: <4FF6E394.4000606@oracle.com>
References: <4FF6E394.4000606@oracle.com>
Message-ID: <FA7E13CF-FEAE-4D30-8C85-4D853B963691@oracle.com>

On 6 Jul 2012, at 14:09, Rob McKenna <rob.mckenna at oracle.com> wrote:

> http://cr.openjdk.java.net/~robm/7179305/webrev.01/ <http://cr.openjdk.java.net/%7Erobm/7179305/webrev.01/>

Looks fine Rob.

-Chris.

> 
> Thanks,
> 
>    -Rob


From david.holmes at oracle.com  Sat Jul  7 07:50:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 07 Jul 2012 17:50:48 +1000
Subject: Request for review: 7179305: (fs) Method name
	sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled
In-Reply-To: <4FF6E394.4000606@oracle.com>
References: <4FF6E394.4000606@oracle.com>
Message-ID: <4FF7EA58.90303@oracle.com>

Looks good.

David

On 6/07/2012 11:09 PM, Rob McKenna wrote:
> http://cr.openjdk.java.net/~robm/7179305/webrev.01/
> <http://cr.openjdk.java.net/%7Erobm/7179305/webrev.01/>
>
> Thanks,
>
> -Rob


From darryl.mocek at oracle.com  Mon Jul  9 18:14:10 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 09 Jul 2012 11:14:10 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FF732DA.9060704@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
Message-ID: <4FFB1F72.2010300@oracle.com>

Stuart,

    see inline...

On Fri 06 Jul 2012 11:47:54 AM PDT, Stuart Marks wrote:
>
> Hi,
>
> I've reviewed the first half of the files, thru
> test/java/rmi/registry/reexport/Reexport.java. Basically things look
> good and make sense, but there are some details to be ironed out and
> some cleanups to be done. Nothing major, I think, with the exception
> of SetChildEnv. See discussion below.
>
> Second half to follow later.
>
> s'marks
>
>
> -------
>
> *** ProblemList.txt
>
>
> The comment for UnbindIdempotent says "Need to be marked othervm, or
> changed to be samevm safe" but the test isn't marked /othervm. Does
> the test need to be updated, or is this comment misleading, and the
> problem really is the port conflict?
This was a port conflict, which is why the UnbindIdempotent test was 
modified.
>
>
> *** ContextWithNullProperties.java
>
>
> (Nitpick: import lines are out of order)
>
> The comment says, "Create registry if one is not already running."
> This is mostly left over from the earlier version which also mentioned
> port 1099. But, aren't we changing things so that this tests always
> creates its own registry on a unique port? If so, I'd just remove the
> comment and remove the catch/ignore of RemoteException (which was
> suspect in the first place). If for some reason we can't create our
> own registry, we should just throw the exception out to the caller and
> let the test error out. If we ignored RemoteException we'd leave
> registryPort as -1 which would presumably cause some obscure failure
> later on.
Changed.
>
> We probably also don't need to declare/initialize registryPort
> separately anymore, so we can just replace the first 8 lines or so of
> main() with the following:
>
> Registry registry = TestLibrary.createRegistryOnUnusedPort();
> int registryPort = TestLibrary.getRegistryPort(registry);
>
> This same pattern occurs in these other tests and so a similar fix
> should be applied to them as well:
>
> - UnbindIdempotent
> - LookupNameWithColon.java
Fixed in all places.
>
>
> *** LookupNameWithColon.java
>
>
> This test is missing an @run tag, thus it won't actually get run!
> Since you've specified an @build tag, you have to specify a separate
> @run tag to run the test. It's possible to deduce this with a careful
> reading of the jtreg tag spec:
>
> http://openjdk.java.net/jtreg/tag-spec.txt
>
> (IMHO this is a terrible usability problem.) I've looked at the other
> tests in this webrev for similar issues, and I didn't see any, but I
> might have missed them.
Added @run to this test.
>
> Regarding the registry, this test is somewhat different from the
> others in that it was originally coded to use an existing registry if
> it couldn't create its own. If it were to find a registry running on
> 1099, it was probably created by some other test, and no assumptions
> can reliably be made about it. So, I'd just take out this logic and
> have the test unconditionally create its own registry.
Changed.
>
>
> *** StubClassesPermitted.java
>
>
> (Nitpick.) It looks like REGISTRY_PORT is a constant, but it's a
> static field. It should be renamed to have a conventional field name
> (i.e., mixed case).
Renamed.
>
>
> *** UnregisterGroup.java
>
>
> Similar to above, rename PORT.
Renamed.
>
>
> *** SetChildEnv.java
>
>
> The testing of the message string from the IOException causes me great
> concern. This message is defined all the way over in
> java.io.PipedInputStream, and while it's not localized, it does seem
> like a pretty fragile dependency. I mean, changing some exception
> message in java.io might cause an RMI Activation test to fail??!?
> (Sorry.)
>
> Certainly we want to ignore spurious errors, and it sounds from the
> comment like normal termination of rmid causes these exceptions to be
> thrown. But I'm wondering if rmid crashes, won't we get the same
> exception and ignore it, improperly?
>
> I don't know what the right thing to do is here. It seems like there
> ought to be a more definitive way to distinguish between normal
> termination and pipe closure from an error.
I don't see a simple solution right now.  I suggest we table this issue 
and re-visit it after the commit.  Another option is to not include the 
fix for Bug #7161503 with this fix until this issue has been addressed.
>
>
> *** AltSecurityManager.java
>
>
> The registry and rmid fields probably should be final. Maybe all caps
> too, except that RMID is the name of a class....
Made final, renamed.
>
> In run() it should probably bomb if utilityToStart equals neither
> registry nor rmid.
OK.
>
> The ensureExit() method has a local variable port, which hides the
> field named port (well, not really, since ensureExit is static and
> port is an instance field) but still, this is kind of confusing.
Renamed.
>
> If the port field is required to be initialized properly, make it a
> blank final (i.e., declare it final but without an initializer) and
> error-check it at the point where it's assigned in the constructor.
Made blank final.
>
>
> *** MultipleRegistries.java
>
>
> Not really a big deal, but the way the second registry is created
> seems somewhat roundabout. It's not clear to me why the code can't
> just do this:
>
> Registry registryImpl1 = TestLibrary.createRegistryOnUnusedPort();
> Registry registryImpl2 = TestLibrary.createRegistryOnUnusedPort();
> int port1 = TestLibrary.getRegistryPort(registryImpl1);
> int port2 = TestLibrary.getRegistryPort(registryImpl2);

This turned out to be an issue with calling 
LocateRegitry.createRegistry(0), which occurs in 
TestLibrary.createRegistryOnUnusedPort().  If 
LocateRegitry.createRegistry(0) is called within the same VM multiple 
times, after the first registry is created (and not destroyed), the 
subsequent calls will fail.  See the comment above creating the second 
registry line:

// Need to get a random port for the second registry.

However, this really isn't the right solution, so I modified 
TestLibrary.createRegistryOnUnusedPort to catch ExportException (which 
is thrown if the above issue occurs), get a random port, and attempt to 
create a registry on that port.  See updated TestLibrary.  
MultipleRegistries has been changed to what you have above as a result.

I'll post the changes to the comments here and the coming other half 
after I address the other half as another webrev.

Darryl
>
>
> -------
>
>
>
> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>
>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and
>> 7161503.
>> Webrev can be found here:
>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>> This commit fixes concurrency issues with the RMI tests.
>>
>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>> RMIRegistry on an unused port. It will try up to 10 times before
>> giving up.
>> - Added a TestLibrary.getRegistryPort(Registry) method to get the
>> port number
>> of the registry.
>> - Changed almost all tests from using hard port numbers to using
>> random port
>> numbers for running the RMI Registry and RMID.
>> - Removed othervm from those tests which don't need it.
>> - Added parameters for tests which spawn a separate VM to pass RMI
>> Registry and
>> RMID ports in cases where needed.
>> - Added PropertyPermission to security policy files where needed.
>> - Removed java/rmi and sun/rmi from tests which cannot be run
>> concurrently.
>> - Added java/rmi/Naming to list of tests which cannot be run
>> concurrently.
>>
>> Thanks,
>> Darryl


From rob.mckenna at oracle.com  Mon Jul  9 21:24:13 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Mon, 09 Jul 2012 21:24:13 +0000
Subject: hg: jdk8/tl/jdk: 7179305: (fs) Method name
	sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled
Message-ID: <20120709212431.5266947EB8@hg.openjdk.java.net>

Changeset: 516e0c884af2
Author:    robm
Date:      2012-07-09 22:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/516e0c884af2

7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled
Reviewed-by: dholmes, chegar

! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/LinuxWatchService.java
! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/solaris/classes/sun/nio/fs/UnixCopyFile.java
! src/solaris/classes/sun/nio/fs/UnixException.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixPath.java



From stuart.marks at oracle.com  Mon Jul  9 23:41:36 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 09 Jul 2012 16:41:36 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FF60595.3020607@oracle.com>
References: <4FF60595.3020607@oracle.com>
Message-ID: <4FFB6C30.2000109@oracle.com>

OK, here's the review for the second half of the files in the webrev. I saw 
your reply to the first half (to which I'll reply separately), and I don't 
think there's anything here that's affected by them.


*** AppleUserImpl.java
*** ApplicationServer.java


REGISTRY_PORT should be a local variable; also rename to use mixed case.

Eh, whoops, after looking at ApplicationServer.java I see that it accesses the 
REGISTRY_PORT field directly. This is why direct field access is a bad idea. 
:-) Now the question is, has REGISTRY_PORT been initialized before 
ApplicationServer needs it? It turns out that it has been -- but only in some 
cases.

It seems like the test is trying to support two modes, one that runs in two 
threads in the same JVM, and the other that runs in two separate JVMs. If they 
are in separate JVMs, things will no longer work because in the JVM that runs 
ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be -1. I suspect 
that our test environment doesn't support the separate JVM mode, but it seems 
unwise to break it.

I'd suggest that in two-JVM mode the classes fall back to using a "well-known" 
default registry port number, which in this case seems like 2006.

In single-JVM mode, AppleUserImpl creates an instance of ApplicationServer, so 
I'd suggest adding a method to ApplicationServer that allows AppleUserImpl to 
store the randomly-assigned registry port number into it, overriding the 
default value.

This seems like this is the simplest way to preserve the two modes of operation 
but to support the random port selection model we're trying to achieve.


*** activatable/EchoImpl.java


     int registryPort = new Integer(System.getProperty("rmi.registry.port"));

I'd suggest using Integer.parseInt() instead of new Integer(). Not a huge deal, 
but it's probably more conventional to use parseInt() and it avoids boxing.

One could probably do Integer.getInteger("rmi.registry.port") but this is seems 
pretty obscure to me even though it's more succinct.

The same also applies to the following:
  - HelloImpl.java
  - unicast/EchoImpl.java
  - ShutdownImpl.java
  - SelfTerminator.java
  - CheckFQDNClient.java
  - LeaseLeakClient.java
  - dgcDeadLock/TestImpl.java


*** FiniteGCLatency.java


The pattern here is a bit odd, as the test creates the registry, throws away 
the returned reference, and then calls getRegistry() to get another Registry 
reference. It *seems* like they're identical references, but in fact the first 
is apparently a reference to the actual Registry implementation, whereas the 
second is a remote stub.

The tests seem to do all the actual work using the remote stub, which seems proper.

This is confusing, though, as it looks like there's a redundant Registry 
reference now. This might lead someone in the future to "simplify" the test by 
not getting the remote stub, which in turn might invalidate some tests. (In 
fact I was going to suggest this but I decided to investigate further first.)

At the very least, I'd suggest renaming the variable that holds the newly 
created Registry to something like "registryImpl" to make it clear that it's 
different from the thing returned by getRegistry(), even though they have a the 
same time.

Another possibility is to rearrange the TestLibrary API so that there is a 
single utility method that combines createRegistryOnUnusedPort() and 
getRegistryPort(). That is, it creates a new registry and simply returns the 
port on which it was created, not a reference to the registry implementation.
I don't think the registry implementation is actually ever used by the tests, 
and it might simplify things a bit as well.

Possibly similar issues with:
  - UnreferencedContext.java
  - NoConsoleOutput.java


*** HttpSocketTest.java


Unnecessary call to TestLibrary.getUnusedRandomPort()?


*** TestLibrary.java

Mostly pretty straightforward, but I do have some concerns about the random 
port selection and a potential clash with the "reserved port range" as defined 
in this test library.

The getUnusedRandomPort() method attempts to get a socket within the range 
(1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS 
allocates ports more-or-less sequentially in the range [49152, 65536) which 
means that when the kernel's internal counter gets to 64000, 
getUnusedRandomPort()'s retries will fail, causing tests to fail until the 
counter wraps around.

Other systems behave differently; Linux seems to allocate them randomly in the 
range [32768,65536) and Windows XP SP3 allocates them sequentially in the range 
(1024,5000]. So it's probably not a problem for them.

I think the thing to do is to check only for "reserved ports" that are actually 
used by tests here. These are in the range [64001,64005]. In 
getUnusedRandomPort(), it should only need to retry if the returned port is 
within this narrow, reserved range. If it's anything else it should be OK.

On another topic, the three utility methods here:
  - createRegistryOnUnusedPort
  - getRegistryPort
  - getUnusedRandomPort

all catch exceptions and then return illegal values (null or -1), sometimes 
after printing some diagnostic information. The problem is that the caller will 
attempt to soldier on with the illegal return value and will stumble over 
something later, such as NullPointerException or IllegalArgumentException. This 
will probably be obvious but it's equally likely to be confusing.

Since these utilities are all called from test code, and the tests are relying 
on them to return valid results, I'd suggest just throwing exceptions from the 
utility methods if they fail. This will (should) cause the test to error out, 
but that's OK, as it never could have succeeded anyway if the utility call had 
failed.

s'marks



On 7/5/12 2:22 PM, Darryl Mocek wrote:
> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 7161503.
> Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
> This commit fixes concurrency issues with the RMI tests.
>
> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
> RMIRegistry on an unused port. It will try up to 10 times before giving up.
> - Added a TestLibrary.getRegistryPort(Registry) method to get the port number
> of the registry.
> - Changed almost all tests from using hard port numbers to using random port
> numbers for running the RMI Registry and RMID.
> - Removed othervm from those tests which don't need it.
> - Added parameters for tests which spawn a separate VM to pass RMI Registry and
> RMID ports in cases where needed.
> - Added PropertyPermission to security policy files where needed.
> - Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>
> Thanks,
> Darryl
>


From stuart.marks at oracle.com  Tue Jul 10 00:02:23 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 09 Jul 2012 17:02:23 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFB1F72.2010300@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFB1F72.2010300@oracle.com>
Message-ID: <4FFB710F.60407@oracle.com>

On 7/9/12 11:14 AM, Darryl Mocek wrote:
>> *** SetChildEnv.java
>>
>> The testing of the message string from the IOException causes me great
>> concern. This message is defined all the way over in
>> java.io.PipedInputStream, and while it's not localized, it does seem
>> like a pretty fragile dependency. I mean, changing some exception
>> message in java.io might cause an RMI Activation test to fail??!?
>> (Sorry.)
>>
>> Certainly we want to ignore spurious errors, and it sounds from the
>> comment like normal termination of rmid causes these exceptions to be
>> thrown. But I'm wondering if rmid crashes, won't we get the same
>> exception and ignore it, improperly?
>>
>> I don't know what the right thing to do is here. It seems like there
>> ought to be a more definitive way to distinguish between normal
>> termination and pipe closure from an error.
> I don't see a simple solution right now. I suggest we table this issue and
> re-visit it after the commit. Another option is to not include the fix for Bug
> #7161503 with this fix until this issue has been addressed.

Tabling this discussion until after the commit is OK. It would be good to have 
a comment that indicates that testing the exception string is a stopgap until 
we find a better way to distinguish the exceptions.

>> *** MultipleRegistries.java
>>
>>
>> Not really a big deal, but the way the second registry is created
>> seems somewhat roundabout. It's not clear to me why the code can't
>> just do this:
>>
>> Registry registryImpl1 = TestLibrary.createRegistryOnUnusedPort();
>> Registry registryImpl2 = TestLibrary.createRegistryOnUnusedPort();
>> int port1 = TestLibrary.getRegistryPort(registryImpl1);
>> int port2 = TestLibrary.getRegistryPort(registryImpl2);
>
> This turned out to be an issue with calling LocateRegitry.createRegistry(0),
> which occurs in TestLibrary.createRegistryOnUnusedPort(). If
> LocateRegitry.createRegistry(0) is called within the same VM multiple times,
> after the first registry is created (and not destroyed), the subsequent calls
> will fail. See the comment above creating the second registry line:
>
> // Need to get a random port for the second registry.
>
> However, this really isn't the right solution, so I modified
> TestLibrary.createRegistryOnUnusedPort to catch ExportException (which is
> thrown if the above issue occurs), get a random port, and attempt to create a
> registry on that port. See updated TestLibrary. MultipleRegistries has been
> changed to what you have above as a result.

OK, I'll look at your updates when you publish the revised webrev.

It might be reasonable to consider avoiding LocateRegistry.createRegistry(0) if 
it has this behavior, and instead (from within the test library) 
unconditionally call getUnusedRandomPort() and then createRegistry() on that port.

s'marks


From darryl.mocek at oracle.com  Tue Jul 10 00:04:04 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 09 Jul 2012 17:04:04 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFB710F.60407@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFB1F72.2010300@oracle.com> <4FFB710F.60407@oracle.com>
Message-ID: <4FFB7174.6000209@oracle.com>



On Mon 09 Jul 2012 05:02:23 PM PDT, Stuart Marks wrote:
>
> On 7/9/12 11:14 AM, Darryl Mocek wrote:
>>
>>>
>>> *** SetChildEnv.java
>>>
>>> The testing of the message string from the IOException causes me great
>>> concern. This message is defined all the way over in
>>> java.io.PipedInputStream, and while it's not localized, it does seem
>>> like a pretty fragile dependency. I mean, changing some exception
>>> message in java.io might cause an RMI Activation test to fail??!?
>>> (Sorry.)
>>>
>>> Certainly we want to ignore spurious errors, and it sounds from the
>>> comment like normal termination of rmid causes these exceptions to be
>>> thrown. But I'm wondering if rmid crashes, won't we get the same
>>> exception and ignore it, improperly?
>>>
>>> I don't know what the right thing to do is here. It seems like there
>>> ought to be a more definitive way to distinguish between normal
>>> termination and pipe closure from an error.
>>
>> I don't see a simple solution right now. I suggest we table this
>> issue and
>> re-visit it after the commit. Another option is to not include the
>> fix for Bug
>> #7161503 with this fix until this issue has been addressed.
>
>
> Tabling this discussion until after the commit is OK. It would be good
> to have a comment that indicates that testing the exception string is
> a stopgap until we find a better way to distinguish the exceptions.
I'll add a comment.
>
>>
>>>
>>> *** MultipleRegistries.java
>>>
>>>
>>> Not really a big deal, but the way the second registry is created
>>> seems somewhat roundabout. It's not clear to me why the code can't
>>> just do this:
>>>
>>> Registry registryImpl1 = TestLibrary.createRegistryOnUnusedPort();
>>> Registry registryImpl2 = TestLibrary.createRegistryOnUnusedPort();
>>> int port1 = TestLibrary.getRegistryPort(registryImpl1);
>>> int port2 = TestLibrary.getRegistryPort(registryImpl2);
>>
>>
>> This turned out to be an issue with calling
>> LocateRegitry.createRegistry(0),
>> which occurs in TestLibrary.createRegistryOnUnusedPort(). If
>> LocateRegitry.createRegistry(0) is called within the same VM multiple
>> times,
>> after the first registry is created (and not destroyed), the
>> subsequent calls
>> will fail. See the comment above creating the second registry line:
>>
>> // Need to get a random port for the second registry.
>>
>> However, this really isn't the right solution, so I modified
>> TestLibrary.createRegistryOnUnusedPort to catch ExportException
>> (which is
>> thrown if the above issue occurs), get a random port, and attempt to
>> create a
>> registry on that port. See updated TestLibrary. MultipleRegistries
>> has been
>> changed to what you have above as a result.
>
>
> OK, I'll look at your updates when you publish the revised webrev.
>
> It might be reasonable to consider avoiding
> LocateRegistry.createRegistry(0) if it has this behavior, and instead
> (from within the test library) unconditionally call
> getUnusedRandomPort() and then createRegistry() on that port.
I originally had getUnusedRandomPort/createRegistry(randomPort), but 
Alan felt LocateRegistry.createRegistry(0) is a better choice. 
getUnusedRandomPort creates a socket to ensure the port is available, 
then closes it and returns the port number.  It's possible (though 
unlikely) that another process will grab the port after closing and 
before createRegistry(randomPort) executes. 
LocateRegistry.createRegistry(0) ensures the registry is started on a 
random port.

Darryl
>
> s'marks


From huizhe.wang at oracle.com  Tue Jul 10 01:42:05 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 09 Jul 2012 18:42:05 -0700
Subject: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri)
	is not IPv6 enabled. It throws MalformedURLException
In-Reply-To: <3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
References: <4FE4FB34.9040808@oracle.com>
	<22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com>
	<4FEA30C1.7080204@oracle.com>
	<3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
Message-ID: <4FFB886D.8070604@oracle.com>

Hi Paul,

I'm back from vacation.

You're right. But such an error is also expected.  The original design 
never tried to out-do the java.net.URL.  If a system ID input fails URL, 
it shall result in an exception.

The patch that supplied the extra encoding was provided to both Sun and 
Apache, and applied to Sun sources. However, it never went into the 
Apache code base (refer to 
https://issues.apache.org/jira/browse/XERCESJ-1156).  I thought of 
removing the patch, bringing our source in sync with that of Apache. But 
then I feared that we might get a regression since the patch has been in 
the source for so many years.

Thus, this ugly solution (removing would be prettier) to leave the old 
change as is but use java.net.URL in all other cases.

By the way, we can only consider this one for 7u8 now.

Thanks,
Joe


On 6/26/2012 11:51 PM, Paul Sandoz wrote:
> Hi,
>
> On Jun 26, 2012, at 11:59 PM, Joe Wang wrote:
>
>> Hi Paul,
>>
>> That method was contributed by engineers from Korea and intended to handle paths that contained international characters, so that was how it was named.  It was an extra processing added. Outside of that scenario, we'd want to skip the process and get back to letting URL handle the input, whether the system id contains space or '[', and etc.
>>
> Your fix will fail if there is an IPv6 encoded address for the host part and there are non-ASCII characters present in, for example, the path part.
>
> If the intent is to *never* percent encode ASCII characters you should change the following (and JavaDoc) to be consistent:
>
> 2638         // for each byte
> 2639         for (i = 0; i<  len; i++) {
> 2640             b = bytes[i];
> 2641             // for non-ascii character: make it positive, then escape
> 2642             if (b<  0) {
> 2643                 ch = b + 256;
> 2644                 buffer.append('%');
> 2645                 buffer.append(gHexChs[ch>>  4]);
> 2646                 buffer.append(gHexChs[ch&  0xf]);
> 2647             }
> 2648             else if (b != '%'&&  b != '#'&&  gNeedEscaping[b]) {  //<--- remove this block
> 2649                 buffer.append('%');
> 2650                 buffer.append(gAfterEscaping1[b]);
> 2651                 buffer.append(gAfterEscaping2[b]);
> 2652             }
> 2653             else {
> 2654                 buffer.append((char)b);
> 2655             }
> 2656         }
>
>
> Thankfully java.net.URL is much more forgiving (a polite way of saying buggy!) than java.net.URI and accepts unencoded reserved ASCII characters as part of the URI encoded characters.
>
> Something does not smell right here. Arguably the system ID should be a correctly encoded URI to begin with otherwise an error should result.
>
> Paul.
>
>> -Joe
>>
>> On 6/25/2012 9:13 AM, Paul Sandoz wrote:
>>> Hi Joe,
>>>
>>> What happens if there is a space character or other characters in the string that should be encoded ?
>>>
>>>    http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3
>>>
>>> I suspect "escapeNonUSAscii" is slightly misleading, it should be really called something like "escapeCharactersInUriString".
>>>
>>> Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded address.
>>>
>>> Paul.
>>>
>>> On Jun 23, 2012, at 1:09 AM, Joe Wang wrote:
>>>
>>>> Hi,
>>>>
>>>> This is a patch to fix the IPv6 issue.
>>>>
>>>> In a previous patch to fix an issue with system id containing international characters, an extra character escaping was added so that any URL passed to the parser goes through method escapeNonUSAscii before it's used to construct an URL.
>>>>
>>>> However, literal IPv6 addresses are enclosed in square brackets. The escapeNonUSAscii encoded address will become unrecognizable to URL that would throw a java.net.MalformedURLException.  An address such ashttp://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml", resulting in java.net.MalformedURLException: For input string: ":la03:73ff:fead:f7b0%5D".
>>>>
>>>> This patch skips the encoding process and returns it as is if there're no non-ascii characters.
>>>>
>>>> webrev:http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/
>>>>
>>>> Please review.
>>>>
>>>> Thanks,
>>>> Joe


From stuart.marks at oracle.com  Tue Jul 10 02:06:42 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 09 Jul 2012 19:06:42 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFB7174.6000209@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFB1F72.2010300@oracle.com> <4FFB710F.60407@oracle.com>
	<4FFB7174.6000209@oracle.com>
Message-ID: <4FFB8E32.7070303@oracle.com>

On 7/9/12 5:04 PM, Darryl Mocek wrote:
> I originally had getUnusedRandomPort/createRegistry(randomPort), but Alan felt
> LocateRegistry.createRegistry(0) is a better choice. getUnusedRandomPort
> creates a socket to ensure the port is available, then closes it and returns
> the port number. It's possible (though unlikely) that another process will grab
> the port after closing and before createRegistry(randomPort) executes.
> LocateRegistry.createRegistry(0) ensures the registry is started on a random port.

Either call getUnusedRandomPort, which opens and closes a socket redundantly 
(with the possible risk of somebody else stealing it before the caller reopens 
it); or call createRegistry(0) which (probably) doesn't close and reopen, but 
which throws an exception you have to deal with if a registry is already 
running in this JVM. The latter is also fairly unlikely but it does occur at 
least once in the test suite. Seems to me like six of one, half a dozen of the 
other.

Do whichever you feel makes more sense.

s'marks


From paul.sandoz at Oracle.com  Tue Jul 10 05:59:25 2012
From: paul.sandoz at Oracle.com (Paul Sandoz)
Date: Tue, 10 Jul 2012 07:59:25 +0200
Subject: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri)
	is not IPv6 enabled. It throws MalformedURLException
In-Reply-To: <4FFB886D.8070604@oracle.com>
References: <4FE4FB34.9040808@oracle.com>
	<22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com>
	<4FEA30C1.7080204@oracle.com>
	<3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
	<4FFB886D.8070604@oracle.com>
Message-ID: <18533EDB-D904-4F24-B502-C31678548053@Oracle.com>

Hi Joe,

What happens when someone logs a bug for system IDs containing IPv6 addresses and non-percent encoded international characters?


On Jul 10, 2012, at 3:42 AM, Joe Wang wrote:
> Hi Paul,
> 
> I'm back from vacation.
> 
> You're right. But such an error is also expected.  The original design never tried to out-do the java.net.URL.  If a system ID input fails URL, it shall result in an exception.
> 
> The patch that supplied the extra encoding was provided to both Sun and Apache, and applied to Sun sources. However, it never went into the Apache code base (refer to https://issues.apache.org/jira/browse/XERCESJ-1156).  I thought of removing the patch, bringing our source in sync with that of Apache. But then I feared that we might get a regression since the patch has been in the source for so many years.
> 
> Thus, this ugly solution (removing would be prettier) to leave the old change as is but use java.net.URL in all other cases.
> 

java.net.URL is being used in all cases:

 602         if (reader == null) {
 603             stream = xmlInputSource.getByteStream();
 604             if (stream == null) {
 605                 URL location = new URL(escapeNonUSAscii(expandedSystemId));
 606                 URLConnection connect = location.openConnection();
 607                 if (!(connect instanceof HttpURLConnection)) {
 608                     stream = connect.getInputStream();
 609                 }

If this is really about supporting non-percent encoded international characters in the system ID, then you can make a simple fix to support IPv6-based URLs in general: do not percent encoded *any* ascii characters.

Paul.


> By the way, we can only consider this one for 7u8 now.
> 
> Thanks,
> Joe
> 


From olivier.lagneau at oracle.com  Tue Jul 10 06:49:02 2012
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Tue, 10 Jul 2012 08:49:02 +0200
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FF732DA.9060704@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
Message-ID: <4FFBD05E.5020307@oracle.com>

Hi Stuart,

I am in vacation for 2 days, but I think I need reply anyway now.

First thanks for reviewing and giving your time on this.

Now in the 7161503 SetChilEnv case:
>
> *** SetChildEnv.java
>
>
> The testing of the message string from the IOException causes me great 
> concern. This message is defined all the way over in 
> java.io.PipedInputStream, and while it's not localized, it does seem 
> like a pretty fragile dependency. I mean, changing some exception 
> message in java.io might cause an RMI Activation test to fail??!? 
> (Sorry.)
>
> Certainly we want to ignore spurious errors, and it sounds from the 
> comment like normal termination of rmid causes these exceptions to be 
> thrown. But I'm wondering if rmid crashes, won't we get the same 
> exception and ignore it, improperly?
>
> I don't know what the right thing to do is here. It seems like there 
> ought to be a more definitive way to distinguish between normal 
> termination and pipe closure from an error.
>
The fact is that the part of the fix we are discussing here is 
cleaning-up of the test. It is not related to 7142596.
As as said in other mails, this test should be written differently and 
in addition brings a systematic "Pipe Broken exception"
each time runwith() is called. I mean in the current JDK state, not this 
fixed one. an ugly thing. That was considered to be ok for a test 
success however.

I surely have gone too far in that fix, and may not have tried to clean 
it up.
Btw, none of the other rmi java test fixed here does try to do any cleanup.

Thus, and because it is important to remain consistant in bug fixes, 
since this one is for 7142596 only,
I think we should just revert to the existing code regarding the 
DebugExecWatcher and related exception cleanup fix.
We must then accept to keep this exception raised each time runwith() is 
called, since this is the current state of the code.
We should also then include in bug description  a note stating the 
problem and how we can fix it.
Such a fix would then be part of recent 7168267.

a full cleanup  fix of DebugExecWatcher code  is simple but involves 
testLibrary framework:
- DebugExecWatcher is a consumer of redirected output of distant rmid: 
it needs to check that "DebugExec" string is found in that stream;
- Thus a way of dealing with consumer of redirected output is needed for it.
- We define in testlibrary an OutputConsumer interface with only one 
method processInput() that must do the needed work.
- By default, no such consumer exist and StreamPipe of testLibrary does 
the work as usual.
- Otherwise, at rmid creation such a consumer is passed and its 
processInput method will be call from streamPipe as needed.

Thanks,
Olivier.










Le 06/07/2012 20:47, Stuart Marks a ?crit :
> Hi,
>
> I've reviewed the first half of the files, thru 
> test/java/rmi/registry/reexport/Reexport.java. Basically things look 
> good and make sense, but there are some details to be ironed out and 
> some cleanups to be done. Nothing major, I think, with the exception 
> of SetChildEnv. See discussion below.
>
> Second half to follow later.
>
> s'marks
>
>
> -------
>
>
>
> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 
>> 7161503.
>> Webrev can be found here: 
>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>> This commit fixes concurrency issues with the RMI tests.
>>
>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>> RMIRegistry on an unused port. It will try up to 10 times before 
>> giving up.
>> - Added a TestLibrary.getRegistryPort(Registry) method to get the 
>> port number
>> of the registry.
>> - Changed almost all tests from using hard port numbers to using 
>> random port
>> numbers for running the RMI Registry and RMID.
>> - Removed othervm from those tests which don't need it.
>> - Added parameters for tests which spawn a separate VM to pass RMI 
>> Registry and
>> RMID ports in cases where needed.
>> - Added PropertyPermission to security policy files where needed.
>> - Removed java/rmi and sun/rmi from tests which cannot be run 
>> concurrently.
>> - Added java/rmi/Naming to list of tests which cannot be run 
>> concurrently.
>>
>> Thanks,
>> Darryl
>>



From olivier.lagneau at oracle.com  Tue Jul 10 06:56:53 2012
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Tue, 10 Jul 2012 08:56:53 +0200
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FFBD05E.5020307@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFBD05E.5020307@oracle.com>
Message-ID: <4FFBD235.3080005@oracle.com>

Le 10/07/2012 08:49, Olivier Lagneau a ?crit :
> Hi Stuart,
>
> I am in vacation for 2 days, but I think I need reply anyway now.
>
> First thanks for reviewing and giving your time on this.
>
> Now in the 7161503 SetChilEnv case:
>>
>> *** SetChildEnv.java
>>
>>
>> The testing of the message string from the IOException causes me 
>> great concern. This message is defined all the way over in 
>> java.io.PipedInputStream, and while it's not localized, it does seem 
>> like a pretty fragile dependency. I mean, changing some exception 
>> message in java.io might cause an RMI Activation test to fail??!? 
>> (Sorry.)
>>
>> Certainly we want to ignore spurious errors, and it sounds from the 
>> comment like normal termination of rmid causes these exceptions to be 
>> thrown. But I'm wondering if rmid crashes, won't we get the same 
>> exception and ignore it, improperly?
>>
>> I don't know what the right thing to do is here. It seems like there 
>> ought to be a more definitive way to distinguish between normal 
>> termination and pipe closure from an error.
>>
> The fact is that the part of the fix we are discussing here is 
> cleaning-up of the test.It is not related to 7142596.
> As as said in other mails, this test should be written differently and 
> in addition brings a systematic "Pipe Broken exception"
> each time runwith() is called. I mean in the current JDK state, not 
> this fixed one. an ugly thing. That was considered to be ok for a test 
> success however.
>
> I surely have gone too far in that fix, and may not have tried to 
> clean it up.
> Btw, none of the other rmi java test fixed here does try to do any 
> cleanup.
>
> Thus, and because it is important to remain consistant in bug fixes, 
> since this one is for 7142596 only,
> I think we should just revert to the existing code regarding the 
> DebugExecWatcher and related exception cleanup fix.
> We must then accept to keep this exception raised each time runwith() 
> is called, since this is the current state of the code.
> We should also then include in bug description  a note stating the 
> problem and how we can fix it.
> Such a fix would then be part of recent 7168267.

>
> a full cleanup  fix of DebugExecWatcher code  is simple but involves 
> testLibrary framework:
> - DebugExecWatcher is a consumer of redirected output of distant rmid: 
> it needs to check that "DebugExec" string is found in that stream;
> - Thus a way of dealing with consumer of redirected output is needed 
> for it.
> - We define in testlibrary an OutputConsumer interface with only one 
> method processInput() that must do the needed work.
> - By default, no such consumer exist and StreamPipe of testLibrary 
> does the work as usual.
> - Otherwise, at rmid creation such a consumer is passed and its 
> processInput method will be call from streamPipe as needed.
forgot to say  this:
- DebugExecWatcher will then disappear as such and "Pipe broken" 
IOException problem as well.

Olivier.
>
> Thanks,
> Olivier.
>



From sean.coffey at oracle.com  Tue Jul 10 16:37:47 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 10 Jul 2012 17:37:47 +0100
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
Message-ID: <4FFC5A5B.2000009@oracle.com>


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.



From huizhe.wang at oracle.com  Tue Jul 10 18:50:07 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 10 Jul 2012 11:50:07 -0700
Subject: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri)
	is not IPv6 enabled. It throws MalformedURLException
In-Reply-To: <18533EDB-D904-4F24-B502-C31678548053@Oracle.com>
References: <4FE4FB34.9040808@oracle.com>
	<22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com>
	<4FEA30C1.7080204@oracle.com>
	<3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
	<4FFB886D.8070604@oracle.com>
	<18533EDB-D904-4F24-B502-C31678548053@Oracle.com>
Message-ID: <4FFC795F.1010906@oracle.com>

On 7/9/2012 10:59 PM, Paul Sandoz wrote:
> Hi Joe,
>
> What happens when someone logs a bug for system IDs containing IPv6 addresses and non-percent encoded international characters?

Exception would be expected just as if Xerces is used.

>
>
> On Jul 10, 2012, at 3:42 AM, Joe Wang wrote:
>> Hi Paul,
>>
>> I'm back from vacation.
>>
>> You're right. But such an error is also expected.  The original design never tried to out-do the java.net.URL.  If a system ID input fails URL, it shall result in an exception.
>>
>> The patch that supplied the extra encoding was provided to both Sun and Apache, and applied to Sun sources. However, it never went into the Apache code base (refer to https://issues.apache.org/jira/browse/XERCESJ-1156).  I thought of removing the patch, bringing our source in sync with that of Apache. But then I feared that we might get a regression since the patch has been in the source for so many years.
>>
>> Thus, this ugly solution (removing would be prettier) to leave the old change as is but use java.net.URL in all other cases.
>>
> java.net.URL is being used in all cases:

Except that an encoded url is the input when escapeNonUSAscii is used.

>
>   602         if (reader == null) {
>   603             stream = xmlInputSource.getByteStream();
>   604             if (stream == null) {
>   605                 URL location = new URL(escapeNonUSAscii(expandedSystemId));
>   606                 URLConnection connect = location.openConnection();
>   607                 if (!(connect instanceof HttpURLConnection)) {
>   608                     stream = connect.getInputStream();
>   609                 }
>
> If this is really about supporting non-percent encoded international characters in the system ID, then you can make a simple fix to support IPv6-based URLs in general: do not percent encoded *any* ascii characters.

When encoding an url, aren't reserved characters supposed to be encoded 
as well?

Joe

>
> Paul.
>
>
>> By the way, we can only consider this one for 7u8 now.
>>
>> Thanks,
>> Joe
>>


From paul.sandoz at oracle.com  Tue Jul 10 19:26:14 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jul 2012 21:26:14 +0200
Subject: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri)
	is not IPv6 enabled. It throws MalformedURLException
In-Reply-To: <4FFC795F.1010906@oracle.com>
References: <4FE4FB34.9040808@oracle.com>
	<22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com>
	<4FEA30C1.7080204@oracle.com>
	<3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
	<4FFB886D.8070604@oracle.com>
	<18533EDB-D904-4F24-B502-C31678548053@Oracle.com>
	<4FFC795F.1010906@oracle.com>
Message-ID: <7D943551-AC7A-4BAC-BC0F-4D6E33EE079B@oracle.com>

Hi Joe,

If you are gonna fix things to support IPv6 addresses in URLs i really think you need to make it work for URLs with international characters too.

On Jul 10, 2012, at 8:50 PM, Joe Wang wrote:
>> 
>>  602         if (reader == null) {
>>  603             stream = xmlInputSource.getByteStream();
>>  604             if (stream == null) {
>>  605                 URL location = new URL(escapeNonUSAscii(expandedSystemId));
>>  606                 URLConnection connect = location.openConnection();
>>  607                 if (!(connect instanceof HttpURLConnection)) {
>>  608                     stream = connect.getInputStream();
>>  609                 }
>> 
>> If this is really about supporting non-percent encoded international characters in the system ID, then you can make a simple fix to support IPv6-based URLs in general: do not percent encoded *any* ascii characters.
> 
> When encoding an url, aren't reserved characters supposed to be encoded as well?
> 

Your fix does not do that:

2608     protected static String escapeNonUSAscii(String str) {
2609         if (str == null) {
2610             return str;
2611         }
2612         int len = str.length(), i=0, ch;
2613         for (; i < len; i++) {
2614             ch = str.charAt(i);
2615             // if it's not an ASCII 7 character, break here, and use UTF-8 encoding
2616             if (ch >= 128)
2617                 break;
2618         }
2619 
2620         // we saw no non-ascii-7 character
2621         if (i == len) {
2622             return str;       // <--- reserved characters are not percent-encoded
2623         }
2624 

I know it is deliberate attempt to avoid '[' and ']' characters being percent encoded, whether the URL has an IPv6 address or not, even though '[' and ']' are reserved characters outside of an IPv6 address .

My point is if you don't encode reserved ASCII characters when all the characters in the URL are ASCII characters then don't encode reserved ASCII characters when there are also international characters present that will be encoded. Then "escapeNonUSAscii" actually does what the method is called :-)

Otherwise the other, more preferable solution IMHO, is to remove the hack of using escapeNonUSAscii.

Paul.

From naoto.sato at oracle.com  Tue Jul 10 20:42:55 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 10 Jul 2012 13:42:55 -0700
Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and
	Adopt Unicode CLDR Data
Message-ID: <4FFC93CF.40105@oracle.com>

Hello,

Please review the JDK8 changes for JEP 127: Improve Locale Data 
Packaging and Adopt Unicode CLDR Data 
(http://openjdk.java.net/jeps/127). The webrev is located at:

http://cr.openjdk.java.net/~naoto/6336885/webrev.00/

The main bug id for this enhancement is:

6336885: RFE: Locale Data Deployment Enhancements

Along with this, the following bugs/enhancements are also implemented in 
this change:

4609153 Provide locale data for Indic locales
5104387 Support for gl_ES locale (galician language)
6337471 desktop/system locale preferences support
7056139 (cal) SPI support for locale-dependent Calendar parameters
7058206 Provide CalendarData SPI for week params and display field value 
names
7073852 Support multiple scripts for digits and decimal symbols per locale
7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat
7171324 getAvailableLocales() of locale sensitive services should return 
the actual availability of locales
7151414 (cal) Support calendar type identification
7168528 LocaleServiceProvider needs to be aware of Locale extensions
7171372 (cal) locale's default Calendar should be created if unknown 
calendar is specified

Please note that packaging changes that relate to Jigsaw module system 
aren't included in this changeset.

Naoto Sato and Masayoshi Okutsu


From stuart.marks at oracle.com  Tue Jul 10 20:52:52 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 10 Jul 2012 13:52:52 -0700
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FFBD235.3080005@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFBD05E.5020307@oracle.com> <4FFBD235.3080005@oracle.com>
Message-ID: <4FFC9624.7060403@oracle.com>

On 7/9/12 11:56 PM, Olivier Lagneau wrote:
> Le 10/07/2012 08:49, Olivier Lagneau a ?crit :
>> Now in the 7161503 SetChilEnv case:
>>>
>> I think we should just revert to the existing code regarding the
>> DebugExecWatcher and related exception cleanup fix.
>> We must then accept to keep this exception raised each time runwith() is
>> called, since this is the current state of the code.
>> We should also then include in bug description a note stating the problem and
>> how we can fix it.
>> Such a fix would then be part of recent 7168267.

Hi Olivier,

Thanks for taking time from your vacation to answer this.

I'm sure I don't have all the background on this (and I don't really need to 
know everything) but from what I recall from talking to Darryl, 7142596 
introduced a test failure that would have to go onto the problem list; and then 
7161503 would fix the failure and then remove it from the problem list.

Instead of fixing these separately we (at least Darryl and I) thought it would 
be best to merge them together.

Now, I had pointed out some issues with the changes to the SetChildEnv test. My 
main concern is that we don't push the changes as-is and then declare things to 
be done. If there's further discussion, design, or cleanup to be done, great, 
we can push the current changes and continue working on a followup changeset. 
If there's a bugid to track this (probably 7161503) so much the better.

If you and Darryl agree to proceed differently, though, I'm fine with that too.

s'marks


From huizhe.wang at oracle.com  Tue Jul 10 21:01:44 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 10 Jul 2012 14:01:44 -0700
Subject: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri)
	is not IPv6 enabled. It throws MalformedURLException
In-Reply-To: <7D943551-AC7A-4BAC-BC0F-4D6E33EE079B@oracle.com>
References: <4FE4FB34.9040808@oracle.com>
	<22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com>
	<4FEA30C1.7080204@oracle.com>
	<3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com>
	<4FFB886D.8070604@oracle.com>
	<18533EDB-D904-4F24-B502-C31678548053@Oracle.com>
	<4FFC795F.1010906@oracle.com>
	<7D943551-AC7A-4BAC-BC0F-4D6E33EE079B@oracle.com>
Message-ID: <4FFC9838.6070407@oracle.com>

Hi Paul,

I agree, it looked quite messy, isn't it :), keeping a hack that 
generates encoded url and yet not support IPv6 addresses that contain 
international characters?

It IS a more preferable solution to remove the hack of using 
escapeNonUSAscii -- so I'll do :)

Thanks,
Joe

On 7/10/2012 12:26 PM, Paul Sandoz wrote:
> Hi Joe,
>
> If you are gonna fix things to support IPv6 addresses in URLs i really think you need to make it work for URLs with international characters too.
>
> On Jul 10, 2012, at 8:50 PM, Joe Wang wrote:
>>>   602         if (reader == null) {
>>>   603             stream = xmlInputSource.getByteStream();
>>>   604             if (stream == null) {
>>>   605                 URL location = new URL(escapeNonUSAscii(expandedSystemId));
>>>   606                 URLConnection connect = location.openConnection();
>>>   607                 if (!(connect instanceof HttpURLConnection)) {
>>>   608                     stream = connect.getInputStream();
>>>   609                 }
>>>
>>> If this is really about supporting non-percent encoded international characters in the system ID, then you can make a simple fix to support IPv6-based URLs in general: do not percent encoded *any* ascii characters.
>> When encoding an url, aren't reserved characters supposed to be encoded as well?
>>
> Your fix does not do that:
>
> 2608     protected static String escapeNonUSAscii(String str) {
> 2609         if (str == null) {
> 2610             return str;
> 2611         }
> 2612         int len = str.length(), i=0, ch;
> 2613         for (; i<  len; i++) {
> 2614             ch = str.charAt(i);
> 2615             // if it's not an ASCII 7 character, break here, and use UTF-8 encoding
> 2616             if (ch>= 128)
> 2617                 break;
> 2618         }
> 2619
> 2620         // we saw no non-ascii-7 character
> 2621         if (i == len) {
> 2622             return str;       //<--- reserved characters are not percent-encoded
> 2623         }
> 2624
>
> I know it is deliberate attempt to avoid '[' and ']' characters being percent encoded, whether the URL has an IPv6 address or not, even though '[' and ']' are reserved characters outside of an IPv6 address .
>
> My point is if you don't encode reserved ASCII characters when all the characters in the URL are ASCII characters then don't encode reserved ASCII characters when there are also international characters present that will be encoded. Then "escapeNonUSAscii" actually does what the method is called :-)
>
> Otherwise the other, more preferable solution IMHO, is to remove the hack of using escapeNonUSAscii.
>
> Paul.


From darryl.mocek at oracle.com  Tue Jul 10 21:14:55 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Tue, 10 Jul 2012 14:14:55 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFB6C30.2000109@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
Message-ID: <4FFC9B4F.1060200@oracle.com>


On 07/09/2012 04:41 PM, Stuart Marks wrote:
> OK, here's the review for the second half of the files in the webrev. 
> I saw your reply to the first half (to which I'll reply separately), 
> and I don't think there's anything here that's affected by them.
>
>
> *** AppleUserImpl.java
> *** ApplicationServer.java
>
>
> REGISTRY_PORT should be a local variable; also rename to use mixed case.
Changed to a private registryPort (see next issue).
>
> Eh, whoops, after looking at ApplicationServer.java I see that it 
> accesses the REGISTRY_PORT field directly. This is why direct field 
> access is a bad idea. :-) Now the question is, has REGISTRY_PORT been 
> initialized before ApplicationServer needs it? It turns out that it 
> has been -- but only in some cases.
>
> It seems like the test is trying to support two modes, one that runs 
> in two threads in the same JVM, and the other that runs in two 
> separate JVMs. If they are in separate JVMs, things will no longer 
> work because in the JVM that runs ApplicationServer.main(), 
> AppleUserImpl.REGISTRY_PORT will be -1. I suspect that our test 
> environment doesn't support the separate JVM mode, but it seems unwise 
> to break it.
>
> I'd suggest that in two-JVM mode the classes fall back to using a 
> "well-known" default registry port number, which in this case seems 
> like 2006.
>
> In single-JVM mode, AppleUserImpl creates an instance of 
> ApplicationServer, so I'd suggest adding a method to ApplicationServer 
> that allows AppleUserImpl to store the randomly-assigned registry port 
> number into it, overriding the default value.
>
> This seems like this is the simplest way to preserve the two modes of 
> operation but to support the random port selection model we're trying 
> to achieve.
Rather then going the "fixed port" route, which is what we're trying to 
get away from, I've changed the implementation of both AppletUserImpl's 
and ApplicationServer so ApplicationServer requires a port and 
AppleUserImpl supplies the port on construction of ApplicationServer.  I 
thought of modifying ApplicationServer's constructor to create a port 
using TestLibrary.getUnusedRandomPort, but decided requiring a port is 
better as ApplicationServer's job is to look for already exported 
AppleUser objects.
>
>
> *** activatable/EchoImpl.java
>
>
>     int registryPort = new 
> Integer(System.getProperty("rmi.registry.port"));
>
> I'd suggest using Integer.parseInt() instead of new Integer(). Not a 
> huge deal, but it's probably more conventional to use parseInt() and 
> it avoids boxing.
>
> One could probably do Integer.getInteger("rmi.registry.port") but this 
> is seems pretty obscure to me even though it's more succinct.
>
> The same also applies to the following:
>  - HelloImpl.java
>  - unicast/EchoImpl.java
>  - ShutdownImpl.java
>  - SelfTerminator.java
>  - CheckFQDNClient.java
>  - LeaseLeakClient.java
>  - dgcDeadLock/TestImpl.java
>
Integer.parseInt returns a primitive (which is what the return is 
assigned to) and it appears Integer.parseInt is "faster" then creating a 
new Integer.  Changed to Integer.parseInt in all places referenced.
>
> *** FiniteGCLatency.java
>
>
> The pattern here is a bit odd, as the test creates the registry, 
> throws away the returned reference, and then calls getRegistry() to 
> get another Registry reference. It *seems* like they're identical 
> references, but in fact the first is apparently a reference to the 
> actual Registry implementation, whereas the second is a remote stub.
>
> The tests seem to do all the actual work using the remote stub, which 
> seems proper.
>
> This is confusing, though, as it looks like there's a redundant 
> Registry reference now. This might lead someone in the future to 
> "simplify" the test by not getting the remote stub, which in turn 
> might invalidate some tests. (In fact I was going to suggest this but 
> I decided to investigate further first.)
>
> At the very least, I'd suggest renaming the variable that holds the 
> newly created Registry to something like "registryImpl" to make it 
> clear that it's different from the thing returned by getRegistry(), 
> even though they have a the same time.
>
> Another possibility is to rearrange the TestLibrary API so that there 
> is a single utility method that combines createRegistryOnUnusedPort() 
> and getRegistryPort(). That is, it creates a new registry and simply 
> returns the port on which it was created, not a reference to the 
> registry implementation.
> I don't think the registry implementation is actually ever used by the 
> tests, and it might simplify things a bit as well.
>
> Possibly similar issues with:
>  - UnreferencedContext.java
>  - NoConsoleOutput.java
>
>
> *** HttpSocketTest.java
>
>
> Unnecessary call to TestLibrary.getUnusedRandomPort()?
Looks like extra code left over from the change from using 
TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) to 
TestLibrary.createRegistryOnUnusedPort...removed.
>
>
> *** TestLibrary.java
>
> Mostly pretty straightforward, but I do have some concerns about the 
> random port selection and a potential clash with the "reserved port 
> range" as defined in this test library.
>
> The getUnusedRandomPort() method attempts to get a socket within the 
> range (1024,64000) and will retry 10 times if it can't. Unfortunately, 
> MacOS allocates ports more-or-less sequentially in the range [49152, 
> 65536) which means that when the kernel's internal counter gets to 
> 64000, getUnusedRandomPort()'s retries will fail, causing tests to 
> fail until the counter wraps around.
>
> Other systems behave differently; Linux seems to allocate them 
> randomly in the range [32768,65536) and Windows XP SP3 allocates them 
> sequentially in the range (1024,5000]. So it's probably not a problem 
> for them.
>
> I think the thing to do is to check only for "reserved ports" that are 
> actually used by tests here. These are in the range [64001,64005]. In 
> getUnusedRandomPort(), it should only need to retry if the returned 
> port is within this narrow, reserved range. If it's anything else it 
> should be OK.
I'll try setting the range this narrow, but I don't know how many 
sequential tests will be run at a time and I'm concerned 5 is too few.  
The -concurrency option on jtreg allows you to specify how many 
concurrent tests will be run.  We should have enough test ports reserved 
to satisfy any concurrency request.  I've run the tests with 
-concurrency=8 (I have a dual-core system showing 4 CPU's).  I tried 
reducing the port range to 64001/64002 and concurrency=4 and all passed 
fine, so maybe we're OK with just 5.
>
> On another topic, the three utility methods here:
>  - createRegistryOnUnusedPort
>  - getRegistryPort
>  - getUnusedRandomPort
>
> all catch exceptions and then return illegal values (null or -1), 
> sometimes after printing some diagnostic information. The problem is 
> that the caller will attempt to soldier on with the illegal return 
> value and will stumble over something later, such as 
> NullPointerException or IllegalArgumentException. This will probably 
> be obvious but it's equally likely to be confusing.
>
> Since these utilities are all called from test code, and the tests are 
> relying on them to return valid results, I'd suggest just throwing 
> exceptions from the utility methods if they fail. This will (should) 
> cause the test to error out, but that's OK, as it never could have 
> succeeded anyway if the utility call had failed.
I already modified createRegistryOnUnusedPort to throw an exception as 
part of the MultipleRegistries change.  I'm now throwing a 
RuntimeException for getRegistryPort and getUnusedRandomPort if they fail.

See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03

Darryl
>
> s'marks
>
>
>
> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 
>> 7161503.
>> Webrev can be found here: 
>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>> This commit fixes concurrency issues with the RMI tests.
>>
>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>> RMIRegistry on an unused port. It will try up to 10 times before 
>> giving up.
>> - Added a TestLibrary.getRegistryPort(Registry) method to get the 
>> port number
>> of the registry.
>> - Changed almost all tests from using hard port numbers to using 
>> random port
>> numbers for running the RMI Registry and RMID.
>> - Removed othervm from those tests which don't need it.
>> - Added parameters for tests which spawn a separate VM to pass RMI 
>> Registry and
>> RMID ports in cases where needed.
>> - Added PropertyPermission to security policy files where needed.
>> - Removed java/rmi and sun/rmi from tests which cannot be run 
>> concurrently.
>> - Added java/rmi/Naming to list of tests which cannot be run 
>> concurrently.
>>
>> Thanks,
>> Darryl
>>




From darryl.mocek at oracle.com  Tue Jul 10 21:17:07 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Tue, 10 Jul 2012 14:17:07 -0700
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FFC9624.7060403@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFBD05E.5020307@oracle.com> <4FFBD235.3080005@oracle.com>
	<4FFC9624.7060403@oracle.com>
Message-ID: <4FFC9BD3.80204@oracle.com>

I think pushing what we have now and doing the cleanup after to get the 
RMI test changes in is the best approach.

Darryl

On 07/10/2012 01:52 PM, Stuart Marks wrote:
> On 7/9/12 11:56 PM, Olivier Lagneau wrote:
>> Le 10/07/2012 08:49, Olivier Lagneau a ?crit :
>>> Now in the 7161503 SetChilEnv case:
>>>>
>>> I think we should just revert to the existing code regarding the
>>> DebugExecWatcher and related exception cleanup fix.
>>> We must then accept to keep this exception raised each time 
>>> runwith() is
>>> called, since this is the current state of the code.
>>> We should also then include in bug description a note stating the 
>>> problem and
>>> how we can fix it.
>>> Such a fix would then be part of recent 7168267.
>
> Hi Olivier,
>
> Thanks for taking time from your vacation to answer this.
>
> I'm sure I don't have all the background on this (and I don't really 
> need to know everything) but from what I recall from talking to 
> Darryl, 7142596 introduced a test failure that would have to go onto 
> the problem list; and then 7161503 would fix the failure and then 
> remove it from the problem list.
>
> Instead of fixing these separately we (at least Darryl and I) thought 
> it would be best to merge them together.
>
> Now, I had pointed out some issues with the changes to the SetChildEnv 
> test. My main concern is that we don't push the changes as-is and then 
> declare things to be done. If there's further discussion, design, or 
> cleanup to be done, great, we can push the current changes and 
> continue working on a followup changeset. If there's a bugid to track 
> this (probably 7161503) so much the better.
>
> If you and Darryl agree to proceed differently, though, I'm fine with 
> that too.
>
> s'marks




From chris.hegarty at oracle.com  Tue Jul 10 21:17:55 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Jul 2012 22:17:55 +0100
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
In-Reply-To: <4FFC5A5B.2000009@oracle.com>
References: <4FFC5A5B.2000009@oracle.com>
Message-ID: <4FFC9C03.8040307@oracle.com>

Sean,

The backout approach seems reasonable, but I really don't like the test. 
It is racey and not guaranteed to consistently pass. I agree/approve the 
backout, but would prefer not to add the test in its current state.

-Chris.

On 10/07/2012 17:37, Se?n Coffey wrote:
>
> 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.
>


From sean.coffey at oracle.com  Tue Jul 10 22:36:04 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 10 Jul 2012 23:36:04 +0100
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
In-Reply-To: <4FFC9C03.8040307@oracle.com>
References: <4FFC5A5B.2000009@oracle.com> <4FFC9C03.8040307@oracle.com>
Message-ID: <4FFCAE54.7020402@oracle.com>

thanks for review Chris, I've no problem dropping the new testcase for 
now. I was just being extra diligent by adding one. I haven't seen the 
testcase fail incorrectly yet however. When you get time, maybe you can 
share tips on what's flaky in it!

I need one more reviewer since we're in critical approval request mode 
for 7u6 fixes.

regards,
Sean.

On 10/07/2012 22:17, Chris Hegarty wrote:
> Sean,
>
> The backout approach seems reasonable, but I really don't like the 
> test. It is racey and not guaranteed to consistently pass. I 
> agree/approve the backout, but would prefer not to add the test in its 
> current state.
>
> -Chris.
>
> On 10/07/2012 17:37, Se?n Coffey wrote:
>>
>> 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.
>>


From joe.darcy at oracle.com  Tue Jul 10 22:52:24 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Jul 2012 15:52:24 -0700
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
In-Reply-To: <4FFCAE54.7020402@oracle.com>
References: <4FFC5A5B.2000009@oracle.com> <4FFC9C03.8040307@oracle.com>
	<4FFCAE54.7020402@oracle.com>
Message-ID: <4FFCB228.9030409@oracle.com>

Hello,

I approve the original changeset being backed out.

Cheers,

-Joe

On 7/10/2012 3:36 PM, Se?n Coffey wrote:
> thanks for review Chris, I've no problem dropping the new testcase for 
> now. I was just being extra diligent by adding one. I haven't seen the 
> testcase fail incorrectly yet however. When you get time, maybe you 
> can share tips on what's flaky in it!
>
> I need one more reviewer since we're in critical approval request mode 
> for 7u6 fixes.
>
> regards,
> Sean.
>
> On 10/07/2012 22:17, Chris Hegarty wrote:
>> Sean,
>>
>> The backout approach seems reasonable, but I really don't like the 
>> test. It is racey and not guaranteed to consistently pass. I 
>> agree/approve the backout, but would prefer not to add the test in 
>> its current state.
>>
>> -Chris.
>>
>> On 10/07/2012 17:37, Se?n Coffey wrote:
>>>
>>> 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.
>>>


From xueming.shen at oracle.com  Tue Jul 10 23:11:10 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Jul 2012 16:11:10 -0700
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
Message-ID: <4FFCB68E.6000608@oracle.com>

Hi,

In JDK7,  the decoder and encoder implementation of most of our 
single-byte charsets
and UTF-8 charset are optimized to implement the internal interfce 
sun.nio.cs.ArrayDecoder/
Encoder to provide a fastpath for String.getBytes(...) and new 
String(byte[]...) operations. I
have an old blog regarding this optimization at

https://blogs.oracle.com/xuemingshen/entry/faster_new_string_bytes_cs

This rfe, as the followup for above changes, is to implement 
ArrayDe/Encoder for most
of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is the 
webrev

http://cr.openjdk.java.net/~sherman/7183053/webrev

The results of the "non -scientific" benchmark StrCodingBenchmarkDB 
running on client
and server vm on my linux machine are included in docs_c (client) and 
docs_s(server)
below.

http://cr.openjdk.java.net/~sherman/7183053/dbcs_c
http://cr.openjdk.java.net/~sherman/7183053/dbcs_s

Numbers are the time spent on the decoding/encoding operations, the 
smaller the
better.

Thanks,
-Sherman


From huizhe.wang at oracle.com  Wed Jul 11 05:59:33 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 10 Jul 2012 22:59:33 -0700
Subject: RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not IPv6
	enabled. It throws MalformedURLException
Message-ID: <4FFD1645.6000504@oracle.com>

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


From luchsh at linux.vnet.ibm.com  Wed Jul 11 06:07:25 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Wed, 11 Jul 2012 14:07:25 +0800
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FFB7D44.8010201@oracle.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com>
	<4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com>
Message-ID: <4FFD181D.3030709@linux.vnet.ibm.com>

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 at openjdk.java.net for a review? Sherman 
> (xueming.shen at 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>




From weijun.wang at oracle.com  Wed Jul 11 06:21:18 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 11 Jul 2012 14:21:18 +0800
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FFD181D.3030709@linux.vnet.ibm.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com>
	<4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com>
	<4FFD181D.3030709@linux.vnet.ibm.com>
Message-ID: <4FFD1B5E.2090208@oracle.com>

Mostly fine.

1. "import java.text.FieldPosition;" is not needed anymore.

2. In jar/Main, you can also consider creating a separate 
SimpleDateFormat object (maybe private final static?). It seems the 
initialization is quite heavy.

You recently became a jdk8 committer, right? That means you can do your 
own push but if you want to make any changes to the bug database, just 
tell me.

Thanks
Max

On 07/11/2012 02:07 PM, Jonathan Lu wrote:
> 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 at openjdk.java.net for a review? Sherman
>> (xueming.shen at 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From xueming.shen at oracle.com  Wed Jul 11 07:13:01 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 11 Jul 2012 00:13:01 -0700
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FFD1B5E.2090208@oracle.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com>
	<4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com>
	<4FFD181D.3030709@linux.vnet.ibm.com> <4FFD1B5E.2090208@oracle.com>
Message-ID: <4FFD277D.9050000@oracle.com>


As Max point out, you definitely need to avoid creating SDF everytime 
you have to
print out one entry. But I'm more worried about the fact you are 
changing the out
put of jar t. Jar is a widely used tool, It might be a surprise to 
someone who has code
depend on the current output format. Personally I would suggest not make 
this change
in jar tool.

-Sherman

On 7/10/2012 11:21 PM, Weijun Wang wrote:
> Mostly fine.
>
> 1. "import java.text.FieldPosition;" is not needed anymore.
>
> 2. In jar/Main, you can also consider creating a separate 
> SimpleDateFormat object (maybe private final static?). It seems the 
> initialization is quite heavy.
>
> You recently became a jdk8 committer, right? That means you can do 
> your own push but if you want to make any changes to the bug database, 
> just tell me.
>
> Thanks
> Max
>
> On 07/11/2012 02:07 PM, Jonathan Lu wrote:
>> 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 at openjdk.java.net for a review? Sherman
>>> (xueming.shen at 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From Alan.Bateman at oracle.com  Wed Jul 11 07:47:33 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 08:47:33 +0100
Subject: Native zlib libraries
In-Reply-To: <3427b874-8c8c-4e7b-b4ec-1b8055e80342@zmail17.collab.prod.int.phx2.redhat.com>
References: <3427b874-8c8c-4e7b-b4ec-1b8055e80342@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FFD2F95.90905@oracle.com>

On 05/07/2012 17:11, Andrew Hughes wrote:
>
> ----- Original Message -----
>> Is there a way to get the native zlib libraries to get picked up
>> instead of the hardcoded version within the JVM?
>>
>> --
>> Azeem Jiva
>> @javawithjiva
> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get it
> upstream.
>
> However, I don't see how this is related to HotSpot, as the zlib usage
> is in the jdk tree.
I think we need to (re)start the discussion on core-libs-dev with a view 
to eliminating the patches that the JDK has to zlib, see:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java

One of these changes relates to the zip64 support and I believe there 
are corner cases when inflating or deflating >2GB that won't work if 
using the system zlib. Sherman will likely recall the details. Given 
that the new build already supports using the system zlib (at least on 
Linux) then it would be good to sort this out so that it just works.

-Alan








From Alan.Bateman at oracle.com  Wed Jul 11 07:51:13 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 08:51:13 +0100
Subject: [8] Review request for 7162111 change tests run in headless mode
	[macosx]
In-Reply-To: <4FF1ADB1.9020508@oracle.com>
References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com>
	<4FE86576.8020407@oracle.com> <4FF1ADB1.9020508@oracle.com>
Message-ID: <4FFD3071.2030302@oracle.com>

On 02/07/2012 15:18, Jason Uh wrote:
> Anthony and Alan,
>
> Thanks for your comments. I've reverted the changes to CommonSetup.sh 
> so that XToolkit is no longer forced. Tests still pass.
>
> Please see the new webrev: 
> http://cr.openjdk.java.net/~juh/7162111/webrev.01/
>
> Thanks,
> Jason
This looks okay to me too. Do you have a sponsor for this? Also do you 
plan to get other tests working on the Mac in headless mode too? There 
are several serialization tests, at least one JMX tests and a couple of 
other random tests in a few of the core areas that run into the same issue.

-Alan.


From luchsh at linux.vnet.ibm.com  Wed Jul 11 07:56:09 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Wed, 11 Jul 2012 15:56:09 +0800
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FFD277D.9050000@oracle.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com>
	<4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com>
	<4FFD181D.3030709@linux.vnet.ibm.com>
	<4FFD1B5E.2090208@oracle.com> <4FFD277D.9050000@oracle.com>
Message-ID: <4FFD3199.7050909@linux.vnet.ibm.com>

Hello Sherman,

Thanks a lot for review!

I've made another patch to no include the changes for jar tool,
http://cr.openjdk.java.net/~luchsh/7163483_6/

And to Max,

Does it make sense for you to change jarSigner only?

best regards!

Jonathan

On 07/11/2012 03:13 PM, Xueming Shen wrote:
>
> As Max point out, you definitely need to avoid creating SDF everytime 
> you have to
> print out one entry. But I'm more worried about the fact you are 
> changing the out
> put of jar t. Jar is a widely used tool, It might be a surprise to 
> someone who has code
> depend on the current output format. Personally I would suggest not 
> make this change
> in jar tool.
>
> -Sherman
>
> On 7/10/2012 11:21 PM, Weijun Wang wrote:
>> Mostly fine.
>>
>> 1. "import java.text.FieldPosition;" is not needed anymore.
>>
>> 2. In jar/Main, you can also consider creating a separate 
>> SimpleDateFormat object (maybe private final static?). It seems the 
>> initialization is quite heavy.
>>
>> You recently became a jdk8 committer, right? That means you can do 
>> your own push but if you want to make any changes to the bug 
>> database, just tell me.
>>
>> Thanks
>> Max
>>
>> On 07/11/2012 02:07 PM, Jonathan Lu wrote:
>>> 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 at openjdk.java.net for a review? Sherman
>>>> (xueming.shen at 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>




From Alan.Bateman at oracle.com  Wed Jul 11 08:10:35 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 09:10:35 +0100
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FF732DA.9060704@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
Message-ID: <4FFD34FB.8020902@oracle.com>

On 06/07/2012 19:47, Stuart Marks wrote:
> :
>
>
> *** LookupNameWithColon.java
>
>
> This test is missing an @run tag, thus it won't actually get run! 
> Since you've specified an @build tag, you have to specify a separate 
> @run tag to run the test. It's possible to deduce this with a careful 
> reading of the jtreg tag spec:
>
> http://openjdk.java.net/jtreg/tag-spec.txt
>
> (IMHO this is a terrible usability problem.) I've looked at the other 
> tests in this webrev for similar issues, and I didn't see any, but I 
> might have missed them.
Yes, very easy to make that mistake. As there only have a tiny @build 
only tests in the jdk repository then we should be able to automate 
finding these issues, the information is already in the report.

FYI, we fixed several of these a few months ago, see:

http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d934b1d9dd5

-Alan


From xueming.shen at oracle.com  Wed Jul 11 08:19:13 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 11 Jul 2012 01:19:13 -0700
Subject: Native zlib libraries
In-Reply-To: <4FFD2F95.90905@oracle.com>
References: <3427b874-8c8c-4e7b-b4ec-1b8055e80342@zmail17.collab.prod.int.phx2.redhat.com>
	<4FFD2F95.90905@oracle.com>
Message-ID: <4FFD3701.3060100@oracle.com>

The zip64 support (total_in/out) part probably can be done at Java level 
(ignore
the total_in/out in z_tream_s).  Need to remove this dependency. Will 
take a look later.

-Sherman

On 7/11/2012 12:47 AM, Alan Bateman wrote:
> On 05/07/2012 17:11, Andrew Hughes wrote:
>>
>> ----- Original Message -----
>>> Is there a way to get the native zlib libraries to get picked up
>>> instead of the hardcoded version within the JVM?
>>>
>>> -- 
>>> Azeem Jiva
>>> @javawithjiva
>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get it
>> upstream.
>>
>> However, I don't see how this is related to HotSpot, as the zlib usage
>> is in the jdk tree.
> I think we need to (re)start the discussion on core-libs-dev with a 
> view to eliminating the patches that the JDK has to zlib, see:
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java 
>
>
> One of these changes relates to the zip64 support and I believe there 
> are corner cases when inflating or deflating >2GB that won't work if 
> using the system zlib. Sherman will likely recall the details. Given 
> that the new build already supports using the system zlib (at least on 
> Linux) then it would be good to sort this out so that it just works.
>
> -Alan
>
>
>
>
>
>


From Alan.Bateman at oracle.com  Wed Jul 11 08:18:44 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 09:18:44 +0100
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FF60595.3020607@oracle.com>
References: <4FF60595.3020607@oracle.com>
Message-ID: <4FFD36E4.7040106@oracle.com>

On 05/07/2012 22:22, Darryl Mocek wrote:
> Hello core-libs.  Please review this webrev to fix Bugs #7142596 and 
> 7161503.  Webrev can be found here: 
> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02. This commit 
> fixes concurrency issues with the RMI tests.
>
> - Added TestLibrary.createRegistryOnUnusedPort method.  This creates 
> an RMIRegistry on an unused port. It will try up to 10 times before 
> giving up.
> - Added a TestLibrary.getRegistryPort(Registry) method to get the port 
> number of the registry.
I don't have cycles to review this in any detail but what is the reason 
for the "try up to 10 times". I thought the plan was to just use 
LocateRegistry.createRegistry(0) and so use an ephemeral port.

Also one idea is to do:

public class TestRegistry extends Registry {
     public static TestRegistry create() { ... }
     public int port() { ... }
     :
}

so that the tests can simply do:

TestRegistry reg = TestRegistry.create();

and then use reg.port() instead of TestLibrary.getRegistryPort 
everywhere. It amounts to the same thing but may be a bit neater.

-Alan.


From weijun.wang at oracle.com  Wed Jul 11 08:22:13 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 11 Jul 2012 16:22:13 +0800
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FFD3199.7050909@linux.vnet.ibm.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com>
	<4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com>
	<4FFD181D.3030709@linux.vnet.ibm.com>
	<4FFD1B5E.2090208@oracle.com> <4FFD277D.9050000@oracle.com>
	<4FFD3199.7050909@linux.vnet.ibm.com>
Message-ID: <4FFD37B5.6060204@oracle.com>



On 07/11/2012 03:56 PM, Jonathan Lu wrote:
> Hello Sherman,
>
> Thanks a lot for review!
>
> I've made another patch to no include the changes for jar tool,
> http://cr.openjdk.java.net/~luchsh/7163483_6/
>
> And to Max,
>
> Does it make sense for you to change jarSigner only?

I don't think so.

My understanding is that if we want to make a change, we should change 
both. Otherwise, neither. Jar is much more widely used, so people read 
the jar output much more than jarsigner. This bug is about whether the 
"locale correctness" is more important than compatibility, and I think 
the answer applies to both tools. If a user is OK with the jar output, I 
see no reason why he/she cannot tolerate the jarsigner output.

Is there a business case?

Thanks
Max


>
> best regards!
>
> Jonathan
>
> On 07/11/2012 03:13 PM, Xueming Shen wrote:
>>
>> As Max point out, you definitely need to avoid creating SDF everytime
>> you have to
>> print out one entry. But I'm more worried about the fact you are
>> changing the out
>> put of jar t. Jar is a widely used tool, It might be a surprise to
>> someone who has code
>> depend on the current output format. Personally I would suggest not
>> make this change
>> in jar tool.
>>
>> -Sherman
>>
>> On 7/10/2012 11:21 PM, Weijun Wang wrote:
>>> Mostly fine.
>>>
>>> 1. "import java.text.FieldPosition;" is not needed anymore.
>>>
>>> 2. In jar/Main, you can also consider creating a separate
>>> SimpleDateFormat object (maybe private final static?). It seems the
>>> initialization is quite heavy.
>>>
>>> You recently became a jdk8 committer, right? That means you can do
>>> your own push but if you want to make any changes to the bug
>>> database, just tell me.
>>>
>>> Thanks
>>> Max
>>>
>>> On 07/11/2012 02:07 PM, Jonathan Lu wrote:
>>>> 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 at openjdk.java.net for a review? Sherman
>>>>> (xueming.shen at 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>



From weijun.wang at oracle.com  Wed Jul 11 09:14:19 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 11 Jul 2012 09:14:19 +0000
Subject: hg: jdk8/tl/jdk: 6966259: Make PrincipalName and Realm immutable
Message-ID: <20120711091601.75D4147F60@hg.openjdk.java.net>

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



From Alan.Bateman at oracle.com  Wed Jul 11 10:43:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 11:43:02 +0100
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
In-Reply-To: <4FFC5A5B.2000009@oracle.com>
References: <4FFC5A5B.2000009@oracle.com>
Message-ID: <4FFD58B6.4040806@oracle.com>

On 10/07/2012 17:37, Se?n Coffey wrote:
>
> 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.
I think the changes for 7105952 are okay, it's just that they have 
exposed an issue with java.net.Socket's getInputStream and 
getOutputStream methods. These methods should really be changed to that 
they only create one InputStream or OutputStream per Socket, not a 
stream connected to the FileDescriptor for each call to getInputStream 
or getOutputStream. Clearly changing this would involve a subtle 
behavior change so it may be better off to keep that for a major release 
(meaning 8).

On weak references then this isn't going to work for FileInputStream or 
FileOutputStream because their finalize methods are specified to close 
the stream. This topic has a long history with several attempts to fix 
all the issues going back over several releases.

As regards 7u6 then changing java.net.Socket is too risky to do this 
late in the release so I agree with your proposal to back-out  7105952. 
It's probably best to create a separate bug for this so that the history 
is easy to understand. We can then use 7181793 to fix java.net.Socket in 
jdk8 (and maybe a future 7u). To keep things simple then I think the 
change to anti-delta the fix should be just that and shouldn't be 
complicated at adding in a new test. The fix for 7105952 can introduce 
additional tests for this area.

-Alan.


From sean.coffey at oracle.com  Wed Jul 11 11:07:36 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 11 Jul 2012 12:07:36 +0100
Subject: Request for review : 7181793 FileDescriptor keeps its own hard
	reference to Closeables causing a memory leak
In-Reply-To: <4FFD58B6.4040806@oracle.com>
References: <4FFC5A5B.2000009@oracle.com> <4FFD58B6.4040806@oracle.com>
Message-ID: <4FFD5E78.8030406@oracle.com>

>
> As regards 7u6 then changing java.net.Socket is too risky to do this 
> late in the release so I agree with your proposal to back-out  
> 7105952. It's probably best to create a separate bug for this so that 
> the history is easy to understand. We can then use 7181793 to fix 
> java.net.Socket in jdk8 (and maybe a future 7u). To keep things simple 
> then I think the change to anti-delta the fix should be just that and 
> shouldn't be complicated at adding in a new test. The fix for 7105952 
> can introduce additional tests for this area. 
I just logged a new CR to track the backout change Alan.
CR 7183209 : Backout 7105952 changes for jdk7u

Regards,
Sean.

On 11/07/12 11:43, Alan Bateman wrote:
> On 10/07/2012 17:37, Se?n Coffey wrote:
>>
>> 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.
> I think the changes for 7105952 are okay, it's just that they have 
> exposed an issue with java.net.Socket's getInputStream and 
> getOutputStream methods. These methods should really be changed to 
> that they only create one InputStream or OutputStream per Socket, not 
> a stream connected to the FileDescriptor for each call to 
> getInputStream or getOutputStream. Clearly changing this would involve 
> a subtle behavior change so it may be better off to keep that for a 
> major release (meaning 8).
>
> On weak references then this isn't going to work for FileInputStream 
> or FileOutputStream because their finalize methods are specified to 
> close the stream. This topic has a long history with several attempts 
> to fix all the issues going back over several releases.
>
> As regards 7u6 then changing java.net.Socket is too risky to do this 
> late in the release so I agree with your proposal to back-out  
> 7105952. It's probably best to create a separate bug for this so that 
> the history is easy to understand. We can then use 7181793 to fix 
> java.net.Socket in jdk8 (and maybe a future 7u). To keep things simple 
> then I think the change to anti-delta the fix should be just that and 
> shouldn't be complicated at adding in a new test. The fix for 7105952 
> can introduce additional tests for this area.
>
> -Alan.




From Alan.Bateman at oracle.com  Wed Jul 11 12:21:21 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 13:21:21 +0100
Subject: classlist.* and jar_reorder ?
In-Reply-To: <4FF29742.2040204@oracle.com>
References: <4FF29742.2040204@oracle.com>
Message-ID: <4FFD6FC1.10708@oracle.com>

On 03/07/2012 07:54, David Holmes wrote:
> 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
There's a README in make/tools/sharing that outlines how the lists are 
created. It's basically a set of benchmarks that are run with 
-verbose:class and the list of classes is used to create the classlist.* 
files. At install time then -Xshare:dump loads this set of classes when 
creating the shared archive. I don't know how jre_reorder is used but I 
see Kelly has replied on that.

-Alan.


From mala.bankal at oracle.com  Wed Jul 11 12:44:39 2012
From: mala.bankal at oracle.com (Mala Bankal)
Date: Wed, 11 Jul 2012 18:14:39 +0530
Subject: Request for approval for bug# 7175845 - "jar uf" changes file
	permissions unexpectedly
Message-ID: <4FFD7537.6010105@oracle.com>

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






From Alan.Bateman at oracle.com  Wed Jul 11 12:45:01 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Jul 2012 13:45:01 +0100
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FEA304E.7080503@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
Message-ID: <4FFD754D.3010804@oracle.com>

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.



From mala.bankal at oracle.com  Wed Jul 11 12:48:13 2012
From: mala.bankal at oracle.com (Mala Bankal)
Date: Wed, 11 Jul 2012 18:18:13 +0530
Subject: Request for approval for bug# 7177216 - native2ascii changes file
	permissions of input file
Message-ID: <4FFD760D.1050803@oracle.com>

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


From olivier.lagneau at oracle.com  Wed Jul 11 15:16:36 2012
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Wed, 11 Jul 2012 17:16:36 +0200
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FFC9624.7060403@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFBD05E.5020307@oracle.com> <4FFBD235.3080005@oracle.com>
	<4FFC9624.7060403@oracle.com>
Message-ID: <4FFD98D4.4030705@oracle.com>

Stuart Marks said  on date 7/10/2012 10:52 PM:
> On 7/9/12 11:56 PM, Olivier Lagneau wrote:
>> Le 10/07/2012 08:49, Olivier Lagneau a ?crit :
>>> Now in the 7161503 SetChilEnv case:
>>>>
>>> I think we should just revert to the existing code regarding the
>>> DebugExecWatcher and related exception cleanup fix.
>>> We must then accept to keep this exception raised each time 
>>> runwith() is
>>> called, since this is the current state of the code.
>>> We should also then include in bug description a note stating the 
>>> problem and
>>> how we can fix it.
>>> Such a fix would then be part of recent 7168267.
>
> Hi Olivier,
>
> Thanks for taking time from your vacation to answer this.
>
> I'm sure I don't have all the background on this (and I don't really 
> need to know everything) but from what I recall from talking to 
> Darryl, 7142596 introduced a test failure that would have to go onto 
> the problem list; and then 7161503 would fix the failure and then 
> remove it from the problem list.
Yes that's it.
>
> Instead of fixing these separately we (at least Darryl and I) thought 
> it would be best to merge them together.
Sure I completely agree with this since 7161503 is a subpart of 7142596
>
> Now, I had pointed out some issues with the changes to the SetChildEnv 
> test. My main concern is that we don't push the changes as-is and then 
> declare things to be done.
I am ok with this too.
> If there's further discussion, design, or cleanup to be done, great, 
> we can push the current changes and continue working on a followup 
> changeset. If there's a bugid to track this (probably 7161503) so much 
> the better.
I will prepare quickly a patch fixing and suppressing DebugExecWatcher 
class (the fix I exposed previously).
We should discuss tomorrow by phone with Darryl on amother subject, we 
will add that to the agenda and sync together on the way to proceed
(wether or not we use the same bug id )

Thanks,
Olivier

>
> If you and Darryl agree to proceed differently, though, I'm fine with 
> that too.
>
> s'marks



From olivier.lagneau at oracle.com  Wed Jul 11 16:16:51 2012
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Wed, 11 Jul 2012 18:16:51 +0200
Subject: Code Review Request (7161503 subcase) 7142596: RMI JPRT tests
	are failing
In-Reply-To: <4FFC9BD3.80204@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FF732DA.9060704@oracle.com>
	<4FFBD05E.5020307@oracle.com> <4FFBD235.3080005@oracle.com>
	<4FFC9624.7060403@oracle.com> <4FFC9BD3.80204@oracle.com>
Message-ID: <4FFDA6F3.6050403@oracle.com>

Darryl Mocek said  on date 7/10/2012 11:17 PM:
> I think pushing what we have now and doing the cleanup after to get 
> the RMI test changes in is the best approach.
I am ok with that approach Darryl.

Olivier.
>
> Darryl
>
> On 07/10/2012 01:52 PM, Stuart Marks wrote:
>> On 7/9/12 11:56 PM, Olivier Lagneau wrote:
>>> Le 10/07/2012 08:49, Olivier Lagneau a ?crit :
>>>> Now in the 7161503 SetChilEnv case:
>>>>>
>>>> I think we should just revert to the existing code regarding the
>>>> DebugExecWatcher and related exception cleanup fix.
>>>> We must then accept to keep this exception raised each time 
>>>> runwith() is
>>>> called, since this is the current state of the code.
>>>> We should also then include in bug description a note stating the 
>>>> problem and
>>>> how we can fix it.
>>>> Such a fix would then be part of recent 7168267.
>>
>> Hi Olivier,
>>
>> Thanks for taking time from your vacation to answer this.
>>
>> I'm sure I don't have all the background on this (and I don't really 
>> need to know everything) but from what I recall from talking to 
>> Darryl, 7142596 introduced a test failure that would have to go onto 
>> the problem list; and then 7161503 would fix the failure and then 
>> remove it from the problem list.
>>
>> Instead of fixing these separately we (at least Darryl and I) thought 
>> it would be best to merge them together.
>>
>> Now, I had pointed out some issues with the changes to the 
>> SetChildEnv test. My main concern is that we don't push the changes 
>> as-is and then declare things to be done. If there's further 
>> discussion, design, or cleanup to be done, great, we can push the 
>> current changes and continue working on a followup changeset. If 
>> there's a bugid to track this (probably 7161503) so much the better.
>>
>> If you and Darryl agree to proceed differently, though, I'm fine with 
>> that too.
>>
>> s'marks
>
>



From wasserman.louis at gmail.com  Wed Jul 11 22:05:22 2012
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Wed, 11 Jul 2012 23:05:22 +0100
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
Message-ID: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>

Not entirely sure I'm posting this in the right place, but it looks like
it...

This is a patch to optimize BigInteger.doubleValue() and floatValue(),
which are both currently implemented by converting to a string and back.

Doing it with bit-twiddling and Double.longBitsToDouble improves the speed
of those methods by something like two orders of magnitude in my benchmarks.

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis

From kurchi.subhra.hazra at oracle.com  Wed Jul 11 23:15:00 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Wed, 11 Jul 2012 16:15:00 -0700
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FFD754D.3010804@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com>
Message-ID: <4FFE08F4.6080306@oracle.com>

Thanks for the review Alan. Updated webrev:
http://cr.openjdk.java.net/~khazra/7160252/webrev.01/

- 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.
>



From chris.hegarty at oracle.com  Wed Jul 11 23:24:20 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Jul 2012 00:24:20 +0100
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FFE08F4.6080306@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com> <4FFE08F4.6080306@oracle.com>
Message-ID: <06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>


On 12 Jul 2012, at 00:15, Kurchi Hazra <kurchi.subhra.hazra at 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?

-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.
>> 
> 


From kurchi.subhra.hazra at oracle.com  Wed Jul 11 23:45:04 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Wed, 11 Jul 2012 16:45:04 -0700
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com> <4FFE08F4.6080306@oracle.com>
	<06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>
Message-ID: <4FFE1000.5000305@oracle.com>

On 7/11/12 4:24 PM, Chris Hegarty wrote:
> On 12 Jul 2012, at 00:15, Kurchi Hazra<kurchi.subhra.hazra at 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.
>>>



From chris.hegarty at oracle.com  Thu Jul 12 06:31:59 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Jul 2012 07:31:59 +0100
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
Message-ID: <kf1d7501hwen5bng3nu9mv6w.1342074719987@email.android.com>

Thanks Kurchi, looks fine.

-Chris

Kurchi Hazra <kurchi.subhra.hazra at 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 at 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.
>>>>
>

From aph at redhat.com  Thu Jul 12 06:58:22 2012
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Jul 2012 07:58:22 +0100
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
In-Reply-To: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
References: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
Message-ID: <4FFE758E.1000003@redhat.com>

On 07/11/2012 11:05 PM, Louis Wasserman wrote:
> Doing it with bit-twiddling and Double.longBitsToDouble improves the speed
> of those methods by something like two orders of magnitude in my benchmarks.

Mmm, but that's going to hit double-rounding bugs for large numbers.  Where
is this patch, anyway?

Andrew.


From Alan.Bateman at oracle.com  Thu Jul 12 07:16:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Jul 2012 08:16:25 +0100
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FFE1000.5000305@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com> <4FFE08F4.6080306@oracle.com>
	<06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>
	<4FFE1000.5000305@oracle.com>
Message-ID: <4FFE79C9.80405@oracle.com>

On 12/07/2012 00:45, Kurchi Hazra wrote:
> On 7/11/12 4:24 PM, Chris Hegarty wrote:
>> On 12 Jul 2012, at 00:15, Kurchi 
>> Hazra<kurchi.subhra.hazra at 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/
Looks fine except that the test case is missing from latest webrev. 
Assuming that test/java/util/prefs/AddNodeChangeListener.java hasn't 
changed from the original webrev then I think you are all set to push.

-Alan.


From wasserman.louis at gmail.com  Thu Jul 12 09:32:49 2012
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Thu, 12 Jul 2012 10:32:49 +0100
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
In-Reply-To: <4FFE758E.1000003@redhat.com>
References: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
	<4FFE758E.1000003@redhat.com>
Message-ID: <CA+tXMXOC1wSrjrY3oGXcrGeAmMoMzj_w7b9cWszoXxJCuuiptQ@mail.gmail.com>

It was attached to the previous message?  I don't know if this list works
with attachments.  Alternately, the patch was attached here:
https://bugs.openjdk.java.net/show_bug.cgi?id=100222

I'm not sure what you mean by double-rounding bugs, though.  It's not
difficult to actually implement the HALF_EVEN rounding behavior with bit
twiddling.  That said, I *did* encounter places where prior erroneous
behavior (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6358355) of
Float.parseFloat caused my correct implementation to fail tests...

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis


On Thu, Jul 12, 2012 at 7:58 AM, Andrew Haley <aph at redhat.com> wrote:

> On 07/11/2012 11:05 PM, Louis Wasserman wrote:
> > Doing it with bit-twiddling and Double.longBitsToDouble improves the
> speed
> > of those methods by something like two orders of magnitude in my
> benchmarks.
>
> Mmm, but that's going to hit double-rounding bugs for large numbers.  Where
> is this patch, anyway?
>
> Andrew.
>


From paul.sandoz at Oracle.com  Thu Jul 12 09:42:04 2012
From: paul.sandoz at Oracle.com (Paul Sandoz)
Date: Thu, 12 Jul 2012 11:42:04 +0200
Subject: RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not IPv6
	enabled. It throws MalformedURLException
In-Reply-To: <4FFD1645.6000504@oracle.com>
References: <4FFD1645.6000504@oracle.com>
Message-ID: <21D7CE22-3B91-40E2-9FBE-688214BC8EEB@Oracle.com>

Hi Joe,

On Jul 11, 2012, at 7:59 AM, Joe Wang wrote:

> 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/
> 

Looks OK to me. Note i am not an official reviewer, yet! so please don't commit cause i thought it looked OK ;-)

Paul.

From aph at redhat.com  Thu Jul 12 10:21:15 2012
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Jul 2012 11:21:15 +0100
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
In-Reply-To: <CA+tXMXOC1wSrjrY3oGXcrGeAmMoMzj_w7b9cWszoXxJCuuiptQ@mail.gmail.com>
References: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
	<4FFE758E.1000003@redhat.com>
	<CA+tXMXOC1wSrjrY3oGXcrGeAmMoMzj_w7b9cWszoXxJCuuiptQ@mail.gmail.com>
Message-ID: <4FFEA51B.4030107@redhat.com>

On 07/12/2012 10:32 AM, Louis Wasserman wrote:
> It was attached to the previous message?  I don't know if this list works
> with attachments.  Alternately, the patch was attached here:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100222
> 
> I'm not sure what you mean by double-rounding bugs, though.  It's
> not difficult to actually implement the HALF_EVEN rounding behavior
> with bit twiddling.

Sure, as long as you've thought about it and done it carefully.  The
bit twiddling is easy to do, and easy to get wrong.

>From the supplied patch it looks like you've done a good job, but
there was no way to tell without it.  I presume the listserv dropped
it on the floor.

Andrew.


From Lance.Andersen at oracle.com  Thu Jul 12 10:55:29 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 12 Jul 2012 06:55:29 -0400
Subject: RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not IPv6
	enabled. It throws MalformedURLException
In-Reply-To: <21D7CE22-3B91-40E2-9FBE-688214BC8EEB@Oracle.com>
References: <4FFD1645.6000504@oracle.com>
	<21D7CE22-3B91-40E2-9FBE-688214BC8EEB@Oracle.com>
Message-ID: <5E3DE447-978F-4A72-8DFE-19800F0C33D7@oracle.com>

+1

Best
Lance
On Jul 12, 2012, at 5:42 AM, Paul Sandoz wrote:

> Hi Joe,
> 
> On Jul 11, 2012, at 7:59 AM, Joe Wang wrote:
> 
>> 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/
>> 
> 
> Looks OK to me. Note i am not an official reviewer, yet! so please don't commit cause i thought it looked OK ;-)
> 
> Paul.


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From wasserman.louis at gmail.com  Thu Jul 12 13:15:16 2012
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Thu, 12 Jul 2012 14:15:16 +0100
Subject: [PATCH] Sunbug 6358355: Rounding error in Float.parseFloat
Message-ID: <CA+tXMXPeKPEPuu-fRyeov+kg=rjHkUz3oUNScH=wSFnJXVVp3A@mail.gmail.com>

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 at gmail.com
http://profiles.google.com/wasserman.louis

From kurchi.subhra.hazra at oracle.com  Thu Jul 12 14:55:31 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Thu, 12 Jul 2012 07:55:31 -0700
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FFE79C9.80405@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com> <4FFE08F4.6080306@oracle.com>
	<06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>
	<4FFE1000.5000305@oracle.com> <4FFE79C9.80405@oracle.com>
Message-ID: <4FFEE563.6020908@oracle.com>

I used a new workspace and missed adding it to mercurial. The test 
remains the same,
I'll push it after adding the test.

- Kurchi

On 7/12/12 12:16 AM, Alan Bateman wrote:
> On 12/07/2012 00:45, Kurchi Hazra wrote:
>> On 7/11/12 4:24 PM, Chris Hegarty wrote:
>>> On 12 Jul 2012, at 00:15, Kurchi 
>>> Hazra<kurchi.subhra.hazra at 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/
> Looks fine except that the test case is missing from latest webrev. 
> Assuming that test/java/util/prefs/AddNodeChangeListener.java hasn't 
> changed from the original webrev then I think you are all set to push.
>
> -Alan.



From huizhe.wang at oracle.com  Thu Jul 12 17:50:03 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 12 Jul 2012 10:50:03 -0700
Subject: RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not
	IPv6 enabled. It throws MalformedURLException
In-Reply-To: <5E3DE447-978F-4A72-8DFE-19800F0C33D7@oracle.com>
References: <4FFD1645.6000504@oracle.com>
	<21D7CE22-3B91-40E2-9FBE-688214BC8EEB@Oracle.com>
	<5E3DE447-978F-4A72-8DFE-19800F0C33D7@oracle.com>
Message-ID: <4FFF0E4B.9090304@oracle.com>

Lance, Paul,

Thanks!

Joe

On 7/12/2012 3:55 AM, Lance Andersen - Oracle wrote:
> +1
>
> Best
> Lance
> On Jul 12, 2012, at 5:42 AM, Paul Sandoz wrote:
>
>> Hi Joe,
>>
>> On Jul 11, 2012, at 7:59 AM, Joe Wang wrote:
>>
>>> 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/
>>>
>> Looks OK to me. Note i am not an official reviewer, yet! so please don't commit cause i thought it looked OK ;-)
>>
>> Paul.
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>


From stuart.marks at oracle.com  Fri Jul 13 00:13:59 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Jul 2012 17:13:59 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFC9B4F.1060200@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com>
Message-ID: <4FFF6847.3020701@oracle.com>

OK, I took a look at the revised webrev. Most stuff is good. A couple changes 
are necessary though.


*** MultipleRegistries.java


Not a big deal, but the comment at lines 65-67 is no longer necessary.


*** TestLibrary.java


I think the reserved port range stuff still needs to be fixed up.

The comment at lines 81-82 talks about a range 64000-64100 which isn't really 
present anywhere. The comment should instead say that PORT_MIN and PORT_MAX 
should be kept adjusted so that they specify the range of ports defined by the 
constants following. Make sure to do this adjustment; PORT_MAX is 64002 here.

The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000 as 
the *allowed* range for ports returned by getUnusedRandomPort(). But as I 
described previously, this is difficult to enforce given the varying port 
allocation schemes on different OSes.

Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX and 
make it be the range of ports reserved by tests that require fixed ports (64001 
through 64005). Then, getUnusedRandomPort() needs to be changed to *disallow* 
ports in this range, that is, to retry if the port is within this range. Thus 
the condition on the while-loop has to be inverted, something like

     while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= PORT_MAX)

So, how could getUnusedRandomPort() have worked in its present state? Well I 
think it ends up retrying 10 times, then at the end of the loop 
unusedRandomPort is actually some legal port number -- albeit possibly one 
within the disallowed range -- and almost certainly not -1, and so the method 
returns it and the caller uses it. So, the success-testing logic here will also 
have to change so that it retests whether the port is in the disallowed range.

The comment on getUnusedRandomPort() also needs to be updated to reflect its 
new policy on the reserved range, as well as throwing an exception on failure. 
Also (nitpick) it should say "less than" not "less then".

Looking at getUnusedRandomPort() again more closely [sorry] I think the catch 
of Exception that does nothing is suspicious. I'm not sure why getting a 
ServerSocket would fail, but if it does (maybe the system is out of ports??) we 
should just throw out to the caller. Perhaps ideally we'd just have this method 
throw IOException, but if that requires all callers to be updated, it might be 
easier just to catch IOException and throw a RuntimeException that wraps the 
caught IOException.

Similar comments apply to the catch(Exception)/do-nothing code in the other 
utility methods.

Certainly getRegistryPort() should just throw (or possibly wrap and rethrow) 
any exception caught.

For createRegistryOnUnusedPort(), the catching of ExportException is handled 
properly. The second catch clause of the outer try-block, and the catch of the 
inner try-block, both ignore exceptions. The code will then end up retrying. Is 
it reasonable that retrying in these cases will result in a different outcome? 
My guess is that it's more likely that something is seriously wrong that will 
cause all the retries to fail, in which case this method will discard the 
exceptions it has just caught and throw a *new* RemoteException instance.

I'm particularly sensitive to this; as you might recall a couple weeks ago I 
was having a wrestling match with the jstatd tests (I finished the match, but 
I'm not sure I won). The primary problem was that several layers of code would 
catch and discard exceptions, which made diagnosing the problem incredibly 
difficult. So, I'd recommend removing the "do nothing" catch clauses.

Thinking further about createRegistryOnUnusedPort(), I'm not sure that retrying 
10 (or some other number of times) actually makes sense. It does for 
getUnusedRandomPort(), which has to retry in order to get a port outside the 
disallowed range. But for creating a registry, createRegistry(0) will usually 
work the first time. If it throws ExportException, it does so for a specific 
reason, so we should retry once on an unused random port. But if this still 
fails, don't think retrying repeatedly makes sense.

s'marks




On 7/10/12 2:14 PM, Darryl Mocek wrote:
>
> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>> OK, here's the review for the second half of the files in the webrev. I saw
>> your reply to the first half (to which I'll reply separately), and I don't
>> think there's anything here that's affected by them.
>>
>>
>> *** AppleUserImpl.java
>> *** ApplicationServer.java
>>
>>
>> REGISTRY_PORT should be a local variable; also rename to use mixed case.
> Changed to a private registryPort (see next issue).
>>
>> Eh, whoops, after looking at ApplicationServer.java I see that it accesses
>> the REGISTRY_PORT field directly. This is why direct field access is a bad
>> idea. :-) Now the question is, has REGISTRY_PORT been initialized before
>> ApplicationServer needs it? It turns out that it has been -- but only in some
>> cases.
>>
>> It seems like the test is trying to support two modes, one that runs in two
>> threads in the same JVM, and the other that runs in two separate JVMs. If
>> they are in separate JVMs, things will no longer work because in the JVM that
>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be -1. I
>> suspect that our test environment doesn't support the separate JVM mode, but
>> it seems unwise to break it.
>>
>> I'd suggest that in two-JVM mode the classes fall back to using a
>> "well-known" default registry port number, which in this case seems like 2006.
>>
>> In single-JVM mode, AppleUserImpl creates an instance of ApplicationServer,
>> so I'd suggest adding a method to ApplicationServer that allows AppleUserImpl
>> to store the randomly-assigned registry port number into it, overriding the
>> default value.
>>
>> This seems like this is the simplest way to preserve the two modes of
>> operation but to support the random port selection model we're trying to
>> achieve.
> Rather then going the "fixed port" route, which is what we're trying to get
> away from, I've changed the implementation of both AppletUserImpl's and
> ApplicationServer so ApplicationServer requires a port and AppleUserImpl
> supplies the port on construction of ApplicationServer. I thought of modifying
> ApplicationServer's constructor to create a port using
> TestLibrary.getUnusedRandomPort, but decided requiring a port is better as
> ApplicationServer's job is to look for already exported AppleUser objects.
>>
>>
>> *** activatable/EchoImpl.java
>>
>>
>> int registryPort = new Integer(System.getProperty("rmi.registry.port"));
>>
>> I'd suggest using Integer.parseInt() instead of new Integer(). Not a huge
>> deal, but it's probably more conventional to use parseInt() and it avoids
>> boxing.
>>
>> One could probably do Integer.getInteger("rmi.registry.port") but this is
>> seems pretty obscure to me even though it's more succinct.
>>
>> The same also applies to the following:
>> - HelloImpl.java
>> - unicast/EchoImpl.java
>> - ShutdownImpl.java
>> - SelfTerminator.java
>> - CheckFQDNClient.java
>> - LeaseLeakClient.java
>> - dgcDeadLock/TestImpl.java
>>
> Integer.parseInt returns a primitive (which is what the return is assigned to)
> and it appears Integer.parseInt is "faster" then creating a new Integer.
> Changed to Integer.parseInt in all places referenced.
>>
>> *** FiniteGCLatency.java
>>
>>
>> The pattern here is a bit odd, as the test creates the registry, throws away
>> the returned reference, and then calls getRegistry() to get another Registry
>> reference. It *seems* like they're identical references, but in fact the
>> first is apparently a reference to the actual Registry implementation,
>> whereas the second is a remote stub.
>>
>> The tests seem to do all the actual work using the remote stub, which seems
>> proper.
>>
>> This is confusing, though, as it looks like there's a redundant Registry
>> reference now. This might lead someone in the future to "simplify" the test
>> by not getting the remote stub, which in turn might invalidate some tests.
>> (In fact I was going to suggest this but I decided to investigate further
>> first.)
>>
>> At the very least, I'd suggest renaming the variable that holds the newly
>> created Registry to something like "registryImpl" to make it clear that it's
>> different from the thing returned by getRegistry(), even though they have a
>> the same time.
>>
>> Another possibility is to rearrange the TestLibrary API so that there is a
>> single utility method that combines createRegistryOnUnusedPort() and
>> getRegistryPort(). That is, it creates a new registry and simply returns the
>> port on which it was created, not a reference to the registry implementation.
>> I don't think the registry implementation is actually ever used by the tests,
>> and it might simplify things a bit as well.
>>
>> Possibly similar issues with:
>> - UnreferencedContext.java
>> - NoConsoleOutput.java
>>
>>
>> *** HttpSocketTest.java
>>
>>
>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
> Looks like extra code left over from the change from using
> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) to
> TestLibrary.createRegistryOnUnusedPort...removed.
>>
>>
>> *** TestLibrary.java
>>
>> Mostly pretty straightforward, but I do have some concerns about the random
>> port selection and a potential clash with the "reserved port range" as
>> defined in this test library.
>>
>> The getUnusedRandomPort() method attempts to get a socket within the range
>> (1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS
>> allocates ports more-or-less sequentially in the range [49152, 65536) which
>> means that when the kernel's internal counter gets to 64000,
>> getUnusedRandomPort()'s retries will fail, causing tests to fail until the
>> counter wraps around.
>>
>> Other systems behave differently; Linux seems to allocate them randomly in
>> the range [32768,65536) and Windows XP SP3 allocates them sequentially in the
>> range (1024,5000]. So it's probably not a problem for them.
>>
>> I think the thing to do is to check only for "reserved ports" that are
>> actually used by tests here. These are in the range [64001,64005]. In
>> getUnusedRandomPort(), it should only need to retry if the returned port is
>> within this narrow, reserved range. If it's anything else it should be OK.
> I'll try setting the range this narrow, but I don't know how many sequential
> tests will be run at a time and I'm concerned 5 is too few. The -concurrency
> option on jtreg allows you to specify how many concurrent tests will be run. We
> should have enough test ports reserved to satisfy any concurrency request. I've
> run the tests with -concurrency=8 (I have a dual-core system showing 4 CPU's).
> I tried reducing the port range to 64001/64002 and concurrency=4 and all passed
> fine, so maybe we're OK with just 5.
>>
>> On another topic, the three utility methods here:
>> - createRegistryOnUnusedPort
>> - getRegistryPort
>> - getUnusedRandomPort
>>
>> all catch exceptions and then return illegal values (null or -1), sometimes
>> after printing some diagnostic information. The problem is that the caller
>> will attempt to soldier on with the illegal return value and will stumble
>> over something later, such as NullPointerException or
>> IllegalArgumentException. This will probably be obvious but it's equally
>> likely to be confusing.
>>
>> Since these utilities are all called from test code, and the tests are
>> relying on them to return valid results, I'd suggest just throwing exceptions
>> from the utility methods if they fail. This will (should) cause the test to
>> error out, but that's OK, as it never could have succeeded anyway if the
>> utility call had failed.
> I already modified createRegistryOnUnusedPort to throw an exception as part of
> the MultipleRegistries change. I'm now throwing a RuntimeException for
> getRegistryPort and getUnusedRandomPort if they fail.
>
> See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>
> Darryl
>>
>> s'marks
>>
>>
>>
>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 7161503.
>>> Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>> This commit fixes concurrency issues with the RMI tests.
>>>
>>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>>> RMIRegistry on an unused port. It will try up to 10 times before giving up.
>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the port number
>>> of the registry.
>>> - Changed almost all tests from using hard port numbers to using random port
>>> numbers for running the RMI Registry and RMID.
>>> - Removed othervm from those tests which don't need it.
>>> - Added parameters for tests which spawn a separate VM to pass RMI Registry and
>>> RMID ports in cases where needed.
>>> - Added PropertyPermission to security policy files where needed.
>>> - Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
>>> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>>>
>>> Thanks,
>>> Darryl
>>>
>
>


From huizhe.wang at oracle.com  Fri Jul 13 04:05:04 2012
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Fri, 13 Jul 2012 04:05:04 +0000
Subject: hg: jdk8/tl/jaxp: 7183760: DocumentBuilder.parse(String uri) is not
	IPv6 enabled
Message-ID: <20120713040508.1C09A48000@hg.openjdk.java.net>

Changeset: 6e444b892c99
Author:    joehw
Date:      2012-07-12 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6e444b892c99

7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled
Summary: removing the hack of using escapeNonUSAscii. this is the same patch as 7166896 for 7u8.
Reviewed-by: psandoz, lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java



From Alan.Bateman at oracle.com  Fri Jul 13 08:59:01 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jul 2012 09:59:01 +0100
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFF6847.3020701@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
Message-ID: <4FFFE355.9090507@oracle.com>

On 13/07/2012 01:13, Stuart Marks wrote:
> But for creating a registry, createRegistry(0) will usually work the 
> first time. If it throws ExportException, it does so for a specific 
> reason, so we should retry once on an unused random port. But if this 
> still fails, don't think retrying repeatedly makes sense.
Do we know what it fails? I would think that createRegistry(0) should 
only fail if there aren't any free port available or there is some 
resource issue.

-Alan


From maurizio.cimadamore at oracle.com  Fri Jul 13 12:01:09 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 13 Jul 2012 12:01:09 +0000
Subject: hg: jdk8/tl/langtools: 7181578: javac reports uninitialized variable
	with nested try...finally blocks
Message-ID: <20120713120114.3458147027@hg.openjdk.java.net>

Changeset: 934a89402f85
Author:    mcimadamore
Date:      2012-07-13 12:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/934a89402f85

7181578: javac reports uninitialized variable with nested try...finally blocks
Summary: regression introduced in refactoring of Flow.java
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/tools/javac/DefiniteAssignment/T7181578.java



From Alan.Bateman at oracle.com  Fri Jul 13 12:19:26 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jul 2012 13:19:26 +0100
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <4FFCB68E.6000608@oracle.com>
References: <4FFCB68E.6000608@oracle.com>
Message-ID: <5000124E.5060002@oracle.com>

On 11/07/2012 00:11, Xueming Shen wrote:
> Hi,
>
> In JDK7,  the decoder and encoder implementation of most of our 
> single-byte charsets
> and UTF-8 charset are optimized to implement the internal interfce 
> sun.nio.cs.ArrayDecoder/
> Encoder to provide a fastpath for String.getBytes(...) and new 
> String(byte[]...) operations. I
> have an old blog regarding this optimization at
>
> https://blogs.oracle.com/xuemingshen/entry/faster_new_string_bytes_cs
>
> This rfe, as the followup for above changes, is to implement 
> ArrayDe/Encoder for most
> of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is 
> the webrev
>
> http://cr.openjdk.java.net/~sherman/7183053/webrev
I've taken a pass over this and it's great to see 
DoubleByte.Decoder/Encoder implementing sun.nio.cs.ArrayDecoder/Encoder. 
The results looks good too, a small number of regressions (Big5 at 
len=32 for example) but this is a micro benchmark and I'm sure there are 
fluctuations. I don't see anything obviously wrong with the EBCDIC 
changes I'd need a history book to remember how the shifts between DBCS 
and SBCS. I think our tests our good for this area so I'm happy. One 
minor nit is the continue in both encode methods, I think it would be 
cleaner to use "else if (bb ..." instead.

I see in TestStringCoding.java that you've commented out the test that 
goes over the buffer limit - would I be correct to say that this isn't 
an issue and this happens with DB charsets today?

Ulf - you've got several patches to the double byte charsets and I 
wonder if you have cycles to try Sherman's patch with jdk8 to see if 
there is any more to be gained?

-Alan.



From Alan.Bateman at oracle.com  Fri Jul 13 15:02:38 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jul 2012 16:02:38 +0100
Subject: <i18n dev> [8] Review request for JEP 127: Improve Locale Data
	Packaging and Adopt Unicode CLDR Data
In-Reply-To: <4FFC93CF.40105@oracle.com>
References: <4FFC93CF.40105@oracle.com>
Message-ID: <5000388E.3030400@oracle.com>

On 10/07/2012 21:42, Naoto Sato wrote:
> Hello,
>
> Please review the JDK8 changes for JEP 127: Improve Locale Data 
> Packaging and Adopt Unicode CLDR Data 
> (http://openjdk.java.net/jeps/127). The webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
There's a lot here, lots of good work but way too much for me to review. 
However just one comment to say that the new layout for the resources 
and locales will make it a lot easier to modularize so this aspect is 
very welcome.

-Alan.



From xueming.shen at oracle.com  Fri Jul 13 17:09:36 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 13 Jul 2012 10:09:36 -0700
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <5000124E.5060002@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
Message-ID: <50005650.9090207@oracle.com>

On 07/13/2012 05:19 AM, Alan Bateman wrote:
> On 11/07/2012 00:11, Xueming Shen wrote:
>> Hi,
>>
>> In JDK7,  the decoder and encoder implementation of most of our 
>> single-byte charsets
>> and UTF-8 charset are optimized to implement the internal interfce 
>> sun.nio.cs.ArrayDecoder/
>> Encoder to provide a fastpath for String.getBytes(...) and new 
>> String(byte[]...) operations. I
>> have an old blog regarding this optimization at
>>
>> https://blogs.oracle.com/xuemingshen/entry/faster_new_string_bytes_cs
>>
>> This rfe, as the followup for above changes, is to implement 
>> ArrayDe/Encoder for most
>> of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is 
>> the webrev
>>
>> http://cr.openjdk.java.net/~sherman/7183053/webrev
> I've taken a pass over this and it's great to see 
> DoubleByte.Decoder/Encoder implementing 
> sun.nio.cs.ArrayDecoder/Encoder. The results looks good too, a small 
> number of regressions (Big5 at len=32 for example) but this is a micro 
> benchmark and I'm sure there are fluctuations. I don't see anything 
> obviously wrong with the EBCDIC changes I'd need a history book to 
> remember how the shifts between DBCS and SBCS. I think our tests our 
> good for this area so I'm happy. One minor nit is the continue in both 
> encode methods, I think it would be cleaner to use "else if (bb ..." 
> instead.

The continue might make the vm happy, but this is the code I did last 
Oct, so I might be
wrong. Will give a couple run later with "else"

>
> I see in TestStringCoding.java that you've commented out the test that 
> goes over the buffer limit - would I be correct to say that this isn't 
> an issue and this happens with DB charsets today?
>

This is also true for utf-8 I did last year, but utf-8 is excluded at 
the beginning of the test. For
SB, it takes the advantage that the output char[] should always be the 
same as the length
of the input bytes, so this can be checked at the very beginning 
together. For mb, to check
both sp and dp slow down the de/encoding (vm obviously does not like too 
many "if"s). Given
this is an internal interface used exclusively by StringCoding, in which 
it has already
calculated the max buf to feed in, I think this is something that can be 
optimized.

-Sherman


> Ulf - you've got several patches to the double byte charsets and I 
> wonder if you have cycles to try Sherman's patch with jdk8 to see if 
> there is any more to be gained?
>
> -Alan.
>



From iris.clark at oracle.com  Fri Jul 13 18:32:56 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 13 Jul 2012 11:32:56 -0700 (PDT)
Subject: <i18n dev> [8] Review request for JEP 127: Improve Locale Data
	Packaging and Adopt Unicode CLDR Data
In-Reply-To: <5000388E.3030400@oracle.com>
References: <4FFC93CF.40105@oracle.com> <5000388E.3030400@oracle.com>
Message-ID: <1f9802b5-fb93-42d8-80e5-b4a262969ef9@default>

Hi, Naoto.

Wow.  Tons of fantastic work!

Looks like many files contain fairly trivial changes related to resources being moved to another package, but there are many others which require more careful review.  

Scanning the list of files in the webrev, one comment pops to mind.  You've made changes to the current make files and some of the tools used during make.  Does the build-infra team need to make similar/appropriate changes in the new system?  If they haven't already been brought into the loop, you might want to do so soon.

Thanks,
iris

-----Original Message-----
From: Alan Bateman 
Sent: Friday, July 13, 2012 8:03 AM
To: Naoto Sato
Cc: Java Core Libs; i18n-dev
Subject: Re: <i18n dev> [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

On 10/07/2012 21:42, Naoto Sato wrote:
> Hello,
>
> Please review the JDK8 changes for JEP 127: Improve Locale Data 
> Packaging and Adopt Unicode CLDR Data 
> (http://openjdk.java.net/jeps/127). The webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
There's a lot here, lots of good work but way too much for me to review. 
However just one comment to say that the new layout for the resources and locales will make it a lot easier to modularize so this aspect is very welcome.

-Alan.



From jason.uh at oracle.com  Mon Jul  2 14:18:25 2012
From: jason.uh at oracle.com (Jason Uh)
Date: Mon, 02 Jul 2012 07:18:25 -0700
Subject: [8] Review request for 7162111 change tests run in headless mode
	[macosx]
In-Reply-To: <4FE86576.8020407@oracle.com>
References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com>
	<4FE86576.8020407@oracle.com>
Message-ID: <4FF1ADB1.9020508@oracle.com>

Anthony and Alan,

Thanks for your comments. I've reverted the changes to CommonSetup.sh so 
that XToolkit is no longer forced. Tests still pass.

Please see the new webrev: 
http://cr.openjdk.java.net/~juh/7162111/webrev.01/

Thanks,
Jason

On 06/25/2012 06:19 AM, Anthony Petrov wrote:
> Hi Alan and Jason,
>
> On 06/23/12 11:28, Alan Bateman wrote:
>> On 23/06/2012 02:01, Jason Uh wrote:
>>> 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.
>>>
>> 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?
>
> I don't think we need to force XToolkit on the Mac. We don't quite
> support it on that platform actually. The normal headless CToolkit
> should work just fine. Could you please revert the changes to
> CommonSetup.sh and verify if the tests pass?
>
> --
> best regards,
> Anthony


From weijun.wang at oracle.com  Fri Jul  6 10:27:22 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 06 Jul 2012 18:27:22 +0800
Subject: Time format in jar and jarsigner output (was Re: Code review request:
	7163483 JarSigner -verify -verbose does not format date string
	according to locale)
In-Reply-To: <4FF6ACF7.6020200@linux.vnet.ibm.com>
References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com>
	<4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com>
	<4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com>
	<4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com>
	<4FF6ACF7.6020200@linux.vnet.ibm.com>
Message-ID: <4FF6BD8A.4080500@oracle.com>

Hi Jonathan

I have these questions:

1. Why always CAPITAL letters for month and weekday?

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.

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

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
>>>
>>
>
>



From azeem.jiva at oracle.com  Wed Jul 11 20:20:22 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Wed, 11 Jul 2012 15:20:22 -0500
Subject: Native zlib libraries
In-Reply-To: <4FFD2F95.90905@oracle.com>
References: <3427b874-8c8c-4e7b-b4ec-1b8055e80342@zmail17.collab.prod.int.phx2.redhat.com>
	<4FFD2F95.90905@oracle.com>
Message-ID: <4FFDE006.4050706@oracle.com>



> I think we need to (re)start the discussion on core-libs-dev with a 
> view to eliminating the patches that the JDK has to zlib, see:
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java 
>
>
> One of these changes relates to the zip64 support and I believe there 
> are corner cases when inflating or deflating >2GB that won't work if 
> using the system zlib. Sherman will likely recall the details. Given 
> that the new build already supports using the system zlib (at least on 
> Linux) then it would be good to sort this out so that it just works.
>
> -Alan

The reason I brought up this issue, is that we'd like the ability to 
swap out the zlib library with ones that have specialized acceleration 
capabilities.  If the ability to swap zlib libraries can be made dynamic 
that would make it easier, although I'm not sure how integrated the 
libraries are.



From naoto.sato at oracle.com  Fri Jul 13 18:59:22 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 13 Jul 2012 11:59:22 -0700
Subject: <i18n dev> [8] Review request for JEP 127: Improve Locale Data
	Packaging and Adopt Unicode CLDR Data
In-Reply-To: <1f9802b5-fb93-42d8-80e5-b4a262969ef9@default>
References: <4FFC93CF.40105@oracle.com> <5000388E.3030400@oracle.com>
	<1f9802b5-fb93-42d8-80e5-b4a262969ef9@default>
Message-ID: <5000700A.20301@oracle.com>

Hi Iris,

Thank you for your comment. We had a meeting with the build infra team 
when Erik was here last week, so they are aware of this change. The 
initial review request actually involved 'build-dev' alias besides 
'i18n-dev' and 'core-libs-dev'.

Naoto

On 12/07/13 11:32, Iris Clark wrote:
> Hi, Naoto.
>
> Wow.  Tons of fantastic work!
>
> Looks like many files contain fairly trivial changes related to resources being moved to another package, but there are many others which require more careful review.
>
> Scanning the list of files in the webrev, one comment pops to mind.  You've made changes to the current make files and some of the tools used during make.  Does the build-infra team need to make similar/appropriate changes in the new system?  If they haven't already been brought into the loop, you might want to do so soon.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Friday, July 13, 2012 8:03 AM
> To: Naoto Sato
> Cc: Java Core Libs; i18n-dev
> Subject: Re: <i18n dev> [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data
>
> On 10/07/2012 21:42, Naoto Sato wrote:
>> Hello,
>>
>> Please review the JDK8 changes for JEP 127: Improve Locale Data
>> Packaging and Adopt Unicode CLDR Data
>> (http://openjdk.java.net/jeps/127). The webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
> There's a lot here, lots of good work but way too much for me to review.
> However just one comment to say that the new layout for the resources and locales will make it a lot easier to modularize so this aspect is very welcome.
>
> -Alan.
>




From mark.reinhold at oracle.com  Fri Jul 13 19:04:20 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 13 Jul 2012 12:04:20 -0700
Subject: Time format in jar and jarsigner output (was Re: Code review
	request: 7163483 JarSigner -verify -verbose does not format
	date string according to locale)
In-Reply-To: weijun.wang@oracle.com; Fri, 06 Jul 2012 18:27:22 +0800;
	<4FF6BD8A.4080500@oracle.com>
Message-ID: <20120713190420.17A10AAF@eggemoggin.niobe.net>

2012/7/6 3:27 -0700, weijun.wang at oracle.com:
> I have these questions:
> 
> ...
> 
> 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?

Excellent idea!

> 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
> 
> BTW, the jar command is using the same format ...

Changing the jarsigner command to use the same format as the jar command
makes the most sense to me.

- Mark


From iris.clark at oracle.com  Fri Jul 13 19:10:14 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 13 Jul 2012 12:10:14 -0700 (PDT)
Subject: <i18n dev> [8] Review request for JEP 127: Improve Locale Data
	Packaging and Adopt Unicode CLDR Data
In-Reply-To: <5000700A.20301@oracle.com>
References: <4FFC93CF.40105@oracle.com> <5000388E.3030400@oracle.com>
	<1f9802b5-fb93-42d8-80e5-b4a262969ef9@default>
	<5000700A.20301@oracle.com>
Message-ID: <6048aea9-c524-48e1-8bfa-490480264679@default>

Hi, Naoto.

Fantastic!  Sorry I didn?t catch that 'build-dev' was in the set of reviewers.

Thanks for being on top of this.

iris

-----Original Message-----
From: Naoto Sato 
Sent: Friday, July 13, 2012 11:59 AM
To: Iris Clark
Cc: Alan Bateman; Java Core Libs; i18n-dev
Subject: Re: <i18n dev> [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

Hi Iris,

Thank you for your comment. We had a meeting with the build infra team when Erik was here last week, so they are aware of this change. The initial review request actually involved 'build-dev' alias besides 'i18n-dev' and 'core-libs-dev'.

Naoto

On 12/07/13 11:32, Iris Clark wrote:
> Hi, Naoto.
>
> Wow.  Tons of fantastic work!
>
> Looks like many files contain fairly trivial changes related to resources being moved to another package, but there are many others which require more careful review.
>
> Scanning the list of files in the webrev, one comment pops to mind.  You've made changes to the current make files and some of the tools used during make.  Does the build-infra team need to make similar/appropriate changes in the new system?  If they haven't already been brought into the loop, you might want to do so soon.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Friday, July 13, 2012 8:03 AM
> To: Naoto Sato
> Cc: Java Core Libs; i18n-dev
> Subject: Re: <i18n dev> [8] Review request for JEP 127: Improve Locale 
> Data Packaging and Adopt Unicode CLDR Data
>
> On 10/07/2012 21:42, Naoto Sato wrote:
>> Hello,
>>
>> Please review the JDK8 changes for JEP 127: Improve Locale Data 
>> Packaging and Adopt Unicode CLDR Data 
>> (http://openjdk.java.net/jeps/127). The webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
> There's a lot here, lots of good work but way too much for me to review.
> However just one comment to say that the new layout for the resources and locales will make it a lot easier to modularize so this aspect is very welcome.
>
> -Alan.
>




From Ulf.Zibis at CoSoCo.de  Fri Jul 13 19:22:30 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Fri, 13 Jul 2012 21:22:30 +0200
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <5000124E.5060002@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
Message-ID: <50007576.7030607@CoSoCo.de>

Am 13.07.2012 14:19, schrieb Alan Bateman:
>
> Ulf - you've got several patches to the double byte charsets and I wonder if you have cycles to 
> try Sherman's patch with jdk8 to see if there is any more to be gained?

First, most of those patches have been closed from official side, don't really understand why:
https://bugs.openjdk.java.net/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=ulf.zibis&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Yes, I have many work prepared for performance tuning upon charsets, but I do not have JDK-8 
environment installed at the moment.

I'm in a kind of vacation from OpenJDK development. One reason is the missing appreciation from 
official side. All attempts to at least have an account on http://cr.openjdk.java.net/, for easier 
publishing webrevs, have ended in *no answer* regardless my activity:
See [Who Sent It?] on: http://markmail.org/search/+list:net.java.openjdk.core-libs-dev

-Ulf



From Ulf.Zibis at CoSoCo.de  Fri Jul 13 19:30:14 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Fri, 13 Jul 2012 21:30:14 +0200
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <5000124E.5060002@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
Message-ID: <50007746.4060807@CoSoCo.de>

Am 13.07.2012 14:19, schrieb Alan Bateman:
>
> Ulf - you've got several patches to the double byte charsets and I wonder if you have cycles to
> try Sherman's patch with jdk8 to see if there is any more to be gained?

Additionally, I'm wondering, that EUC_TW is not part of the patch.
I've worked on that for some months last year, gaining an improvement of ~30 % but have no final 
result though.

-Ulf



From kelly.ohair at oracle.com  Fri Jul 13 20:20:03 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 13 Jul 2012 13:20:03 -0700
Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and
	Adopt Unicode CLDR Data
In-Reply-To: <4FFC93CF.40105@oracle.com>
References: <4FFC93CF.40105@oracle.com>
Message-ID: <FD1B35D1-908F-4F14-8264-1A03BED7FECA@oracle.com>


Something seems strange here:
   http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html
It's like someone was avoiding overall quotes, but using them to add spaces somehow...
I sure would like to get rid of this shell logic, seems like there are lots repeated logic that
this script does over and over or could be done with makefile pattern subst's instead of exec's.
---

Overall, just looking at the makefiles, the build-infra team may need some time to fully absorb this into the
new makefiles, some of it will be trivial, not sure all of it will be.

Not sure how to proceed here, the build-infra team does need an action item to deal with this, maybe
before it gets integrated because I suspect the new makefiles will break with all the filename or
directory changes. But I hate to hold up your integration plans.

I'd like to get some advice from Erik on this before saying anything further.

-kto

On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote:

> Hello,
> 
> Please review the JDK8 changes for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (http://openjdk.java.net/jeps/127). The webrev is located at:
> 
> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
> 
> The main bug id for this enhancement is:
> 
> 6336885: RFE: Locale Data Deployment Enhancements
> 
> Along with this, the following bugs/enhancements are also implemented in this change:
> 
> 4609153 Provide locale data for Indic locales
> 5104387 Support for gl_ES locale (galician language)
> 6337471 desktop/system locale preferences support
> 7056139 (cal) SPI support for locale-dependent Calendar parameters
> 7058206 Provide CalendarData SPI for week params and display field value names
> 7073852 Support multiple scripts for digits and decimal symbols per locale
> 7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat
> 7171324 getAvailableLocales() of locale sensitive services should return the actual availability of locales
> 7151414 (cal) Support calendar type identification
> 7168528 LocaleServiceProvider needs to be aware of Locale extensions
> 7171372 (cal) locale's default Calendar should be created if unknown calendar is specified
> 
> Please note that packaging changes that relate to Jigsaw module system aren't included in this changeset.
> 
> Naoto Sato and Masayoshi Okutsu



From Alan.Bateman at oracle.com  Fri Jul 13 20:20:01 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Jul 2012 21:20:01 +0100
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50007576.7030607@CoSoCo.de>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
	<50007576.7030607@CoSoCo.de>
Message-ID: <500082F1.5050805@oracle.com>

On 13/07/2012 20:22, Ulf Zibis wrote:
>
> First, most of those patches have been closed from official side, 
> don't really understand why:
> https://bugs.openjdk.java.net/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=ulf.zibis&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0= 
>
Sorry, I don't know, looks like Tim has been doing some cleanup. From a 
brief scan then at least some of these were fixed or closed a long time 
ago.

You do need author role to push webrevs to cr.openjdk.java.net, I had 
thought were had this already but it seems not.

-Alan.


From darryl.mocek at oracle.com  Fri Jul 13 20:40:14 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Fri, 13 Jul 2012 13:40:14 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFF6847.3020701@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
Message-ID: <500087AE.7070501@oracle.com>


On 07/12/2012 05:13 PM, Stuart Marks wrote:
> OK, I took a look at the revised webrev. Most stuff is good. A couple 
> changes are necessary though.
>
>
> *** MultipleRegistries.java
>
>
> Not a big deal, but the comment at lines 65-67 is no longer necessary.
Comment removed.
>
>
> *** TestLibrary.java
>
>
> I think the reserved port range stuff still needs to be fixed up.
>
> The comment at lines 81-82 talks about a range 64000-64100 which isn't 
> really present anywhere. The comment should instead say that PORT_MIN 
> and PORT_MAX should be kept adjusted so that they specify the range of 
> ports defined by the constants following. Make sure to do this 
> adjustment; PORT_MAX is 64002 here.
I reserved ports 64000-64100 (even though only 64001-64005 are currently 
being used) for fixed port tests (for tests which require fixed ports) 
so any future tests which require fixed ports can be assured there are 
ports available within a range for their use.  In fixing the tests, I 
saw  that those who wrote tests and used fixed ports grabbed random port 
numbers all over the place.  Providing a reserved range allows them to 
just grab the next number and to keep the fixed port numbers in a group, 
even when new tests are added. If the ports are defined in a central 
place, like TestLibrary, then hopefully developers will come to 
TestLibrary to reserve the ports rather then define them in the tests 
themselves, like was done previously.  I chose 100 ports for 
"future-proofing"...I don't think 100 is too many, but I've reduced it 
to 10 and lowered the max to 64010.  I was also thinking of looking for 
tests which used fixed ports outside of RMI tests and standardizing 
those ports here, but that's possible future work and I'm not sure it's 
necessary.
>
> The previous webrev had PORT_MIN and PORT_MAX specify a range of 
> 1024-64000 as the *allowed* range for ports returned by 
> getUnusedRandomPort(). But as I described previously, this is 
> difficult to enforce given the varying port allocation schemes on 
> different OSes.
>
> Instead I think we need to invert the sense of the range 
> PORT_MIN..PORT_MAX and make it be the range of ports reserved by tests 
> that require fixed ports (64001 through 64005). Then, 
> getUnusedRandomPort() needs to be changed to *disallow* ports in this 
> range, that is, to retry if the port is within this range. Thus the 
> condition on the while-loop has to be inverted, something like
>
>     while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= 
> PORT_MAX)
Yes, this is correct and it has been changed.
>
> So, how could getUnusedRandomPort() have worked in its present state? 
> Well I think it ends up retrying 10 times, then at the end of the loop 
> unusedRandomPort is actually some legal port number -- albeit possibly 
> one within the disallowed range -- and almost certainly not -1, and so 
> the method returns it and the caller uses it. So, the success-testing 
> logic here will also have to change so that it retests whether the 
> port is in the disallowed range.
Correct...done.
>
> The comment on getUnusedRandomPort() also needs to be updated to 
> reflect its new policy on the reserved range, as well as throwing an 
> exception on failure. Also (nitpick) it should say "less than" not 
> "less then".
Yes, I always do this. :(
>
> Looking at getUnusedRandomPort() again more closely [sorry] I think 
> the catch of Exception that does nothing is suspicious. I'm not sure 
> why getting a ServerSocket would fail, but if it does (maybe the 
> system is out of ports??) we should just throw out to the caller. 
> Perhaps ideally we'd just have this method throw IOException, but if 
> that requires all callers to be updated, it might be easier just to 
> catch IOException and throw a RuntimeException that wraps the caught 
> IOException.
I see no harm in trying again if it fails.  If we have run out of ports, 
then possibly one or more used ports will be closed and freed and a 
subsequent try will succeed.  I don't know all of the cases where a 
failure might occur.  Anyway, if this is the prevailing way of handling 
this, I'll change it.
>
> Similar comments apply to the catch(Exception)/do-nothing code in the 
> other utility methods.
Now throwing RuntimeException in getRegistryPort.
>
> Certainly getRegistryPort() should just throw (or possibly wrap and 
> rethrow) any exception caught.
>
> For createRegistryOnUnusedPort(), the catching of ExportException is 
> handled properly. The second catch clause of the outer try-block, and 
> the catch of the inner try-block, both ignore exceptions. The code 
> will then end up retrying. Is it reasonable that retrying in these 
> cases will result in a different outcome? My guess is that it's more 
> likely that something is seriously wrong that will cause all the 
> retries to fail, in which case this method will discard the exceptions 
> it has just caught and throw a *new* RemoteException instance.
This was a holdover from webrev.00 which should have been removed. I 
agree with Alan and you here that multiple tries of 
LocateRegistry.createRegistry(0) is unnecessary.  I've modified this to 
make a single attempt at using LocateRegistry.createRegistry(0) and if 
it fails, make a single attempt at getting an unused random port and 
creating a registry on this port, then failing with a RuntimeException.
>
> I'm particularly sensitive to this; as you might recall a couple weeks 
> ago I was having a wrestling match with the jstatd tests (I finished 
> the match, but I'm not sure I won). The primary problem was that 
> several layers of code would catch and discard exceptions, which made 
> diagnosing the problem incredibly difficult. So, I'd recommend 
> removing the "do nothing" catch clauses.
>
> Thinking further about createRegistryOnUnusedPort(), I'm not sure that 
> retrying 10 (or some other number of times) actually makes sense. It 
> does for getUnusedRandomPort(), which has to retry in order to get a 
> port outside the disallowed range. But for creating a registry, 
> createRegistry(0) will usually work the first time. If it throws 
> ExportException, it does so for a specific reason, so we should retry 
> once on an unused random port. But if this still fails, don't think 
> retrying repeatedly makes sense.
See above.

Changes pass all tests.  Updated webrev at 
http://cr.openjdk.java.net/~dmocek/7142596/webrev.04

Darryl
>
> s'marks
>
>
>
>
> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>
>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>> OK, here's the review for the second half of the files in the 
>>> webrev. I saw
>>> your reply to the first half (to which I'll reply separately), and I 
>>> don't
>>> think there's anything here that's affected by them.
>>>
>>>
>>> *** AppleUserImpl.java
>>> *** ApplicationServer.java
>>>
>>>
>>> REGISTRY_PORT should be a local variable; also rename to use mixed 
>>> case.
>> Changed to a private registryPort (see next issue).
>>>
>>> Eh, whoops, after looking at ApplicationServer.java I see that it 
>>> accesses
>>> the REGISTRY_PORT field directly. This is why direct field access is 
>>> a bad
>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized 
>>> before
>>> ApplicationServer needs it? It turns out that it has been -- but 
>>> only in some
>>> cases.
>>>
>>> It seems like the test is trying to support two modes, one that runs 
>>> in two
>>> threads in the same JVM, and the other that runs in two separate 
>>> JVMs. If
>>> they are in separate JVMs, things will no longer work because in the 
>>> JVM that
>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be 
>>> -1. I
>>> suspect that our test environment doesn't support the separate JVM 
>>> mode, but
>>> it seems unwise to break it.
>>>
>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>> "well-known" default registry port number, which in this case seems 
>>> like 2006.
>>>
>>> In single-JVM mode, AppleUserImpl creates an instance of 
>>> ApplicationServer,
>>> so I'd suggest adding a method to ApplicationServer that allows 
>>> AppleUserImpl
>>> to store the randomly-assigned registry port number into it, 
>>> overriding the
>>> default value.
>>>
>>> This seems like this is the simplest way to preserve the two modes of
>>> operation but to support the random port selection model we're 
>>> trying to
>>> achieve.
>> Rather then going the "fixed port" route, which is what we're trying 
>> to get
>> away from, I've changed the implementation of both AppletUserImpl's and
>> ApplicationServer so ApplicationServer requires a port and AppleUserImpl
>> supplies the port on construction of ApplicationServer. I thought of 
>> modifying
>> ApplicationServer's constructor to create a port using
>> TestLibrary.getUnusedRandomPort, but decided requiring a port is 
>> better as
>> ApplicationServer's job is to look for already exported AppleUser 
>> objects.
>>>
>>>
>>> *** activatable/EchoImpl.java
>>>
>>>
>>> int registryPort = new 
>>> Integer(System.getProperty("rmi.registry.port"));
>>>
>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not a 
>>> huge
>>> deal, but it's probably more conventional to use parseInt() and it 
>>> avoids
>>> boxing.
>>>
>>> One could probably do Integer.getInteger("rmi.registry.port") but 
>>> this is
>>> seems pretty obscure to me even though it's more succinct.
>>>
>>> The same also applies to the following:
>>> - HelloImpl.java
>>> - unicast/EchoImpl.java
>>> - ShutdownImpl.java
>>> - SelfTerminator.java
>>> - CheckFQDNClient.java
>>> - LeaseLeakClient.java
>>> - dgcDeadLock/TestImpl.java
>>>
>> Integer.parseInt returns a primitive (which is what the return is 
>> assigned to)
>> and it appears Integer.parseInt is "faster" then creating a new Integer.
>> Changed to Integer.parseInt in all places referenced.
>>>
>>> *** FiniteGCLatency.java
>>>
>>>
>>> The pattern here is a bit odd, as the test creates the registry, 
>>> throws away
>>> the returned reference, and then calls getRegistry() to get another 
>>> Registry
>>> reference. It *seems* like they're identical references, but in fact 
>>> the
>>> first is apparently a reference to the actual Registry implementation,
>>> whereas the second is a remote stub.
>>>
>>> The tests seem to do all the actual work using the remote stub, 
>>> which seems
>>> proper.
>>>
>>> This is confusing, though, as it looks like there's a redundant 
>>> Registry
>>> reference now. This might lead someone in the future to "simplify" 
>>> the test
>>> by not getting the remote stub, which in turn might invalidate some 
>>> tests.
>>> (In fact I was going to suggest this but I decided to investigate 
>>> further
>>> first.)
>>>
>>> At the very least, I'd suggest renaming the variable that holds the 
>>> newly
>>> created Registry to something like "registryImpl" to make it clear 
>>> that it's
>>> different from the thing returned by getRegistry(), even though they 
>>> have a
>>> the same time.
>>>
>>> Another possibility is to rearrange the TestLibrary API so that 
>>> there is a
>>> single utility method that combines createRegistryOnUnusedPort() and
>>> getRegistryPort(). That is, it creates a new registry and simply 
>>> returns the
>>> port on which it was created, not a reference to the registry 
>>> implementation.
>>> I don't think the registry implementation is actually ever used by 
>>> the tests,
>>> and it might simplify things a bit as well.
>>>
>>> Possibly similar issues with:
>>> - UnreferencedContext.java
>>> - NoConsoleOutput.java
>>>
>>>
>>> *** HttpSocketTest.java
>>>
>>>
>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>> Looks like extra code left over from the change from using
>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) 
>> to
>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>
>>>
>>> *** TestLibrary.java
>>>
>>> Mostly pretty straightforward, but I do have some concerns about the 
>>> random
>>> port selection and a potential clash with the "reserved port range" as
>>> defined in this test library.
>>>
>>> The getUnusedRandomPort() method attempts to get a socket within the 
>>> range
>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS
>>> allocates ports more-or-less sequentially in the range [49152, 
>>> 65536) which
>>> means that when the kernel's internal counter gets to 64000,
>>> getUnusedRandomPort()'s retries will fail, causing tests to fail 
>>> until the
>>> counter wraps around.
>>>
>>> Other systems behave differently; Linux seems to allocate them 
>>> randomly in
>>> the range [32768,65536) and Windows XP SP3 allocates them 
>>> sequentially in the
>>> range (1024,5000]. So it's probably not a problem for them.
>>>
>>> I think the thing to do is to check only for "reserved ports" that are
>>> actually used by tests here. These are in the range [64001,64005]. In
>>> getUnusedRandomPort(), it should only need to retry if the returned 
>>> port is
>>> within this narrow, reserved range. If it's anything else it should 
>>> be OK.
>> I'll try setting the range this narrow, but I don't know how many 
>> sequential
>> tests will be run at a time and I'm concerned 5 is too few. The 
>> -concurrency
>> option on jtreg allows you to specify how many concurrent tests will 
>> be run. We
>> should have enough test ports reserved to satisfy any concurrency 
>> request. I've
>> run the tests with -concurrency=8 (I have a dual-core system showing 
>> 4 CPU's).
>> I tried reducing the port range to 64001/64002 and concurrency=4 and 
>> all passed
>> fine, so maybe we're OK with just 5.
>>>
>>> On another topic, the three utility methods here:
>>> - createRegistryOnUnusedPort
>>> - getRegistryPort
>>> - getUnusedRandomPort
>>>
>>> all catch exceptions and then return illegal values (null or -1), 
>>> sometimes
>>> after printing some diagnostic information. The problem is that the 
>>> caller
>>> will attempt to soldier on with the illegal return value and will 
>>> stumble
>>> over something later, such as NullPointerException or
>>> IllegalArgumentException. This will probably be obvious but it's 
>>> equally
>>> likely to be confusing.
>>>
>>> Since these utilities are all called from test code, and the tests are
>>> relying on them to return valid results, I'd suggest just throwing 
>>> exceptions
>>> from the utility methods if they fail. This will (should) cause the 
>>> test to
>>> error out, but that's OK, as it never could have succeeded anyway if 
>>> the
>>> utility call had failed.
>> I already modified createRegistryOnUnusedPort to throw an exception 
>> as part of
>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>> getRegistryPort and getUnusedRandomPort if they fail.
>>
>> See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>
>> Darryl
>>>
>>> s'marks
>>>
>>>
>>>
>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 
>>>> 7161503.
>>>> Webrev can be found here: 
>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>> This commit fixes concurrency issues with the RMI tests.
>>>>
>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>>>> RMIRegistry on an unused port. It will try up to 10 times before 
>>>> giving up.
>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the 
>>>> port number
>>>> of the registry.
>>>> - Changed almost all tests from using hard port numbers to using 
>>>> random port
>>>> numbers for running the RMI Registry and RMID.
>>>> - Removed othervm from those tests which don't need it.
>>>> - Added parameters for tests which spawn a separate VM to pass RMI 
>>>> Registry and
>>>> RMID ports in cases where needed.
>>>> - Added PropertyPermission to security policy files where needed.
>>>> - Removed java/rmi and sun/rmi from tests which cannot be run 
>>>> concurrently.
>>>> - Added java/rmi/Naming to list of tests which cannot be run 
>>>> concurrently.
>>>>
>>>> Thanks,
>>>> Darryl
>>>>
>>
>>




From naoto.sato at oracle.com  Fri Jul 13 21:22:18 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 13 Jul 2012 14:22:18 -0700
Subject: [8] Review request for JEP 127: Improve Locale Data Packaging
	and Adopt Unicode CLDR Data
In-Reply-To: <FD1B35D1-908F-4F14-8264-1A03BED7FECA@oracle.com>
References: <4FFC93CF.40105@oracle.com>
	<FD1B35D1-908F-4F14-8264-1A03BED7FECA@oracle.com>
Message-ID: <5000918A.708@oracle.com>

Hi Kelly,

The shell script in question is pretty likely to be removed, or at least 
rewritten when we make modifications for Jigsaw packaging of the locale 
data. Right now the script creates the pre-baked locale list based on 
the existing resource bundle source files in the repository, but that 
locale list will have to be created at the run time, not build time.

Naoto

On 12/07/13 13:20, Kelly O'Hair wrote:
>
> Something seems strange here:
>     http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html
> It's like someone was avoiding overall quotes, but using them to add spaces somehow...
> I sure would like to get rid of this shell logic, seems like there are lots repeated logic that
> this script does over and over or could be done with makefile pattern subst's instead of exec's.
> ---
>
> Overall, just looking at the makefiles, the build-infra team may need some time to fully absorb this into the
> new makefiles, some of it will be trivial, not sure all of it will be.
>
> Not sure how to proceed here, the build-infra team does need an action item to deal with this, maybe
> before it gets integrated because I suspect the new makefiles will break with all the filename or
> directory changes. But I hate to hold up your integration plans.
>
> I'd like to get some advice from Erik on this before saying anything further.
>
> -kto
>
> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote:
>
>> Hello,
>>
>> Please review the JDK8 changes for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (http://openjdk.java.net/jeps/127). The webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
>>
>> The main bug id for this enhancement is:
>>
>> 6336885: RFE: Locale Data Deployment Enhancements
>>
>> Along with this, the following bugs/enhancements are also implemented in this change:
>>
>> 4609153 Provide locale data for Indic locales
>> 5104387 Support for gl_ES locale (galician language)
>> 6337471 desktop/system locale preferences support
>> 7056139 (cal) SPI support for locale-dependent Calendar parameters
>> 7058206 Provide CalendarData SPI for week params and display field value names
>> 7073852 Support multiple scripts for digits and decimal symbols per locale
>> 7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat
>> 7171324 getAvailableLocales() of locale sensitive services should return the actual availability of locales
>> 7151414 (cal) Support calendar type identification
>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions
>> 7171372 (cal) locale's default Calendar should be created if unknown calendar is specified
>>
>> Please note that packaging changes that relate to Jigsaw module system aren't included in this changeset.
>>
>> Naoto Sato and Masayoshi Okutsu
>




From dalibor.topic at oracle.com  Fri Jul 13 21:59:48 2012
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 13 Jul 2012 23:59:48 +0200
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50007576.7030607@CoSoCo.de>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
	<50007576.7030607@CoSoCo.de>
Message-ID: <50009A54.4060300@oracle.com>

On 7/13/12 9:22 PM, Ulf Zibis wrote:
> Am 13.07.2012 14:19, schrieb Alan Bateman:
>>
>> Ulf - you've got several patches to the double byte charsets and I wonder if you have cycles to try Sherman's patch with jdk8 to see if there is any more to be gained?
> 
> First, most of those patches have been closed from official side, don't really understand why:
> https://bugs.openjdk.java.net/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=ulf.zibis&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Tim is going through then issues in Bugzilla and closing the already fixed ones, and migrating the rest over to bug.sun.com in preparation for the the JIRA migration, afaik.

> I'm in a kind of vacation from OpenJDK development. One reason is the missing appreciation from official side. All attempts to at least have an account on http://cr.openjdk.java.net/, for easier publishing webrevs, have ended in *no answer* regardless my activity:
> See [Who Sent It?] on: http://markmail.org/search/+list:net.java.openjdk.core-libs-dev

If this patch is eventually headed for JDK 7 Updates, I could grant you an Author role there, if you wish.

cheers,
dalibor topic
-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment




From kurchi.subhra.hazra at oracle.com  Fri Jul 13 22:16:31 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Fri, 13 Jul 2012 15:16:31 -0700
Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not
	delivered when new node add when new Node
In-Reply-To: <4FFEE563.6020908@oracle.com>
References: <4FE35F86.3050109@oracle.com> <4FEA304E.7080503@oracle.com>
	<4FFD754D.3010804@oracle.com> <4FFE08F4.6080306@oracle.com>
	<06FEDB87-E697-44CC-986B-FC9240FF3BAD@oracle.com>
	<4FFE1000.5000305@oracle.com> <4FFE79C9.80405@oracle.com>
	<4FFEE563.6020908@oracle.com>
Message-ID: <50009E3F.9080402@oracle.com>

I am pushing this changeset but backing out the changes to 
ProblemList.txt. Those tests
are still failing depending on the machine and user permissions. I have 
a fair idea what is going wrong with them, and will
work on them with their associated CR (7150557).

Thanks,
Kurchi

On 7/12/2012 7:55 AM, Kurchi Subhra Hazra wrote:
> I used a new workspace and missed adding it to mercurial. The test 
> remains the same,
> I'll push it after adding the test.
>
> - Kurchi
>
> On 7/12/12 12:16 AM, Alan Bateman wrote:
>> On 12/07/2012 00:45, Kurchi Hazra wrote:
>>> On 7/11/12 4:24 PM, Chris Hegarty wrote:
>>>> On 12 Jul 2012, at 00:15, Kurchi 
>>>> Hazra<kurchi.subhra.hazra at 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/
>> Looks fine except that the test case is missing from latest webrev. 
>> Assuming that test/java/util/prefs/AddNodeChangeListener.java hasn't 
>> changed from the original webrev then I think you are all set to push.
>>
>> -Alan.
>

-- 
-Kurchi



From kurchi.subhra.hazra at oracle.com  Fri Jul 13 23:04:20 2012
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Fri, 13 Jul 2012 23:04:20 +0000
Subject: hg: jdk8/tl/jdk: 7160252: (prefs) NodeAddedEvent was not delivered
	when new node add when new Node
Message-ID: <20120713230446.C14E747036@hg.openjdk.java.net>

Changeset: e9461aeff91f
Author:    khazra
Date:      2012-07-13 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f

7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node
Summary: Change native code to convey to Java code whether a new node was added
Reviewed-by: alanb, chegar

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/native/java/util/MacOSXPreferencesFile.m
+ test/java/util/prefs/AddNodeChangeListener.java



From stuart.marks at oracle.com  Fri Jul 13 23:09:16 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 13 Jul 2012 16:09:16 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <4FFFE355.9090507@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<4FFFE355.9090507@oracle.com>
Message-ID: <5000AA9C.6050601@oracle.com>

On 7/13/12 1:59 AM, Alan Bateman wrote:
> On 13/07/2012 01:13, Stuart Marks wrote:
>> But for creating a registry, createRegistry(0) will usually work the first
>> time. If it throws ExportException, it does so for a specific reason, so we
>> should retry once on an unused random port. But if this still fails, don't
>> think retrying repeatedly makes sense.
> Do we know what it fails? I would think that createRegistry(0) should only fail
> if there aren't any free port available or there is some resource issue.

There is at least one test case that wants to create two registries within the 
same JVM. The first call to createRegistry(0) will usually succeed. The second 
call from the same JVM will throw an ExportException. So, we catch this and 
retry using a random port instead to create the second registry. If *that* 
fails we give up at that point instead of retrying repeatedly.

s'marks



From mike.duigou at oracle.com  Fri Jul 13 23:09:40 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Jul 2012 16:09:40 -0700
Subject: Update on alternative hashing for String keys with hash-based Maps 
Message-ID: <B738006F-74A3-4208-A72C-7A6E90C4A30A@oracle.com>

Hello all;

About a month ago a significant change was made to the Java SE 7 and 8 hash based Map implementations. This change was previously proposed and discussed on this list[1]. The change affects all of the hashing based Map implementations (HashMap, Hashtable, WeakHashMap, LinkedHashMap, ConcurrentHashMap), the derived Set implementations (HashSet, LinkedHashSet, etc.) and other classes which depend upon these classes (Properties, UIDefaults). The change to hash based Maps improves performance when a large number of key hash code collisions are encountered. This is accomplished by altering the handling of String keys to use a different (better) hash function.

As initially proposed, the alternative hashing behaviour was planned to apply to all hash based Maps larger than 512 elements. Smaller maps would continue to use the existing hashing approach. ConcurrentHashMap, because reasons related to the complexity of it's implementation, would always use the improved approach regardless of map capacity. Providing capacity based triggering of the alternative hashing is intended to improve compatibility by ensuring that the order in which elements are iterated does not change. Specifically, at less than the threshold capacity Map elements will be iterated in the same order as today. At or above the threshold, the iteration order will be different than the current order. Testing and evaluation of existing Java applications has shown us that some applications have explicit or implicit dependence upon the order that keys, values or entries will be iterated. The vast majority of iteration order dependent cases involve small maps--once a map contains hundreds of elements generally incorrect assumptions about iteration order will have already been found and resolved. We believed that triggering the alternative hashing behaviour at 512 element capacity would protect iteration order in cases which depended upon the existing iteration order. Java SE 7 and Java SE 8 have different policies. Java SE 8 is intended to always use alternative hashing of String keys regardless of the capacity of the Map.

After  integration a number of cases of iteration order dependence were encountered within the OpenJDK code itself, in tests and in user code. Some of these faults were easily diagnosed and correct. Some other cases, because iteration order is not consistent from run-to-run under alternative hashing, proved difficult to isolate and resolve. 

Following this testing and and consultation with Java licensees and developers it was decided disable the alternative hashing behaviour for Java SE 7.  To ensure the greatest degree of compatibility with existing applications it seems best to only enable alternative hashing by explicit control. In Java SE 7u6 it will be necessary to set the system property jdk.map.althashing.threshold in order to enable alternative hashing. It is also still possible that the feature may be enabled by default in future Java SE 7 releases but this will only happen if further testing indicates compatibility can be reasonably assured.

Because Java 8 is unreleased and we still wish to shake out iteration order dependencies alternative hashing remains enabled in Java SE 8. Alternative hashing is very likely to be enabled by default in Java SE 8. Doug Lea has been investigating further improvements to handling of key hash code collisions and his design is extremely likely to be the basis for all Java SE 8 hash based Map implementations.[2] 

Developers and deployers are strongly encouraged to test their applications by enabling the alternative String key hashing feature in Java SE 7u6 or later and/or testing with Java SE 8 builds. BE WARNED: it will probably not be possible to disable alternative hashing in Java SE 8. Applications MUST remove dependencies upon iteration order before they can be deployed with Java SE 8.

Thanks,

Mike

TL;DR:
- Java SE 7 and 8 both now support alternative hashing for String keys with hash based Maps
- Alternative hashing improves performance when many String key hash codes collide
- Alternative hashing impacts key, value and element iteration order
- Alternative hashing is currently DISABLED by default for Java SE 7
- Future Java SE 7 releases may enable alternative hashing for "large" (>512 capacity) maps
- Developers can enable the eature in Java SE 7 for testing and deployment with a system property
- Alternative hashing is ENABLED for all maps in Java SE 8
- It will probably not be possible to disable alternative hashing in Java SE 8
- Hash map key, value and element iteration order WILL be different and unpredictable in Java SE 8
- Different implementation approaches are still being investigated for Java SE 8 and remain subject to change

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010238.html
[2] http://cs.oswego.edu/pipermail/concurrency-interest/2012-June/009505.html

From joe.darcy at oracle.com  Sat Jul 14 00:27:00 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 13 Jul 2012 17:27:00 -0700
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50009A54.4060300@oracle.com>
References: <4FFCB68E.6000608@oracle.com>
	<5000124E.5060002@oracle.com>	<50007576.7030607@CoSoCo.de>
	<50009A54.4060300@oracle.com>
Message-ID: <5000BCD4.7080301@oracle.com>

Hello,

On 7/13/2012 2:59 PM, Dalibor Topic wrote:
> On 7/13/12 9:22 PM, Ulf Zibis wrote:
>> Am 13.07.2012 14:19, schrieb Alan Bateman:
>>> Ulf - you've got several patches to the double byte charsets and I wonder if you have cycles to try Sherman's patch with jdk8 to see if there is any more to be gained?
>> First, most of those patches have been closed from official side, don't really understand why:
>> https://bugs.openjdk.java.net/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=ulf.zibis&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=
> Tim is going through then issues in Bugzilla and closing the already fixed ones, and migrating the rest over to bug.sun.com in preparation for the the JIRA migration, afaik.

That is correct.  I've asked Tim to go over the Bugzilla issues as part 
of the effort to move the JDK to JIRA:

     https://blogs.oracle.com/darcy/entry/moving_monarchs_dragons

Bugzilla issues will be closed out if appropriate and patches, etc. 
moved from Bugzilla into the legacy bugtraq system so that they are then 
moved forward as a consequence of the bugtraq to JIRA migration.

HTH,

-Joe


From joe.darcy at oracle.com  Sat Jul 14 01:20:37 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 13 Jul 2012 18:20:37 -0700
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
In-Reply-To: <4FFEA51B.4030107@redhat.com>
References: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
	<4FFE758E.1000003@redhat.com>
	<CA+tXMXOC1wSrjrY3oGXcrGeAmMoMzj_w7b9cWszoXxJCuuiptQ@mail.gmail.com>
	<4FFEA51B.4030107@redhat.com>
Message-ID: <5000C965.7070101@oracle.com>

Hello,

Thanks for the patch Louis.

On 7/12/2012 3:21 AM, Andrew Haley wrote:
> On 07/12/2012 10:32 AM, Louis Wasserman wrote:
>> It was attached to the previous message?  I don't know if this list works
>> with attachments.  Alternately, the patch was attached here:
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100222
>>
>> I'm not sure what you mean by double-rounding bugs, though.  It's
>> not difficult to actually implement the HALF_EVEN rounding behavior
>> with bit twiddling.
> Sure, as long as you've thought about it and done it carefully.  The
> bit twiddling is easy to do, and easy to get wrong.
>
> > From the supplied patch it looks like you've done a good job, but
> there was no way to tell without it.  I presume the listserv dropped
> it on the floor.
>
> Andrew.

I've taken a quick look at the patch.  The concept for the change is 
good; the current path of converting to float/double through a string is 
a simple but very roundabout way to accomplish this task.

Unfortunately, I'm saturated with the JDK bug migration [1] and will 
continue to be saturated for at least several more weeks so I won't be 
able to take a more detailed look at the patch for a while.  I suspect 
some more directly test cases will be needed to test tricky rounding 
situations.

Thanks,

-Joe

[1] https://blogs.oracle.com/darcy/entry/moving_monarchs_dragons


From Alan.Bateman at oracle.com  Sat Jul 14 10:31:44 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Jul 2012 11:31:44 +0100
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <5000AA9C.6050601@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<4FFFE355.9090507@oracle.com> <5000AA9C.6050601@oracle.com>
Message-ID: <50014A90.6040506@oracle.com>

On 14/07/2012 00:09, Stuart Marks wrote:
>
> There is at least one test case that wants to create two registries 
> within the same JVM. The first call to createRegistry(0) will usually 
> succeed. The second call from the same JVM will throw an 
> ExportException. So, we catch this and retry using a random port 
> instead to create the second registry. If *that* fails we give up at 
> that point instead of retrying repeatedly.
Okay, so it's the export of the object that is the issue because the 
objID is based on the argument rather than the actual port. In that case 
would it make sense to switch to the factory method that takes the 
RMIServerSocketFactory as argument, something like:

   static class ServerSocketFactory implements RMIServerSocketFactory {
     public ServerSocket createServerSocket(int port) throws IOException 
{ return new ServerSocket(0); }
   }

   static class ClientSocketFactory implements RMIClientSocketFactory {
     public Socket createSocket(String host, int port) throws 
IOException { return new Socket(host, port); }
   }

   Registry registry = LocateRegistry.createRegistry(0, new 
ClientSocketFactory(), new ServerSocketFactory());

-Alan.




From forax at univ-mlv.fr  Sat Jul 14 11:47:39 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 14 Jul 2012 13:47:39 +0200
Subject: Update on alternative hashing for String keys with hash-based Maps
In-Reply-To: <B738006F-74A3-4208-A72C-7A6E90C4A30A@oracle.com>
References: <B738006F-74A3-4208-A72C-7A6E90C4A30A@oracle.com>
Message-ID: <50015C5B.1020806@univ-mlv.fr>

The other solution is for 7 to use murmur hash instead of classical hash 
but to always with the same seed, in that case it will not change from 
run to run.

cheers,
R?mi

On 07/14/2012 01:09 AM, Mike Duigou wrote:
> Hello all;
>
> About a month ago a significant change was made to the Java SE 7 and 8 hash based Map implementations. This change was previously proposed and discussed on this list[1]. The change affects all of the hashing based Map implementations (HashMap, Hashtable, WeakHashMap, LinkedHashMap, ConcurrentHashMap), the derived Set implementations (HashSet, LinkedHashSet, etc.) and other classes which depend upon these classes (Properties, UIDefaults). The change to hash based Maps improves performance when a large number of key hash code collisions are encountered. This is accomplished by altering the handling of String keys to use a different (better) hash function.
>
> As initially proposed, the alternative hashing behaviour was planned to apply to all hash based Maps larger than 512 elements. Smaller maps would continue to use the existing hashing approach. ConcurrentHashMap, because reasons related to the complexity of it's implementation, would always use the improved approach regardless of map capacity. Providing capacity based triggering of the alternative hashing is intended to improve compatibility by ensuring that the order in which elements are iterated does not change. Specifically, at less than the threshold capacity Map elements will be iterated in the same order as today. At or above the threshold, the iteration order will be different than the current order. Testing and evaluation of existing Java applications has shown us that some applications have explicit or implicit dependence upon the order that keys, values or entries will be iterated. The vast majority of iteration order dependent cases involve small maps--once a map contains hundreds of elements generally incorrect assumptions about iteration order will have already been found and resolved. We believed that triggering the alternative hashing behaviour at 512 element capacity would protect iteration order in cases which depended upon the existing iteration order. Java SE 7 and Java SE 8 have different policies. Java SE 8 is intended to always use alternative hashing of String keys regardless of the capacity of the Map.
>
> After  integration a number of cases of iteration order dependence were encountered within the OpenJDK code itself, in tests and in user code. Some of these faults were easily diagnosed and correct. Some other cases, because iteration order is not consistent from run-to-run under alternative hashing, proved difficult to isolate and resolve.
>
> Following this testing and and consultation with Java licensees and developers it was decided disable the alternative hashing behaviour for Java SE 7.  To ensure the greatest degree of compatibility with existing applications it seems best to only enable alternative hashing by explicit control. In Java SE 7u6 it will be necessary to set the system property jdk.map.althashing.threshold in order to enable alternative hashing. It is also still possible that the feature may be enabled by default in future Java SE 7 releases but this will only happen if further testing indicates compatibility can be reasonably assured.
>
> Because Java 8 is unreleased and we still wish to shake out iteration order dependencies alternative hashing remains enabled in Java SE 8. Alternative hashing is very likely to be enabled by default in Java SE 8. Doug Lea has been investigating further improvements to handling of key hash code collisions and his design is extremely likely to be the basis for all Java SE 8 hash based Map implementations.[2]
>
> Developers and deployers are strongly encouraged to test their applications by enabling the alternative String key hashing feature in Java SE 7u6 or later and/or testing with Java SE 8 builds. BE WARNED: it will probably not be possible to disable alternative hashing in Java SE 8. Applications MUST remove dependencies upon iteration order before they can be deployed with Java SE 8.
>
> Thanks,
>
> Mike
>
> TL;DR:
> - Java SE 7 and 8 both now support alternative hashing for String keys with hash based Maps
> - Alternative hashing improves performance when many String key hash codes collide
> - Alternative hashing impacts key, value and element iteration order
> - Alternative hashing is currently DISABLED by default for Java SE 7
> - Future Java SE 7 releases may enable alternative hashing for "large" (>512 capacity) maps
> - Developers can enable the eature in Java SE 7 for testing and deployment with a system property
> - Alternative hashing is ENABLED for all maps in Java SE 8
> - It will probably not be possible to disable alternative hashing in Java SE 8
> - Hash map key, value and element iteration order WILL be different and unpredictable in Java SE 8
> - Different implementation approaches are still being investigated for Java SE 8 and remain subject to change
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010238.html
> [2] http://cs.oswego.edu/pipermail/concurrency-interest/2012-June/009505.html





From wasserman.louis at gmail.com  Sat Jul 14 12:32:07 2012
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Sat, 14 Jul 2012 13:32:07 +0100
Subject: [PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(),
	floatValue()
In-Reply-To: <5000C965.7070101@oracle.com>
References: <CA+tXMXMAAVXNf6Lc+EeVP_iHVP+49rW38MekPYWgU0QUD1SNRw@mail.gmail.com>
	<4FFE758E.1000003@redhat.com>
	<CA+tXMXOC1wSrjrY3oGXcrGeAmMoMzj_w7b9cWszoXxJCuuiptQ@mail.gmail.com>
	<4FFEA51B.4030107@redhat.com> <5000C965.7070101@oracle.com>
Message-ID: <CA+tXMXOZU-i9pkndhSURs=bqaj9jOc9sQw1Jk2QVWUog5GaPdg@mail.gmail.com>

Understood.  FYI, testing for this change revealed a bug in
Float.parseFloat, a patch for which has been separately sent to this
mailing list under the subject line "[PATCH] Sunbug 6358355: Rounding error
in Float.parseFloat".  (As a result, the BigInteger patch may fail some of
the provided tests at the moment, but that is truly because the reference
implementation it's being tested against is faulty.)

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis


On Sat, Jul 14, 2012 at 2:20 AM, Joseph Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Thanks for the patch Louis.
>
>
> On 7/12/2012 3:21 AM, Andrew Haley wrote:
>
>> On 07/12/2012 10:32 AM, Louis Wasserman wrote:
>>
>>> It was attached to the previous message?  I don't know if this list works
>>> with attachments.  Alternately, the patch was attached here:
>>> https://bugs.openjdk.java.net/**show_bug.cgi?id=100222<https://bugs.openjdk.java.net/show_bug.cgi?id=100222>
>>>
>>> I'm not sure what you mean by double-rounding bugs, though.  It's
>>> not difficult to actually implement the HALF_EVEN rounding behavior
>>> with bit twiddling.
>>>
>> Sure, as long as you've thought about it and done it carefully.  The
>> bit twiddling is easy to do, and easy to get wrong.
>>
>> > From the supplied patch it looks like you've done a good job, but
>> there was no way to tell without it.  I presume the listserv dropped
>> it on the floor.
>>
>> Andrew.
>>
>
> I've taken a quick look at the patch.  The concept for the change is good;
> the current path of converting to float/double through a string is a simple
> but very roundabout way to accomplish this task.
>
> Unfortunately, I'm saturated with the JDK bug migration [1] and will
> continue to be saturated for at least several more weeks so I won't be able
> to take a more detailed look at the patch for a while.  I suspect some more
> directly test cases will be needed to test tricky rounding situations.
>
> Thanks,
>
> -Joe
>
> [1] https://blogs.oracle.com/**darcy/entry/moving_monarchs_**dragons<https://blogs.oracle.com/darcy/entry/moving_monarchs_dragons>
>


From Alan.Bateman at oracle.com  Sat Jul 14 15:11:27 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Jul 2012 16:11:27 +0100
Subject: Update on alternative hashing for String keys with hash-based Maps
In-Reply-To: <50015C5B.1020806@univ-mlv.fr>
References: <B738006F-74A3-4208-A72C-7A6E90C4A30A@oracle.com>
	<50015C5B.1020806@univ-mlv.fr>
Message-ID: <50018C1F.7010200@oracle.com>

On 14/07/2012 12:47, R?mi Forax wrote:
> The other solution is for 7 to use murmur hash instead of classical 
> hash but to always with the same seed, in that case it will not change 
> from run to run.
That would restore predictability but I assume opens up the possibility 
of collisions again (albeit much harder to do).

In any case, I think Doug's work in the latest CHM is very promising, 
lots of advantages.

-Alan.



From kumar.x.srinivasan at oracle.COM  Sat Jul 14 19:32:12 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Sat, 14 Jul 2012 12:32:12 -0700
Subject: Please review: 7184145 pack200 NPE
Message-ID: <5001C93C.5060200@oracle.COM>

Hi,

Please review the following bug, it is not yet available on bugs.sun.com,
there is a discussion thread jdk7u-dev at openjdk.java.net

http://cr.openjdk.java.net/~ksrini/7184145/


Thanks
Kumar



From Alan.Bateman at oracle.com  Sat Jul 14 20:34:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Jul 2012 21:34:31 +0100
Subject: Please review: 7184145 pack200 NPE
In-Reply-To: <5001C93C.5060200@oracle.COM>
References: <5001C93C.5060200@oracle.COM>
Message-ID: <5001D7D7.2000700@oracle.com>

On 14/07/2012 20:32, Kumar Srinivasan wrote:
> Hi,
>
> Please review the following bug, it is not yet available on bugs.sun.com,
> there is a discussion thread jdk7u-dev at openjdk.java.net
>
> http://cr.openjdk.java.net/~ksrini/7184145/
The change looks good to me, thanks for sorting it out quickly. I guess 
we'll see if it can be fixed in 7u6 too.

The only comment I have on the webrev is the term "orphan" in the test 
seems a bit odd, I guess I would have said "tests repacking of a jarfile 
specified by a simple file name". It's not an interesting point so 
thumbs up from me.

-Alan


From Ulf.Zibis at CoSoCo.de  Sat Jul 14 22:02:58 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sun, 15 Jul 2012 00:02:58 +0200
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50009A54.4060300@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
	<50007576.7030607@CoSoCo.de> <50009A54.4060300@oracle.com>
Message-ID: <5001EC92.70708@CoSoCo.de>

Am 13.07.2012 23:59, schrieb Dalibor Topic:
> Tim is going through then issues in Bugzilla and closing the already fixed ones, and migrating the rest over to bug.sun.com in preparation for the the JIRA migration, afaik.

So if I understand Joe correct, the patches form bugs.openjdk.java.net have been copied to the 
appropriate bug.sun.com bugs, and later will be again publicly visible after migration to JIRA. So 
bugs.openjdk.java.net will be no more used as an interim solution to file patches.
Please correct me if I'm wrong.

>> I'm in a kind of vacation from OpenJDK development. One reason is the missing appreciation from official side. All attempts to at least have an account on http://cr.openjdk.java.net/, for easier publishing webrevs, have ended in *no answer* regardless my activity:
>> See [Who Sent It?] on: http://markmail.org/search/+list:net.java.openjdk.core-libs-dev
> If this patch is eventually headed for JDK 7 Updates, I could grant you an Author role there, if you wish.

Thanks, that would be great. Please use the email of above From: field, not my old GMX address.

-Ulf



From xueming.shen at oracle.com  Sat Jul 14 23:45:41 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 14 Jul 2012 16:45:41 -0700
Subject: Please review: 7184145 pack200 NPE
In-Reply-To: <5001C93C.5060200@oracle.COM>
References: <5001C93C.5060200@oracle.COM>
Message-ID: <500204A5.5070105@oracle.com>

On 7/14/12 12:32 PM, Kumar Srinivasan wrote:
> Hi,
>
> Please review the following bug, it is not yet available on bugs.sun.com,
> there is a discussion thread jdk7u-dev at openjdk.java.net
>
> http://cr.openjdk.java.net/~ksrini/7184145/
>
>
> Thanks
> Kumar
>

looks fine for me.

-Sherman


From kumar.x.srinivasan at oracle.COM  Sun Jul 15 00:43:07 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Sat, 14 Jul 2012 17:43:07 -0700
Subject: Please review: 7184145 pack200 NPE
In-Reply-To: <5001D7D7.2000700@oracle.com>
References: <5001C93C.5060200@oracle.COM> <5001D7D7.2000700@oracle.com>
Message-ID: <5002121B.2090301@oracle.COM>

Ok took care of it.

Thanks
Kumar

> On 14/07/2012 20:32, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review the following bug, it is not yet available on 
>> bugs.sun.com,
>> there is a discussion thread jdk7u-dev at openjdk.java.net
>>
>> http://cr.openjdk.java.net/~ksrini/7184145/
> The change looks good to me, thanks for sorting it out quickly. I 
> guess we'll see if it can be fixed in 7u6 too.
>
> The only comment I have on the webrev is the term "orphan" in the test 
> seems a bit odd, I guess I would have said "tests repacking of a 
> jarfile specified by a simple file name". It's not an interesting 
> point so thumbs up from me.
>
> -Alan



From kumar.x.srinivasan at oracle.com  Sun Jul 15 03:27:42 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Sun, 15 Jul 2012 03:27:42 +0000
Subject: hg: jdk8/tl/jdk: 7184145: (pack200) pack200 --repack throws
	NullPointerException when JAR file specified without path
Message-ID: <20120715032804.575674705F@hg.openjdk.java.net>

Changeset: 9e5150e8bcf5
Author:    ksrini
Date:      2012-07-14 18:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e5150e8bcf5

7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path
Reviewed-by: alanb, sherman

! src/share/classes/com/sun/java/util/jar/pack/Driver.java
+ test/tools/pack200/RepackTest.java



From kurchi.subhra.hazra at oracle.com  Sun Jul 15 18:54:33 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Sun, 15 Jul 2012 11:54:33 -0700
Subject: Code Review Request: 7183800: TEST_BUG: Update tests to run on Ubuntu
	12.04 (localhost is 127.0.1.1)
Message-ID: <500311E9.4070809@oracle.com>

Hi,

    Some tests in our test repository assume that 
InetAddress.getLocalHost() will return 127.0.0.1. However, with
linux systems running Ubuntu 12.04 now returning 127.0.1.1 as localhost, 
these tests are failing. I have changed two
of the NIO tests to remove their dependency on 
InetAddress.getLocalHost(). A third test has been added to
the ProblemList.txt since the changes required for it are more involved.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800
Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/


Thanks,
Kurchi



From chris.hegarty at oracle.com  Sun Jul 15 21:52:44 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 15 Jul 2012 22:52:44 +0100
Subject: Code Review Request: 7183800: TEST_BUG: Update tests to run on
	Ubuntu 12.04 (localhost is 127.0.1.1)
In-Reply-To: <500311E9.4070809@oracle.com>
References: <500311E9.4070809@oracle.com>
Message-ID: <50033BAC.1020205@oracle.com>

Kurchi,

I don't have any problem with the source changes ( they make sense ), 
but I don't see why they are necessary.

The listening socket is bound to the wildcard address, so sending to the 
local address should work. I guess this is some kind of (default 
configuration error/issue). Anyway, your test changes are fine.

Adding the third test to the problem list makes sense ( as you say, it 
will require a more involved fix ), but you should create a new separate 
bug number for it and add it to the comment in the ProblemList. It may 
be a little confusing to see this bug number in the comment when the bug 
database will show it as fixed.

-Chris.

On 15/07/12 19:54, Kurchi Subhra Hazra wrote:
> Hi,
>
> Some tests in our test repository assume that InetAddress.getLocalHost()
> will return 127.0.0.1. However, with
> linux systems running Ubuntu 12.04 now returning 127.0.1.1 as localhost,
> these tests are failing. I have changed two
> of the NIO tests to remove their dependency on
> InetAddress.getLocalHost(). A third test has been added to
> the ProblemList.txt since the changes required for it are more involved.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800
> Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/
>
>
> Thanks,
> Kurchi
>


From xueming.shen at oracle.com  Sun Jul 15 22:12:14 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 15 Jul 2012 15:12:14 -0700
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
Message-ID: <5003403E.3070701@oracle.com>

Hi

This changeset includes the migration of our JIS0201/0208/0212 based single/
double-byte charsets to the new mapping based implementation.  This is the
left-over of the effort we put in JDK7 to re-implement most of our 
charsets in
charsets.jar to (1)have better performance (2) small storage foot print 
and (3)
ease the maintenance burden.

http://cr.openjdk.java.net/~sherman/6653797/webrev/

Notes of the implementation:

(1) jis0201/0208/0212 and their variants are now generated from the 
mapping table
during the build time. (See those new .map *.nr and *.c2b tables)

(2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now 
using these
new jis0201/02080212 charsets.

(3) Those in red (in webrev) are the old implementation, since no 
charset uses them
anymore, I removed them from the repository)

(4) There are two approaches for PCK and SJIS. PCK.java_v1 and 
SJIS.java_v1 are the
one that follows the old implementation, which decode/encodes base on the
jis0201/0208 (and the variants) mapping via Ken's algorithm. This is 
known to be
slow and buggy (the algothrim does not take care of illegal sjis cp, see 
#6653797
and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java)
So in this charset, I generated the direct mapping tables for sjis and 
pck and use
the "general" DoubleByte base class for these two charsets. This results 
in much
faster decoding/encoding and correct mapping for all code points. The 
downside
of this approach is that it adds about 50k uncompressed side to the 
charsets.jar.
But given this change actually reduces about 300K from the rt.jar, we 
still get
a net 250K, so I decided to go with this approach for better performance.

It appears to be lots of files (80+) in the webrev, but that number 
includes the
removed old implementation and the tests I put in to guarantee the identical
de/encoding result from the old and new implementations (those OLD... test
cases), the change is actually not that big:-) So please help review. I 
can then
put this multi-year efforts into rest.

-Sherman







From Alan.Bateman at oracle.com  Mon Jul 16 10:56:39 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jul 2012 11:56:39 +0100
Subject: Code Review Request: 7183800: TEST_BUG: Update tests to run on
	Ubuntu 12.04 (localhost is 127.0.1.1)
In-Reply-To: <500311E9.4070809@oracle.com>
References: <500311E9.4070809@oracle.com>
Message-ID: <5003F367.20708@oracle.com>

On 15/07/2012 19:54, Kurchi Subhra Hazra wrote:
> Hi,
>
>    Some tests in our test repository assume that 
> InetAddress.getLocalHost() will return 127.0.0.1. However, with
> linux systems running Ubuntu 12.04 now returning 127.0.1.1 as 
> localhost, these tests are failing. I have changed two
> of the NIO tests to remove their dependency on 
> InetAddress.getLocalHost(). A third test has been added to
> the ProblemList.txt since the changes required for it are more involved.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800
> Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/
>
As Chris pointed out, these tests bind to the wildcard address and you 
need a specific address to setup the address association, otherwise it's 
highly platform/implementation specific as to whether it will do as 
intended. So I think the proposed changes will cause problems where you 
can't connect to 0.0.0.0 and so I think we need to look for another 
solution.

Given that none of the TCP tests fail then it suggests it mean that 
something else is going on, maybe something in the Ubuntu 12 
configuration. Do these tests run if IPv6 is disabled? We've had issues 
with some distributions where multicast tests fail and these have always 
come down to iptables blocking IPv6 multicast packets causing the tests 
to fail. I just wonder if we have something similar here.

-Alan



From stuart.marks at oracle.com  Mon Jul 16 15:42:28 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 16 Jul 2012 08:42:28 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <500087AE.7070501@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<500087AE.7070501@oracle.com>
Message-ID: <50043664.90306@oracle.com>

Hi Darryl,

Sorry, I'm going to have to ask you to update this again. The issues are in 
TestLibrary.java and are all related to catching exceptions and throwing new 
exception instances, discarding the original exception (and probably relevant 
diagnostic information) in the process.

Let's get together today and work on it. I expect it will take only half an 
hour or so to knock things out.

s'marks




On 7/13/12 1:40 PM, Darryl Mocek wrote:
>
> On 07/12/2012 05:13 PM, Stuart Marks wrote:
>> OK, I took a look at the revised webrev. Most stuff is good. A couple changes
>> are necessary though.
>>
>>
>> *** MultipleRegistries.java
>>
>>
>> Not a big deal, but the comment at lines 65-67 is no longer necessary.
> Comment removed.
>>
>>
>> *** TestLibrary.java
>>
>>
>> I think the reserved port range stuff still needs to be fixed up.
>>
>> The comment at lines 81-82 talks about a range 64000-64100 which isn't really
>> present anywhere. The comment should instead say that PORT_MIN and PORT_MAX
>> should be kept adjusted so that they specify the range of ports defined by
>> the constants following. Make sure to do this adjustment; PORT_MAX is 64002
>> here.
> I reserved ports 64000-64100 (even though only 64001-64005 are currently being
> used) for fixed port tests (for tests which require fixed ports) so any future
> tests which require fixed ports can be assured there are ports available within
> a range for their use. In fixing the tests, I saw that those who wrote tests
> and used fixed ports grabbed random port numbers all over the place. Providing
> a reserved range allows them to just grab the next number and to keep the fixed
> port numbers in a group, even when new tests are added. If the ports are
> defined in a central place, like TestLibrary, then hopefully developers will
> come to TestLibrary to reserve the ports rather then define them in the tests
> themselves, like was done previously. I chose 100 ports for
> "future-proofing"...I don't think 100 is too many, but I've reduced it to 10
> and lowered the max to 64010. I was also thinking of looking for tests which
> used fixed ports outside of RMI tests and standardizing those ports here, but
> that's possible future work and I'm not sure it's necessary.
>>
>> The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000
>> as the *allowed* range for ports returned by getUnusedRandomPort(). But as I
>> described previously, this is difficult to enforce given the varying port
>> allocation schemes on different OSes.
>>
>> Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX
>> and make it be the range of ports reserved by tests that require fixed ports
>> (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to
>> *disallow* ports in this range, that is, to retry if the port is within this
>> range. Thus the condition on the while-loop has to be inverted, something like
>>
>> while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= PORT_MAX)
> Yes, this is correct and it has been changed.
>>
>> So, how could getUnusedRandomPort() have worked in its present state? Well I
>> think it ends up retrying 10 times, then at the end of the loop
>> unusedRandomPort is actually some legal port number -- albeit possibly one
>> within the disallowed range -- and almost certainly not -1, and so the method
>> returns it and the caller uses it. So, the success-testing logic here will
>> also have to change so that it retests whether the port is in the disallowed
>> range.
> Correct...done.
>>
>> The comment on getUnusedRandomPort() also needs to be updated to reflect its
>> new policy on the reserved range, as well as throwing an exception on
>> failure. Also (nitpick) it should say "less than" not "less then".
> Yes, I always do this. :(
>>
>> Looking at getUnusedRandomPort() again more closely [sorry] I think the catch
>> of Exception that does nothing is suspicious. I'm not sure why getting a
>> ServerSocket would fail, but if it does (maybe the system is out of ports??)
>> we should just throw out to the caller. Perhaps ideally we'd just have this
>> method throw IOException, but if that requires all callers to be updated, it
>> might be easier just to catch IOException and throw a RuntimeException that
>> wraps the caught IOException.
> I see no harm in trying again if it fails. If we have run out of ports, then
> possibly one or more used ports will be closed and freed and a subsequent try
> will succeed. I don't know all of the cases where a failure might occur.
> Anyway, if this is the prevailing way of handling this, I'll change it.
>>
>> Similar comments apply to the catch(Exception)/do-nothing code in the other
>> utility methods.
> Now throwing RuntimeException in getRegistryPort.
>>
>> Certainly getRegistryPort() should just throw (or possibly wrap and rethrow)
>> any exception caught.
>>
>> For createRegistryOnUnusedPort(), the catching of ExportException is handled
>> properly. The second catch clause of the outer try-block, and the catch of
>> the inner try-block, both ignore exceptions. The code will then end up
>> retrying. Is it reasonable that retrying in these cases will result in a
>> different outcome? My guess is that it's more likely that something is
>> seriously wrong that will cause all the retries to fail, in which case this
>> method will discard the exceptions it has just caught and throw a *new*
>> RemoteException instance.
> This was a holdover from webrev.00 which should have been removed. I agree with
> Alan and you here that multiple tries of LocateRegistry.createRegistry(0) is
> unnecessary. I've modified this to make a single attempt at using
> LocateRegistry.createRegistry(0) and if it fails, make a single attempt at
> getting an unused random port and creating a registry on this port, then
> failing with a RuntimeException.
>>
>> I'm particularly sensitive to this; as you might recall a couple weeks ago I
>> was having a wrestling match with the jstatd tests (I finished the match, but
>> I'm not sure I won). The primary problem was that several layers of code
>> would catch and discard exceptions, which made diagnosing the problem
>> incredibly difficult. So, I'd recommend removing the "do nothing" catch clauses.
>>
>> Thinking further about createRegistryOnUnusedPort(), I'm not sure that
>> retrying 10 (or some other number of times) actually makes sense. It does for
>> getUnusedRandomPort(), which has to retry in order to get a port outside the
>> disallowed range. But for creating a registry, createRegistry(0) will usually
>> work the first time. If it throws ExportException, it does so for a specific
>> reason, so we should retry once on an unused random port. But if this still
>> fails, don't think retrying repeatedly makes sense.
> See above.
>
> Changes pass all tests. Updated webrev at
> http://cr.openjdk.java.net/~dmocek/7142596/webrev.04
>
> Darryl
>>
>> s'marks
>>
>>
>>
>>
>> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>>
>>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>>> OK, here's the review for the second half of the files in the webrev. I saw
>>>> your reply to the first half (to which I'll reply separately), and I don't
>>>> think there's anything here that's affected by them.
>>>>
>>>>
>>>> *** AppleUserImpl.java
>>>> *** ApplicationServer.java
>>>>
>>>>
>>>> REGISTRY_PORT should be a local variable; also rename to use mixed case.
>>> Changed to a private registryPort (see next issue).
>>>>
>>>> Eh, whoops, after looking at ApplicationServer.java I see that it accesses
>>>> the REGISTRY_PORT field directly. This is why direct field access is a bad
>>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized before
>>>> ApplicationServer needs it? It turns out that it has been -- but only in some
>>>> cases.
>>>>
>>>> It seems like the test is trying to support two modes, one that runs in two
>>>> threads in the same JVM, and the other that runs in two separate JVMs. If
>>>> they are in separate JVMs, things will no longer work because in the JVM that
>>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be -1. I
>>>> suspect that our test environment doesn't support the separate JVM mode, but
>>>> it seems unwise to break it.
>>>>
>>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>>> "well-known" default registry port number, which in this case seems like 2006.
>>>>
>>>> In single-JVM mode, AppleUserImpl creates an instance of ApplicationServer,
>>>> so I'd suggest adding a method to ApplicationServer that allows AppleUserImpl
>>>> to store the randomly-assigned registry port number into it, overriding the
>>>> default value.
>>>>
>>>> This seems like this is the simplest way to preserve the two modes of
>>>> operation but to support the random port selection model we're trying to
>>>> achieve.
>>> Rather then going the "fixed port" route, which is what we're trying to get
>>> away from, I've changed the implementation of both AppletUserImpl's and
>>> ApplicationServer so ApplicationServer requires a port and AppleUserImpl
>>> supplies the port on construction of ApplicationServer. I thought of modifying
>>> ApplicationServer's constructor to create a port using
>>> TestLibrary.getUnusedRandomPort, but decided requiring a port is better as
>>> ApplicationServer's job is to look for already exported AppleUser objects.
>>>>
>>>>
>>>> *** activatable/EchoImpl.java
>>>>
>>>>
>>>> int registryPort = new Integer(System.getProperty("rmi.registry.port"));
>>>>
>>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not a huge
>>>> deal, but it's probably more conventional to use parseInt() and it avoids
>>>> boxing.
>>>>
>>>> One could probably do Integer.getInteger("rmi.registry.port") but this is
>>>> seems pretty obscure to me even though it's more succinct.
>>>>
>>>> The same also applies to the following:
>>>> - HelloImpl.java
>>>> - unicast/EchoImpl.java
>>>> - ShutdownImpl.java
>>>> - SelfTerminator.java
>>>> - CheckFQDNClient.java
>>>> - LeaseLeakClient.java
>>>> - dgcDeadLock/TestImpl.java
>>>>
>>> Integer.parseInt returns a primitive (which is what the return is assigned to)
>>> and it appears Integer.parseInt is "faster" then creating a new Integer.
>>> Changed to Integer.parseInt in all places referenced.
>>>>
>>>> *** FiniteGCLatency.java
>>>>
>>>>
>>>> The pattern here is a bit odd, as the test creates the registry, throws away
>>>> the returned reference, and then calls getRegistry() to get another Registry
>>>> reference. It *seems* like they're identical references, but in fact the
>>>> first is apparently a reference to the actual Registry implementation,
>>>> whereas the second is a remote stub.
>>>>
>>>> The tests seem to do all the actual work using the remote stub, which seems
>>>> proper.
>>>>
>>>> This is confusing, though, as it looks like there's a redundant Registry
>>>> reference now. This might lead someone in the future to "simplify" the test
>>>> by not getting the remote stub, which in turn might invalidate some tests.
>>>> (In fact I was going to suggest this but I decided to investigate further
>>>> first.)
>>>>
>>>> At the very least, I'd suggest renaming the variable that holds the newly
>>>> created Registry to something like "registryImpl" to make it clear that it's
>>>> different from the thing returned by getRegistry(), even though they have a
>>>> the same time.
>>>>
>>>> Another possibility is to rearrange the TestLibrary API so that there is a
>>>> single utility method that combines createRegistryOnUnusedPort() and
>>>> getRegistryPort(). That is, it creates a new registry and simply returns the
>>>> port on which it was created, not a reference to the registry implementation.
>>>> I don't think the registry implementation is actually ever used by the tests,
>>>> and it might simplify things a bit as well.
>>>>
>>>> Possibly similar issues with:
>>>> - UnreferencedContext.java
>>>> - NoConsoleOutput.java
>>>>
>>>>
>>>> *** HttpSocketTest.java
>>>>
>>>>
>>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>>> Looks like extra code left over from the change from using
>>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) to
>>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>>
>>>>
>>>> *** TestLibrary.java
>>>>
>>>> Mostly pretty straightforward, but I do have some concerns about the random
>>>> port selection and a potential clash with the "reserved port range" as
>>>> defined in this test library.
>>>>
>>>> The getUnusedRandomPort() method attempts to get a socket within the range
>>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS
>>>> allocates ports more-or-less sequentially in the range [49152, 65536) which
>>>> means that when the kernel's internal counter gets to 64000,
>>>> getUnusedRandomPort()'s retries will fail, causing tests to fail until the
>>>> counter wraps around.
>>>>
>>>> Other systems behave differently; Linux seems to allocate them randomly in
>>>> the range [32768,65536) and Windows XP SP3 allocates them sequentially in the
>>>> range (1024,5000]. So it's probably not a problem for them.
>>>>
>>>> I think the thing to do is to check only for "reserved ports" that are
>>>> actually used by tests here. These are in the range [64001,64005]. In
>>>> getUnusedRandomPort(), it should only need to retry if the returned port is
>>>> within this narrow, reserved range. If it's anything else it should be OK.
>>> I'll try setting the range this narrow, but I don't know how many sequential
>>> tests will be run at a time and I'm concerned 5 is too few. The -concurrency
>>> option on jtreg allows you to specify how many concurrent tests will be run. We
>>> should have enough test ports reserved to satisfy any concurrency request. I've
>>> run the tests with -concurrency=8 (I have a dual-core system showing 4 CPU's).
>>> I tried reducing the port range to 64001/64002 and concurrency=4 and all passed
>>> fine, so maybe we're OK with just 5.
>>>>
>>>> On another topic, the three utility methods here:
>>>> - createRegistryOnUnusedPort
>>>> - getRegistryPort
>>>> - getUnusedRandomPort
>>>>
>>>> all catch exceptions and then return illegal values (null or -1), sometimes
>>>> after printing some diagnostic information. The problem is that the caller
>>>> will attempt to soldier on with the illegal return value and will stumble
>>>> over something later, such as NullPointerException or
>>>> IllegalArgumentException. This will probably be obvious but it's equally
>>>> likely to be confusing.
>>>>
>>>> Since these utilities are all called from test code, and the tests are
>>>> relying on them to return valid results, I'd suggest just throwing exceptions
>>>> from the utility methods if they fail. This will (should) cause the test to
>>>> error out, but that's OK, as it never could have succeeded anyway if the
>>>> utility call had failed.
>>> I already modified createRegistryOnUnusedPort to throw an exception as part of
>>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>>> getRegistryPort and getUnusedRandomPort if they fail.
>>>
>>> See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>>
>>> Darryl
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and 7161503.
>>>>> Webrev can be found here:
>>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>>> This commit fixes concurrency issues with the RMI tests.
>>>>>
>>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>>>>> RMIRegistry on an unused port. It will try up to 10 times before giving up.
>>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the port number
>>>>> of the registry.
>>>>> - Changed almost all tests from using hard port numbers to using random port
>>>>> numbers for running the RMI Registry and RMID.
>>>>> - Removed othervm from those tests which don't need it.
>>>>> - Added parameters for tests which spawn a separate VM to pass RMI
>>>>> Registry and
>>>>> RMID ports in cases where needed.
>>>>> - Added PropertyPermission to security policy files where needed.
>>>>> - Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
>>>>> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>>>>>
>>>>> Thanks,
>>>>> Darryl
>>>>>
>>>
>>>
>
>


From darryl.mocek at oracle.com  Mon Jul 16 16:33:50 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 16 Jul 2012 09:33:50 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <50043664.90306@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<500087AE.7070501@oracle.com> <50043664.90306@oracle.com>
Message-ID: <5004426E.5070108@oracle.com>

After looking at it again, technically, we ought to remove the fixed 
ports from the list of ports available to the RMI Registry (OK, so this 
isn't a BIG deal).  Using SocketFactory's as Alan suggests will solve 
this problem as well.

Darryl

On 07/16/2012 08:42 AM, Stuart Marks wrote:
> Hi Darryl,
>
> Sorry, I'm going to have to ask you to update this again. The issues 
> are in TestLibrary.java and are all related to catching exceptions and 
> throwing new exception instances, discarding the original exception 
> (and probably relevant diagnostic information) in the process.
>
> Let's get together today and work on it. I expect it will take only 
> half an hour or so to knock things out.
>
> s'marks
>
>
>
>
> On 7/13/12 1:40 PM, Darryl Mocek wrote:
>>
>> On 07/12/2012 05:13 PM, Stuart Marks wrote:
>>> OK, I took a look at the revised webrev. Most stuff is good. A 
>>> couple changes
>>> are necessary though.
>>>
>>>
>>> *** MultipleRegistries.java
>>>
>>>
>>> Not a big deal, but the comment at lines 65-67 is no longer necessary.
>> Comment removed.
>>>
>>>
>>> *** TestLibrary.java
>>>
>>>
>>> I think the reserved port range stuff still needs to be fixed up.
>>>
>>> The comment at lines 81-82 talks about a range 64000-64100 which 
>>> isn't really
>>> present anywhere. The comment should instead say that PORT_MIN and 
>>> PORT_MAX
>>> should be kept adjusted so that they specify the range of ports 
>>> defined by
>>> the constants following. Make sure to do this adjustment; PORT_MAX 
>>> is 64002
>>> here.
>> I reserved ports 64000-64100 (even though only 64001-64005 are 
>> currently being
>> used) for fixed port tests (for tests which require fixed ports) so 
>> any future
>> tests which require fixed ports can be assured there are ports 
>> available within
>> a range for their use. In fixing the tests, I saw that those who 
>> wrote tests
>> and used fixed ports grabbed random port numbers all over the place. 
>> Providing
>> a reserved range allows them to just grab the next number and to keep 
>> the fixed
>> port numbers in a group, even when new tests are added. If the ports are
>> defined in a central place, like TestLibrary, then hopefully 
>> developers will
>> come to TestLibrary to reserve the ports rather then define them in 
>> the tests
>> themselves, like was done previously. I chose 100 ports for
>> "future-proofing"...I don't think 100 is too many, but I've reduced 
>> it to 10
>> and lowered the max to 64010. I was also thinking of looking for 
>> tests which
>> used fixed ports outside of RMI tests and standardizing those ports 
>> here, but
>> that's possible future work and I'm not sure it's necessary.
>>>
>>> The previous webrev had PORT_MIN and PORT_MAX specify a range of 
>>> 1024-64000
>>> as the *allowed* range for ports returned by getUnusedRandomPort(). 
>>> But as I
>>> described previously, this is difficult to enforce given the varying 
>>> port
>>> allocation schemes on different OSes.
>>>
>>> Instead I think we need to invert the sense of the range 
>>> PORT_MIN..PORT_MAX
>>> and make it be the range of ports reserved by tests that require 
>>> fixed ports
>>> (64001 through 64005). Then, getUnusedRandomPort() needs to be 
>>> changed to
>>> *disallow* ports in this range, that is, to retry if the port is 
>>> within this
>>> range. Thus the condition on the while-loop has to be inverted, 
>>> something like
>>>
>>> while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= 
>>> PORT_MAX)
>> Yes, this is correct and it has been changed.
>>>
>>> So, how could getUnusedRandomPort() have worked in its present 
>>> state? Well I
>>> think it ends up retrying 10 times, then at the end of the loop
>>> unusedRandomPort is actually some legal port number -- albeit 
>>> possibly one
>>> within the disallowed range -- and almost certainly not -1, and so 
>>> the method
>>> returns it and the caller uses it. So, the success-testing logic 
>>> here will
>>> also have to change so that it retests whether the port is in the 
>>> disallowed
>>> range.
>> Correct...done.
>>>
>>> The comment on getUnusedRandomPort() also needs to be updated to 
>>> reflect its
>>> new policy on the reserved range, as well as throwing an exception on
>>> failure. Also (nitpick) it should say "less than" not "less then".
>> Yes, I always do this. :(
>>>
>>> Looking at getUnusedRandomPort() again more closely [sorry] I think 
>>> the catch
>>> of Exception that does nothing is suspicious. I'm not sure why 
>>> getting a
>>> ServerSocket would fail, but if it does (maybe the system is out of 
>>> ports??)
>>> we should just throw out to the caller. Perhaps ideally we'd just 
>>> have this
>>> method throw IOException, but if that requires all callers to be 
>>> updated, it
>>> might be easier just to catch IOException and throw a 
>>> RuntimeException that
>>> wraps the caught IOException.
>> I see no harm in trying again if it fails. If we have run out of 
>> ports, then
>> possibly one or more used ports will be closed and freed and a 
>> subsequent try
>> will succeed. I don't know all of the cases where a failure might occur.
>> Anyway, if this is the prevailing way of handling this, I'll change it.
>>>
>>> Similar comments apply to the catch(Exception)/do-nothing code in 
>>> the other
>>> utility methods.
>> Now throwing RuntimeException in getRegistryPort.
>>>
>>> Certainly getRegistryPort() should just throw (or possibly wrap and 
>>> rethrow)
>>> any exception caught.
>>>
>>> For createRegistryOnUnusedPort(), the catching of ExportException is 
>>> handled
>>> properly. The second catch clause of the outer try-block, and the 
>>> catch of
>>> the inner try-block, both ignore exceptions. The code will then end up
>>> retrying. Is it reasonable that retrying in these cases will result 
>>> in a
>>> different outcome? My guess is that it's more likely that something is
>>> seriously wrong that will cause all the retries to fail, in which 
>>> case this
>>> method will discard the exceptions it has just caught and throw a *new*
>>> RemoteException instance.
>> This was a holdover from webrev.00 which should have been removed. I 
>> agree with
>> Alan and you here that multiple tries of 
>> LocateRegistry.createRegistry(0) is
>> unnecessary. I've modified this to make a single attempt at using
>> LocateRegistry.createRegistry(0) and if it fails, make a single 
>> attempt at
>> getting an unused random port and creating a registry on this port, then
>> failing with a RuntimeException.
>>>
>>> I'm particularly sensitive to this; as you might recall a couple 
>>> weeks ago I
>>> was having a wrestling match with the jstatd tests (I finished the 
>>> match, but
>>> I'm not sure I won). The primary problem was that several layers of 
>>> code
>>> would catch and discard exceptions, which made diagnosing the problem
>>> incredibly difficult. So, I'd recommend removing the "do nothing" 
>>> catch clauses.
>>>
>>> Thinking further about createRegistryOnUnusedPort(), I'm not sure that
>>> retrying 10 (or some other number of times) actually makes sense. It 
>>> does for
>>> getUnusedRandomPort(), which has to retry in order to get a port 
>>> outside the
>>> disallowed range. But for creating a registry, createRegistry(0) 
>>> will usually
>>> work the first time. If it throws ExportException, it does so for a 
>>> specific
>>> reason, so we should retry once on an unused random port. But if 
>>> this still
>>> fails, don't think retrying repeatedly makes sense.
>> See above.
>>
>> Changes pass all tests. Updated webrev at
>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.04
>>
>> Darryl
>>>
>>> s'marks
>>>
>>>
>>>
>>>
>>> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>>>
>>>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>>>> OK, here's the review for the second half of the files in the 
>>>>> webrev. I saw
>>>>> your reply to the first half (to which I'll reply separately), and 
>>>>> I don't
>>>>> think there's anything here that's affected by them.
>>>>>
>>>>>
>>>>> *** AppleUserImpl.java
>>>>> *** ApplicationServer.java
>>>>>
>>>>>
>>>>> REGISTRY_PORT should be a local variable; also rename to use mixed 
>>>>> case.
>>>> Changed to a private registryPort (see next issue).
>>>>>
>>>>> Eh, whoops, after looking at ApplicationServer.java I see that it 
>>>>> accesses
>>>>> the REGISTRY_PORT field directly. This is why direct field access 
>>>>> is a bad
>>>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized 
>>>>> before
>>>>> ApplicationServer needs it? It turns out that it has been -- but 
>>>>> only in some
>>>>> cases.
>>>>>
>>>>> It seems like the test is trying to support two modes, one that 
>>>>> runs in two
>>>>> threads in the same JVM, and the other that runs in two separate 
>>>>> JVMs. If
>>>>> they are in separate JVMs, things will no longer work because in 
>>>>> the JVM that
>>>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be 
>>>>> -1. I
>>>>> suspect that our test environment doesn't support the separate JVM 
>>>>> mode, but
>>>>> it seems unwise to break it.
>>>>>
>>>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>>>> "well-known" default registry port number, which in this case 
>>>>> seems like 2006.
>>>>>
>>>>> In single-JVM mode, AppleUserImpl creates an instance of 
>>>>> ApplicationServer,
>>>>> so I'd suggest adding a method to ApplicationServer that allows 
>>>>> AppleUserImpl
>>>>> to store the randomly-assigned registry port number into it, 
>>>>> overriding the
>>>>> default value.
>>>>>
>>>>> This seems like this is the simplest way to preserve the two modes of
>>>>> operation but to support the random port selection model we're 
>>>>> trying to
>>>>> achieve.
>>>> Rather then going the "fixed port" route, which is what we're 
>>>> trying to get
>>>> away from, I've changed the implementation of both AppletUserImpl's 
>>>> and
>>>> ApplicationServer so ApplicationServer requires a port and 
>>>> AppleUserImpl
>>>> supplies the port on construction of ApplicationServer. I thought 
>>>> of modifying
>>>> ApplicationServer's constructor to create a port using
>>>> TestLibrary.getUnusedRandomPort, but decided requiring a port is 
>>>> better as
>>>> ApplicationServer's job is to look for already exported AppleUser 
>>>> objects.
>>>>>
>>>>>
>>>>> *** activatable/EchoImpl.java
>>>>>
>>>>>
>>>>> int registryPort = new 
>>>>> Integer(System.getProperty("rmi.registry.port"));
>>>>>
>>>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not 
>>>>> a huge
>>>>> deal, but it's probably more conventional to use parseInt() and it 
>>>>> avoids
>>>>> boxing.
>>>>>
>>>>> One could probably do Integer.getInteger("rmi.registry.port") but 
>>>>> this is
>>>>> seems pretty obscure to me even though it's more succinct.
>>>>>
>>>>> The same also applies to the following:
>>>>> - HelloImpl.java
>>>>> - unicast/EchoImpl.java
>>>>> - ShutdownImpl.java
>>>>> - SelfTerminator.java
>>>>> - CheckFQDNClient.java
>>>>> - LeaseLeakClient.java
>>>>> - dgcDeadLock/TestImpl.java
>>>>>
>>>> Integer.parseInt returns a primitive (which is what the return is 
>>>> assigned to)
>>>> and it appears Integer.parseInt is "faster" then creating a new 
>>>> Integer.
>>>> Changed to Integer.parseInt in all places referenced.
>>>>>
>>>>> *** FiniteGCLatency.java
>>>>>
>>>>>
>>>>> The pattern here is a bit odd, as the test creates the registry, 
>>>>> throws away
>>>>> the returned reference, and then calls getRegistry() to get 
>>>>> another Registry
>>>>> reference. It *seems* like they're identical references, but in 
>>>>> fact the
>>>>> first is apparently a reference to the actual Registry 
>>>>> implementation,
>>>>> whereas the second is a remote stub.
>>>>>
>>>>> The tests seem to do all the actual work using the remote stub, 
>>>>> which seems
>>>>> proper.
>>>>>
>>>>> This is confusing, though, as it looks like there's a redundant 
>>>>> Registry
>>>>> reference now. This might lead someone in the future to "simplify" 
>>>>> the test
>>>>> by not getting the remote stub, which in turn might invalidate 
>>>>> some tests.
>>>>> (In fact I was going to suggest this but I decided to investigate 
>>>>> further
>>>>> first.)
>>>>>
>>>>> At the very least, I'd suggest renaming the variable that holds 
>>>>> the newly
>>>>> created Registry to something like "registryImpl" to make it clear 
>>>>> that it's
>>>>> different from the thing returned by getRegistry(), even though 
>>>>> they have a
>>>>> the same time.
>>>>>
>>>>> Another possibility is to rearrange the TestLibrary API so that 
>>>>> there is a
>>>>> single utility method that combines createRegistryOnUnusedPort() and
>>>>> getRegistryPort(). That is, it creates a new registry and simply 
>>>>> returns the
>>>>> port on which it was created, not a reference to the registry 
>>>>> implementation.
>>>>> I don't think the registry implementation is actually ever used by 
>>>>> the tests,
>>>>> and it might simplify things a bit as well.
>>>>>
>>>>> Possibly similar issues with:
>>>>> - UnreferencedContext.java
>>>>> - NoConsoleOutput.java
>>>>>
>>>>>
>>>>> *** HttpSocketTest.java
>>>>>
>>>>>
>>>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>>>> Looks like extra code left over from the change from using
>>>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) 
>>>> to
>>>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>>>
>>>>>
>>>>> *** TestLibrary.java
>>>>>
>>>>> Mostly pretty straightforward, but I do have some concerns about 
>>>>> the random
>>>>> port selection and a potential clash with the "reserved port 
>>>>> range" as
>>>>> defined in this test library.
>>>>>
>>>>> The getUnusedRandomPort() method attempts to get a socket within 
>>>>> the range
>>>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, 
>>>>> MacOS
>>>>> allocates ports more-or-less sequentially in the range [49152, 
>>>>> 65536) which
>>>>> means that when the kernel's internal counter gets to 64000,
>>>>> getUnusedRandomPort()'s retries will fail, causing tests to fail 
>>>>> until the
>>>>> counter wraps around.
>>>>>
>>>>> Other systems behave differently; Linux seems to allocate them 
>>>>> randomly in
>>>>> the range [32768,65536) and Windows XP SP3 allocates them 
>>>>> sequentially in the
>>>>> range (1024,5000]. So it's probably not a problem for them.
>>>>>
>>>>> I think the thing to do is to check only for "reserved ports" that 
>>>>> are
>>>>> actually used by tests here. These are in the range [64001,64005]. In
>>>>> getUnusedRandomPort(), it should only need to retry if the 
>>>>> returned port is
>>>>> within this narrow, reserved range. If it's anything else it 
>>>>> should be OK.
>>>> I'll try setting the range this narrow, but I don't know how many 
>>>> sequential
>>>> tests will be run at a time and I'm concerned 5 is too few. The 
>>>> -concurrency
>>>> option on jtreg allows you to specify how many concurrent tests 
>>>> will be run. We
>>>> should have enough test ports reserved to satisfy any concurrency 
>>>> request. I've
>>>> run the tests with -concurrency=8 (I have a dual-core system 
>>>> showing 4 CPU's).
>>>> I tried reducing the port range to 64001/64002 and concurrency=4 
>>>> and all passed
>>>> fine, so maybe we're OK with just 5.
>>>>>
>>>>> On another topic, the three utility methods here:
>>>>> - createRegistryOnUnusedPort
>>>>> - getRegistryPort
>>>>> - getUnusedRandomPort
>>>>>
>>>>> all catch exceptions and then return illegal values (null or -1), 
>>>>> sometimes
>>>>> after printing some diagnostic information. The problem is that 
>>>>> the caller
>>>>> will attempt to soldier on with the illegal return value and will 
>>>>> stumble
>>>>> over something later, such as NullPointerException or
>>>>> IllegalArgumentException. This will probably be obvious but it's 
>>>>> equally
>>>>> likely to be confusing.
>>>>>
>>>>> Since these utilities are all called from test code, and the tests 
>>>>> are
>>>>> relying on them to return valid results, I'd suggest just throwing 
>>>>> exceptions
>>>>> from the utility methods if they fail. This will (should) cause 
>>>>> the test to
>>>>> error out, but that's OK, as it never could have succeeded anyway 
>>>>> if the
>>>>> utility call had failed.
>>>> I already modified createRegistryOnUnusedPort to throw an exception 
>>>> as part of
>>>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>>>> getRegistryPort and getUnusedRandomPort if they fail.
>>>>
>>>> See updated webrev: 
>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>>>
>>>> Darryl
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>>
>>>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 
>>>>>> and 7161503.
>>>>>> Webrev can be found here:
>>>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>>>> This commit fixes concurrency issues with the RMI tests.
>>>>>>
>>>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This 
>>>>>> creates an
>>>>>> RMIRegistry on an unused port. It will try up to 10 times before 
>>>>>> giving up.
>>>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the 
>>>>>> port number
>>>>>> of the registry.
>>>>>> - Changed almost all tests from using hard port numbers to using 
>>>>>> random port
>>>>>> numbers for running the RMI Registry and RMID.
>>>>>> - Removed othervm from those tests which don't need it.
>>>>>> - Added parameters for tests which spawn a separate VM to pass RMI
>>>>>> Registry and
>>>>>> RMID ports in cases where needed.
>>>>>> - Added PropertyPermission to security policy files where needed.
>>>>>> - Removed java/rmi and sun/rmi from tests which cannot be run 
>>>>>> concurrently.
>>>>>> - Added java/rmi/Naming to list of tests which cannot be run 
>>>>>> concurrently.
>>>>>>
>>>>>> Thanks,
>>>>>> Darryl
>>>>>>
>>>>
>>>>
>>
>>




From xueming.shen at oracle.com  Mon Jul 16 16:59:13 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Jul 2012 09:59:13 -0700
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
In-Reply-To: <5004418C.90602@gmx.de>
References: <5003403E.3070701@oracle.com> <5004418C.90602@gmx.de>
Message-ID: <50044861.4060108@oracle.com>



On 7/16/2012 9:30 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> as I just said for 7183053, I can't look in the details at the moment, 
> as I do not have suitable environment installed at the moment.
>
> Just one comment: I think it should be possible to share the mapping 
> data partly across charsets, so the charsets.jar would be decreased 
> again more?

Yes,  it might be desirable to share some of the mappings, especially 
among those variants. But as
I suggested at the very beginning of the project, the priority for now 
is to move all the charsets to
the new mapping based/build-time generated implementation, then it opens 
the door for new
optimization,  any improvement on those base classes and the "generator" 
tools (to share the
mapping, for example) will be shared by all the sub-classes/classes. 
While it might be ideal to
achieve all the goals at one shot, our resource restrict really does not 
allow me to spend most
of my time on it (mapping re-generate really takes time and I have to 
test from various angles
to make sure it does not break anything and not miss any corner case). 
This is more like a
side-project (sure I do have a JEP for it but...) for now and I just 
found two "spare" weeks to push
these two RFEs out.  I might have more time on charsets later around the 
end development
stage of JDK8.

-Sherman

>
> -Ulf
>
>
> Am 16.07.2012 00:12, schrieb Xueming Shen:
>> Hi
>>
>> This changeset includes the migration of our JIS0201/0208/0212 based 
>> single/
>> double-byte charsets to the new mapping based implementation. This is 
>> the
>> left-over of the effort we put in JDK7 to re-implement most of our 
>> charsets in
>> charsets.jar to (1)have better performance (2) small storage foot 
>> print and (3)
>> ease the maintenance burden.
>>
>> http://cr.openjdk.java.net/~sherman/6653797/webrev/
>>
>> Notes of the implementation:
>>
>> (1) jis0201/0208/0212 and their variants are now generated from the 
>> mapping table
>> during the build time. (See those new .map *.nr and *.c2b tables)
>>
>> (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now 
>> using these
>> new jis0201/02080212 charsets.
>>
>> (3) Those in red (in webrev) are the old implementation, since no 
>> charset uses them
>> anymore, I removed them from the repository)
>>
>> (4) There are two approaches for PCK and SJIS. PCK.java_v1 and 
>> SJIS.java_v1 are the
>> one that follows the old implementation, which decode/encodes base on 
>> the
>> jis0201/0208 (and the variants) mapping via Ken's algorithm. This is 
>> known to be
>> slow and buggy (the algothrim does not take care of illegal sjis cp, 
>> see #6653797
>> and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java)
>> So in this charset, I generated the direct mapping tables for sjis 
>> and pck and use
>> the "general" DoubleByte base class for these two charsets. This 
>> results in much
>> faster decoding/encoding and correct mapping for all code points. The 
>> downside
>> of this approach is that it adds about 50k uncompressed side to the 
>> charsets.jar.
>> But given this change actually reduces about 300K from the rt.jar, we 
>> still get
>> a net 250K, so I decided to go with this approach for better 
>> performance.
>>
>> It appears to be lots of files (80+) in the webrev, but that number 
>> includes the
>> removed old implementation and the tests I put in to guarantee the 
>> identical
>> de/encoding result from the old and new implementations (those OLD... 
>> test
>> cases), the change is actually not that big:-) So please help review. 
>> I can then
>> put this multi-year efforts into rest.
>>
>> -Sherman
>>
>>
>>
>>
>>
>>
>
>


From Ulf.Zibis at CoSoCo.de  Mon Jul 16 16:57:38 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 16 Jul 2012 18:57:38 +0200
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
In-Reply-To: <5003403E.3070701@oracle.com>
References: <5003403E.3070701@oracle.com>
Message-ID: <50044802.30703@CoSoCo.de>

Hi Sherman,

as I just said for 7183053, I can't look in the details at the moment, as I do not have suitable 
environment installed at the moment.
All I can see, looks reasonable.
Regarding part 4 of bug 6653797, there is still existing adaptor from my side, if desired.

Just one comment: I think it should be possible to share the mapping data partly across charsets, so 
the charsets.jar would be decreased again more?

-Ulf


Am 16.07.2012 00:12, schrieb Xueming Shen:
> Hi
>
> This changeset includes the migration of our JIS0201/0208/0212 based single/
> double-byte charsets to the new mapping based implementation. This is the
> left-over of the effort we put in JDK7 to re-implement most of our charsets in
> charsets.jar to (1)have better performance (2) small storage foot print and (3)
> ease the maintenance burden.
>
> http://cr.openjdk.java.net/~sherman/6653797/webrev/
>
> Notes of the implementation:
>
> (1) jis0201/0208/0212 and their variants are now generated from the mapping table
> during the build time. (See those new .map *.nr and *.c2b tables)
>
> (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these
> new jis0201/02080212 charsets.
>
> (3) Those in red (in webrev) are the old implementation, since no charset uses them
> anymore, I removed them from the repository)
>
> (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the
> one that follows the old implementation, which decode/encodes base on the
> jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be
> slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797
> and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java)
> So in this charset, I generated the direct mapping tables for sjis and pck and use
> the "general" DoubleByte base class for these two charsets. This results in much
> faster decoding/encoding and correct mapping for all code points. The downside
> of this approach is that it adds about 50k uncompressed side to the charsets.jar.
> But given this change actually reduces about 300K from the rt.jar, we still get
> a net 250K, so I decided to go with this approach for better performance.
>
> It appears to be lots of files (80+) in the webrev, but that number includes the
> removed old implementation and the tests I put in to guarantee the identical
> de/encoding result from the old and new implementations (those OLD... test
> cases), the change is actually not that big:-) So please help review. I can then
> put this multi-year efforts into rest.
>
> -Sherman
>
>
>
>
>
>




From xueming.shen at oracle.com  Mon Jul 16 17:13:22 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Jul 2012 10:13:22 -0700
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
In-Reply-To: <50044802.30703@CoSoCo.de>
References: <5003403E.3070701@oracle.com> <50044802.30703@CoSoCo.de>
Message-ID: <50044BB2.8050005@oracle.com>



On 7/16/2012 9:57 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> as I just said for 7183053, I can't look in the details at the moment, 
> as I do not have suitable environment installed at the moment.
> All I can see, looks reasonable.
> Regarding part 4 of bug 6653797, there is still existing adaptor from 
> my side, if desired.

The sun.io has been removed. That will be an alternative if we hear any 
complain.

Thanks!
-Sherman


>
> Just one comment: I think it should be possible to share the mapping 
> data partly across charsets, so the charsets.jar would be decreased 
> again more?
>
> -Ulf
>
>
> Am 16.07.2012 00:12, schrieb Xueming Shen:
>> Hi
>>
>> This changeset includes the migration of our JIS0201/0208/0212 based 
>> single/
>> double-byte charsets to the new mapping based implementation. This is 
>> the
>> left-over of the effort we put in JDK7 to re-implement most of our 
>> charsets in
>> charsets.jar to (1)have better performance (2) small storage foot 
>> print and (3)
>> ease the maintenance burden.
>>
>> http://cr.openjdk.java.net/~sherman/6653797/webrev/
>>
>> Notes of the implementation:
>>
>> (1) jis0201/0208/0212 and their variants are now generated from the 
>> mapping table
>> during the build time. (See those new .map *.nr and *.c2b tables)
>>
>> (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now 
>> using these
>> new jis0201/02080212 charsets.
>>
>> (3) Those in red (in webrev) are the old implementation, since no 
>> charset uses them
>> anymore, I removed them from the repository)
>>
>> (4) There are two approaches for PCK and SJIS. PCK.java_v1 and 
>> SJIS.java_v1 are the
>> one that follows the old implementation, which decode/encodes base on 
>> the
>> jis0201/0208 (and the variants) mapping via Ken's algorithm. This is 
>> known to be
>> slow and buggy (the algothrim does not take care of illegal sjis cp, 
>> see #6653797
>> and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java)
>> So in this charset, I generated the direct mapping tables for sjis 
>> and pck and use
>> the "general" DoubleByte base class for these two charsets. This 
>> results in much
>> faster decoding/encoding and correct mapping for all code points. The 
>> downside
>> of this approach is that it adds about 50k uncompressed side to the 
>> charsets.jar.
>> But given this change actually reduces about 300K from the rt.jar, we 
>> still get
>> a net 250K, so I decided to go with this approach for better 
>> performance.
>>
>> It appears to be lots of files (80+) in the webrev, but that number 
>> includes the
>> removed old implementation and the tests I put in to guarantee the 
>> identical
>> de/encoding result from the old and new implementations (those OLD... 
>> test
>> cases), the change is actually not that big:-) So please help review. 
>> I can then
>> put this multi-year efforts into rest.
>>
>> -Sherman
>>
>>
>>
>>
>>
>>
>
>


From Ulf.Zibis at CoSoCo.de  Mon Jul 16 17:13:20 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 16 Jul 2012 19:13:20 +0200
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
In-Reply-To: <50044861.4060108@oracle.com>
References: <5003403E.3070701@oracle.com> <5004418C.90602@gmx.de>
	<50044861.4060108@oracle.com>
Message-ID: <50044BB0.7030200@CoSoCo.de>

Am 16.07.2012 18:59, schrieb Xueming Shen:
> Yes,  it might be desirable to share some of the mappings, especially among those variants. But as
> I suggested at the very beginning of the project, the priority for now is to move all the charsets to
> the new mapping based/build-time generated implementation, then it opens the door for new
> optimization,  any improvement on those base classes and the "generator" tools (to share the
> mapping, for example) will be shared by all the sub-classes/classes. While it might be ideal to
> achieve all the goals at one shot, our resource restrict really does not allow me to spend most
> of my time on it (mapping re-generate really takes time and I have to test from various angles
> to make sure it does not break anything and not miss any corner case). This is more like a
> side-project (sure I do have a JEP for it but...) for now and I just found two "spare" weeks to push
> these two RFEs out.  I might have more time on charsets later around the end development
> stage of JDK8.

I totally agree, thanks.
Hopefully I will have more time then.

Sorry for the double-posting. The 2nd one has correct email for the list + one more text line.

-Ulf



From xueming.shen at oracle.com  Mon Jul 16 18:42:28 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Jul 2012 11:42:28 -0700
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50005650.9090207@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
	<50005650.9090207@oracle.com>
Message-ID: <50046094.8050804@oracle.com>

Hi Alan,

I gave the "continue ->else if " a try, it appears the server vm 
obviously likes
the "continue" approach (it is consistent with what we experienced in 
the past
when we did similar approach for ascii, in which we separate/singled the 
ascii
path out). So I guess we probably want to keep the continue here.

Here are the data. dbcs2_new is to replace the continue with else if and the
dbcs2 is the "continue".

http://cr.openjdk.java.net/~sherman/7183053/dbcs2_new
http://cr.openjdk.java.net/~sherman/7183053/dbcs2

-Sherman

On 07/13/2012 10:09 AM, Xueming Shen wrote:
>>> In JDK7,  the decoder and encoder implementation of most of our 
>>> single-byte charsets
>>> and UTF-8 charset are optimized to implement the internal interfce 
>>> sun.nio.cs.ArrayDecoder/
>>> Encoder to provide a fastpath for String.getBytes(...) and new 
>>> String(byte[]...) operations. I
>>> have an old blog regarding this optimization at
>>>
>>> https://blogs.oracle.com/xuemingshen/entry/faster_new_string_bytes_cs
>>>
>>> This rfe, as the followup for above changes, is to implement 
>>> ArrayDe/Encoder for most
>>> of the sun.nio.cs.ext.DoubleByte based double-byte charsets. Here is 
>>> the webrev
>>>
>>> http://cr.openjdk.java.net/~sherman/7183053/webrev
>> I've taken a pass over this and it's great to see 
>> DoubleByte.Decoder/Encoder implementing 
>> sun.nio.cs.ArrayDecoder/Encoder. The results looks good too, a small 
>> number of regressions (Big5 at len=32 for example) but this is a 
>> micro benchmark and I'm sure there are fluctuations. I don't see 
>> anything obviously wrong with the EBCDIC changes I'd need a history 
>> book to remember how the shifts between DBCS and SBCS. I think our 
>> tests our good for this area so I'm happy. One minor nit is the 
>> continue in both encode methods, I think it would be cleaner to use 
>> "else if (bb ..." instead.
>
>
> The continue might make the vm happy, but this is the code I did last 
> Oct, so I might be
> wrong. Will give a couple run later with "else"
>



From kurchi.subhra.hazra at oracle.com  Mon Jul 16 20:12:15 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Mon, 16 Jul 2012 13:12:15 -0700
Subject: Code Review Request: 7183800: TEST_BUG: Update tests to run on
	Ubuntu 12.04 (localhost is 127.0.1.1)
In-Reply-To: <5003F367.20708@oracle.com>
References: <500311E9.4070809@oracle.com> <5003F367.20708@oracle.com>
Message-ID: <5004759F.7060200@oracle.com>

   I just tried running these tests with -Djava.net.preferIPv4Stack set 
to true, but they still fail. I remember working on some of these 
failures in networking where ipv6 multicast was buggy,
but absolutely nothing made those tests work.
However, in this case, if we make sure that the address that the sender 
is sending the packets to and the address that the listener is binding 
to is the same, the tests are passing.

The fix in this webrev is not working for Windows since the tests try to 
connect to 0.0.0.0. So we have to think of some other solution.

- Kurchi

On 7/16/2012 3:56 AM, Alan Bateman wrote:
> On 15/07/2012 19:54, Kurchi Subhra Hazra wrote:
>> Hi,
>>
>>    Some tests in our test repository assume that 
>> InetAddress.getLocalHost() will return 127.0.0.1. However, with
>> linux systems running Ubuntu 12.04 now returning 127.0.1.1 as 
>> localhost, these tests are failing. I have changed two
>> of the NIO tests to remove their dependency on 
>> InetAddress.getLocalHost(). A third test has been added to
>> the ProblemList.txt since the changes required for it are more involved.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800
>> Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/
>>
> As Chris pointed out, these tests bind to the wildcard address and you 
> need a specific address to setup the address association, otherwise 
> it's highly platform/implementation specific as to whether it will do 
> as intended. So I think the proposed changes will cause problems where 
> you can't connect to 0.0.0.0 and so I think we need to look for 
> another solution.
>
> Given that none of the TCP tests fail then it suggests it mean that 
> something else is going on, maybe something in the Ubuntu 12 
> configuration. Do these tests run if IPv6 is disabled? We've had 
> issues with some distributions where multicast tests fail and these 
> have always come down to iptables blocking IPv6 multicast packets 
> causing the tests to fail. I just wonder if we have something similar 
> here.
>
> -Alan
>

-- 
-Kurchi



From vincent.x.ryan at oracle.com  Mon Jul 16 21:42:18 2012
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Mon, 16 Jul 2012 21:42:18 +0000
Subject: hg: jdk8/tl/jdk: 6880559: Enable PKCS11 64-bit windows builds
Message-ID: <20120716214241.A20AC470A2@hg.openjdk.java.net>

Changeset: 5cee646eaaa7
Author:    vinnie
Date:      2012-07-16 22:38 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cee646eaaa7

6880559: Enable PKCS11 64-bit windows builds
Reviewed-by: valeriep

! THIRD_PARTY_README
! make/sun/security/Makefile
! test/sun/security/pkcs11/PKCS11Test.java
+ test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk
+ test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib
+ test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk
+ test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll
+ test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk
+ test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk
+ test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib
+ test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk
+ test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll
+ test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib
+ test/sun/security/pkcs11/nss/src/MD5SUMS
+ test/sun/security/pkcs11/nss/src/SHA1SUMS
+ test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz



From vincent.x.ryan at oracle.com  Mon Jul 16 21:44:03 2012
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Mon, 16 Jul 2012 21:44:03 +0000
Subject: hg: jdk8/tl: 6880559: Enable PKCS11 64-bit windows builds
Message-ID: <20120716214403.8316D470A3@hg.openjdk.java.net>

Changeset: 0562a97bd601
Author:    vinnie
Date:      2012-07-16 22:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0562a97bd601

6880559: Enable PKCS11 64-bit windows builds
Reviewed-by: valeriep

! THIRD_PARTY_README



From darryl.mocek at oracle.com  Mon Jul 16 22:54:57 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 16 Jul 2012 15:54:57 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <50043664.90306@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<500087AE.7070501@oracle.com> <50043664.90306@oracle.com>
Message-ID: <50049BC1.4050808@oracle.com>

Here's webrev.05 
(http://cr.openjdk.java.net/~dmocek/7142596/webrev.05).  Changes:

- Simplify createRegistryOnUnusedPort()
- Simplify getUnusedRandomPort()
- Add isReservedPort() method to determine if a port is a reserved port 
# (not just one of the FIXED_PORT's, but also any port which shouldn't 
be used).

Passes all tests.

Darryl

On 07/16/2012 08:42 AM, Stuart Marks wrote:
> Hi Darryl,
>
> Sorry, I'm going to have to ask you to update this again. The issues 
> are in TestLibrary.java and are all related to catching exceptions and 
> throwing new exception instances, discarding the original exception 
> (and probably relevant diagnostic information) in the process.
>
> Let's get together today and work on it. I expect it will take only 
> half an hour or so to knock things out.
>
> s'marks
>
>
>
>
> On 7/13/12 1:40 PM, Darryl Mocek wrote:
>>
>> On 07/12/2012 05:13 PM, Stuart Marks wrote:
>>> OK, I took a look at the revised webrev. Most stuff is good. A 
>>> couple changes
>>> are necessary though.
>>>
>>>
>>> *** MultipleRegistries.java
>>>
>>>
>>> Not a big deal, but the comment at lines 65-67 is no longer necessary.
>> Comment removed.
>>>
>>>
>>> *** TestLibrary.java
>>>
>>>
>>> I think the reserved port range stuff still needs to be fixed up.
>>>
>>> The comment at lines 81-82 talks about a range 64000-64100 which 
>>> isn't really
>>> present anywhere. The comment should instead say that PORT_MIN and 
>>> PORT_MAX
>>> should be kept adjusted so that they specify the range of ports 
>>> defined by
>>> the constants following. Make sure to do this adjustment; PORT_MAX 
>>> is 64002
>>> here.
>> I reserved ports 64000-64100 (even though only 64001-64005 are 
>> currently being
>> used) for fixed port tests (for tests which require fixed ports) so 
>> any future
>> tests which require fixed ports can be assured there are ports 
>> available within
>> a range for their use. In fixing the tests, I saw that those who 
>> wrote tests
>> and used fixed ports grabbed random port numbers all over the place. 
>> Providing
>> a reserved range allows them to just grab the next number and to keep 
>> the fixed
>> port numbers in a group, even when new tests are added. If the ports are
>> defined in a central place, like TestLibrary, then hopefully 
>> developers will
>> come to TestLibrary to reserve the ports rather then define them in 
>> the tests
>> themselves, like was done previously. I chose 100 ports for
>> "future-proofing"...I don't think 100 is too many, but I've reduced 
>> it to 10
>> and lowered the max to 64010. I was also thinking of looking for 
>> tests which
>> used fixed ports outside of RMI tests and standardizing those ports 
>> here, but
>> that's possible future work and I'm not sure it's necessary.
>>>
>>> The previous webrev had PORT_MIN and PORT_MAX specify a range of 
>>> 1024-64000
>>> as the *allowed* range for ports returned by getUnusedRandomPort(). 
>>> But as I
>>> described previously, this is difficult to enforce given the varying 
>>> port
>>> allocation schemes on different OSes.
>>>
>>> Instead I think we need to invert the sense of the range 
>>> PORT_MIN..PORT_MAX
>>> and make it be the range of ports reserved by tests that require 
>>> fixed ports
>>> (64001 through 64005). Then, getUnusedRandomPort() needs to be 
>>> changed to
>>> *disallow* ports in this range, that is, to retry if the port is 
>>> within this
>>> range. Thus the condition on the while-loop has to be inverted, 
>>> something like
>>>
>>> while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= 
>>> PORT_MAX)
>> Yes, this is correct and it has been changed.
>>>
>>> So, how could getUnusedRandomPort() have worked in its present 
>>> state? Well I
>>> think it ends up retrying 10 times, then at the end of the loop
>>> unusedRandomPort is actually some legal port number -- albeit 
>>> possibly one
>>> within the disallowed range -- and almost certainly not -1, and so 
>>> the method
>>> returns it and the caller uses it. So, the success-testing logic 
>>> here will
>>> also have to change so that it retests whether the port is in the 
>>> disallowed
>>> range.
>> Correct...done.
>>>
>>> The comment on getUnusedRandomPort() also needs to be updated to 
>>> reflect its
>>> new policy on the reserved range, as well as throwing an exception on
>>> failure. Also (nitpick) it should say "less than" not "less then".
>> Yes, I always do this. :(
>>>
>>> Looking at getUnusedRandomPort() again more closely [sorry] I think 
>>> the catch
>>> of Exception that does nothing is suspicious. I'm not sure why 
>>> getting a
>>> ServerSocket would fail, but if it does (maybe the system is out of 
>>> ports??)
>>> we should just throw out to the caller. Perhaps ideally we'd just 
>>> have this
>>> method throw IOException, but if that requires all callers to be 
>>> updated, it
>>> might be easier just to catch IOException and throw a 
>>> RuntimeException that
>>> wraps the caught IOException.
>> I see no harm in trying again if it fails. If we have run out of 
>> ports, then
>> possibly one or more used ports will be closed and freed and a 
>> subsequent try
>> will succeed. I don't know all of the cases where a failure might occur.
>> Anyway, if this is the prevailing way of handling this, I'll change it.
>>>
>>> Similar comments apply to the catch(Exception)/do-nothing code in 
>>> the other
>>> utility methods.
>> Now throwing RuntimeException in getRegistryPort.
>>>
>>> Certainly getRegistryPort() should just throw (or possibly wrap and 
>>> rethrow)
>>> any exception caught.
>>>
>>> For createRegistryOnUnusedPort(), the catching of ExportException is 
>>> handled
>>> properly. The second catch clause of the outer try-block, and the 
>>> catch of
>>> the inner try-block, both ignore exceptions. The code will then end up
>>> retrying. Is it reasonable that retrying in these cases will result 
>>> in a
>>> different outcome? My guess is that it's more likely that something is
>>> seriously wrong that will cause all the retries to fail, in which 
>>> case this
>>> method will discard the exceptions it has just caught and throw a *new*
>>> RemoteException instance.
>> This was a holdover from webrev.00 which should have been removed. I 
>> agree with
>> Alan and you here that multiple tries of 
>> LocateRegistry.createRegistry(0) is
>> unnecessary. I've modified this to make a single attempt at using
>> LocateRegistry.createRegistry(0) and if it fails, make a single 
>> attempt at
>> getting an unused random port and creating a registry on this port, then
>> failing with a RuntimeException.
>>>
>>> I'm particularly sensitive to this; as you might recall a couple 
>>> weeks ago I
>>> was having a wrestling match with the jstatd tests (I finished the 
>>> match, but
>>> I'm not sure I won). The primary problem was that several layers of 
>>> code
>>> would catch and discard exceptions, which made diagnosing the problem
>>> incredibly difficult. So, I'd recommend removing the "do nothing" 
>>> catch clauses.
>>>
>>> Thinking further about createRegistryOnUnusedPort(), I'm not sure that
>>> retrying 10 (or some other number of times) actually makes sense. It 
>>> does for
>>> getUnusedRandomPort(), which has to retry in order to get a port 
>>> outside the
>>> disallowed range. But for creating a registry, createRegistry(0) 
>>> will usually
>>> work the first time. If it throws ExportException, it does so for a 
>>> specific
>>> reason, so we should retry once on an unused random port. But if 
>>> this still
>>> fails, don't think retrying repeatedly makes sense.
>> See above.
>>
>> Changes pass all tests. Updated webrev at
>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.04
>>
>> Darryl
>>>
>>> s'marks
>>>
>>>
>>>
>>>
>>> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>>>
>>>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>>>> OK, here's the review for the second half of the files in the 
>>>>> webrev. I saw
>>>>> your reply to the first half (to which I'll reply separately), and 
>>>>> I don't
>>>>> think there's anything here that's affected by them.
>>>>>
>>>>>
>>>>> *** AppleUserImpl.java
>>>>> *** ApplicationServer.java
>>>>>
>>>>>
>>>>> REGISTRY_PORT should be a local variable; also rename to use mixed 
>>>>> case.
>>>> Changed to a private registryPort (see next issue).
>>>>>
>>>>> Eh, whoops, after looking at ApplicationServer.java I see that it 
>>>>> accesses
>>>>> the REGISTRY_PORT field directly. This is why direct field access 
>>>>> is a bad
>>>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized 
>>>>> before
>>>>> ApplicationServer needs it? It turns out that it has been -- but 
>>>>> only in some
>>>>> cases.
>>>>>
>>>>> It seems like the test is trying to support two modes, one that 
>>>>> runs in two
>>>>> threads in the same JVM, and the other that runs in two separate 
>>>>> JVMs. If
>>>>> they are in separate JVMs, things will no longer work because in 
>>>>> the JVM that
>>>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be 
>>>>> -1. I
>>>>> suspect that our test environment doesn't support the separate JVM 
>>>>> mode, but
>>>>> it seems unwise to break it.
>>>>>
>>>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>>>> "well-known" default registry port number, which in this case 
>>>>> seems like 2006.
>>>>>
>>>>> In single-JVM mode, AppleUserImpl creates an instance of 
>>>>> ApplicationServer,
>>>>> so I'd suggest adding a method to ApplicationServer that allows 
>>>>> AppleUserImpl
>>>>> to store the randomly-assigned registry port number into it, 
>>>>> overriding the
>>>>> default value.
>>>>>
>>>>> This seems like this is the simplest way to preserve the two modes of
>>>>> operation but to support the random port selection model we're 
>>>>> trying to
>>>>> achieve.
>>>> Rather then going the "fixed port" route, which is what we're 
>>>> trying to get
>>>> away from, I've changed the implementation of both AppletUserImpl's 
>>>> and
>>>> ApplicationServer so ApplicationServer requires a port and 
>>>> AppleUserImpl
>>>> supplies the port on construction of ApplicationServer. I thought 
>>>> of modifying
>>>> ApplicationServer's constructor to create a port using
>>>> TestLibrary.getUnusedRandomPort, but decided requiring a port is 
>>>> better as
>>>> ApplicationServer's job is to look for already exported AppleUser 
>>>> objects.
>>>>>
>>>>>
>>>>> *** activatable/EchoImpl.java
>>>>>
>>>>>
>>>>> int registryPort = new 
>>>>> Integer(System.getProperty("rmi.registry.port"));
>>>>>
>>>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not 
>>>>> a huge
>>>>> deal, but it's probably more conventional to use parseInt() and it 
>>>>> avoids
>>>>> boxing.
>>>>>
>>>>> One could probably do Integer.getInteger("rmi.registry.port") but 
>>>>> this is
>>>>> seems pretty obscure to me even though it's more succinct.
>>>>>
>>>>> The same also applies to the following:
>>>>> - HelloImpl.java
>>>>> - unicast/EchoImpl.java
>>>>> - ShutdownImpl.java
>>>>> - SelfTerminator.java
>>>>> - CheckFQDNClient.java
>>>>> - LeaseLeakClient.java
>>>>> - dgcDeadLock/TestImpl.java
>>>>>
>>>> Integer.parseInt returns a primitive (which is what the return is 
>>>> assigned to)
>>>> and it appears Integer.parseInt is "faster" then creating a new 
>>>> Integer.
>>>> Changed to Integer.parseInt in all places referenced.
>>>>>
>>>>> *** FiniteGCLatency.java
>>>>>
>>>>>
>>>>> The pattern here is a bit odd, as the test creates the registry, 
>>>>> throws away
>>>>> the returned reference, and then calls getRegistry() to get 
>>>>> another Registry
>>>>> reference. It *seems* like they're identical references, but in 
>>>>> fact the
>>>>> first is apparently a reference to the actual Registry 
>>>>> implementation,
>>>>> whereas the second is a remote stub.
>>>>>
>>>>> The tests seem to do all the actual work using the remote stub, 
>>>>> which seems
>>>>> proper.
>>>>>
>>>>> This is confusing, though, as it looks like there's a redundant 
>>>>> Registry
>>>>> reference now. This might lead someone in the future to "simplify" 
>>>>> the test
>>>>> by not getting the remote stub, which in turn might invalidate 
>>>>> some tests.
>>>>> (In fact I was going to suggest this but I decided to investigate 
>>>>> further
>>>>> first.)
>>>>>
>>>>> At the very least, I'd suggest renaming the variable that holds 
>>>>> the newly
>>>>> created Registry to something like "registryImpl" to make it clear 
>>>>> that it's
>>>>> different from the thing returned by getRegistry(), even though 
>>>>> they have a
>>>>> the same time.
>>>>>
>>>>> Another possibility is to rearrange the TestLibrary API so that 
>>>>> there is a
>>>>> single utility method that combines createRegistryOnUnusedPort() and
>>>>> getRegistryPort(). That is, it creates a new registry and simply 
>>>>> returns the
>>>>> port on which it was created, not a reference to the registry 
>>>>> implementation.
>>>>> I don't think the registry implementation is actually ever used by 
>>>>> the tests,
>>>>> and it might simplify things a bit as well.
>>>>>
>>>>> Possibly similar issues with:
>>>>> - UnreferencedContext.java
>>>>> - NoConsoleOutput.java
>>>>>
>>>>>
>>>>> *** HttpSocketTest.java
>>>>>
>>>>>
>>>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>>>> Looks like extra code left over from the change from using
>>>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) 
>>>> to
>>>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>>>
>>>>>
>>>>> *** TestLibrary.java
>>>>>
>>>>> Mostly pretty straightforward, but I do have some concerns about 
>>>>> the random
>>>>> port selection and a potential clash with the "reserved port 
>>>>> range" as
>>>>> defined in this test library.
>>>>>
>>>>> The getUnusedRandomPort() method attempts to get a socket within 
>>>>> the range
>>>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, 
>>>>> MacOS
>>>>> allocates ports more-or-less sequentially in the range [49152, 
>>>>> 65536) which
>>>>> means that when the kernel's internal counter gets to 64000,
>>>>> getUnusedRandomPort()'s retries will fail, causing tests to fail 
>>>>> until the
>>>>> counter wraps around.
>>>>>
>>>>> Other systems behave differently; Linux seems to allocate them 
>>>>> randomly in
>>>>> the range [32768,65536) and Windows XP SP3 allocates them 
>>>>> sequentially in the
>>>>> range (1024,5000]. So it's probably not a problem for them.
>>>>>
>>>>> I think the thing to do is to check only for "reserved ports" that 
>>>>> are
>>>>> actually used by tests here. These are in the range [64001,64005]. In
>>>>> getUnusedRandomPort(), it should only need to retry if the 
>>>>> returned port is
>>>>> within this narrow, reserved range. If it's anything else it 
>>>>> should be OK.
>>>> I'll try setting the range this narrow, but I don't know how many 
>>>> sequential
>>>> tests will be run at a time and I'm concerned 5 is too few. The 
>>>> -concurrency
>>>> option on jtreg allows you to specify how many concurrent tests 
>>>> will be run. We
>>>> should have enough test ports reserved to satisfy any concurrency 
>>>> request. I've
>>>> run the tests with -concurrency=8 (I have a dual-core system 
>>>> showing 4 CPU's).
>>>> I tried reducing the port range to 64001/64002 and concurrency=4 
>>>> and all passed
>>>> fine, so maybe we're OK with just 5.
>>>>>
>>>>> On another topic, the three utility methods here:
>>>>> - createRegistryOnUnusedPort
>>>>> - getRegistryPort
>>>>> - getUnusedRandomPort
>>>>>
>>>>> all catch exceptions and then return illegal values (null or -1), 
>>>>> sometimes
>>>>> after printing some diagnostic information. The problem is that 
>>>>> the caller
>>>>> will attempt to soldier on with the illegal return value and will 
>>>>> stumble
>>>>> over something later, such as NullPointerException or
>>>>> IllegalArgumentException. This will probably be obvious but it's 
>>>>> equally
>>>>> likely to be confusing.
>>>>>
>>>>> Since these utilities are all called from test code, and the tests 
>>>>> are
>>>>> relying on them to return valid results, I'd suggest just throwing 
>>>>> exceptions
>>>>> from the utility methods if they fail. This will (should) cause 
>>>>> the test to
>>>>> error out, but that's OK, as it never could have succeeded anyway 
>>>>> if the
>>>>> utility call had failed.
>>>> I already modified createRegistryOnUnusedPort to throw an exception 
>>>> as part of
>>>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>>>> getRegistryPort and getUnusedRandomPort if they fail.
>>>>
>>>> See updated webrev: 
>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>>>
>>>> Darryl
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>>
>>>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 
>>>>>> and 7161503.
>>>>>> Webrev can be found here:
>>>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>>>> This commit fixes concurrency issues with the RMI tests.
>>>>>>
>>>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This 
>>>>>> creates an
>>>>>> RMIRegistry on an unused port. It will try up to 10 times before 
>>>>>> giving up.
>>>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the 
>>>>>> port number
>>>>>> of the registry.
>>>>>> - Changed almost all tests from using hard port numbers to using 
>>>>>> random port
>>>>>> numbers for running the RMI Registry and RMID.
>>>>>> - Removed othervm from those tests which don't need it.
>>>>>> - Added parameters for tests which spawn a separate VM to pass RMI
>>>>>> Registry and
>>>>>> RMID ports in cases where needed.
>>>>>> - Added PropertyPermission to security policy files where needed.
>>>>>> - Removed java/rmi and sun/rmi from tests which cannot be run 
>>>>>> concurrently.
>>>>>> - Added java/rmi/Naming to list of tests which cannot be run 
>>>>>> concurrently.
>>>>>>
>>>>>> Thanks,
>>>>>> Darryl
>>>>>>
>>>>
>>>>
>>
>>




From darryl.mocek at oracle.com  Mon Jul 16 22:56:00 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 16 Jul 2012 15:56:00 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <50014A90.6040506@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<4FFFE355.9090507@oracle.com> <5000AA9C.6050601@oracle.com>
	<50014A90.6040506@oracle.com>
Message-ID: <50049C00.7030407@oracle.com>

Hi Alan.  The reason we didn't go this route is that we want to be able 
to create the RMI Registry on a random port which is not one of the 
reserved ports (see TestLibrary.FIXED_PORT_MIN/MAX).  To do this, we use 
'new ServerSocket(0)', which creates a socket on a random port, then 
close the port, check if it's a 'reserved' port, and return the port 
number if it's not.  Since we have to go through this process anyway, 
the current implementation (see webrev05: 
http://cr.openjdk.java.net/~dmocek/7142596/webrev.05) already works and 
has broader applicability (e.g. this also supports getting a random port 
for tests which require a socket rather then hard-coding port numbers 
into tests, although this change isn't in this webrev).

Darryl

On 07/14/2012 03:31 AM, Alan Bateman wrote:
> On 14/07/2012 00:09, Stuart Marks wrote:
>>
>> There is at least one test case that wants to create two registries 
>> within the same JVM. The first call to createRegistry(0) will usually 
>> succeed. The second call from the same JVM will throw an 
>> ExportException. So, we catch this and retry using a random port 
>> instead to create the second registry. If *that* fails we give up at 
>> that point instead of retrying repeatedly.
> Okay, so it's the export of the object that is the issue because the 
> objID is based on the argument rather than the actual port. In that 
> case would it make sense to switch to the factory method that takes 
> the RMIServerSocketFactory as argument, something like:
>
>   static class ServerSocketFactory implements RMIServerSocketFactory {
>     public ServerSocket createServerSocket(int port) throws 
> IOException { return new ServerSocket(0); }
>   }
>
>   static class ClientSocketFactory implements RMIClientSocketFactory {
>     public Socket createSocket(String host, int port) throws 
> IOException { return new Socket(host, port); }
>   }
>
>   Registry registry = LocateRegistry.createRegistry(0, new 
> ClientSocketFactory(), new ServerSocketFactory());
>
> -Alan.
>
>




From kurchi.subhra.hazra at oracle.com  Mon Jul 16 23:31:20 2012
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Mon, 16 Jul 2012 23:31:20 +0000
Subject: hg: jdk8/tl/jdk: 7177045: Rework the TestProviderLeak.java regression
	test, it is too fragile to low memory errors.
Message-ID: <20120716233142.CBD14470AE@hg.openjdk.java.net>

Changeset: 1469be7182b4
Author:    khazra
Date:      2012-07-16 16:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1469be7182b4

7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors.
Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory.
Reviewed-by: wetmore
Contributed-by: dan.xu at oracle.com

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java



From weijun.wang at oracle.com  Tue Jul 17 03:28:44 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 17 Jul 2012 03:28:44 +0000
Subject: hg: jdk8/tl/jdk: 7183203: ShortRSAKeynnn.sh tests intermittent failure
Message-ID: <20120717032905.9D5CA470B5@hg.openjdk.java.net>

Changeset: e2d265c9b592
Author:    weijun
Date:      2012-07-17 11:28 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2d265c9b592

7183203: ShortRSAKeynnn.sh tests intermittent failure
Reviewed-by: xuelei

! test/sun/security/mscapi/ShortRSAKey1024.sh
- test/sun/security/mscapi/ShortRSAKey512.sh
- test/sun/security/mscapi/ShortRSAKey768.sh



From weijun.wang at oracle.com  Tue Jul 17 03:57:52 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 17 Jul 2012 03:57:52 +0000
Subject: hg: jdk8/tl/jdk: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh
	should be modified
Message-ID: <20120717035802.78DFE470B7@hg.openjdk.java.net>

Changeset: 2a39c98c1241
Author:    weijun
Date:      2012-07-17 11:57 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a39c98c1241

7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified
Reviewed-by: mullan

! test/sun/security/util/Oid/S11N.sh



From lana.steuck at oracle.com  Tue Jul 17 05:12:06 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:12:06 +0000
Subject: hg: jdk8/tl: 6 new changesets
Message-ID: <20120717051207.0452E470BB@hg.openjdk.java.net>

Changeset: f6a685069274
Author:    katleman
Date:      2012-07-05 18:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f6a685069274

Added tag jdk8-b46 for changeset 27fa766a2298

! .hgtags

Changeset: c8d320b48626
Author:    erikj
Date:      2012-07-03 16:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c8d320b48626

7181504: Update of latest build-infra Makefiles
Reviewed-by: ohair

! common/autoconf/autogen.sh
! common/autoconf/build-aux/config.guess
! common/autoconf/builddeps.conf.example
! common/autoconf/builddeps.m4
! common/autoconf/configure
! common/autoconf/configure.ac
- common/autoconf/cores.m4
! common/autoconf/help.m4
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! common/bin/compareimage.sh
! common/bin/diffexec.sh
! common/bin/diffjarzip.sh
! common/bin/difflib.sh
! common/makefiles/IdlCompilation.gmk
! common/makefiles/JavaCompilation.gmk
! common/makefiles/MakeBase.gmk
! common/makefiles/Makefile
! common/makefiles/NativeCompilation.gmk
- common/makefiles/RMICompile.gmk

Changeset: 3156dff953b1
Author:    erikj
Date:      2012-07-05 18:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/3156dff953b1

7182051: Update of latest build-infra Makefiles (missing files)
Reviewed-by: ohair

+ common/autoconf/basics.m4
+ common/autoconf/boot-jdk.m4
+ common/autoconf/build-aux/autoconf-config.guess
+ common/autoconf/build-performance.m4
+ common/autoconf/generated-configure.sh
+ common/autoconf/jdk-options.m4
+ common/autoconf/libraries.m4
+ common/autoconf/source-dirs.m4
+ common/autoconf/spec.sh.in
+ common/autoconf/toolchain.m4
+ common/bin/compare-objects.sh
! common/makefiles/IdlCompilation.gmk
+ common/makefiles/MakeHelpers.gmk
! common/makefiles/NativeCompilation.gmk
+ common/makefiles/RMICompilation.gmk

Changeset: 1dcb4b7b9373
Author:    katleman
Date:      2012-07-11 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/1dcb4b7b9373

Merge

- common/autoconf/cores.m4
- common/makefiles/RMICompile.gmk

Changeset: aaae5471808d
Author:    katleman
Date:      2012-07-12 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/aaae5471808d

Added tag jdk8-b47 for changeset 1dcb4b7b9373

! .hgtags

Changeset: c88aceaf2f3f
Author:    lana
Date:      2012-07-16 17:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c88aceaf2f3f

Merge

- common/autoconf/cores.m4
- common/makefiles/RMICompile.gmk



From lana.steuck at oracle.com  Tue Jul 17 05:12:03 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:12:03 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20120717051212.3FF12470BC@hg.openjdk.java.net>

Changeset: cb31b67326bc
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb31b67326bc

Added tag jdk8-b46 for changeset 30141e598d72

! .hgtags

Changeset: 21e46ea21c6a
Author:    lana
Date:      2012-07-10 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/21e46ea21c6a

Merge


Changeset: 7e2b179a5b4d
Author:    katleman
Date:      2012-07-12 16:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/7e2b179a5b4d

Added tag jdk8-b47 for changeset 21e46ea21c6a

! .hgtags



From lana.steuck at oracle.com  Tue Jul 17 05:11:58 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:11:58 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20120717051219.85727470BD@hg.openjdk.java.net>

Changeset: fe6a060afc40
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fe6a060afc40

Added tag jdk8-b46 for changeset ae368a83c240

! .hgtags

Changeset: efb564de8a8e
Author:    katleman
Date:      2012-07-12 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/efb564de8a8e

Added tag jdk8-b47 for changeset fe6a060afc40

! .hgtags



From lana.steuck at oracle.com  Tue Jul 17 05:11:56 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:11:56 +0000
Subject: hg: jdk8/tl/hotspot: 2 new changesets
Message-ID: <20120717051219.D71AE470BE@hg.openjdk.java.net>

Changeset: 0c7bb1f4f9c8
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c7bb1f4f9c8

Added tag jdk8-b46 for changeset cf37a594c38d

! .hgtags

Changeset: fa0c28fabbb1
Author:    katleman
Date:      2012-07-12 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa0c28fabbb1

Added tag jdk8-b47 for changeset 0c7bb1f4f9c8

! .hgtags



From lana.steuck at oracle.com  Tue Jul 17 05:11:56 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:11:56 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20120717051227.A461A470BF@hg.openjdk.java.net>

Changeset: bf27b857c6ee
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bf27b857c6ee

Added tag jdk8-b46 for changeset 300f45e99064

! .hgtags

Changeset: 404521944ac9
Author:    lana
Date:      2012-07-10 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/404521944ac9

Merge


Changeset: 1c88da9a1365
Author:    katleman
Date:      2012-07-12 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c88da9a1365

Added tag jdk8-b47 for changeset 404521944ac9

! .hgtags

Changeset: df4092828362
Author:    lana
Date:      2012-07-16 17:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/df4092828362

Merge




From lana.steuck at oracle.com  Tue Jul 17 05:11:56 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:11:56 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20120717051228.582D0470C0@hg.openjdk.java.net>

Changeset: c7e62fc9df92
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7e62fc9df92

Added tag jdk8-b46 for changeset 4ca599497172

! .hgtags

Changeset: 01d9911df25d
Author:    erikj
Date:      2012-06-28 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01d9911df25d

7180594: Fix GenStubs in langtools for build-infra builds
Reviewed-by: ohair

! make/tools/genstubs/GenStubs.java

Changeset: 7e6be2f239c9
Author:    ohair
Date:      2012-07-08 20:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7e6be2f239c9

Merge


Changeset: afb0a5231557
Author:    katleman
Date:      2012-07-12 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afb0a5231557

Added tag jdk8-b47 for changeset 7e6be2f239c9

! .hgtags

Changeset: 1f8fc9e50a1f
Author:    lana
Date:      2012-07-16 17:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f8fc9e50a1f

Merge




From lana.steuck at oracle.com  Tue Jul 17 05:13:09 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 17 Jul 2012 05:13:09 +0000
Subject: hg: jdk8/tl/jdk: 22 new changesets
Message-ID: <20120717052455.79C10470C7@hg.openjdk.java.net>

Changeset: 9d1738ef61d6
Author:    katleman
Date:      2012-07-05 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d1738ef61d6

Added tag jdk8-b46 for changeset 8d2ed9d58453

! .hgtags

Changeset: 9881db0a65bf
Author:    prr
Date:      2012-06-26 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9881db0a65bf

7145771: [macosx] CreateFont/Register.java test fails because of cached results of getAllFonts()
Reviewed-by: igor, flar

! src/macosx/classes/sun/awt/CGraphicsEnvironment.java

Changeset: c689cc1ef29a
Author:    prr
Date:      2012-06-26 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c689cc1ef29a

7176447: Lunix/Solaris fontpath.c : double free(family)
Reviewed-by: igor, flar

! src/solaris/native/sun/awt/fontpath.c

Changeset: ad126e65ccc5
Author:    prr
Date:      2012-06-26 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad126e65ccc5

7164282: check for NULL return from malloc is testing wrong variable name.
Reviewed-by: igor, flar

! src/windows/native/sun/font/lcdglyph.c

Changeset: c960cb8d0f8b
Author:    lana
Date:      2012-06-27 18:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c960cb8d0f8b

Merge


Changeset: 8e6b8a676596
Author:    lana
Date:      2012-07-03 20:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e6b8a676596

Merge


Changeset: 7d1eae258183
Author:    serb
Date:      2012-06-26 13:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d1eae258183

7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Reviewed-by: anthony, art

! src/macosx/classes/sun/lwawt/LWButtonPeer.java
! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java
! src/macosx/classes/sun/lwawt/LWChoicePeer.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWLabelPeer.java
! src/macosx/classes/sun/lwawt/LWListPeer.java
! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java
! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java
! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java
! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java
! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: c66b34ec39c3
Author:    bagiras
Date:      2012-06-26 16:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c66b34ec39c3

7024749: JDK7 b131---a crash in: Java_sun_awt_windows_ThemeReader_isGetThemeTransitionDurationDefined+0x75
Reviewed-by: art, ant

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_FileDialog.cpp
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_TextComponent.cpp
+ test/java/awt/Frame/7024749/bug7024749.java

Changeset: 6d37b95f0555
Author:    anthony
Date:      2012-06-26 17:29 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d37b95f0555

7124326: [macosx] An issue similar to   autoshutdown one in two AppContexts situation.
Summary: Don't add SystemTrayPeer to the peers map
Reviewed-by: art, leonidr

! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java

Changeset: 7cadd5bb6983
Author:    lana
Date:      2012-06-27 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cadd5bb6983

Merge


Changeset: 85f72a4f5f68
Author:    rupashka
Date:      2012-06-28 14:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85f72a4f5f68

7169111: Unreadable menu bar with Ambiance theme in GTK L&F
Reviewed-by: kizune

! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java

Changeset: 8a284872ee2d
Author:    lana
Date:      2012-07-03 20:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a284872ee2d

Merge


Changeset: d828938945af
Author:    lana
Date:      2012-07-03 20:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d828938945af

Merge


Changeset: 9957b4759354
Author:    lana
Date:      2012-07-10 11:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9957b4759354

Merge


Changeset: 6df318863178
Author:    erikj
Date:      2012-07-03 16:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df318863178

7181504: Update of latest build-infra Makefiles
Reviewed-by: ohair

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CopySamples.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataBreakIterator.gmk
! makefiles/GendataFontConfig.gmk
! makefiles/GendataHtml32dtd.gmk
! makefiles/GenerateClasses.gmk
! makefiles/GenerateData.gmk
! makefiles/GenerateJavaSources.gmk
! makefiles/GensrcBuffer.gmk
! makefiles/GensrcIcons.gmk
+ makefiles/GensrcJObjC.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcProperties.gmk
! makefiles/GensrcX11Wrappers.gmk
! makefiles/Images.gmk
+ makefiles/Import.gmk
- makefiles/LegacyMakefiles.gmk
! makefiles/Makefile
- makefiles/OldImages.gmk
! makefiles/Tools.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjfr/mapfile-vers
! makefiles/mapfiles/libnio/mapfile-linux
! makefiles/mapfiles/libnio/mapfile-solaris
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: 8cb908672d9e
Author:    erikj
Date:      2012-07-03 11:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cb908672d9e

7181508: Remove GenerateNativeHeader on awt java file
Reviewed-by: ohair

! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/sun/awt/CharsetString.java
! src/share/classes/sun/java2d/pipe/RegionIterator.java
! src/share/native/sun/awt/image/cvutils/img_globals.c

Changeset: 6cd68b7bd962
Author:    erikj
Date:      2012-07-03 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cd68b7bd962

7181501: Add some GenerateNativeHeader annotations and misc Mac adjustments to makefiles
Reviewed-by: ohair

! src/macosx/native/jobjc/build.xml
! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java
! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java

Changeset: 5b0f880eb154
Author:    ohair
Date:      2012-07-05 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b0f880eb154

Merge

- makefiles/LegacyMakefiles.gmk
- makefiles/OldImages.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: 00b22b23269a
Author:    katleman
Date:      2012-07-11 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00b22b23269a

Merge

- makefiles/LegacyMakefiles.gmk
- makefiles/OldImages.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: 3e4ab821f461
Author:    katleman
Date:      2012-07-12 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e4ab821f461

Added tag jdk8-b47 for changeset 00b22b23269a

! .hgtags

Changeset: 7b5e4a64368a
Author:    lana
Date:      2012-07-16 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b5e4a64368a

Merge

- makefiles/LegacyMakefiles.gmk
- makefiles/OldImages.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: c7e3106e455a
Author:    lana
Date:      2012-07-16 22:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7e3106e455a

Merge

- test/sun/security/mscapi/ShortRSAKey512.sh
- test/sun/security/mscapi/ShortRSAKey768.sh



From Alan.Bateman at oracle.com  Tue Jul 17 08:18:32 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Jul 2012 09:18:32 +0100
Subject: Codereview request for 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
In-Reply-To: <50046094.8050804@oracle.com>
References: <4FFCB68E.6000608@oracle.com> <5000124E.5060002@oracle.com>
	<50005650.9090207@oracle.com> <50046094.8050804@oracle.com>
Message-ID: <50051FD8.1040905@oracle.com>

On 16/07/2012 19:42, Xueming Shen wrote:
> Hi Alan,
>
> I gave the "continue ->else if " a try, it appears the server vm 
> obviously likes
> the "continue" approach (it is consistent with what we experienced in 
> the past
> when we did similar approach for ascii, in which we separate/singled 
> the ascii
> path out). So I guess we probably want to keep the continue here.
>
> Here are the data. dbcs2_new is to replace the continue with else if 
> and the
> dbcs2 is the "continue".
>
> http://cr.openjdk.java.net/~sherman/7183053/dbcs2_new
> http://cr.openjdk.java.net/~sherman/7183053/dbcs2
>
> -Sherman
Thanks for checking, I had expected it would ultimately get compiled to 
the same code but it seems not.

In that case the changes in the webrev look fine to me.

-Alan


From stuart.marks at oracle.com  Tue Jul 17 16:08:40 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 17 Jul 2012 09:08:40 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <50049BC1.4050808@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<500087AE.7070501@oracle.com> <50043664.90306@oracle.com>
	<50049BC1.4050808@oracle.com>
Message-ID: <50058E08.7080808@oracle.com>

OK! Looks good!

I guess I have to push this for you. Can you commit the changeset in your repo, 
with proper commit comments etc., and send me the exported changeset? (Directly 
to me is fine, it doesn't need to be on the open list.) I'll push it later today.

Thanks.

s'marks


On 7/16/12 3:54 PM, Darryl Mocek wrote:
> Here's webrev.05 (http://cr.openjdk.java.net/~dmocek/7142596/webrev.05). Changes:
>
> - Simplify createRegistryOnUnusedPort()
> - Simplify getUnusedRandomPort()
> - Add isReservedPort() method to determine if a port is a reserved port # (not
> just one of the FIXED_PORT's, but also any port which shouldn't be used).
>
> Passes all tests.
>
> Darryl
>
> On 07/16/2012 08:42 AM, Stuart Marks wrote:
>> Hi Darryl,
>>
>> Sorry, I'm going to have to ask you to update this again. The issues are in
>> TestLibrary.java and are all related to catching exceptions and throwing new
>> exception instances, discarding the original exception (and probably relevant
>> diagnostic information) in the process.
>>
>> Let's get together today and work on it. I expect it will take only half an
>> hour or so to knock things out.
>>
>> s'marks
>>
>>
>>
>>
>> On 7/13/12 1:40 PM, Darryl Mocek wrote:
>>>
>>> On 07/12/2012 05:13 PM, Stuart Marks wrote:
>>>> OK, I took a look at the revised webrev. Most stuff is good. A couple changes
>>>> are necessary though.
>>>>
>>>>
>>>> *** MultipleRegistries.java
>>>>
>>>>
>>>> Not a big deal, but the comment at lines 65-67 is no longer necessary.
>>> Comment removed.
>>>>
>>>>
>>>> *** TestLibrary.java
>>>>
>>>>
>>>> I think the reserved port range stuff still needs to be fixed up.
>>>>
>>>> The comment at lines 81-82 talks about a range 64000-64100 which isn't really
>>>> present anywhere. The comment should instead say that PORT_MIN and PORT_MAX
>>>> should be kept adjusted so that they specify the range of ports defined by
>>>> the constants following. Make sure to do this adjustment; PORT_MAX is 64002
>>>> here.
>>> I reserved ports 64000-64100 (even though only 64001-64005 are currently being
>>> used) for fixed port tests (for tests which require fixed ports) so any future
>>> tests which require fixed ports can be assured there are ports available within
>>> a range for their use. In fixing the tests, I saw that those who wrote tests
>>> and used fixed ports grabbed random port numbers all over the place. Providing
>>> a reserved range allows them to just grab the next number and to keep the fixed
>>> port numbers in a group, even when new tests are added. If the ports are
>>> defined in a central place, like TestLibrary, then hopefully developers will
>>> come to TestLibrary to reserve the ports rather then define them in the tests
>>> themselves, like was done previously. I chose 100 ports for
>>> "future-proofing"...I don't think 100 is too many, but I've reduced it to 10
>>> and lowered the max to 64010. I was also thinking of looking for tests which
>>> used fixed ports outside of RMI tests and standardizing those ports here, but
>>> that's possible future work and I'm not sure it's necessary.
>>>>
>>>> The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000
>>>> as the *allowed* range for ports returned by getUnusedRandomPort(). But as I
>>>> described previously, this is difficult to enforce given the varying port
>>>> allocation schemes on different OSes.
>>>>
>>>> Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX
>>>> and make it be the range of ports reserved by tests that require fixed ports
>>>> (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to
>>>> *disallow* ports in this range, that is, to retry if the port is within this
>>>> range. Thus the condition on the while-loop has to be inverted, something like
>>>>
>>>> while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= PORT_MAX)
>>> Yes, this is correct and it has been changed.
>>>>
>>>> So, how could getUnusedRandomPort() have worked in its present state? Well I
>>>> think it ends up retrying 10 times, then at the end of the loop
>>>> unusedRandomPort is actually some legal port number -- albeit possibly one
>>>> within the disallowed range -- and almost certainly not -1, and so the method
>>>> returns it and the caller uses it. So, the success-testing logic here will
>>>> also have to change so that it retests whether the port is in the disallowed
>>>> range.
>>> Correct...done.
>>>>
>>>> The comment on getUnusedRandomPort() also needs to be updated to reflect its
>>>> new policy on the reserved range, as well as throwing an exception on
>>>> failure. Also (nitpick) it should say "less than" not "less then".
>>> Yes, I always do this. :(
>>>>
>>>> Looking at getUnusedRandomPort() again more closely [sorry] I think the catch
>>>> of Exception that does nothing is suspicious. I'm not sure why getting a
>>>> ServerSocket would fail, but if it does (maybe the system is out of ports??)
>>>> we should just throw out to the caller. Perhaps ideally we'd just have this
>>>> method throw IOException, but if that requires all callers to be updated, it
>>>> might be easier just to catch IOException and throw a RuntimeException that
>>>> wraps the caught IOException.
>>> I see no harm in trying again if it fails. If we have run out of ports, then
>>> possibly one or more used ports will be closed and freed and a subsequent try
>>> will succeed. I don't know all of the cases where a failure might occur.
>>> Anyway, if this is the prevailing way of handling this, I'll change it.
>>>>
>>>> Similar comments apply to the catch(Exception)/do-nothing code in the other
>>>> utility methods.
>>> Now throwing RuntimeException in getRegistryPort.
>>>>
>>>> Certainly getRegistryPort() should just throw (or possibly wrap and rethrow)
>>>> any exception caught.
>>>>
>>>> For createRegistryOnUnusedPort(), the catching of ExportException is handled
>>>> properly. The second catch clause of the outer try-block, and the catch of
>>>> the inner try-block, both ignore exceptions. The code will then end up
>>>> retrying. Is it reasonable that retrying in these cases will result in a
>>>> different outcome? My guess is that it's more likely that something is
>>>> seriously wrong that will cause all the retries to fail, in which case this
>>>> method will discard the exceptions it has just caught and throw a *new*
>>>> RemoteException instance.
>>> This was a holdover from webrev.00 which should have been removed. I agree with
>>> Alan and you here that multiple tries of LocateRegistry.createRegistry(0) is
>>> unnecessary. I've modified this to make a single attempt at using
>>> LocateRegistry.createRegistry(0) and if it fails, make a single attempt at
>>> getting an unused random port and creating a registry on this port, then
>>> failing with a RuntimeException.
>>>>
>>>> I'm particularly sensitive to this; as you might recall a couple weeks ago I
>>>> was having a wrestling match with the jstatd tests (I finished the match, but
>>>> I'm not sure I won). The primary problem was that several layers of code
>>>> would catch and discard exceptions, which made diagnosing the problem
>>>> incredibly difficult. So, I'd recommend removing the "do nothing" catch
>>>> clauses.
>>>>
>>>> Thinking further about createRegistryOnUnusedPort(), I'm not sure that
>>>> retrying 10 (or some other number of times) actually makes sense. It does for
>>>> getUnusedRandomPort(), which has to retry in order to get a port outside the
>>>> disallowed range. But for creating a registry, createRegistry(0) will usually
>>>> work the first time. If it throws ExportException, it does so for a specific
>>>> reason, so we should retry once on an unused random port. But if this still
>>>> fails, don't think retrying repeatedly makes sense.
>>> See above.
>>>
>>> Changes pass all tests. Updated webrev at
>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.04
>>>
>>> Darryl
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>>
>>>> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>>>>
>>>>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>>>>> OK, here's the review for the second half of the files in the webrev. I saw
>>>>>> your reply to the first half (to which I'll reply separately), and I don't
>>>>>> think there's anything here that's affected by them.
>>>>>>
>>>>>>
>>>>>> *** AppleUserImpl.java
>>>>>> *** ApplicationServer.java
>>>>>>
>>>>>>
>>>>>> REGISTRY_PORT should be a local variable; also rename to use mixed case.
>>>>> Changed to a private registryPort (see next issue).
>>>>>>
>>>>>> Eh, whoops, after looking at ApplicationServer.java I see that it accesses
>>>>>> the REGISTRY_PORT field directly. This is why direct field access is a bad
>>>>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized before
>>>>>> ApplicationServer needs it? It turns out that it has been -- but only in
>>>>>> some
>>>>>> cases.
>>>>>>
>>>>>> It seems like the test is trying to support two modes, one that runs in two
>>>>>> threads in the same JVM, and the other that runs in two separate JVMs. If
>>>>>> they are in separate JVMs, things will no longer work because in the JVM
>>>>>> that
>>>>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be -1. I
>>>>>> suspect that our test environment doesn't support the separate JVM mode, but
>>>>>> it seems unwise to break it.
>>>>>>
>>>>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>>>>> "well-known" default registry port number, which in this case seems like
>>>>>> 2006.
>>>>>>
>>>>>> In single-JVM mode, AppleUserImpl creates an instance of ApplicationServer,
>>>>>> so I'd suggest adding a method to ApplicationServer that allows
>>>>>> AppleUserImpl
>>>>>> to store the randomly-assigned registry port number into it, overriding the
>>>>>> default value.
>>>>>>
>>>>>> This seems like this is the simplest way to preserve the two modes of
>>>>>> operation but to support the random port selection model we're trying to
>>>>>> achieve.
>>>>> Rather then going the "fixed port" route, which is what we're trying to get
>>>>> away from, I've changed the implementation of both AppletUserImpl's and
>>>>> ApplicationServer so ApplicationServer requires a port and AppleUserImpl
>>>>> supplies the port on construction of ApplicationServer. I thought of
>>>>> modifying
>>>>> ApplicationServer's constructor to create a port using
>>>>> TestLibrary.getUnusedRandomPort, but decided requiring a port is better as
>>>>> ApplicationServer's job is to look for already exported AppleUser objects.
>>>>>>
>>>>>>
>>>>>> *** activatable/EchoImpl.java
>>>>>>
>>>>>>
>>>>>> int registryPort = new Integer(System.getProperty("rmi.registry.port"));
>>>>>>
>>>>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not a huge
>>>>>> deal, but it's probably more conventional to use parseInt() and it avoids
>>>>>> boxing.
>>>>>>
>>>>>> One could probably do Integer.getInteger("rmi.registry.port") but this is
>>>>>> seems pretty obscure to me even though it's more succinct.
>>>>>>
>>>>>> The same also applies to the following:
>>>>>> - HelloImpl.java
>>>>>> - unicast/EchoImpl.java
>>>>>> - ShutdownImpl.java
>>>>>> - SelfTerminator.java
>>>>>> - CheckFQDNClient.java
>>>>>> - LeaseLeakClient.java
>>>>>> - dgcDeadLock/TestImpl.java
>>>>>>
>>>>> Integer.parseInt returns a primitive (which is what the return is assigned
>>>>> to)
>>>>> and it appears Integer.parseInt is "faster" then creating a new Integer.
>>>>> Changed to Integer.parseInt in all places referenced.
>>>>>>
>>>>>> *** FiniteGCLatency.java
>>>>>>
>>>>>>
>>>>>> The pattern here is a bit odd, as the test creates the registry, throws away
>>>>>> the returned reference, and then calls getRegistry() to get another Registry
>>>>>> reference. It *seems* like they're identical references, but in fact the
>>>>>> first is apparently a reference to the actual Registry implementation,
>>>>>> whereas the second is a remote stub.
>>>>>>
>>>>>> The tests seem to do all the actual work using the remote stub, which seems
>>>>>> proper.
>>>>>>
>>>>>> This is confusing, though, as it looks like there's a redundant Registry
>>>>>> reference now. This might lead someone in the future to "simplify" the test
>>>>>> by not getting the remote stub, which in turn might invalidate some tests.
>>>>>> (In fact I was going to suggest this but I decided to investigate further
>>>>>> first.)
>>>>>>
>>>>>> At the very least, I'd suggest renaming the variable that holds the newly
>>>>>> created Registry to something like "registryImpl" to make it clear that it's
>>>>>> different from the thing returned by getRegistry(), even though they have a
>>>>>> the same time.
>>>>>>
>>>>>> Another possibility is to rearrange the TestLibrary API so that there is a
>>>>>> single utility method that combines createRegistryOnUnusedPort() and
>>>>>> getRegistryPort(). That is, it creates a new registry and simply returns the
>>>>>> port on which it was created, not a reference to the registry
>>>>>> implementation.
>>>>>> I don't think the registry implementation is actually ever used by the
>>>>>> tests,
>>>>>> and it might simplify things a bit as well.
>>>>>>
>>>>>> Possibly similar issues with:
>>>>>> - UnreferencedContext.java
>>>>>> - NoConsoleOutput.java
>>>>>>
>>>>>>
>>>>>> *** HttpSocketTest.java
>>>>>>
>>>>>>
>>>>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>>>>> Looks like extra code left over from the change from using
>>>>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) to
>>>>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>>>>
>>>>>>
>>>>>> *** TestLibrary.java
>>>>>>
>>>>>> Mostly pretty straightforward, but I do have some concerns about the random
>>>>>> port selection and a potential clash with the "reserved port range" as
>>>>>> defined in this test library.
>>>>>>
>>>>>> The getUnusedRandomPort() method attempts to get a socket within the range
>>>>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS
>>>>>> allocates ports more-or-less sequentially in the range [49152, 65536) which
>>>>>> means that when the kernel's internal counter gets to 64000,
>>>>>> getUnusedRandomPort()'s retries will fail, causing tests to fail until the
>>>>>> counter wraps around.
>>>>>>
>>>>>> Other systems behave differently; Linux seems to allocate them randomly in
>>>>>> the range [32768,65536) and Windows XP SP3 allocates them sequentially in
>>>>>> the
>>>>>> range (1024,5000]. So it's probably not a problem for them.
>>>>>>
>>>>>> I think the thing to do is to check only for "reserved ports" that are
>>>>>> actually used by tests here. These are in the range [64001,64005]. In
>>>>>> getUnusedRandomPort(), it should only need to retry if the returned port is
>>>>>> within this narrow, reserved range. If it's anything else it should be OK.
>>>>> I'll try setting the range this narrow, but I don't know how many sequential
>>>>> tests will be run at a time and I'm concerned 5 is too few. The -concurrency
>>>>> option on jtreg allows you to specify how many concurrent tests will be
>>>>> run. We
>>>>> should have enough test ports reserved to satisfy any concurrency request.
>>>>> I've
>>>>> run the tests with -concurrency=8 (I have a dual-core system showing 4
>>>>> CPU's).
>>>>> I tried reducing the port range to 64001/64002 and concurrency=4 and all
>>>>> passed
>>>>> fine, so maybe we're OK with just 5.
>>>>>>
>>>>>> On another topic, the three utility methods here:
>>>>>> - createRegistryOnUnusedPort
>>>>>> - getRegistryPort
>>>>>> - getUnusedRandomPort
>>>>>>
>>>>>> all catch exceptions and then return illegal values (null or -1), sometimes
>>>>>> after printing some diagnostic information. The problem is that the caller
>>>>>> will attempt to soldier on with the illegal return value and will stumble
>>>>>> over something later, such as NullPointerException or
>>>>>> IllegalArgumentException. This will probably be obvious but it's equally
>>>>>> likely to be confusing.
>>>>>>
>>>>>> Since these utilities are all called from test code, and the tests are
>>>>>> relying on them to return valid results, I'd suggest just throwing
>>>>>> exceptions
>>>>>> from the utility methods if they fail. This will (should) cause the test to
>>>>>> error out, but that's OK, as it never could have succeeded anyway if the
>>>>>> utility call had failed.
>>>>> I already modified createRegistryOnUnusedPort to throw an exception as
>>>>> part of
>>>>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>>>>> getRegistryPort and getUnusedRandomPort if they fail.
>>>>>
>>>>> See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>>>>
>>>>> Darryl
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and
>>>>>>> 7161503.
>>>>>>> Webrev can be found here:
>>>>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>>>>> This commit fixes concurrency issues with the RMI tests.
>>>>>>>
>>>>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>>>>>>> RMIRegistry on an unused port. It will try up to 10 times before giving up.
>>>>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the port
>>>>>>> number
>>>>>>> of the registry.
>>>>>>> - Changed almost all tests from using hard port numbers to using random
>>>>>>> port
>>>>>>> numbers for running the RMI Registry and RMID.
>>>>>>> - Removed othervm from those tests which don't need it.
>>>>>>> - Added parameters for tests which spawn a separate VM to pass RMI
>>>>>>> Registry and
>>>>>>> RMID ports in cases where needed.
>>>>>>> - Added PropertyPermission to security policy files where needed.
>>>>>>> - Removed java/rmi and sun/rmi from tests which cannot be run concurrently.
>>>>>>> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Darryl
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>


From stuart.marks at oracle.com  Tue Jul 17 21:14:26 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Tue, 17 Jul 2012 21:14:26 +0000
Subject: hg: jdk8/tl/jdk: 7142596: RMI JPRT tests are failing
Message-ID: <20120717211447.1CD49470DE@hg.openjdk.java.net>

Changeset: b6f78869c66d
Author:    dmocek
Date:      2012-07-17 11:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6f78869c66d

7142596: RMI JPRT tests are failing
Summary: Changed RMI tests to use random port numbers for the RMI Registry and RMID so the tests can be run concurrently without test failures due to tests using the same port numbers.
Reviewed-by: smarks, alanb
Contributed-by: olivier.lagneau at oracle.com

! test/ProblemList.txt
! test/TEST.ROOT
! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java
! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
! test/java/rmi/Naming/LookupNameWithColon.java
! test/java/rmi/Naming/RmiIsNoScheme.java
! test/java/rmi/Naming/UnderscoreHost.java
! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java
! test/java/rmi/activation/Activatable/checkActivateRef/security.policy
! test/java/rmi/activation/Activatable/checkAnnotations/security.policy
! test/java/rmi/activation/Activatable/checkImplClassLoader/security.policy
! test/java/rmi/activation/Activatable/checkRegisterInLog/security.policy
! test/java/rmi/activation/Activatable/createPrivateActivable/security.policy
! test/java/rmi/activation/Activatable/downloadParameterClass/security.policy
! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy
! test/java/rmi/activation/Activatable/extLoadedImpl/security.policy
! test/java/rmi/activation/Activatable/forceLogSnapshot/security.policy
! test/java/rmi/activation/Activatable/inactiveGroup/security.policy
! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java
! test/java/rmi/activation/Activatable/nestedActivate/security.policy
! test/java/rmi/activation/Activatable/nonExistentActivatable/security.policy
! test/java/rmi/activation/Activatable/restartCrashedService/security.policy
! test/java/rmi/activation/Activatable/restartLatecomer/security.policy
! test/java/rmi/activation/Activatable/restartService/security.policy
! test/java/rmi/activation/Activatable/shutdownGracefully/security.policy
! test/java/rmi/activation/Activatable/unregisterInactive/security.policy
! test/java/rmi/activation/ActivateFailedException/activateFails/security.policy
! test/java/rmi/activation/ActivationSystem/activeGroup/security.policy
! test/java/rmi/activation/ActivationSystem/modifyDescriptor/security.policy
! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java
! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/security.policy
! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java
! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy
! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
! test/java/rmi/activation/CommandEnvironment/security.policy
! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
! test/java/rmi/activation/rmidViaInheritedChannel/rmid.security.policy
! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/emptyName/EmptyName.java
! test/java/rmi/registry/interfaceHash/InterfaceHash.java
! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java
! test/java/rmi/registry/readTest/readTest.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/registry/reexport/Reexport.java
! test/java/rmi/reliability/juicer/AppleUserImpl.java
! test/java/rmi/reliability/juicer/ApplicationServer.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/security.policy
! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/HelloImpl.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/security.policy
! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/EchoImpl.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/security.policy
! test/java/rmi/server/RemoteServer/AddrInUse.java
! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java
! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/ShutdownImpl.java
! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java
! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java
! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java
! test/java/rmi/server/Unreferenced/leaseCheckInterval/SelfTerminator.java
! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java
! test/java/rmi/server/useCustomRef/UseCustomRef.java
! test/java/rmi/server/useCustomRef/security.policy
! test/java/rmi/testlibrary/ActivationLibrary.java
! test/java/rmi/testlibrary/RMID.java
! test/java/rmi/testlibrary/RegistryRunner.java
! test/java/rmi/testlibrary/StreamPipe.java
! test/java/rmi/testlibrary/TestLibrary.java
! test/java/rmi/transport/checkFQDN/CheckFQDN.java
! test/java/rmi/transport/checkFQDN/CheckFQDNClient.java
! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java
! test/java/rmi/transport/checkLeaseInfoLeak/LeaseLeakClient.java
! test/java/rmi/transport/checkLeaseInfoLeak/security.policy
! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java
! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java
! test/java/rmi/transport/dgcDeadLock/TestImpl.java
! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java
! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java
! test/java/rmi/transport/httpSocket/HttpSocketTest.java
! test/java/rmi/transport/httpSocket/security.policy
! test/java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java
! test/sun/rmi/rmic/newrmic/equivalence/AppleUserImpl.java
! test/sun/rmi/rmic/newrmic/equivalence/run.sh
! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java
! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
! test/sun/rmi/transport/proxy/EagerHttpFallback.java
! test/sun/rmi/transport/tcp/DeadCachedConnection.java



From stuart.marks at oracle.com  Tue Jul 17 21:18:37 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 17 Jul 2012 14:18:37 -0700
Subject: Code Review Request 7142596: RMI JPRT tests are failing
In-Reply-To: <50058E08.7080808@oracle.com>
References: <4FF60595.3020607@oracle.com> <4FFB6C30.2000109@oracle.com>
	<4FFC9B4F.1060200@oracle.com> <4FFF6847.3020701@oracle.com>
	<500087AE.7070501@oracle.com> <50043664.90306@oracle.com>
	<50049BC1.4050808@oracle.com> <50058E08.7080808@oracle.com>
Message-ID: <5005D6AD.3020500@oracle.com>

Pushed:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6f78869c66d

Darryl, please update the bug report.

Thanks,

s'marks

On 7/17/12 9:08 AM, Stuart Marks wrote:
> OK! Looks good!
>
> I guess I have to push this for you. Can you commit the changeset in your repo,
> with proper commit comments etc., and send me the exported changeset? (Directly
> to me is fine, it doesn't need to be on the open list.) I'll push it later today.
>
> Thanks.
>
> s'marks
>
>
> On 7/16/12 3:54 PM, Darryl Mocek wrote:
>> Here's webrev.05 (http://cr.openjdk.java.net/~dmocek/7142596/webrev.05).
>> Changes:
>>
>> - Simplify createRegistryOnUnusedPort()
>> - Simplify getUnusedRandomPort()
>> - Add isReservedPort() method to determine if a port is a reserved port # (not
>> just one of the FIXED_PORT's, but also any port which shouldn't be used).
>>
>> Passes all tests.
>>
>> Darryl
>>
>> On 07/16/2012 08:42 AM, Stuart Marks wrote:
>>> Hi Darryl,
>>>
>>> Sorry, I'm going to have to ask you to update this again. The issues are in
>>> TestLibrary.java and are all related to catching exceptions and throwing new
>>> exception instances, discarding the original exception (and probably relevant
>>> diagnostic information) in the process.
>>>
>>> Let's get together today and work on it. I expect it will take only half an
>>> hour or so to knock things out.
>>>
>>> s'marks
>>>
>>>
>>>
>>>
>>> On 7/13/12 1:40 PM, Darryl Mocek wrote:
>>>>
>>>> On 07/12/2012 05:13 PM, Stuart Marks wrote:
>>>>> OK, I took a look at the revised webrev. Most stuff is good. A couple changes
>>>>> are necessary though.
>>>>>
>>>>>
>>>>> *** MultipleRegistries.java
>>>>>
>>>>>
>>>>> Not a big deal, but the comment at lines 65-67 is no longer necessary.
>>>> Comment removed.
>>>>>
>>>>>
>>>>> *** TestLibrary.java
>>>>>
>>>>>
>>>>> I think the reserved port range stuff still needs to be fixed up.
>>>>>
>>>>> The comment at lines 81-82 talks about a range 64000-64100 which isn't really
>>>>> present anywhere. The comment should instead say that PORT_MIN and PORT_MAX
>>>>> should be kept adjusted so that they specify the range of ports defined by
>>>>> the constants following. Make sure to do this adjustment; PORT_MAX is 64002
>>>>> here.
>>>> I reserved ports 64000-64100 (even though only 64001-64005 are currently being
>>>> used) for fixed port tests (for tests which require fixed ports) so any future
>>>> tests which require fixed ports can be assured there are ports available
>>>> within
>>>> a range for their use. In fixing the tests, I saw that those who wrote tests
>>>> and used fixed ports grabbed random port numbers all over the place. Providing
>>>> a reserved range allows them to just grab the next number and to keep the
>>>> fixed
>>>> port numbers in a group, even when new tests are added. If the ports are
>>>> defined in a central place, like TestLibrary, then hopefully developers will
>>>> come to TestLibrary to reserve the ports rather then define them in the tests
>>>> themselves, like was done previously. I chose 100 ports for
>>>> "future-proofing"...I don't think 100 is too many, but I've reduced it to 10
>>>> and lowered the max to 64010. I was also thinking of looking for tests which
>>>> used fixed ports outside of RMI tests and standardizing those ports here, but
>>>> that's possible future work and I'm not sure it's necessary.
>>>>>
>>>>> The previous webrev had PORT_MIN and PORT_MAX specify a range of 1024-64000
>>>>> as the *allowed* range for ports returned by getUnusedRandomPort(). But as I
>>>>> described previously, this is difficult to enforce given the varying port
>>>>> allocation schemes on different OSes.
>>>>>
>>>>> Instead I think we need to invert the sense of the range PORT_MIN..PORT_MAX
>>>>> and make it be the range of ports reserved by tests that require fixed ports
>>>>> (64001 through 64005). Then, getUnusedRandomPort() needs to be changed to
>>>>> *disallow* ports in this range, that is, to retry if the port is within this
>>>>> range. Thus the condition on the while-loop has to be inverted, something
>>>>> like
>>>>>
>>>>> while (... unusedRandomPort >= PORT_MIN && unusedRandomPort <= PORT_MAX)
>>>> Yes, this is correct and it has been changed.
>>>>>
>>>>> So, how could getUnusedRandomPort() have worked in its present state? Well I
>>>>> think it ends up retrying 10 times, then at the end of the loop
>>>>> unusedRandomPort is actually some legal port number -- albeit possibly one
>>>>> within the disallowed range -- and almost certainly not -1, and so the method
>>>>> returns it and the caller uses it. So, the success-testing logic here will
>>>>> also have to change so that it retests whether the port is in the disallowed
>>>>> range.
>>>> Correct...done.
>>>>>
>>>>> The comment on getUnusedRandomPort() also needs to be updated to reflect its
>>>>> new policy on the reserved range, as well as throwing an exception on
>>>>> failure. Also (nitpick) it should say "less than" not "less then".
>>>> Yes, I always do this. :(
>>>>>
>>>>> Looking at getUnusedRandomPort() again more closely [sorry] I think the catch
>>>>> of Exception that does nothing is suspicious. I'm not sure why getting a
>>>>> ServerSocket would fail, but if it does (maybe the system is out of ports??)
>>>>> we should just throw out to the caller. Perhaps ideally we'd just have this
>>>>> method throw IOException, but if that requires all callers to be updated, it
>>>>> might be easier just to catch IOException and throw a RuntimeException that
>>>>> wraps the caught IOException.
>>>> I see no harm in trying again if it fails. If we have run out of ports, then
>>>> possibly one or more used ports will be closed and freed and a subsequent try
>>>> will succeed. I don't know all of the cases where a failure might occur.
>>>> Anyway, if this is the prevailing way of handling this, I'll change it.
>>>>>
>>>>> Similar comments apply to the catch(Exception)/do-nothing code in the other
>>>>> utility methods.
>>>> Now throwing RuntimeException in getRegistryPort.
>>>>>
>>>>> Certainly getRegistryPort() should just throw (or possibly wrap and rethrow)
>>>>> any exception caught.
>>>>>
>>>>> For createRegistryOnUnusedPort(), the catching of ExportException is handled
>>>>> properly. The second catch clause of the outer try-block, and the catch of
>>>>> the inner try-block, both ignore exceptions. The code will then end up
>>>>> retrying. Is it reasonable that retrying in these cases will result in a
>>>>> different outcome? My guess is that it's more likely that something is
>>>>> seriously wrong that will cause all the retries to fail, in which case this
>>>>> method will discard the exceptions it has just caught and throw a *new*
>>>>> RemoteException instance.
>>>> This was a holdover from webrev.00 which should have been removed. I agree
>>>> with
>>>> Alan and you here that multiple tries of LocateRegistry.createRegistry(0) is
>>>> unnecessary. I've modified this to make a single attempt at using
>>>> LocateRegistry.createRegistry(0) and if it fails, make a single attempt at
>>>> getting an unused random port and creating a registry on this port, then
>>>> failing with a RuntimeException.
>>>>>
>>>>> I'm particularly sensitive to this; as you might recall a couple weeks ago I
>>>>> was having a wrestling match with the jstatd tests (I finished the match, but
>>>>> I'm not sure I won). The primary problem was that several layers of code
>>>>> would catch and discard exceptions, which made diagnosing the problem
>>>>> incredibly difficult. So, I'd recommend removing the "do nothing" catch
>>>>> clauses.
>>>>>
>>>>> Thinking further about createRegistryOnUnusedPort(), I'm not sure that
>>>>> retrying 10 (or some other number of times) actually makes sense. It does for
>>>>> getUnusedRandomPort(), which has to retry in order to get a port outside the
>>>>> disallowed range. But for creating a registry, createRegistry(0) will usually
>>>>> work the first time. If it throws ExportException, it does so for a specific
>>>>> reason, so we should retry once on an unused random port. But if this still
>>>>> fails, don't think retrying repeatedly makes sense.
>>>> See above.
>>>>
>>>> Changes pass all tests. Updated webrev at
>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.04
>>>>
>>>> Darryl
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/10/12 2:14 PM, Darryl Mocek wrote:
>>>>>>
>>>>>> On 07/09/2012 04:41 PM, Stuart Marks wrote:
>>>>>>> OK, here's the review for the second half of the files in the webrev. I saw
>>>>>>> your reply to the first half (to which I'll reply separately), and I don't
>>>>>>> think there's anything here that's affected by them.
>>>>>>>
>>>>>>>
>>>>>>> *** AppleUserImpl.java
>>>>>>> *** ApplicationServer.java
>>>>>>>
>>>>>>>
>>>>>>> REGISTRY_PORT should be a local variable; also rename to use mixed case.
>>>>>> Changed to a private registryPort (see next issue).
>>>>>>>
>>>>>>> Eh, whoops, after looking at ApplicationServer.java I see that it accesses
>>>>>>> the REGISTRY_PORT field directly. This is why direct field access is a bad
>>>>>>> idea. :-) Now the question is, has REGISTRY_PORT been initialized before
>>>>>>> ApplicationServer needs it? It turns out that it has been -- but only in
>>>>>>> some
>>>>>>> cases.
>>>>>>>
>>>>>>> It seems like the test is trying to support two modes, one that runs in two
>>>>>>> threads in the same JVM, and the other that runs in two separate JVMs. If
>>>>>>> they are in separate JVMs, things will no longer work because in the JVM
>>>>>>> that
>>>>>>> runs ApplicationServer.main(), AppleUserImpl.REGISTRY_PORT will be -1. I
>>>>>>> suspect that our test environment doesn't support the separate JVM mode,
>>>>>>> but
>>>>>>> it seems unwise to break it.
>>>>>>>
>>>>>>> I'd suggest that in two-JVM mode the classes fall back to using a
>>>>>>> "well-known" default registry port number, which in this case seems like
>>>>>>> 2006.
>>>>>>>
>>>>>>> In single-JVM mode, AppleUserImpl creates an instance of ApplicationServer,
>>>>>>> so I'd suggest adding a method to ApplicationServer that allows
>>>>>>> AppleUserImpl
>>>>>>> to store the randomly-assigned registry port number into it, overriding the
>>>>>>> default value.
>>>>>>>
>>>>>>> This seems like this is the simplest way to preserve the two modes of
>>>>>>> operation but to support the random port selection model we're trying to
>>>>>>> achieve.
>>>>>> Rather then going the "fixed port" route, which is what we're trying to get
>>>>>> away from, I've changed the implementation of both AppletUserImpl's and
>>>>>> ApplicationServer so ApplicationServer requires a port and AppleUserImpl
>>>>>> supplies the port on construction of ApplicationServer. I thought of
>>>>>> modifying
>>>>>> ApplicationServer's constructor to create a port using
>>>>>> TestLibrary.getUnusedRandomPort, but decided requiring a port is better as
>>>>>> ApplicationServer's job is to look for already exported AppleUser objects.
>>>>>>>
>>>>>>>
>>>>>>> *** activatable/EchoImpl.java
>>>>>>>
>>>>>>>
>>>>>>> int registryPort = new Integer(System.getProperty("rmi.registry.port"));
>>>>>>>
>>>>>>> I'd suggest using Integer.parseInt() instead of new Integer(). Not a huge
>>>>>>> deal, but it's probably more conventional to use parseInt() and it avoids
>>>>>>> boxing.
>>>>>>>
>>>>>>> One could probably do Integer.getInteger("rmi.registry.port") but this is
>>>>>>> seems pretty obscure to me even though it's more succinct.
>>>>>>>
>>>>>>> The same also applies to the following:
>>>>>>> - HelloImpl.java
>>>>>>> - unicast/EchoImpl.java
>>>>>>> - ShutdownImpl.java
>>>>>>> - SelfTerminator.java
>>>>>>> - CheckFQDNClient.java
>>>>>>> - LeaseLeakClient.java
>>>>>>> - dgcDeadLock/TestImpl.java
>>>>>>>
>>>>>> Integer.parseInt returns a primitive (which is what the return is assigned
>>>>>> to)
>>>>>> and it appears Integer.parseInt is "faster" then creating a new Integer.
>>>>>> Changed to Integer.parseInt in all places referenced.
>>>>>>>
>>>>>>> *** FiniteGCLatency.java
>>>>>>>
>>>>>>>
>>>>>>> The pattern here is a bit odd, as the test creates the registry, throws
>>>>>>> away
>>>>>>> the returned reference, and then calls getRegistry() to get another
>>>>>>> Registry
>>>>>>> reference. It *seems* like they're identical references, but in fact the
>>>>>>> first is apparently a reference to the actual Registry implementation,
>>>>>>> whereas the second is a remote stub.
>>>>>>>
>>>>>>> The tests seem to do all the actual work using the remote stub, which seems
>>>>>>> proper.
>>>>>>>
>>>>>>> This is confusing, though, as it looks like there's a redundant Registry
>>>>>>> reference now. This might lead someone in the future to "simplify" the test
>>>>>>> by not getting the remote stub, which in turn might invalidate some tests.
>>>>>>> (In fact I was going to suggest this but I decided to investigate further
>>>>>>> first.)
>>>>>>>
>>>>>>> At the very least, I'd suggest renaming the variable that holds the newly
>>>>>>> created Registry to something like "registryImpl" to make it clear that
>>>>>>> it's
>>>>>>> different from the thing returned by getRegistry(), even though they have a
>>>>>>> the same time.
>>>>>>>
>>>>>>> Another possibility is to rearrange the TestLibrary API so that there is a
>>>>>>> single utility method that combines createRegistryOnUnusedPort() and
>>>>>>> getRegistryPort(). That is, it creates a new registry and simply returns
>>>>>>> the
>>>>>>> port on which it was created, not a reference to the registry
>>>>>>> implementation.
>>>>>>> I don't think the registry implementation is actually ever used by the
>>>>>>> tests,
>>>>>>> and it might simplify things a bit as well.
>>>>>>>
>>>>>>> Possibly similar issues with:
>>>>>>> - UnreferencedContext.java
>>>>>>> - NoConsoleOutput.java
>>>>>>>
>>>>>>>
>>>>>>> *** HttpSocketTest.java
>>>>>>>
>>>>>>>
>>>>>>> Unnecessary call to TestLibrary.getUnusedRandomPort()?
>>>>>> Looks like extra code left over from the change from using
>>>>>> TestLibrary.getUnusedRandomPort/LocateRegistry.createRegistry(randomPort) to
>>>>>> TestLibrary.createRegistryOnUnusedPort...removed.
>>>>>>>
>>>>>>>
>>>>>>> *** TestLibrary.java
>>>>>>>
>>>>>>> Mostly pretty straightforward, but I do have some concerns about the random
>>>>>>> port selection and a potential clash with the "reserved port range" as
>>>>>>> defined in this test library.
>>>>>>>
>>>>>>> The getUnusedRandomPort() method attempts to get a socket within the range
>>>>>>> (1024,64000) and will retry 10 times if it can't. Unfortunately, MacOS
>>>>>>> allocates ports more-or-less sequentially in the range [49152, 65536) which
>>>>>>> means that when the kernel's internal counter gets to 64000,
>>>>>>> getUnusedRandomPort()'s retries will fail, causing tests to fail until the
>>>>>>> counter wraps around.
>>>>>>>
>>>>>>> Other systems behave differently; Linux seems to allocate them randomly in
>>>>>>> the range [32768,65536) and Windows XP SP3 allocates them sequentially in
>>>>>>> the
>>>>>>> range (1024,5000]. So it's probably not a problem for them.
>>>>>>>
>>>>>>> I think the thing to do is to check only for "reserved ports" that are
>>>>>>> actually used by tests here. These are in the range [64001,64005]. In
>>>>>>> getUnusedRandomPort(), it should only need to retry if the returned port is
>>>>>>> within this narrow, reserved range. If it's anything else it should be OK.
>>>>>> I'll try setting the range this narrow, but I don't know how many sequential
>>>>>> tests will be run at a time and I'm concerned 5 is too few. The -concurrency
>>>>>> option on jtreg allows you to specify how many concurrent tests will be
>>>>>> run. We
>>>>>> should have enough test ports reserved to satisfy any concurrency request.
>>>>>> I've
>>>>>> run the tests with -concurrency=8 (I have a dual-core system showing 4
>>>>>> CPU's).
>>>>>> I tried reducing the port range to 64001/64002 and concurrency=4 and all
>>>>>> passed
>>>>>> fine, so maybe we're OK with just 5.
>>>>>>>
>>>>>>> On another topic, the three utility methods here:
>>>>>>> - createRegistryOnUnusedPort
>>>>>>> - getRegistryPort
>>>>>>> - getUnusedRandomPort
>>>>>>>
>>>>>>> all catch exceptions and then return illegal values (null or -1), sometimes
>>>>>>> after printing some diagnostic information. The problem is that the caller
>>>>>>> will attempt to soldier on with the illegal return value and will stumble
>>>>>>> over something later, such as NullPointerException or
>>>>>>> IllegalArgumentException. This will probably be obvious but it's equally
>>>>>>> likely to be confusing.
>>>>>>>
>>>>>>> Since these utilities are all called from test code, and the tests are
>>>>>>> relying on them to return valid results, I'd suggest just throwing
>>>>>>> exceptions
>>>>>>> from the utility methods if they fail. This will (should) cause the test to
>>>>>>> error out, but that's OK, as it never could have succeeded anyway if the
>>>>>>> utility call had failed.
>>>>>> I already modified createRegistryOnUnusedPort to throw an exception as
>>>>>> part of
>>>>>> the MultipleRegistries change. I'm now throwing a RuntimeException for
>>>>>> getRegistryPort and getUnusedRandomPort if they fail.
>>>>>>
>>>>>> See updated webrev: http://cr.openjdk.java.net/~dmocek/7142596/webrev.03
>>>>>>
>>>>>> Darryl
>>>>>>>
>>>>>>> s'marks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/5/12 2:22 PM, Darryl Mocek wrote:
>>>>>>>> Hello core-libs. Please review this webrev to fix Bugs #7142596 and
>>>>>>>> 7161503.
>>>>>>>> Webrev can be found here:
>>>>>>>> http://cr.openjdk.java.net/~dmocek/7142596/webrev.02.
>>>>>>>> This commit fixes concurrency issues with the RMI tests.
>>>>>>>>
>>>>>>>> - Added TestLibrary.createRegistryOnUnusedPort method. This creates an
>>>>>>>> RMIRegistry on an unused port. It will try up to 10 times before giving
>>>>>>>> up.
>>>>>>>> - Added a TestLibrary.getRegistryPort(Registry) method to get the port
>>>>>>>> number
>>>>>>>> of the registry.
>>>>>>>> - Changed almost all tests from using hard port numbers to using random
>>>>>>>> port
>>>>>>>> numbers for running the RMI Registry and RMID.
>>>>>>>> - Removed othervm from those tests which don't need it.
>>>>>>>> - Added parameters for tests which spawn a separate VM to pass RMI
>>>>>>>> Registry and
>>>>>>>> RMID ports in cases where needed.
>>>>>>>> - Added PropertyPermission to security policy files where needed.
>>>>>>>> - Removed java/rmi and sun/rmi from tests which cannot be run
>>>>>>>> concurrently.
>>>>>>>> - Added java/rmi/Naming to list of tests which cannot be run concurrently.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Darryl
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


From xueming.shen at oracle.com  Wed Jul 18 02:49:53 2012
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 18 Jul 2012 02:49:53 +0000
Subject: hg: jdk8/tl/jdk: 7183053: Optimize DoubleByte charset for
	String.getBytes()/new String(byte[])
Message-ID: <20120718025004.292C3470F5@hg.openjdk.java.net>

Changeset: c76ad79a5a2f
Author:    sherman
Date:      2012-07-17 19:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c76ad79a5a2f

7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[])
Summary: DoubleByte implements sun/nio.cs/ArrayDe/Encoder interface
Reviewed-by: alanb

! src/share/classes/sun/nio/cs/ext/DoubleByte.java
! src/share/classes/sun/nio/cs/ext/HKSCS.java
! test/sun/nio/cs/StrCodingBenchmark.java
+ test/sun/nio/cs/StrCodingBenchmarkDB.java
! test/sun/nio/cs/TestStringCoding.java



From stuart.marks at oracle.com  Wed Jul 18 17:02:51 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Wed, 18 Jul 2012 17:02:51 +0000
Subject: hg: jdk8/tl/jdk: 7184943: fix failing test
	com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java; ...
Message-ID: <20120718170303.4B29447108@hg.openjdk.java.net>

Changeset: 89129c0737f1
Author:    dmocek
Date:      2012-07-18 10:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89129c0737f1

7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
7184946: fix failing test com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java
Reviewed-by: smarks

! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java
! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java



From michael.x.mcmahon at oracle.com  Wed Jul 18 17:52:28 2012
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Wed, 18 Jul 2012 17:52:28 +0000
Subject: hg: jdk8/tl/jdk: 7183292: HttpURLConnection.getHeaderFields() throws
	IllegalArgumentException: Illegal cookie name
Message-ID: <20120718175239.1E4B247109@hg.openjdk.java.net>

Changeset: 7bd32bfc0539
Author:    michaelm
Date:      2012-07-18 18:46 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd32bfc0539

7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name
Reviewed-by: khazra, chegar

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java
+ test/java/net/HttpCookie/IllegalCookieNameTest.java



From kurchi.subhra.hazra at oracle.com  Wed Jul 18 23:40:07 2012
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Wed, 18 Jul 2012 23:40:07 +0000
Subject: hg: jdk8/tl/jdk: 7185051: Remove TestProviderLeak.java from the
	ProblemList
Message-ID: <20120718234027.C9FE14712E@hg.openjdk.java.net>

Changeset: 773474da570b
Author:    khazra
Date:      2012-07-18 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/773474da570b

7185051: Remove TestProviderLeak.java from the ProblemList
Summary: Remove TestProviderLeak.java from jdk test problem list.
Reviewed-by: khazra
Contributed-by: dan.xu at oracle.com

! test/ProblemList.txt



From yiming.wang at oracle.com  Thu Jul 19 08:54:42 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Thu, 19 Jul 2012 16:54:42 +0800
Subject: [PATCH] Review request: 7081476
	test/java/net/InetSocketAddress/B6469803.java failing intermittently
Message-ID: <5007CB52.8010206@oracle.com>

Hi Chris,

Please help to review the fix for 7081476 
<http://monaco.us.oracle.com/detail.jsf?cr=7081476>: 
test/java/net/InetSocketAddress/B6469803.java failing intermittently.
http://dl.dropbox.com/u/90659131/fixes/7081476/webrev/index.html

The test failed when it is running with 
java/net/DatagramPacket/ReuseBuf.java concurrently. As discussed, the 
root cause is:
1. The call InetAddress.getByName("LocalHost") in ReuseBuf.java 
generates the address entry which hostname is "LocalHost" and put it 
with lowercase key "localhost" into InetAddress cache.
2. if the test B6469803.java executes concurrently, the call new 
InetSocketAddress("localhost", 12345) lookups the InetAddress cache by 
using the key "localhost", it can find the result in cache which 
hostname is "LocalHost", so the test fails as the expected value is 
"localhost".

Regards,
Eric


From ahughes at redhat.com  Thu Jul 19 13:20:44 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Thu, 19 Jul 2012 09:20:44 -0400 (EDT)
Subject: Native zlib libraries
In-Reply-To: <4FFD2F95.90905@oracle.com>
Message-ID: <87bfdc62-8fa3-4fbe-bed0-a9cf083af064@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 05/07/2012 17:11, Andrew Hughes wrote:
> >
> > ----- Original Message -----
> >> Is there a way to get the native zlib libraries to get picked up
> >> instead of the hardcoded version within the JVM?
> >>
> >> --
> >> Azeem Jiva
> >> @javawithjiva
> > We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get it
> > upstream.
> >
> > However, I don't see how this is related to HotSpot, as the zlib
> > usage
> > is in the jdk tree.
> I think we need to (re)start the discussion on core-libs-dev with a
> view
> to eliminating the patches that the JDK has to zlib, see:
> 
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
> 
> One of these changes relates to the zip64 support and I believe there
> are corner cases when inflating or deflating >2GB that won't work if
> using the system zlib. Sherman will likely recall the details. Given
> that the new build already supports using the system zlib (at least
> on
> Linux) then it would be good to sort this out so that it just works.
> 

Hmmm... this is interesting as we've been shipping OpenJDK with system zlib the whole time.

Are some of the issues resolved in newer versions?  My system copy is 1.2.7.

Not only is it generally against GNU/Linux distribution policy to bundle libraries without good reason, but it also means
we then have to rebuild OpenJDK for any security issues in those dependencies.

> -Alan
> 
> 
> 
> 
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From Alan.Bateman at oracle.com  Thu Jul 19 13:43:54 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jul 2012 14:43:54 +0100
Subject: Native zlib libraries
In-Reply-To: <87bfdc62-8fa3-4fbe-bed0-a9cf083af064@zmail17.collab.prod.int.phx2.redhat.com>
References: <87bfdc62-8fa3-4fbe-bed0-a9cf083af064@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <50080F1A.6090004@oracle.com>

On 19/07/2012 14:20, Andrew Hughes wrote:
> :
>
> Hmmm... this is interesting as we've been shipping OpenJDK with system zlib the whole time.
>
> Are some of the issues resolved in newer versions?  My system copy is 1.2.7.
>
> Not only is it generally against GNU/Linux distribution policy to bundle libraries without good reason, but it also means
> we then have to rebuild OpenJDK for any security issues in those dependencies.
>
I think using the system zlib (or libz as it seems to shipped as on 
Solaris and MacOSX) would have been okay with jdk6, it's just that the 
zip64 support in jdk7 changed total_in/out to "long long".

The copy that we have in the jdk repository at this time is 1.2.5. I'm 
not aware of any updates that avoid this patch but I think the right 
thing is to change the java.util.zip code so that it works with an 
unmodified zlib. I think Sherman has ideas on this, just hasn't got to 
it yet. If you have cycles to look at it that would be great (and I 
understand that distributions would frown on attempts to bundle a 
private copy with OpenJDK).

-Alan.


From chris.hegarty at oracle.com  Thu Jul 19 17:19:49 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 19 Jul 2012 17:19:49 +0000
Subject: hg: jdk8/tl/jdk: 7081476:
	test/java/net/InetSocketAddress/B6469803.java failing intermittently
Message-ID: <20120719172024.05C0247149@hg.openjdk.java.net>

Changeset: 2c2e4ecc8f7e
Author:    chegar
Date:      2012-07-19 18:19 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c2e4ecc8f7e

7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently
Reviewed-by: chegar
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/ProblemList.txt
! test/java/net/DatagramPacket/ReuseBuf.java



From chris.hegarty at oracle.com  Thu Jul 19 17:20:16 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Jul 2012 18:20:16 +0100
Subject: [PATCH] Review request: 7081476
	test/java/net/InetSocketAddress/B6469803.java failing intermittently
In-Reply-To: <5007CB52.8010206@oracle.com>
References: <5007CB52.8010206@oracle.com>
Message-ID: <500841D0.8040306@oracle.com>

Looks fine to me.  Thanks for tracking it down.

I'll push the changeset for you.

-Chris.

On 19/07/12 09:54, Eric Wang wrote:
> Hi Chris,
>
> Please help to review the fix for 7081476
> <http://monaco.us.oracle.com/detail.jsf?cr=7081476>:
> test/java/net/InetSocketAddress/B6469803.java failing intermittently.
> http://dl.dropbox.com/u/90659131/fixes/7081476/webrev/index.html
>
> The test failed when it is running with
> java/net/DatagramPacket/ReuseBuf.java concurrently. As discussed, the
> root cause is:
> 1. The call InetAddress.getByName("LocalHost") in ReuseBuf.java
> generates the address entry which hostname is "LocalHost" and put it
> with lowercase key "localhost" into InetAddress cache.
> 2. if the test B6469803.java executes concurrently, the call new
> InetSocketAddress("localhost", 12345) lookups the InetAddress cache by
> using the key "localhost", it can find the result in cache which
> hostname is "LocalHost", so the test fails as the expected value is
> "localhost".
>
> Regards,
> Eric


From kurchi.subhra.hazra at oracle.com  Thu Jul 19 18:31:20 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Thu, 19 Jul 2012 11:31:20 -0700
Subject: Code Review Request: 7184287: (prefs) BackingStoreException when
	calling flush on root node[macosx]
Message-ID: <059F9478-4212-438F-A7AD-A40FAA3702FB@oracle.com>

Hi, 

While flushing user preferences, a BackingStoreException is not expected, since 
the current user should be able to write such preferences to the 
persistent storage (unlike system preferences, where current user needs 
to have admin rights). This fix aims at allowing a user preference node 
to flush any changes to the persistent storage on Mac OS X.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287 
Webrev: http://cr.openjdk.java.net/~khazra/7184287/webrev.00/ 

Thanks, 
Kurchi

From xueming.shen at oracle.com  Fri Jul 20 04:23:51 2012
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Fri, 20 Jul 2012 04:23:51 +0000
Subject: hg: jdk8/tl/jdk: 7130915: File.equals does not give expected results
	when path contains Non-English characters on Mac OS X
Message-ID: <20120720042421.9835647159@hg.openjdk.java.net>

Changeset: 84cd98a5641c
Author:    sherman
Date:      2012-07-19 21:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84cd98a5641c

7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
Summary: to support Unicode nfd/nfc file path on Macos
Reviewed-by: alanb

! make/java/nio/Makefile
! src/share/native/java/io/io_util.h
! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java
+ src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java
+ src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java
+ src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixFileSystem.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/native/java/io/UnixFileSystem_md.c
! src/solaris/native/java/io/io_util_md.c
! src/solaris/native/java/io/io_util_md.h
+ src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c
+ test/java/io/File/MacPathTest.java
+ test/java/io/File/MacPathTest.sh
+ test/java/nio/file/Path/MacPathTest.java
+ test/java/nio/file/Path/MacPathTest.sh



From david.holmes at oracle.com  Fri Jul 20 08:12:42 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Jul 2012 18:12:42 +1000
Subject: RFR: 7130909 Add a more general mechanism for customizing the build
	logic
Message-ID: <500912FA.6010105@oracle.com>

This continues from a preliminary discussion on the build-dev list way 
back in January:

http://mail.openjdk.java.net/pipermail/build-dev/2012-January/005383.html

but now includes changes for the build-infra build, which now supports 
the SE-Embedded builds

This has to be sent to three mailing lists:
- build-dev for legacy build
- build-infra for new build
- core-libs as a heads up of what is coming

The plan is to push this through the build-infra repositories to keep 
everything together.


The intent is to move all of the SE-Embedded related build files (and 
eventually other "closed" components) out of the OpenJDK repositories. 
The mechanism for doing this is to allow the user to set a 
CUSTOM_MAKE_DIR and then have specific makefiles use the -include 
mechanism to then include the custom file if it exists. In its most 
general form every makefile could include a custom counterpart - but 
naturally we do not want to go there. So at present the only hooks are 
around the places where the SE-Embedded specialization occurred.

The -include mechanism is used so that we don't need to a bunch of 
existence tests. If a particular file is not found then make will ignore 
that (aside: we should probably fix the makefiles so that make does not 
try to create missing makefiles!) There is no expectation that you have 
to provide a custom file for every hook that exists - you only provide 
what you need.

On the build-infra side we allow for the CUSTOM_MAKE_DIR and add support 
for the CUSTOM_CONFIG_DIR (which generalizes the "closed" config hook 
that was recently added).

There are thus two webrevs. One for the jdk repo:

http://cr.openjdk.java.net/~dholmes/7130909/webrev.jdk/

make/* is legacy build changes
makefiles/* is new build-infra changes


the other in the root repo:

http://cr.openjdk.java.net/~dholmes/7130909/webrev.root/

which contains the build-infra changes to the autoconf stuff:
- add support for --with-custom-make-dir as a configure flag.
- modified the "closed hook" mechanism to
  - rename closed hook to custom hook
  - allow setting CUSTOM_CONFIG_DIR at autogen time and configure time, 
to point to alternate location to find the custom-hook.m4 file

Note that because of the way this all works you must run autogen if you 
want to specify a custom config dir for the custom-hook.m4.

But note that you don't need to have a custom config just to use 
CUSTOM_MAKE_DIR!

Thanks,
David


From Ulf.Zibis at gmx.de  Mon Jul 16 16:30:04 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 16 Jul 2012 18:30:04 +0200
Subject: Codereview request for 6653797: Reimplement JDK charset repository
	charsets.jar
In-Reply-To: <5003403E.3070701@oracle.com>
References: <5003403E.3070701@oracle.com>
Message-ID: <5004418C.90602@gmx.de>

Hi Sherman,

as I just said for 7183053, I can't look in the details at the moment, as I do not have suitable 
environment installed at the moment.

Just one comment: I think it should be possible to share the mapping data partly across charsets, so 
the charsets.jar would be decreased again more?

-Ulf


Am 16.07.2012 00:12, schrieb Xueming Shen:
> Hi
>
> This changeset includes the migration of our JIS0201/0208/0212 based single/
> double-byte charsets to the new mapping based implementation. This is the
> left-over of the effort we put in JDK7 to re-implement most of our charsets in
> charsets.jar to (1)have better performance (2) small storage foot print and (3)
> ease the maintenance burden.
>
> http://cr.openjdk.java.net/~sherman/6653797/webrev/
>
> Notes of the implementation:
>
> (1) jis0201/0208/0212 and their variants are now generated from the mapping table
> during the build time. (See those new .map *.nr and *.c2b tables)
>
> (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these
> new jis0201/02080212 charsets.
>
> (3) Those in red (in webrev) are the old implementation, since no charset uses them
> anymore, I removed them from the repository)
>
> (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the
> one that follows the old implementation, which decode/encodes base on the
> jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be
> slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797
> and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java)
> So in this charset, I generated the direct mapping tables for sjis and pck and use
> the "general" DoubleByte base class for these two charsets. This results in much
> faster decoding/encoding and correct mapping for all code points. The downside
> of this approach is that it adds about 50k uncompressed side to the charsets.jar.
> But given this change actually reduces about 300K from the rt.jar, we still get
> a net 250K, so I decided to go with this approach for better performance.
>
> It appears to be lots of files (80+) in the webrev, but that number includes the
> removed old implementation and the tests I put in to guarantee the identical
> de/encoding result from the old and new implementations (those OLD... test
> cases), the change is actually not that big:-) So please help review. I can then
> put this multi-year efforts into rest.
>
> -Sherman
>
>
>
>
>
>




From weijun.wang at oracle.com  Sat Jul 21 12:01:50 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Sat, 21 Jul 2012 12:01:50 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120721120238.B496847184@hg.openjdk.java.net>

Changeset: 5dc3f32c0d26
Author:    weijun
Date:      2012-07-21 19:56 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5dc3f32c0d26

7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes
Reviewed-by: xuelei

! src/share/classes/com/sun/crypto/provider/OAEPParameters.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
! src/share/classes/sun/security/x509/AlgorithmId.java
+ test/sun/security/x509/AlgorithmId/NonStandardNames.java

Changeset: 7e49c6f7507e
Author:    weijun
Date:      2012-07-21 19:56 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e49c6f7507e

7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout
Reviewed-by: xuelei

! test/sun/security/krb5/auto/BadKdc.java
! test/sun/security/krb5/auto/BadKdc1.java
! test/sun/security/krb5/auto/BadKdc2.java
! test/sun/security/krb5/auto/BadKdc3.java
! test/sun/security/krb5/auto/BadKdc4.java



From Ulf.Zibis at CoSoCo.de  Sat Jul 21 17:22:29 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Sat, 21 Jul 2012 19:22:29 +0200
Subject: Author role for Ulf Zibis for JDK 7 Updates
In-Reply-To: <500543A2.5040105@oracle.com>
References: <500543A2.5040105@oracle.com>
Message-ID: <500AE555.801@CoSoCo.de>

Thanks Dalibor.

Now I'm in. The id is: ulfzibis

Cheers,

Ulf


Am 17.07.2012 12:51, schrieb Dalibor Topic:
> Dear Registrar,
>
> please add Ulf Zibis as an Author to the JDK 7 Updates Project. Ulf does not have
> an OpenJDK id yet.
>
> cheers,
> dalibor topic



From Alan.Bateman at oracle.com  Sun Jul 22 19:16:11 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Jul 2012 20:16:11 +0100
Subject: Code Review Request: 7184287: (prefs) BackingStoreException when
	calling flush on root node[macosx]
In-Reply-To: <059F9478-4212-438F-A7AD-A40FAA3702FB@oracle.com>
References: <059F9478-4212-438F-A7AD-A40FAA3702FB@oracle.com>
Message-ID: <500C517B.20401@oracle.com>

On 19/07/2012 19:31, Kurchi Subhra Hazra wrote:
> Hi,
>
> While flushing user preferences, a BackingStoreException is not expected, since
> the current user should be able to write such preferences to the
> persistent storage (unlike system preferences, where current user needs
> to have admin rights). This fix aims at allowing a user preference node
> to flush any changes to the persistent storage on Mac OS X.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287
> Webrev: http://cr.openjdk.java.net/~khazra/7184287/webrev.00/
>
> Thanks,
> Kurchi
I looked at the changes and the approach looks good to me. Hopefully 
this is the end of the issues with the preferences API on Mac. The only 
thing that doesn't seem right to me is MacOSXPreferences.java L234 where 
it looks like an additional brace has sneaked in.

-Alan.


From alan.bateman at oracle.com  Sun Jul 22 19:33:36 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 22 Jul 2012 19:33:36 +0000
Subject: hg: jdk8/tl/jdk: 6633549: (dc) Include-mode filtering of IPv6 sources
	does not block datagrams on Linux
Message-ID: <20120722193409.01D0F47196@hg.openjdk.java.net>

Changeset: 11d5ddc6a6d4
Author:    alanb
Date:      2012-07-22 20:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11d5ddc6a6d4

6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux
Reviewed-by: chegar

! src/solaris/native/sun/nio/ch/DatagramDispatcher.c
! src/solaris/native/sun/nio/ch/Net.c
! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java



From kurchi.subhra.hazra at oracle.com  Sun Jul 22 19:39:43 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Sun, 22 Jul 2012 12:39:43 -0700
Subject: Code Review Request: 7184287: (prefs) BackingStoreException when
	calling flush on root node[macosx]
In-Reply-To: <500C517B.20401@oracle.com>
References: <059F9478-4212-438F-A7AD-A40FAA3702FB@oracle.com>
	<500C517B.20401@oracle.com>
Message-ID: <500C56FF.7@oracle.com>

Thanks Alan. There is another bug on synchronization in the prefs 
implementation that I need to look into.

I will get rid of the extra brace, and push this then.

- Kurchi

On 7/22/12 12:16 PM, Alan Bateman wrote:
> On 19/07/2012 19:31, Kurchi Subhra Hazra wrote:
>> Hi,
>>
>> While flushing user preferences, a BackingStoreException is not 
>> expected, since
>> the current user should be able to write such preferences to the
>> persistent storage (unlike system preferences, where current user needs
>> to have admin rights). This fix aims at allowing a user preference node
>> to flush any changes to the persistent storage on Mac OS X.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287
>> Webrev: http://cr.openjdk.java.net/~khazra/7184287/webrev.00/
>>
>> Thanks,
>> Kurchi
> I looked at the changes and the approach looks good to me. Hopefully 
> this is the end of the issues with the preferences API on Mac. The 
> only thing that doesn't seem right to me is MacOSXPreferences.java 
> L234 where it looks like an additional brace has sneaked in.
>
> -Alan.



From weijun.wang at oracle.com  Tue Jul 24 01:21:12 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 24 Jul 2012 01:21:12 +0000
Subject: hg: jdk8/tl/jdk: 7179796: GSSExceptionImpl outputs duplicate mech oid
Message-ID: <20120724012131.8E1BA471C2@hg.openjdk.java.net>

Changeset: f7731fc8c98a
Author:    weijun
Date:      2012-07-24 09:20 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7731fc8c98a

7179796: GSSExceptionImpl outputs duplicate mech oid
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/GSSCredentialImpl.java



From yiming.wang at oracle.com  Tue Jul 24 03:16:09 2012
From: yiming.wang at oracle.com (Eric Wang)
Date: Tue, 24 Jul 2012 11:16:09 +0800
Subject: [PATCH] review request: 7148829
	sun/net/InetAddress/nameservice/simple/CacheTest.java failing
Message-ID: <500E1379.50706@oracle.com>

Hi Chris,

Please help to review the fix for bug 7148829 
<http://monaco.us.oracle.com/detail.jsf?cr=7148829> 
sun/net/InetAddress/nameservice/simple/CacheTest.java failing
http://dl.dropbox.com/u/90659131/fixes/7148829/webrev/index.html

The root cause is on certain Vitrual Machines the wall clock time 
(System.currentTimeMillis) is not advancing by the exected sleep() time."

As Thread.sleep() is subject to the precision and accuracy of system 
timers and schedulers, the fix is to hang the tests for specified time 
until CacheEntry timeout.

BTW, The fix has been verified on the host sc11136014 which bug occurred.

Thanks,
Eric





From xuelei.fan at oracle.com  Tue Jul 24 10:33:00 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 24 Jul 2012 10:33:00 +0000
Subject: hg: jdk8/tl/jdk: 7185576: Need to consider the connection timeout at
	test/com/sun/jndi/ldap/InvalidLdapFilters.java
Message-ID: <20120724103329.95ACC471D1@hg.openjdk.java.net>

Changeset: e0e7cc711bda
Author:    xuelei
Date:      2012-07-24 03:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0e7cc711bda

7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java
Reviewed-by: vinnie

! test/com/sun/jndi/ldap/InvalidLdapFilters.java



From xueming.shen at oracle.com  Tue Jul 24 19:16:28 2012
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 24 Jul 2012 19:16:28 +0000
Subject: hg: jdk8/tl/jdk: 6653797: Reimplement JDK charset repository
	charsets.jar
Message-ID: <20120724191654.CB822471DA@hg.openjdk.java.net>

Changeset: a18f2806bef2
Author:    sherman
Date:      2012-07-24 12:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a18f2806bef2

6653797: Reimplement JDK charset repository charsets.jar
Summary: Migrated all jis based charsets to new implementation
Reviewed-by: okutsu

! make/java/nio/FILES_java.gmk
! make/java/sun_nio/FILES_java.gmk
! make/sun/nio/cs/FILES_java.gmk
! make/tools/CharsetMapping/DoubleByte-X.java.template
+ make/tools/CharsetMapping/JIS_X_0201.c2b
! make/tools/CharsetMapping/JIS_X_0201.map
+ make/tools/CharsetMapping/JIS_X_0208.map
+ make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b
+ make/tools/CharsetMapping/JIS_X_0208_MS5022X.map
+ make/tools/CharsetMapping/JIS_X_0208_MS932.map
+ make/tools/CharsetMapping/JIS_X_0208_MS932.nr
+ make/tools/CharsetMapping/JIS_X_0208_Solaris.map
+ make/tools/CharsetMapping/JIS_X_0208_Solaris.nr
+ make/tools/CharsetMapping/JIS_X_0212.map
+ make/tools/CharsetMapping/JIS_X_0212_MS5022X.map
+ make/tools/CharsetMapping/JIS_X_0212_Solaris.map
+ make/tools/CharsetMapping/JIS_X_0212_Solaris.nr
+ make/tools/CharsetMapping/PCK.c2b
+ make/tools/CharsetMapping/PCK.map
+ make/tools/CharsetMapping/PCK.nr
+ make/tools/CharsetMapping/SJIS.c2b
+ make/tools/CharsetMapping/SJIS.map
! make/tools/CharsetMapping/dbcs
! make/tools/CharsetMapping/extsbcs
! make/tools/src/build/tools/charsetmapping/DBCS.java
! make/tools/src/build/tools/charsetmapping/SBCS.java
! src/share/classes/sun/nio/cs/SingleByte.java
- src/share/classes/sun/nio/cs/SingleByteDecoder.java
- src/share/classes/sun/nio/cs/SingleByteEncoder.java
! src/share/classes/sun/nio/cs/ext/DoubleByte.java
- src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
! src/share/classes/sun/nio/cs/ext/EUC_JP.java
! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java
! src/share/classes/sun/nio/cs/ext/IBM834.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java
! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0201.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java
- src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java
! src/share/classes/sun/nio/cs/ext/MS50220.java
! src/share/classes/sun/nio/cs/ext/MS50221.java
! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java
- src/share/classes/sun/nio/cs/ext/PCK.java
- src/share/classes/sun/nio/cs/ext/SJIS.java
! src/solaris/classes/sun/awt/motif/X11JIS0201.java
! src/solaris/classes/sun/awt/motif/X11JIS0208.java
! src/solaris/classes/sun/awt/motif/X11JIS0212.java
! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
! test/sun/nio/cs/OLD/DoubleByteDecoder.java
! test/sun/nio/cs/OLD/DoubleByteEncoder.java
+ test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java
+ test/sun/nio/cs/OLD/EUC_JP_OLD.java
+ test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java
+ test/sun/nio/cs/OLD/JIS_X_0201_OLD.java
+ test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java
+ test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java
+ test/sun/nio/cs/OLD/JIS_X_0208_OLD.java
+ test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java
+ test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java
+ test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java
+ test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java
+ test/sun/nio/cs/OLD/JIS_X_0212_OLD.java
+ test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java
+ test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java
! test/sun/nio/cs/OLD/MS932_OLD.java
+ test/sun/nio/cs/OLD/PCK_OLD.java
+ test/sun/nio/cs/OLD/SJIS_OLD.java
+ test/sun/nio/cs/OLD/SingleByteDecoder.java
+ test/sun/nio/cs/OLD/SingleByteEncoder.java
! test/sun/nio/cs/OLD/TestIBMDB.java
! test/sun/nio/cs/TestX11JIS0201.java



From kurchi.subhra.hazra at oracle.com  Tue Jul 24 20:39:49 2012
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Tue, 24 Jul 2012 20:39:49 +0000
Subject: hg: jdk8/tl/jdk: 7184287: (prefs) BackingStoreException when calling
	flush on root node[macosx]
Message-ID: <20120724204017.C5C5B471E2@hg.openjdk.java.net>

Changeset: 74ceda3a98a0
Author:    khazra
Date:      2012-07-24 13:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74ceda3a98a0

7184287: (prefs) BackingStoreException when calling flush on root node[macosx]
Summary: Change implementation to enable user without administrative privileges to call flush
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! test/ProblemList.txt



From ahughes at redhat.com  Wed Jul 25 14:58:45 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 25 Jul 2012 10:58:45 -0400 (EDT)
Subject: Native zlib libraries
In-Reply-To: <50080F1A.6090004@oracle.com>
Message-ID: <1733006288.3249685.1343228325322.JavaMail.root@redhat.com>



----- Original Message -----
> On 19/07/2012 14:20, Andrew Hughes wrote:
> > :
> >
> > Hmmm... this is interesting as we've been shipping OpenJDK with
> > system zlib the whole time.
> >
> > Are some of the issues resolved in newer versions?  My system copy
> > is 1.2.7.
> >
> > Not only is it generally against GNU/Linux distribution policy to
> > bundle libraries without good reason, but it also means
> > we then have to rebuild OpenJDK for any security issues in those
> > dependencies.
> >
> I think using the system zlib (or libz as it seems to shipped as on
> Solaris and MacOSX) would have been okay with jdk6, it's just that
> the
> zip64 support in jdk7 changed total_in/out to "long long".
> 
> The copy that we have in the jdk repository at this time is 1.2.5.
> I'm
> not aware of any updates that avoid this patch but I think the right
> thing is to change the java.util.zip code so that it works with an
> unmodified zlib. I think Sherman has ideas on this, just hasn't got
> to
> it yet. If you have cycles to look at it that would be great (and I
> understand that distributions would frown on attempts to bundle a
> private copy with OpenJDK).
> 

I've started looking at this and it seems 7 still has 1.2.3,
1.2.5 is only in 8. I also can't see any obvious changes which
change zlib.

Are you sure this change was introduced in 7 and not 8?  Do you happen
to know the bug ID for it?

> -Alan.
> 

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From Alan.Bateman at oracle.com  Wed Jul 25 15:04:08 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jul 2012 16:04:08 +0100
Subject: Native zlib libraries
In-Reply-To: <1733006288.3249685.1343228325322.JavaMail.root@redhat.com>
References: <1733006288.3249685.1343228325322.JavaMail.root@redhat.com>
Message-ID: <50100AE8.2050401@oracle.com>

On 25/07/2012 15:58, Andrew Hughes wrote:
> :
>
>
> I've started looking at this and it seems 7 still has 1.2.3,
> 1.2.5 is only in 8. I also can't see any obvious changes which
> change zlib.
>
> Are you sure this change was introduced in 7 and not 8?  Do you happen
> to know the bug ID for it?
>
Yes, jdk7 had 1.2.3 and according to the history of 
zlib-1.2.3/patches/ChangeLog_java then the bugID was 4963968 (b115cf946852).

jdk8 has 1.2.3 and zlib-1.2.5/patches/ChangeLog_java has 7110149 
(a47de985fec9).

-Alan


From xueming.shen at oracle.com  Wed Jul 25 19:45:42 2012
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 25 Jul 2012 19:45:42 +0000
Subject: hg: jdk8/tl/jdk: 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java
	failed in jdk8 TL nightly build
Message-ID: <20120725194553.03F5E471FD@hg.openjdk.java.net>

Changeset: 42eac77355d2
Author:    sherman
Date:      2012-07-25 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42eac77355d2

7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build
Summary: fixed the test case
Reviewed-by: alanb

! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java



From weijun.wang at oracle.com  Thu Jul 26 12:39:08 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Thu, 26 Jul 2012 12:39:08 +0000
Subject: hg: jdk8/tl/jdk: 7187051: ShortRSAKeynnn.sh tests should do cleanup
	before start test
Message-ID: <20120726123938.886A64721A@hg.openjdk.java.net>

Changeset: f267302093d4
Author:    weijun
Date:      2012-07-26 20:38 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f267302093d4

7187051: ShortRSAKeynnn.sh tests should do cleanup before start test
Reviewed-by: xuelei

! test/sun/security/mscapi/ShortRSAKey1024.sh



From jim.gish at oracle.com  Thu Jul 26 20:12:24 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 26 Jul 2012 16:12:24 -0400
Subject: RFR: 691423 - (str) Missing synchronization in
	java.lang.String#contentEquals(CharSequence)
Message-ID: <5011A4A8.1040000@oracle.com>

Summary:  currently String.contentEquals( StringBuffer sb ) synchronizes 
on sb, but String.contentEquals( CharSequence cs ) does not sync when cs 
is a StringBuffer
Proposed change:  remove contentEquals( StringBuffer ) and have 
contentEquals( CharSequence ) do the checking and synchronize if the cs 
is a StringBuffer.
Note: I expect this will require CCC approval because of the removal of 
contentEquals( StringBuffer ).

Thanks,
    Jim

Proposed patch:
diff --git a/src/share/classes/java/lang/String.java 
b/src/share/classes/java/lang/String.java
--- a/src/share/classes/java/lang/String.java
+++ b/src/share/classes/java/lang/String.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 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
@@ -984,30 +984,26 @@
          return false;
      }

-    /**
-     * Compares this string to the specified {@code StringBuffer}.  The 
result
-     * is {@code true} if and only if this {@code String} represents 
the same
-     * sequence of characters as the specified {@code StringBuffer}.
-     *
-     * @param  sb
-     *         The {@code StringBuffer} to compare this {@code String} 
against
-     *
-     * @return  {@code true} if this {@code String} represents the same
-     *          sequence of characters as the specified {@code 
StringBuffer},
-     *          {@code false} otherwise
-     *
-     * @since  1.4
-     */
-    public boolean contentEquals(StringBuffer sb) {
-        synchronized (sb) {
-            return contentEquals((CharSequence) sb);
+    private boolean contentEquals(AbstractStringBuilder sb) {
+        char v1[] = value;
+        char v2[] = sb.getValue();
+        int i = 0;
+        int n = value.length;
+        while (n-- != 0) {
+            if (v1[i] != v2[i]) {
+                return false;
+            }
+            i++;
          }
+        return true;
      }

      /**
-     * Compares this string to the specified {@code CharSequence}.  The 
result
-     * is {@code true} if and only if this {@code String} represents 
the same
-     * sequence of char values as the specified sequence.
+     * Compares this string to the specified {@code CharSequence}.  The
+     * result is {@code true} if and only if this {@code String} 
represents the
+     * same sequence of char values as the specified sequence. Note 
that if the
+     * {@code CharSequence} is a {@code StringBuffer} then the method
+     * synchronizes on it.
       *
       * @param  cs
       *         The sequence to compare this {@code String} against
@@ -1023,16 +1019,13 @@
              return false;
          // Argument is a StringBuffer, StringBuilder
          if (cs instanceof AbstractStringBuilder) {
-            char v1[] = value;
-            char v2[] = ((AbstractStringBuilder) cs).getValue();
-            int i = 0;
-            int n = value.length;
-            while (n-- != 0) {
-                if (v1[i] != v2[i])
-                    return false;
-                i++;
+            if (cs instanceof StringBuffer) {
+                synchronized(cs) {
+                   return contentEquals((AbstractStringBuilder)cs);
+                }
+            } else {
+                return contentEquals((AbstractStringBuilder)cs);
              }
-            return true;
          }
          // Argument is a String
          if (cs.equals(this))



-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mike.duigou at oracle.com  Thu Jul 26 20:28:24 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 26 Jul 2012 13:28:24 -0700
Subject: RFR: 691423 - (str) Missing synchronization in
	java.lang.String#contentEquals(CharSequence)
In-Reply-To: <5011A4A8.1040000@oracle.com>
References: <5011A4A8.1040000@oracle.com>
Message-ID: <B238C2D6-7E8C-431D-BDBD-30200FCE0CAE@oracle.com>

This would appear to be source compatible but not binary compatible. I don't believe we can remove the contentsEqual(StringBuffer) overload. Code compiled against the existing interface would fail to find the CharSequence interface at runtime and fail.

I believe it would be reasonable to add locking on StringBuffer into the contentsEqual(CharSequence) overload. This would make the behaviour consistent between the two invocations which is important because it will not always be possible for developers to tell which overload is being selected.

Mike

On Jul 26 2012, at 13:12 , Jim Gish wrote:

> Summary:  currently String.contentEquals( StringBuffer sb ) synchronizes on sb, but String.contentEquals( CharSequence cs ) does not sync when cs is a StringBuffer
> Proposed change:  remove contentEquals( StringBuffer ) and have contentEquals( CharSequence ) do the checking and synchronize if the cs is a StringBuffer.
> Note: I expect this will require CCC approval because of the removal of contentEquals( StringBuffer ).
> 
> Thanks,
>   Jim
> 
> Proposed patch:
> diff --git a/src/share/classes/java/lang/String.java b/src/share/classes/java/lang/String.java
> --- a/src/share/classes/java/lang/String.java
> +++ b/src/share/classes/java/lang/String.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1994, 2010, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1994, 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
> @@ -984,30 +984,26 @@
>         return false;
>     }
> 
> -    /**
> -     * Compares this string to the specified {@code StringBuffer}.  The result
> -     * is {@code true} if and only if this {@code String} represents the same
> -     * sequence of characters as the specified {@code StringBuffer}.
> -     *
> -     * @param  sb
> -     *         The {@code StringBuffer} to compare this {@code String} against
> -     *
> -     * @return  {@code true} if this {@code String} represents the same
> -     *          sequence of characters as the specified {@code StringBuffer},
> -     *          {@code false} otherwise
> -     *
> -     * @since  1.4
> -     */
> -    public boolean contentEquals(StringBuffer sb) {
> -        synchronized (sb) {
> -            return contentEquals((CharSequence) sb);
> +    private boolean contentEquals(AbstractStringBuilder sb) {
> +        char v1[] = value;
> +        char v2[] = sb.getValue();
> +        int i = 0;
> +        int n = value.length;
> +        while (n-- != 0) {
> +            if (v1[i] != v2[i]) {
> +                return false;
> +            }
> +            i++;
>         }
> +        return true;
>     }
> 
>     /**
> -     * Compares this string to the specified {@code CharSequence}.  The result
> -     * is {@code true} if and only if this {@code String} represents the same
> -     * sequence of char values as the specified sequence.
> +     * Compares this string to the specified {@code CharSequence}.  The
> +     * result is {@code true} if and only if this {@code String} represents the
> +     * same sequence of char values as the specified sequence. Note that if the
> +     * {@code CharSequence} is a {@code StringBuffer} then the method
> +     * synchronizes on it.
>      *
>      * @param  cs
>      *         The sequence to compare this {@code String} against
> @@ -1023,16 +1019,13 @@
>             return false;
>         // Argument is a StringBuffer, StringBuilder
>         if (cs instanceof AbstractStringBuilder) {
> -            char v1[] = value;
> -            char v2[] = ((AbstractStringBuilder) cs).getValue();
> -            int i = 0;
> -            int n = value.length;
> -            while (n-- != 0) {
> -                if (v1[i] != v2[i])
> -                    return false;
> -                i++;
> +            if (cs instanceof StringBuffer) {
> +                synchronized(cs) {
> +                   return contentEquals((AbstractStringBuilder)cs);
> +                }
> +            } else {
> +                return contentEquals((AbstractStringBuilder)cs);
>             }
> -            return true;
>         }
>         // Argument is a String
>         if (cs.equals(this))
> 
> 
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
> 



From jim.gish at oracle.com  Thu Jul 26 20:38:16 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 26 Jul 2012 16:38:16 -0400
Subject: RFR: 691423 - (str) Missing synchronization in
	java.lang.String#contentEquals(CharSequence)
In-Reply-To: <B238C2D6-7E8C-431D-BDBD-30200FCE0CAE@oracle.com>
References: <5011A4A8.1040000@oracle.com>
	<B238C2D6-7E8C-431D-BDBD-30200FCE0CAE@oracle.com>
Message-ID: <5011AAB8.6070809@oracle.com>

OK.  With that in mind, here's an update where I leave contentEquals( 
StringBuffer ) in place (adding a clarifying spec), and defer the 
synchronization as I had it to the contentEquals( CharSequence ) method:

diff --git a/src/share/classes/java/lang/String.java 
b/src/share/classes/java/lang/String.java
--- a/src/share/classes/java/lang/String.java
+++ b/src/share/classes/java/lang/String.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 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
@@ -983,11 +983,11 @@
          }
          return false;
      }
-
-    /**
+   /**
       * Compares this string to the specified {@code StringBuffer}.  
The result
       * is {@code true} if and only if this {@code String} represents 
the same
-     * sequence of characters as the specified {@code StringBuffer}.
+     * sequence of characters as the specified {@code StringBuffer}. 
This method
+     * synchronizes on the {@code StringBuffer}.
       *
       * @param  sb
       *         The {@code StringBuffer} to compare this {@code String} 
against
@@ -999,15 +999,29 @@
       * @since  1.4
       */
      public boolean contentEquals(StringBuffer sb) {
-        synchronized (sb) {
-            return contentEquals((CharSequence) sb);
+        return contentEquals((CharSequence) sb);
+    }
+
+    private boolean nonSyncContentEquals(AbstractStringBuilder sb) {
+        char v1[] = value;
+        char v2[] = sb.getValue();
+        int i = 0;
+        int n = value.length;
+        while (n-- != 0) {
+            if (v1[i] != v2[i]) {
+                return false;
+            }
+            i++;
          }
+        return true;
      }

      /**
-     * Compares this string to the specified {@code CharSequence}.  The 
result
-     * is {@code true} if and only if this {@code String} represents 
the same
-     * sequence of char values as the specified sequence.
+     * Compares this string to the specified {@code CharSequence}.  The
+     * result is {@code true} if and only if this {@code String} 
represents the
+     * same sequence of char values as the specified sequence. Note 
that if the
+     * {@code CharSequence} is a {@code StringBuffer} then the method
+     * synchronizes on it.
       *
       * @param  cs
       *         The sequence to compare this {@code String} against
@@ -1023,16 +1037,13 @@
              return false;
          // Argument is a StringBuffer, StringBuilder
          if (cs instanceof AbstractStringBuilder) {
-            char v1[] = value;
-            char v2[] = ((AbstractStringBuilder) cs).getValue();
-            int i = 0;
-            int n = value.length;
-            while (n-- != 0) {
-                if (v1[i] != v2[i])
-                    return false;
-                i++;
+            if (cs instanceof StringBuffer) {
+                synchronized(cs) {
+                   return nonSyncContentEquals((AbstractStringBuilder)cs);
+                }
+            } else {
+                return nonSyncContentEquals((AbstractStringBuilder)cs);
              }
-            return true;
          }
          // Argument is a String
          if (cs.equals(this))



On 07/26/2012 04:28 PM, Mike Duigou wrote:
> This would appear to be source compatible but not binary compatible. I don't believe we can remove the contentsEqual(StringBuffer) overload. Code compiled against the existing interface would fail to find the CharSequence interface at runtime and fail.
>
> I believe it would be reasonable to add locking on StringBuffer into the contentsEqual(CharSequence) overload. This would make the behaviour consistent between the two invocations which is important because it will not always be possible for developers to tell which overload is being selected.
>
> Mike
>



From sean.coffey at oracle.com  Thu Jul 26 20:58:35 2012
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Thu, 26 Jul 2012 20:58:35 +0000
Subject: hg: jdk8/tl/jdk: 7179879: SSLSocket connect times out instead of
	throwing socket closed exception
Message-ID: <20120726205857.A53094722F@hg.openjdk.java.net>

Changeset: 35fec642fd32
Author:    coffeys
Date:      2012-07-26 22:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35fec642fd32

7179879: SSLSocket connect times out instead of throwing socket closed exception
Reviewed-by: xuelei, chegar

! src/share/classes/sun/security/ssl/SSLSocketImpl.java



From stuart.marks at oracle.com  Fri Jul 27 07:26:31 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 27 Jul 2012 00:26:31 -0700
Subject: RFR: 7186111 fix test
	java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
Message-ID: <501242A7.4080203@oracle.com>

Hi Darryl,

Please review the webrev here:

     http://cr.openjdk.java.net/~smarks/reviews/7186111/webrev.0/

which should fix the problems in the UnregisterGroup test. The permissions 
adjustment you had sent doesn't fix the test; it still passes, but it was still 
dysfunctional. Given that the SQE folks have been complaining that this test 
has been hanging their system, I decided to dig into it.

Explanation follows.

As things stand prior to this change, the test run has this 
AccessControlException stack trace in it:

     java.lang.RuntimeException: Error getting registry port.
	at TestLibrary.getRegistryPort(TestLibrary.java:394)
	at UnregisterGroup.main(UnregisterGroup.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:474)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:722)
     Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "accessClassInPackage.sun.rmi.registry")
	at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:364)
	at java.security.AccessController.checkPermission(AccessController.java:555)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at TestLibrary.getRegistryPort(TestLibrary.java:388)
	... 7 more

You had sent me some permissions changes that we thought would fix this bug. 
Indeed, they clear up the access control problem. But the test still had some 
additional errors, and these weren't cleared up by adjusting the permissions:

     java.net.MalformedURLException: invalid authority: //:-1/Callback
	at java.rmi.Naming.intParseURL(Naming.java:326)
	at java.rmi.Naming.parseURL(Naming.java:237)
	at java.rmi.Naming.lookup(Naming.java:96)
	at UnregisterGroup.run(UnregisterGroup.java:119)
	at java.lang.Thread.run(Thread.java:722)

The problem here is that we're creating a registry on a random port, and (with 
the permissions adjustment) we're successfully getting the port number out of 
it. But the port in the URL is still -1?? Well, that's because the code 
attempting to contact the registry is an Activatable object which is running in 
a different JVM. So we can't get the random registry port over to it.

I pulled out the random port stuff (and the corresponding permissions) and had 
this test use a reserved port for the registry. (At some point we might want to 
consider trying to use a random port, but we have to pass this all the way from 
the test program through rmid into the activated objects, and I don't know how 
to do that.)

The next problem was that I got intermittent "connection refused" messages when 
the activated objects were trying to look up the Callback object. The problem 
there was that the test program activated the objects and *then* created its 
registry, causing a race condition where the activated objects might attempt to 
contact the registry before it was created. Creating the registry up front 
fixed that.

The next problem was that the activated objects would usually not end up 
calling the Callback object. This occurred because when the object deactivated 
itself, it would kill the JVM containing the activated object. Thus the call to 
the Callback might not complete. The fix here is to call the Callback before 
deactivating the object. Now that the callbacks are reliable, the main test 
program doesn't wait around for 30 seconds for callbacks that won't occur, and 
it now runs in about 3 seconds instead.

After all that, the code and the changes are actually pretty simple.

s'marks


From kumar.x.srinivasan at oracle.COM  Fri Jul 27 12:41:47 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 27 Jul 2012 05:41:47 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single entry
	classpath
Message-ID: <50128C8B.10603@oracle.COM>

Hi,

Please review the fix
http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/

to address:
7146424: Wildcard expansion for single entry classpath
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
and
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744


Notes:
a. cmdtoargs.c will be pushed as a separate changeset using a separate CR
and with contributor attribution to akhil.arora at oracle.com

b. src/solaris/bin/java_md.c is a redundant file and will be removed,
webrev for whatever reason is not reporting it.

Thanks

Kumar





From jim.gish at oracle.com  Fri Jul 27 14:54:03 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 27 Jul 2012 10:54:03 -0400
Subject: RFR: 7186111 fix test
	java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
In-Reply-To: <501242A7.4080203@oracle.com>
References: <501242A7.4080203@oracle.com>
Message-ID: <5012AB8B.2070108@oracle.com>

Hi Stuart,

The code looks fine.  Personally, I would like to see some of your 
explanation below end up as comments in the code, so that subsequent 
readers/modifiers of the code understand why it's done the way it is, in 
particular why we are now using a fixed port instead of a random port 
and what are the unanswered questions in reintroducing a random port if 
someone wants to try giving it a shot in the future.

Thanks,
    Jim

On 07/27/2012 03:26 AM, Stuart Marks wrote:
> Hi Darryl,
>
> Please review the webrev here:
>
>     http://cr.openjdk.java.net/~smarks/reviews/7186111/webrev.0/
>
> which should fix the problems in the UnregisterGroup test. The 
> permissions adjustment you had sent doesn't fix the test; it still 
> passes, but it was still dysfunctional. Given that the SQE folks have 
> been complaining that this test has been hanging their system, I 
> decided to dig into it.
>
> Explanation follows.
>
> As things stand prior to this change, the test run has this 
> AccessControlException stack trace in it:
>
>     java.lang.RuntimeException: Error getting registry port.
>     at TestLibrary.getRegistryPort(TestLibrary.java:394)
>     at UnregisterGroup.main(UnregisterGroup.java:239)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:474)
>     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     at java.lang.Thread.run(Thread.java:722)
>     Caused by: java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessClassInPackage.sun.rmi.registry")
>     at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:364)
>     at 
> java.security.AccessController.checkPermission(AccessController.java:555)
>     at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>     at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>     at TestLibrary.getRegistryPort(TestLibrary.java:388)
>     ... 7 more
>
> You had sent me some permissions changes that we thought would fix 
> this bug. Indeed, they clear up the access control problem. But the 
> test still had some additional errors, and these weren't cleared up by 
> adjusting the permissions:
>
>     java.net.MalformedURLException: invalid authority: //:-1/Callback
>     at java.rmi.Naming.intParseURL(Naming.java:326)
>     at java.rmi.Naming.parseURL(Naming.java:237)
>     at java.rmi.Naming.lookup(Naming.java:96)
>     at UnregisterGroup.run(UnregisterGroup.java:119)
>     at java.lang.Thread.run(Thread.java:722)
>
> The problem here is that we're creating a registry on a random port, 
> and (with the permissions adjustment) we're successfully getting the 
> port number out of it. But the port in the URL is still -1?? Well, 
> that's because the code attempting to contact the registry is an 
> Activatable object which is running in a different JVM. So we can't 
> get the random registry port over to it.
>
> I pulled out the random port stuff (and the corresponding permissions) 
> and had this test use a reserved port for the registry. (At some point 
> we might want to consider trying to use a random port, but we have to 
> pass this all the way from the test program through rmid into the 
> activated objects, and I don't know how to do that.)
>
> The next problem was that I got intermittent "connection refused" 
> messages when the activated objects were trying to look up the 
> Callback object. The problem there was that the test program activated 
> the objects and *then* created its registry, causing a race condition 
> where the activated objects might attempt to contact the registry 
> before it was created. Creating the registry up front fixed that.
>
> The next problem was that the activated objects would usually not end 
> up calling the Callback object. This occurred because when the object 
> deactivated itself, it would kill the JVM containing the activated 
> object. Thus the call to the Callback might not complete. The fix here 
> is to call the Callback before deactivating the object. Now that the 
> callbacks are reliable, the main test program doesn't wait around for 
> 30 seconds for callbacks that won't occur, and it now runs in about 3 
> seconds instead.
>
> After all that, the code and the changes are actually pretty simple.
>
> s'marks

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From ahughes at redhat.com  Fri Jul 27 17:37:39 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Fri, 27 Jul 2012 13:37:39 -0400 (EDT)
Subject: Native zlib libraries
In-Reply-To: <4FFD3701.3060100@oracle.com>
Message-ID: <343016845.4406676.1343410659578.JavaMail.root@redhat.com>

----- Original Message -----
> The zip64 support (total_in/out) part probably can be done at Java
> level
> (ignore
> the total_in/out in z_tream_s).  Need to remove this dependency. Will
> take a look later.
> 

Yes, it seems they still mention the size of total_in/out on the website on the zlib site, and that they shouldn't be relied on:

http://www.zlib.net/zlib_faq.html#faq32

"Note however that the strm.total_in and strm_total_out counters may be limited to 4 GB. These counters are provided as a convenience and are not used internally by inflate() or deflate(). The application can easily set up its own counters updated after each call of inflate() or deflate() to count beyond 4 GB"

"The word "may" appears several times above since there is a 4 GB limit only if the compiler's long type is 32 bits. If the compiler's long type is 64 bits, then the limit is 16 exabytes."

I notice a test went in with the 64-bit support, but I assume it can't test these counters as the Deflater for a ZipStream is protected.  At least, they aren't failing on our builds with system zlib.

Are you actively working on this now or shall I take a look?

> -Sherman
> 
> On 7/11/2012 12:47 AM, Alan Bateman wrote:
> > On 05/07/2012 17:11, Andrew Hughes wrote:
> >>
> >> ----- Original Message -----
> >>> Is there a way to get the native zlib libraries to get picked up
> >>> instead of the hardcoded version within the JVM?
> >>>
> >>> --
> >>> Azeem Jiva
> >>> @javawithjiva
> >> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
> >> it
> >> upstream.
> >>
> >> However, I don't see how this is related to HotSpot, as the zlib
> >> usage
> >> is in the jdk tree.
> > I think we need to (re)start the discussion on core-libs-dev with a
> > view to eliminating the patches that the JDK has to zlib, see:
> >
> > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
> >
> >
> > One of these changes relates to the zip64 support and I believe
> > there
> > are corner cases when inflating or deflating >2GB that won't work
> > if
> > using the system zlib. Sherman will likely recall the details.
> > Given
> > that the new build already supports using the system zlib (at least
> > on
> > Linux) then it would be good to sort this out so that it just
> > works.
> >
> > -Alan
> >
> >
> >
> >
> >
> >
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From xueming.shen at oracle.com  Fri Jul 27 18:16:40 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Jul 2012 11:16:40 -0700
Subject: Native zlib libraries
In-Reply-To: <343016845.4406676.1343410659578.JavaMail.root@redhat.com>
References: <343016845.4406676.1343410659578.JavaMail.root@redhat.com>
Message-ID: <5012DB08.6090109@oracle.com>

On 07/27/2012 10:37 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> The zip64 support (total_in/out) part probably can be done at Java
>> level
>> (ignore
>> the total_in/out in z_tream_s).  Need to remove this dependency. Will
>> take a look later.
>>
> Yes, it seems they still mention the size of total_in/out on the website on the zlib site, and that they shouldn't be relied on:
>
> http://www.zlib.net/zlib_faq.html#faq32
>
> "Note however that the strm.total_in and strm_total_out counters may be limited to 4 GB. These counters are provided as a convenience and are not used internally by inflate() or deflate(). The application can easily set up its own counters updated after each call of inflate() or deflate() to count beyond 4 GB"
>
> "The word "may" appears several times above since there is a 4 GB limit only if the compiler's long type is 32 bits. If the compiler's long type is 64 bits, then the limit is 16 exabytes."
>
> I notice a test went in with the 64-bit support, but I assume it can't test these counters as the Deflater for a ZipStream is protected.  At least, they aren't failing on our builds with system zlib.

That test is not configured to be run for "auto testing", it just takes 
too long to zip/unzip
a 4G+ file. I use it manually to test the ZIP64 support.

I will give it a try to remove this dependency next week. It would be 
helpful if you can
help "migrate" the icetea patch. How does the icetea patch work now? 
Always use the
system zlib, if it presents? any configurable option to switch on and off?

-Sherman

> Are you actively working on this now or shall I take a look?
>
>> -Sherman
>>
>> On 7/11/2012 12:47 AM, Alan Bateman wrote:
>>> On 05/07/2012 17:11, Andrew Hughes wrote:
>>>> ----- Original Message -----
>>>>> Is there a way to get the native zlib libraries to get picked up
>>>>> instead of the hardcoded version within the JVM?
>>>>>
>>>>> --
>>>>> Azeem Jiva
>>>>> @javawithjiva
>>>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
>>>> it
>>>> upstream.
>>>>
>>>> However, I don't see how this is related to HotSpot, as the zlib
>>>> usage
>>>> is in the jdk tree.
>>> I think we need to (re)start the discussion on core-libs-dev with a
>>> view to eliminating the patches that the JDK has to zlib, see:
>>>
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
>>>
>>>
>>> One of these changes relates to the zip64 support and I believe
>>> there
>>> are corner cases when inflating or deflating>2GB that won't work
>>> if
>>> using the system zlib. Sherman will likely recall the details.
>>> Given
>>> that the new build already supports using the system zlib (at least
>>> on
>>> Linux) then it would be good to sort this out so that it just
>>> works.
>>>
>>> -Alan
>>>
>>>
>>>
>>>
>>>
>>>



From darryl.mocek at oracle.com  Fri Jul 27 19:59:51 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Fri, 27 Jul 2012 12:59:51 -0700
Subject: RFR: 7186111 fix test
	java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
In-Reply-To: <501242A7.4080203@oracle.com>
References: <501242A7.4080203@oracle.com>
Message-ID: <5012F337.7020708@oracle.com>

Hi Stuart,

    I've changed this fix back to using a random port for the RMI 
Registry.  I set the port as a property (and supplied the appropriate 
permissions) after the random port is created and added it to the 
ActivationGroupDesc, which will get passed as a property when the object 
is activated.  I then get the property in UnregisterGroup's run method.  
This test (really) passes with these changes.  Webrev can be found here: 
http://cr.openjdk.java.net/~dmocek/7186111/webrev.01

Darryl


On 07/27/2012 12:26 AM, Stuart Marks wrote:
> Hi Darryl,
>
> Please review the webrev here:
>
>     http://cr.openjdk.java.net/~smarks/reviews/7186111/webrev.0/
>
> which should fix the problems in the UnregisterGroup test. The 
> permissions adjustment you had sent doesn't fix the test; it still 
> passes, but it was still dysfunctional. Given that the SQE folks have 
> been complaining that this test has been hanging their system, I 
> decided to dig into it.
>
> Explanation follows.
>
> As things stand prior to this change, the test run has this 
> AccessControlException stack trace in it:
>
>     java.lang.RuntimeException: Error getting registry port.
>     at TestLibrary.getRegistryPort(TestLibrary.java:394)
>     at UnregisterGroup.main(UnregisterGroup.java:239)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:474)
>     at 
> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>     at java.lang.Thread.run(Thread.java:722)
>     Caused by: java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessClassInPackage.sun.rmi.registry")
>     at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:364)
>     at 
> java.security.AccessController.checkPermission(AccessController.java:555)
>     at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>     at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>     at TestLibrary.getRegistryPort(TestLibrary.java:388)
>     ... 7 more
>
> You had sent me some permissions changes that we thought would fix 
> this bug. Indeed, they clear up the access control problem. But the 
> test still had some additional errors, and these weren't cleared up by 
> adjusting the permissions:
>
>     java.net.MalformedURLException: invalid authority: //:-1/Callback
>     at java.rmi.Naming.intParseURL(Naming.java:326)
>     at java.rmi.Naming.parseURL(Naming.java:237)
>     at java.rmi.Naming.lookup(Naming.java:96)
>     at UnregisterGroup.run(UnregisterGroup.java:119)
>     at java.lang.Thread.run(Thread.java:722)
>
> The problem here is that we're creating a registry on a random port, 
> and (with the permissions adjustment) we're successfully getting the 
> port number out of it. But the port in the URL is still -1?? Well, 
> that's because the code attempting to contact the registry is an 
> Activatable object which is running in a different JVM. So we can't 
> get the random registry port over to it.
>
> I pulled out the random port stuff (and the corresponding permissions) 
> and had this test use a reserved port for the registry. (At some point 
> we might want to consider trying to use a random port, but we have to 
> pass this all the way from the test program through rmid into the 
> activated objects, and I don't know how to do that.)
>
> The next problem was that I got intermittent "connection refused" 
> messages when the activated objects were trying to look up the 
> Callback object. The problem there was that the test program activated 
> the objects and *then* created its registry, causing a race condition 
> where the activated objects might attempt to contact the registry 
> before it was created. Creating the registry up front fixed that.
>
> The next problem was that the activated objects would usually not end 
> up calling the Callback object. This occurred because when the object 
> deactivated itself, it would kill the JVM containing the activated 
> object. Thus the call to the Callback might not complete. The fix here 
> is to call the Callback before deactivating the object. Now that the 
> callbacks are reliable, the main test program doesn't wait around for 
> 30 seconds for callbacks that won't occur, and it now runs in about 3 
> seconds instead.
>
> After all that, the code and the changes are actually pretty simple.
>
> s'marks



From stuart.marks at oracle.com  Fri Jul 27 23:53:08 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Fri, 27 Jul 2012 23:53:08 +0000
Subject: hg: jdk8/tl/jdk: 7186111: fix bugs in
	java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
Message-ID: <20120727235332.1EC9D4726A@hg.openjdk.java.net>

Changeset: 018e555a7a07
Author:    dmocek
Date:      2012-07-27 16:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/018e555a7a07

7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
Reviewed-by: smarks, jgish

! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java
! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy
! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy
! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy



From stuart.marks at oracle.com  Fri Jul 27 23:58:09 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 27 Jul 2012 16:58:09 -0700
Subject: RFR: 7186111 fix test
	java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
In-Reply-To: <5012F337.7020708@oracle.com>
References: <501242A7.4080203@oracle.com> <5012F337.7020708@oracle.com>
Message-ID: <50132B11.8080803@oracle.com>

Great! Glad you found a way to pass a random port through to the activated objects.

Poking around further, I think it's possible to use rmid's registry for 
everything (instead of having the test start up its own registry) and to pass 
the port information through to the activated objects running in rmid 
subprocesses via the -C option. However, that's more work, and we'll keep that 
in mind for the future.

I've removed the extra call to ActivationLibrary.deactivate() from the top of 
the run() method, since this reintroduced the race condition that might cause 
the callback object not to be called.

I also added a few comments to explain the ordering requirements, and the 
possibility of using RMID's registry.

Pushed:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/018e555a7a07

s'marks

On 7/27/12 12:59 PM, Darryl Mocek wrote:
> Hi Stuart,
>
> I've changed this fix back to using a random port for the RMI Registry. I set
> the port as a property (and supplied the appropriate permissions) after the
> random port is created and added it to the ActivationGroupDesc, which will get
> passed as a property when the object is activated. I then get the property in
> UnregisterGroup's run method. This test (really) passes with these changes.
> Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7186111/webrev.01
>
> Darryl
>
>
> On 07/27/2012 12:26 AM, Stuart Marks wrote:
>> Hi Darryl,
>>
>> Please review the webrev here:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/7186111/webrev.0/
>>
>> which should fix the problems in the UnregisterGroup test. The permissions
>> adjustment you had sent doesn't fix the test; it still passes, but it was
>> still dysfunctional. Given that the SQE folks have been complaining that this
>> test has been hanging their system, I decided to dig into it.
>>
>> Explanation follows.
>>
>> As things stand prior to this change, the test run has this
>> AccessControlException stack trace in it:
>>
>> java.lang.RuntimeException: Error getting registry port.
>> at TestLibrary.getRegistryPort(TestLibrary.java:394)
>> at UnregisterGroup.main(UnregisterGroup.java:239)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:474)
>> at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>> at java.lang.Thread.run(Thread.java:722)
>> Caused by: java.security.AccessControlException: access denied
>> ("java.lang.RuntimePermission" "accessClassInPackage.sun.rmi.registry")
>> at
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:364)
>>
>> at java.security.AccessController.checkPermission(AccessController.java:555)
>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>> at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>> at TestLibrary.getRegistryPort(TestLibrary.java:388)
>> ... 7 more
>>
>> You had sent me some permissions changes that we thought would fix this bug.
>> Indeed, they clear up the access control problem. But the test still had some
>> additional errors, and these weren't cleared up by adjusting the permissions:
>>
>> java.net.MalformedURLException: invalid authority: //:-1/Callback
>> at java.rmi.Naming.intParseURL(Naming.java:326)
>> at java.rmi.Naming.parseURL(Naming.java:237)
>> at java.rmi.Naming.lookup(Naming.java:96)
>> at UnregisterGroup.run(UnregisterGroup.java:119)
>> at java.lang.Thread.run(Thread.java:722)
>>
>> The problem here is that we're creating a registry on a random port, and
>> (with the permissions adjustment) we're successfully getting the port number
>> out of it. But the port in the URL is still -1?? Well, that's because the
>> code attempting to contact the registry is an Activatable object which is
>> running in a different JVM. So we can't get the random registry port over to it.
>>
>> I pulled out the random port stuff (and the corresponding permissions) and
>> had this test use a reserved port for the registry. (At some point we might
>> want to consider trying to use a random port, but we have to pass this all
>> the way from the test program through rmid into the activated objects, and I
>> don't know how to do that.)
>>
>> The next problem was that I got intermittent "connection refused" messages
>> when the activated objects were trying to look up the Callback object. The
>> problem there was that the test program activated the objects and *then*
>> created its registry, causing a race condition where the activated objects
>> might attempt to contact the registry before it was created. Creating the
>> registry up front fixed that.
>>
>> The next problem was that the activated objects would usually not end up
>> calling the Callback object. This occurred because when the object
>> deactivated itself, it would kill the JVM containing the activated object.
>> Thus the call to the Callback might not complete. The fix here is to call the
>> Callback before deactivating the object. Now that the callbacks are reliable,
>> the main test program doesn't wait around for 30 seconds for callbacks that
>> won't occur, and it now runs in about 3 seconds instead.
>>
>> After all that, the code and the changes are actually pretty simple.
>>
>> s'marks
>


From lana.steuck at oracle.com  Sat Jul 28 06:39:01 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:01 +0000
Subject: hg: jdk8/tl: 6 new changesets
Message-ID: <20120728063902.3449547274@hg.openjdk.java.net>

Changeset: ba77d95ed219
Author:    ohair
Date:      2012-07-16 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ba77d95ed219

7184406: Adjust get_source/hgforest script to allow for trailing // characters
Reviewed-by: tbell

! make/scripts/hgforest.sh

Changeset: 3f6c72d1c2a6
Author:    katleman
Date:      2012-07-18 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/3f6c72d1c2a6

Merge


Changeset: 969c75896558
Author:    cl
Date:      2012-07-23 12:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/969c75896558

Added tag jdk8-b48 for changeset 3f6c72d1c2a6

! .hgtags

Changeset: 36998bc84cff
Author:    lana
Date:      2012-07-18 16:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/36998bc84cff

Merge


Changeset: c97b99424815
Author:    lana
Date:      2012-07-24 11:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c97b99424815

Merge


Changeset: 2fd67618b9a3
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/2fd67618b9a3

Added tag jdk8-b49 for changeset c97b99424815

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:01 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:01 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20120728063905.0514347275@hg.openjdk.java.net>

Changeset: fe44e58a6bdb
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe44e58a6bdb

Added tag jdk8-b48 for changeset 7e2b179a5b4d

! .hgtags

Changeset: d20d9eb9f093
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/d20d9eb9f093

Added tag jdk8-b49 for changeset fe44e58a6bdb

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:10 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:10 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20120728063918.95EC947276@hg.openjdk.java.net>

Changeset: b48865af8ac5
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b48865af8ac5

Added tag jdk8-b48 for changeset efb564de8a8e

! .hgtags

Changeset: bdab72e87b83
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bdab72e87b83

Added tag jdk8-b49 for changeset b48865af8ac5

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:04 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:04 +0000
Subject: hg: jdk8/tl/jaxp: 3 new changesets
Message-ID: <20120728063920.533F547277@hg.openjdk.java.net>

Changeset: a7e6e1048e4c
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7e6e1048e4c

Added tag jdk8-b48 for changeset 1c88da9a1365

! .hgtags

Changeset: f81e981eca7b
Author:    lana
Date:      2012-07-24 11:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f81e981eca7b

Merge


Changeset: 2791ec55f66b
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2791ec55f66b

Added tag jdk8-b49 for changeset f81e981eca7b

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:13 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:13 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20120728063922.5FA4347278@hg.openjdk.java.net>

Changeset: 9ee07e5dc0e2
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9ee07e5dc0e2

Added tag jdk8-b48 for changeset afb0a5231557

! .hgtags

Changeset: c72c164ced67
Author:    lana
Date:      2012-07-24 11:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c72c164ced67

Merge


Changeset: b2d8a270f5f2
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b2d8a270f5f2

Added tag jdk8-b49 for changeset c72c164ced67

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:23 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:23 +0000
Subject: hg: jdk8/tl/hotspot: 18 new changesets
Message-ID: <20120728064002.5E56347279@hg.openjdk.java.net>

Changeset: bcffa4c5eef6
Author:    amurillo
Date:      2012-06-29 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcffa4c5eef6

7180882: new hotspot build - hs24-b16
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3759236eea14
Author:    kamg
Date:      2012-07-02 10:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3759236eea14

7167142: Consider a warning when finding a .hotspotrc or .hotspot_compiler file that isn't used
Summary: Send warnings to output stream
Reviewed-by: dholmes, fparain

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: d2a62e0f25eb
Author:    zgu
Date:      2012-06-28 17:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d2a62e0f25eb

6995781: Native Memory Tracking (Phase 1)
7151532: DCmd for hotspot native memory tracking
Summary: Implementation of native memory tracking phase 1, which tracks VM native memory usage, and related DCmd
Reviewed-by: acorn, coleenp, fparain

! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! make/bsd/makefiles/jvmg.make
! make/linux/makefiles/jvmg.make
! make/solaris/makefiles/jvmg.make
! make/windows/makefiles/debug.make
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.hpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/dtrace/hs_private.d
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/c1/c1_CFGPrinter.cpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/javaAssertions.cpp
! src/share/vm/classfile/javaAssertions.hpp
! src/share/vm/classfile/loaderConstraints.cpp
! src/share/vm/classfile/loaderConstraints.hpp
! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/classfile/resolutionErrors.cpp
! src/share/vm/classfile/resolutionErrors.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/stubs.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/g1/survRateGroup.cpp
! src/share/vm/gc_implementation/g1/survRateGroup.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp
! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp
! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/collectorCounters.cpp
! src/share/vm/gc_implementation/shared/collectorCounters.hpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp
! src/share/vm/gc_implementation/shared/gcStats.hpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/immutableSpace.hpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp
! src/share/vm/gc_implementation/shared/spaceCounters.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceDecorator.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/libadt/set.cpp
! src/share/vm/libadt/vectset.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/barrierSet.hpp
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/collectorPolicy.hpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genOopClosures.hpp
! src/share/vm/memory/genRemSet.hpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/generationSpec.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/memRegion.hpp
! src/share/vm/memory/permGen.hpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/memory/restore.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiEnvThreadState.cpp
! src/share/vm/prims/jvmtiEnvThreadState.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiExtensions.cpp
! src/share/vm/prims/jvmtiGetLoadedClasses.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiRawMonitor.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/prims/jvmtiUtil.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/dtraceJSDT.hpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/jniHandles.hpp
! src/share/vm/runtime/monitorChunk.cpp
! src/share/vm/runtime/monitorChunk.hpp
! src/share/vm/runtime/mutex.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/osThread.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/perfData.hpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/reflectionUtils.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/safepoint.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/task.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/unhandledOops.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframeArray.hpp
! src/share/vm/runtime/vframe_hp.cpp
! src/share/vm/runtime/vframe_hp.hpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmThread.hpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/diagnosticArgument.cpp
! src/share/vm/services/diagnosticArgument.hpp
! src/share/vm/services/diagnosticFramework.hpp
! src/share/vm/services/gcNotifier.cpp
! src/share/vm/services/gcNotifier.hpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/lowMemoryDetector.hpp
! src/share/vm/services/management.cpp
+ src/share/vm/services/memBaseline.cpp
+ src/share/vm/services/memBaseline.hpp
+ src/share/vm/services/memPtr.cpp
+ src/share/vm/services/memPtr.hpp
+ src/share/vm/services/memPtrArray.hpp
+ src/share/vm/services/memRecorder.cpp
+ src/share/vm/services/memRecorder.hpp
+ src/share/vm/services/memReporter.cpp
+ src/share/vm/services/memReporter.hpp
+ src/share/vm/services/memSnapshot.cpp
+ src/share/vm/services/memSnapshot.hpp
+ src/share/vm/services/memTrackWorker.cpp
+ src/share/vm/services/memTrackWorker.hpp
+ src/share/vm/services/memTracker.cpp
+ src/share/vm/services/memTracker.hpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryService.cpp
+ src/share/vm/services/nmtDCmd.cpp
+ src/share/vm/services/nmtDCmd.hpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/threadService.hpp
! src/share/vm/utilities/array.cpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/decoder.hpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfFile.hpp
! src/share/vm/utilities/elfStringTable.cpp
! src/share/vm/utilities/elfStringTable.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/events.hpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/growableArray.cpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/hashtable.inline.hpp
! src/share/vm/utilities/histogram.cpp
! src/share/vm/utilities/histogram.hpp
! src/share/vm/utilities/intHisto.cpp
! src/share/vm/utilities/intHisto.hpp
! src/share/vm/utilities/numberSeq.cpp
! src/share/vm/utilities/numberSeq.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/stack.hpp
! src/share/vm/utilities/stack.inline.hpp
! src/share/vm/utilities/taskqueue.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/xmlstream.cpp

Changeset: 24b9c7f4cae6
Author:    coleenp
Date:      2012-07-02 13:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24b9c7f4cae6

Merge

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/memory/universe.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 3f1ab0c19c30
Author:    dholmes
Date:      2012-07-03 01:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f1ab0c19c30

7179383: MaxDirectMemorySize argument parsing is broken for values >2G
Summary: change hotspot flag to be unsigned
Reviewed-by: dholmes, sla, fparain, brutisso
Contributed-by: Chris Dennis <cdennis at terracottatech.com>

! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 65906dc96aa1
Author:    mikael
Date:      2012-07-03 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65906dc96aa1

7129724: MAC: Core file location is wrong in crash report
Summary: Updated core path location to reflect macosx default
Reviewed-by: dholmes, kamg

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/runtime/os.hpp

Changeset: ace99a6ffc83
Author:    coleenp
Date:      2012-07-04 15:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ace99a6ffc83

7181200: JVM new hashing code breaks SA in product mode
Summary: Made new_hash() overloaded rather than a virtual function so SA code doesn't need to be changed.
Reviewed-by: kvn, acorn, dholmes, fparain

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp

Changeset: 5a1f452f8f90
Author:    sla
Date:      2012-06-28 11:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a1f452f8f90

7178703: Fix handling of quoted arguments and better error messages in dcmd
Reviewed-by: coleenp, mgronlun, rbackman

! src/share/vm/prims/whitebox.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/diagnosticFramework.cpp
! src/share/vm/services/diagnosticFramework.hpp
! test/serviceability/ParserTest.java

Changeset: 04ade88d9712
Author:    fparain
Date:      2012-07-09 01:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04ade88d9712

6294277: java -Xdebug crashes on SourceDebugExtension attribute larger than 64K
Reviewed-by: sspitsyn, dholmes, coleenp, kamg

! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp
+ test/runtime/6294277/SourceDebugExtension.java
+ test/runtime/6294277/Test6294277.sh

Changeset: 90d5a592ea8f
Author:    coleenp
Date:      2012-07-12 14:26 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90d5a592ea8f

Merge

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: d50605d9417e
Author:    roland
Date:      2012-07-02 09:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d50605d9417e

7177917: Failed test java/lang/Math/PowTests.java
Summary: When c2 intrinsifies pow/exp, it should never inline the java implementations.
Reviewed-by: kvn

! src/share/vm/opto/library_call.cpp
+ test/compiler/7177917/Test7177917.java

Changeset: 70862d781d01
Author:    kvn
Date:      2012-07-02 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70862d781d01

7180769: assert(tboth->klass_is_exact()) failed: klass should be exact
Summary: Use class exactness as part of the condition for class compare optimization instead of assert.
Reviewed-by: twisti, roland

! src/share/vm/opto/parse2.cpp

Changeset: ae9241bbce4a
Author:    kvn
Date:      2012-07-11 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae9241bbce4a

7181658: CTW: assert(t->meet(t0) == t) failed: Not monotonic
Summary: Use uncast node equivalence checks in CmpUNode::sub.
Reviewed-by: kvn, twisti
Contributed-by: vladimir.x.ivanov at oracle.com

! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp

Changeset: cc787232c4c5
Author:    kvn
Date:      2012-07-12 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc787232c4c5

Merge


Changeset: 66b0450071c1
Author:    amurillo
Date:      2012-07-13 14:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/66b0450071c1

Merge


Changeset: 1e26f61bbb52
Author:    amurillo
Date:      2012-07-13 14:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e26f61bbb52

Added tag hs24-b16 for changeset 66b0450071c1

! .hgtags

Changeset: e3619706a725
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3619706a725

Added tag jdk8-b48 for changeset 1e26f61bbb52

! .hgtags

Changeset: ea926f2921d6
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea926f2921d6

Added tag jdk8-b49 for changeset e3619706a725

! .hgtags



From lana.steuck at oracle.com  Sat Jul 28 06:39:51 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 28 Jul 2012 06:39:51 +0000
Subject: hg: jdk8/tl/jdk: 18 new changesets
Message-ID: <20120728064259.5316E4727A@hg.openjdk.java.net>

Changeset: 09a79167142c
Author:    cl
Date:      2012-07-23 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a79167142c

Added tag jdk8-b48 for changeset 3e4ab821f461

! .hgtags

Changeset: a18a547546a4
Author:    prr
Date:      2012-07-12 16:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a18a547546a4

7183458: Metrics of space character in algorithmically emboldened font have changed in JDK 7.
Reviewed-by: igor, jgodinez

+ test/java/awt/FontMetrics/StyledSpaceAdvance.java

Changeset: 9f21c95bfbc1
Author:    lana
Date:      2012-07-16 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f21c95bfbc1

Merge

- makefiles/LegacyMakefiles.gmk
- makefiles/OldImages.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: ab0b2720a756
Author:    prr
Date:      2012-07-17 16:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab0b2720a756

7183251: Netbeans editor renders text wrong on JDK 7u6 build 17
Reviewed-by: igor, jgodinez

! src/share/classes/sun/font/SunLayoutEngine.java

Changeset: f1a90ee31b38
Author:    serb
Date:      2012-07-04 14:38 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1a90ee31b38

7124244: [macosx] Shaped windows support
Reviewed-by: anthony, art

! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWRepaintArea.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/AWTWindow.m
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/sun/awt/SunToolkit.java

Changeset: 80c592c9458e
Author:    serb
Date:      2012-07-04 15:36 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80c592c9458e

7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar
Reviewed-by: anthony, art

! src/macosx/classes/com/apple/laf/AquaPanelUI.java
! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java
! src/macosx/classes/com/apple/laf/AquaToolBarUI.java
! src/macosx/classes/com/apple/laf/AquaUtils.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/javax/swing/JViewport.java

Changeset: 911195d40b89
Author:    anthony
Date:      2012-07-06 14:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/911195d40b89

7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7
Summary: Avoid unnecessary changes to the extended state
Reviewed-by: art, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
+ test/java/awt/Frame/HideMaximized/HideMaximized.java

Changeset: 4d750ca79fb7
Author:    ptisnovs
Date:      2012-07-12 16:54 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d750ca79fb7

7022041: TitleBorder Null Pointer Exception
Summary: Added check if getTitleFont() and getTitleColor() don't return null
Reviewed-by: alexsch

! src/share/classes/javax/swing/border/TitledBorder.java
+ test/javax/swing/border/Test7022041.java

Changeset: 4624486823a7
Author:    serb
Date:      2012-07-16 14:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4624486823a7

7181438: [OGL] Incorrect alpha used, during blit from SW to the texture.
Reviewed-by: prr, campbell

! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
+ test/sun/java2d/OpenGL/bug7181438.java

Changeset: c277657e5e10
Author:    serb
Date:      2012-07-16 14:04 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c277657e5e10

7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List
Reviewed-by: rupashka

! src/share/classes/javax/swing/SwingUtilities.java
+ test/javax/swing/SwingUtilities/7170657/bug7170657.java

Changeset: 6d9ea8c91808
Author:    lana
Date:      2012-07-16 14:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d9ea8c91808

Merge

- makefiles/LegacyMakefiles.gmk
- makefiles/OldImages.gmk
- makefiles/com/sun/crypto/provider/Makefile
- makefiles/common/Classes.gmk
- makefiles/common/Cscope.gmk
- makefiles/common/Defs-embedded.gmk
- makefiles/common/Defs-linux.gmk
- makefiles/common/Defs-macosx.gmk
- makefiles/common/Defs-solaris.gmk
- makefiles/common/Defs-windows.gmk
- makefiles/common/Defs.gmk
- makefiles/common/Demo.gmk
- makefiles/common/Library.gmk
- makefiles/common/Mapfile-vers.gmk
- makefiles/common/Modules.gmk
- makefiles/common/Program.gmk
- makefiles/common/Release-embedded.gmk
- makefiles/common/Release-macosx.gmk
- makefiles/common/Release.gmk
- makefiles/common/Rules.gmk
- makefiles/common/Subdirs.gmk
- makefiles/common/internal/Defs-corba.gmk
- makefiles/common/internal/Defs-jaxp.gmk
- makefiles/common/internal/Defs-jaxws.gmk
- makefiles/common/internal/Defs-langtools.gmk
- makefiles/common/internal/ImportComponents.gmk
- makefiles/common/internal/NativeCompileRules.gmk
- makefiles/common/internal/Resources.gmk
- makefiles/common/shared/Compiler-gcc.gmk
- makefiles/common/shared/Compiler-llvm.gmk
- makefiles/common/shared/Compiler-msvc.gmk
- makefiles/common/shared/Compiler-sun.gmk
- makefiles/common/shared/Defs-control.gmk
- makefiles/common/shared/Defs-java.gmk
- makefiles/common/shared/Defs-javadoc.gmk
- makefiles/common/shared/Defs-linux.gmk
- makefiles/common/shared/Defs-macosx.gmk
- makefiles/common/shared/Defs-solaris.gmk
- makefiles/common/shared/Defs-versions.gmk
- makefiles/common/shared/Defs-windows.gmk
- makefiles/common/shared/Defs.gmk
- makefiles/common/shared/Platform.gmk
- makefiles/common/shared/PrivateDefs.gmk-example
- makefiles/common/shared/Sanity-Settings.gmk
- makefiles/java/Makefile
- makefiles/java/invoke/Makefile
- makefiles/java/redist/Makefile
- makefiles/java/redist/sajdi/Makefile
- makefiles/javax/crypto/Defs-jce.gmk
- makefiles/javax/crypto/Makefile
- makefiles/javax/crypto/policy/limited/LIMITED
- makefiles/javax/crypto/policy/limited/default_local.policy
- makefiles/javax/crypto/policy/limited/exempt_local.policy
- makefiles/javax/crypto/policy/unlimited/UNLIMITED
- makefiles/javax/crypto/policy/unlimited/default_US_export.policy
- makefiles/javax/crypto/policy/unlimited/default_local.policy
- makefiles/mkdemo/Makefile
- makefiles/mkdemo/jni/Makefile
- makefiles/mkdemo/jni/Poller/Makefile
- makefiles/mkdemo/jvmti/Makefile
- makefiles/mkdemo/jvmti/README.txt
- makefiles/mkdemo/jvmti/hprof/Makefile
- makefiles/mkdemo/jvmti/mapfile-vers
- makefiles/mkdemo/management/README.txt
- makefiles/sun/jkernel/Makefile
- makefiles/sun/security/ec/Makefile
- makefiles/sun/security/pkcs11/FILES_c.gmk
- makefiles/sun/security/pkcs11/Makefile
- makefiles/sun/security/pkcs11/mapfile-vers

Changeset: 08842f8ce960
Author:    bagiras
Date:      2012-07-17 12:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08842f8ce960

7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater
Reviewed-by: anthony, ant

! src/share/classes/sun/awt/SunToolkit.java

Changeset: 8a90db6c4d77
Author:    alexsch
Date:      2012-07-18 18:25 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a90db6c4d77

7182902: [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7
Reviewed-by: bae, kizune

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/native/sun/awt/CGraphicsDevice.m

Changeset: 86ca943c120b
Author:    lana
Date:      2012-07-18 16:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86ca943c120b

Merge


Changeset: 255c2c63697e
Author:    lana
Date:      2012-07-18 16:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/255c2c63697e

Merge

- src/share/classes/sun/security/krb5/ServiceName.java
- test/sun/security/krb5/ServiceNameClone.java
- test/sun/security/mscapi/ShortRSAKey512.sh
- test/sun/security/mscapi/ShortRSAKey768.sh

Changeset: 51707c3b75c0
Author:    lana
Date:      2012-07-24 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51707c3b75c0

Merge


Changeset: e4bae5c53fca
Author:    cl
Date:      2012-07-26 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4bae5c53fca

Added tag jdk8-b49 for changeset 51707c3b75c0

! .hgtags

Changeset: a093f6247b52
Author:    lana
Date:      2012-07-27 22:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a093f6247b52

Merge




From joe.darcy at oracle.com  Sun Jul 29 03:10:23 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 28 Jul 2012 20:10:23 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <50128C8B.10603@oracle.COM>
References: <50128C8B.10603@oracle.COM>
Message-ID: <5014A99F.4010104@oracle.com>

Hi Kumar,

Didn't see anything amiss after a quick look, but I think other people 
should review it too.

Cheers,

-Joe

On 7/27/2012 5:41 AM, Kumar Srinivasan wrote:
> Hi,
>
> Please review the fix
> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>
> to address:
> 7146424: Wildcard expansion for single entry classpath
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
> and
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>
>
> Notes:
> a. cmdtoargs.c will be pushed as a separate changeset using a separate CR
> and with contributor attribution to akhil.arora at oracle.com
>
> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
> webrev for whatever reason is not reporting it.
>
> Thanks
>
> Kumar
>
>
>


From dan.xu at oracle.com  Sun Jul 29 03:53:20 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Sat, 28 Jul 2012 20:53:20 -0700
Subject: Code Review Request For 7185340
Message-ID: <5014B3B0.1010307@oracle.com>

Hi Alan,

Please review the fix to bug 7185340. The webrev can be found at, 
http://cr.openjdk.java.net/~dxu/7185340/webrev.01/.

The fix is to increase the -XX:MaxDirectMemorySize parameter from 64M to 
75M. Bug 7176485 allows the temporary buffer cache to grow to IOV MAX. 
Therefore, in Windows each thread can have up to 16 direct buffers in 
the cache, which causes the addition of this jvm parameter to run this 
testcase.

Thanks,

-Dan


From david.holmes at oracle.com  Sun Jul 29 21:35:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jul 2012 07:35:40 +1000
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <50128C8B.10603@oracle.COM>
References: <50128C8B.10603@oracle.COM>
Message-ID: <5015ACAC.5030603@oracle.com>

Hi Kumar,

I can't comment on the details of the actual expansion logic, nor the tests.

Looking at the overall structure I'm still unclear why more of this 
isn't just hidden in win32 only files. Why do the new JLI_* methods have 
to be JLI methods? I would have hoped that everything could be 
hidden/handled inside CreateApplicationArgs/

One specific comment:

share/bin/main.c:

   99 #ifdef _WIN32
  100     {
  101         int i = 0;
  102         if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
  103             printf("Windows original main args:\n");
  104             for (i = 0 ; i < __argc ; i++) {
  105                 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
  106             }
  107         }
  108     }

Does MSC not permit declaration of i inside the for loop? It avoids the 
need for the extra scope.

David
-----

On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
> Hi,
>
> Please review the fix
> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>
> to address:
> 7146424: Wildcard expansion for single entry classpath
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
> and
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>
>
> Notes:
> a. cmdtoargs.c will be pushed as a separate changeset using a separate CR
> and with contributor attribution to akhil.arora at oracle.com
>
> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
> webrev for whatever reason is not reporting it.
>
> Thanks
>
> Kumar
>
>
>


From xiaofanhadoop at gmail.com  Mon Jul 30 00:53:46 2012
From: xiaofanhadoop at gmail.com (jjian fan)
Date: Mon, 30 Jul 2012 08:53:46 +0800
Subject: bug with File.mkdir?
Message-ID: <CA+4y=mWsXZ7cZS4Oh_rKgBEigwrzZ3EHjLiFL=G1gxtBKPQTCg@mail.gmail.com>

Hi:
   Guys, anyone knows there is any bug in Java.io.File.mkdir?  In our high
cocurrent scala message system, we create directory like ax-0,ax-1,ax-2,
but File.mkdir sometimes just create directory ax. The function is like as:

private val fsLock = new ReentrantLock();
private def createLog(topic: String, partition: Int): =  {
   fsLock.lock()
   try
     {
      val d = new File(logDir, topic + "-" + partition)

      if(!d.exists()) {
       if(d.mkdir())
          info("create directory " + d.getAbsolutePath()+" is success")
      }
     else
       {
        info("Directory " + topic + "-" + partition + " is existed")
       }

    }
    finally
      {
         fsLock.unlock()
      }
  }

Java version is  "1.7.0_05-icedtea".


Thanks!
Best Regards!
Jian Fan


From Alan.Bateman at oracle.com  Mon Jul 30 03:40:26 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jul 2012 04:40:26 +0100
Subject: bug with File.mkdir?
In-Reply-To: <CA+4y=mWsXZ7cZS4Oh_rKgBEigwrzZ3EHjLiFL=G1gxtBKPQTCg@mail.gmail.com>
References: <CA+4y=mWsXZ7cZS4Oh_rKgBEigwrzZ3EHjLiFL=G1gxtBKPQTCg@mail.gmail.com>
Message-ID: <5016022A.4060706@oracle.com>

On 30/07/2012 01:53, jjian fan wrote:
> Hi:
>     Guys, anyone knows there is any bug in Java.io.File.mkdir?  In our high
> cocurrent scala message system, we create directory like ax-0,ax-1,ax-2,
> but File.mkdir sometimes just create directory ax.
You say the version is "1.7.0_05-icedtea" so I assume this is Linux. Is 
there any chance that "topic" contains one or more characters that 
encode to bytes that include NUL (0). That might explain why the 
directory is created as "ax". If you change the code to use 
java.nio.file.Path then you will be able to detect this.

-Alan.


From Alan.Bateman at oracle.com  Mon Jul 30 03:41:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jul 2012 04:41:31 +0100
Subject: Code Review Request For 7185340
In-Reply-To: <5014B3B0.1010307@oracle.com>
References: <5014B3B0.1010307@oracle.com>
Message-ID: <5016026B.1040309@oracle.com>

On 29/07/2012 04:53, Dan Xu wrote:
> Hi Alan,
>
> Please review the fix to bug 7185340. The webrev can be found at, 
> http://cr.openjdk.java.net/~dxu/7185340/webrev.01/.
>
> The fix is to increase the -XX:MaxDirectMemorySize parameter from 64M 
> to 75M. Bug 7176485 allows the temporary buffer cache to grow to IOV 
> MAX. Therefore, in Windows each thread can have up to 16 direct 
> buffers in the cache, which causes the addition of this jvm parameter 
> to run this testcase.
>
> Thanks,
>
> -Dan
Thanks Dan, this looks fine to me and looks like you've worked out the 
maximum amount of direct memory that this test will use. I can push this 
for you.

-Alan


From alan.bateman at oracle.com  Mon Jul 30 03:58:21 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 30 Jul 2012 03:58:21 +0000
Subject: hg: jdk8/tl/jdk: 7185340: TEST_BUG:
	java/nio/channels/AsynchronousSocketChannel/Leaky.java failing
	intermittently [win]
Message-ID: <20120730035848.E61B04729D@hg.openjdk.java.net>

Changeset: 78644d4a9a32
Author:    dxu
Date:      2012-07-30 04:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78644d4a9a32

7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win]
Reviewed-by: alanb

! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java



From dan.xu at oracle.com  Mon Jul 30 04:20:29 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Sun, 29 Jul 2012 21:20:29 -0700
Subject: Code Review Request For 7185340
In-Reply-To: <5016026B.1040309@oracle.com>
References: <5014B3B0.1010307@oracle.com> <5016026B.1040309@oracle.com>
Message-ID: <50160B8D.4020904@oracle.com>

On 07/29/2012 08:41 PM, Alan Bateman wrote:
> On 29/07/2012 04:53, Dan Xu wrote:
>> Hi Alan,
>>
>> Please review the fix to bug 7185340. The webrev can be found at, 
>> http://cr.openjdk.java.net/~dxu/7185340/webrev.01/.
>>
>> The fix is to increase the -XX:MaxDirectMemorySize parameter from 64M 
>> to 75M. Bug 7176485 allows the temporary buffer cache to grow to IOV 
>> MAX. Therefore, in Windows each thread can have up to 16 direct 
>> buffers in the cache, which causes the addition of this jvm parameter 
>> to run this testcase.
>>
>> Thanks,
>>
>> -Dan
> Thanks Dan, this looks fine to me and looks like you've worked out the 
> maximum amount of direct memory that this test will use. I can push 
> this for you.
>
> -Alan
Thank you, Alan. I see the change is already pushed into the repository. 
I am going to move the bug status to 10-Fix Delivered. But I don't know 
what values I need put into "Commit To Fix In Build", "Fixed In Build", 
and "Integrated In Build". In glisten, I see the latest build under 
/java/re/jdk/8/promoted/all is b49. Shall I put b49 to those fields? Thanks!

- Dan


From david.holmes at oracle.com  Mon Jul 30 06:17:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jul 2012 16:17:45 +1000
Subject: Code Review Request For 7185340
In-Reply-To: <50160B8D.4020904@oracle.com>
References: <5014B3B0.1010307@oracle.com> <5016026B.1040309@oracle.com>
	<50160B8D.4020904@oracle.com>
Message-ID: <50162709.4070407@oracle.com>

Hi Dan,

On 30/07/2012 2:20 PM, Dan Xu wrote:
> Thank you, Alan. I see the change is already pushed into the repository.
> I am going to move the bug status to 10-Fix Delivered. But I don't know
> what values I need put into "Commit To Fix In Build", "Fixed In Build",
> and "Integrated In Build". In glisten, I see the latest build under
> /java/re/jdk/8/promoted/all is b49. Shall I put b49 to those fields?

While Alan is likely sleeping ... :)

Change the bug to "Fix Available". It is marked "Fix Delivered" after 
the TL repository integrates. b49 is already promoted and I would not 
expect TL to integrate again before the next promotion (b50), so b51 is 
a reasonable guesstimate for both "commit to fix in build" and "fixed in 
build". RE will fill in "Integrated in build" when the bug is moved to 
Fix Delivered after integration. It is "Integrated in build" that is the 
important value for tracking purposes.

Cheers,
David Holmes

> Thanks!
>
> - Dan


From huizhe.wang at oracle.com  Mon Jul 30 06:59:23 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Sun, 29 Jul 2012 23:59:23 -0700
Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader
In-Reply-To: <4FE8B9D5.6030005@oracle.com>
References: <4FE2D380.2010803@oracle.com>
	<36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com>
	<4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com>
	<4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com>
	<4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com>
	<5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com>
	<4FE8B9D5.6030005@oracle.com>
Message-ID: <501630CB.8000100@oracle.com>

Hi Paul, Alan,

I'm back on this change.

On 6/25/2012 12:19 PM, Joe Wang wrote:
>
>
> On 6/25/2012 9:34 AM, Paul Sandoz wrote:
>> H Joe,
>>
>> I just focused on javax.xml.datatype and assumed the rest follows the 
>> same pattern :-)
>
> Yeah, they are mostly similar, except Schema and XPath that do a 
> little extra check.
>
>
I said too quick.  Yes, the steps are the same except for the validation 
and XPath.  But it happened that DatatypeFactory is the only one that 
had defined Exception in the 3rd step. All others were made to ignore 
any error, since in the regular JDK, we can always fall back to the 
default impl unless requested not to.

I've made all of the changes as we've discussed,  to catch the 
ServiceConfigurationError and pass on the cause for all of the 
factories/finders.  I wanted to post the change so that you could see 
them on Mon.  But I had to read the definitions again when I got to the 
SchemaFactory and noticed that it was the only one that did not have its 
own exception. Instead, it was defined to always throw IAE if no impl is 
available.

As I thought through these definitions, I felt I would probably change 
them back although I started to hate the tedious duplications as you 
expected :)   Indeed, I have to argue again, in the regular JDK, there's 
no need to catch any errors since they would be considered abnormal 
(Windows' blue screen came to my mind).  And in jigsaw, we shall only 
need to figure out a different error message when no provider is 
available, only if we wanted it to be more end-user friendly.

-Joe



From ahughes at redhat.com  Mon Jul 30 10:20:14 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 30 Jul 2012 06:20:14 -0400 (EDT)
Subject: Native zlib libraries
In-Reply-To: <5012DB08.6090109@oracle.com>
Message-ID: <1236740822.5028742.1343643614692.JavaMail.root@redhat.com>

----- Original Message -----
> On 07/27/2012 10:37 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> The zip64 support (total_in/out) part probably can be done at Java
> >> level
> >> (ignore
> >> the total_in/out in z_tream_s).  Need to remove this dependency.
> >> Will
> >> take a look later.
> >>
> > Yes, it seems they still mention the size of total_in/out on the
> > website on the zlib site, and that they shouldn't be relied on:
> >
> > http://www.zlib.net/zlib_faq.html#faq32
> >
> > "Note however that the strm.total_in and strm_total_out counters
> > may be limited to 4 GB. These counters are provided as a
> > convenience and are not used internally by inflate() or deflate().
> > The application can easily set up its own counters updated after
> > each call of inflate() or deflate() to count beyond 4 GB"
> >
> > "The word "may" appears several times above since there is a 4 GB
> > limit only if the compiler's long type is 32 bits. If the
> > compiler's long type is 64 bits, then the limit is 16 exabytes."
> >
> > I notice a test went in with the 64-bit support, but I assume it
> > can't test these counters as the Deflater for a ZipStream is
> > protected.  At least, they aren't failing on our builds with
> > system zlib.
> 
> That test is not configured to be run for "auto testing", it just
> takes
> too long to zip/unzip
> a 4G+ file. I use it manually to test the ZIP64 support.
> 

Yes, sorry, I noticed this after posting.  I've since run it manually and it passes
with a system zlib, both on the zip it creates and one I created containing just
a single 4.2gb file (a RHEL ISO image zipped).  But I'm not sure if it's testing total bytes
read for overflow.

> I will give it a try to remove this dependency next week.

Thanks.

> It would be
> helpful if you can
> help "migrate" the icetea patch. How does the icetea patch work now?
> Always use the
> system zlib, if it presents? any configurable option to switch on and
> off?

It adds a switch and also support for setting the CFLAGS/LIBS:

    USE_SYSTEM_ZLIB=true \
    ZLIB_LIBS="$(pkg-config --libs zlib)" \
    ZLIB_CFLAGS="$(pkg-config --cflags zlib)" \

This is the same nomenclature we use for the other libraries too
(lcms, jpeg, png, gif, cups, etc.)

I'll try and post the patch later today.

> 
> -Sherman
> 
> > Are you actively working on this now or shall I take a look?
> >
> >> -Sherman
> >>
> >> On 7/11/2012 12:47 AM, Alan Bateman wrote:
> >>> On 05/07/2012 17:11, Andrew Hughes wrote:
> >>>> ----- Original Message -----
> >>>>> Is there a way to get the native zlib libraries to get picked
> >>>>> up
> >>>>> instead of the hardcoded version within the JVM?
> >>>>>
> >>>>> --
> >>>>> Azeem Jiva
> >>>>> @javawithjiva
> >>>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
> >>>> it
> >>>> upstream.
> >>>>
> >>>> However, I don't see how this is related to HotSpot, as the zlib
> >>>> usage
> >>>> is in the jdk tree.
> >>> I think we need to (re)start the discussion on core-libs-dev with
> >>> a
> >>> view to eliminating the patches that the JDK has to zlib, see:
> >>>
> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
> >>>
> >>>
> >>> One of these changes relates to the zip64 support and I believe
> >>> there
> >>> are corner cases when inflating or deflating>2GB that won't work
> >>> if
> >>> using the system zlib. Sherman will likely recall the details.
> >>> Given
> >>> that the new build already supports using the system zlib (at
> >>> least
> >>> on
> >>> Linux) then it would be good to sort this out so that it just
> >>> works.
> >>>
> >>> -Alan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From kumar.x.srinivasan at oracle.COM  Mon Jul 30 12:32:40 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 30 Jul 2012 05:32:40 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5015ACAC.5030603@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
Message-ID: <50167EE8.10306@oracle.COM>

HI David,

> I can't comment on the details of the actual expansion logic, nor the 
> tests.

Akhil and I have gone over this.

>
> Looking at the overall structure I'm still unclear why more of this 
> isn't just hidden in win32 only files. Why do the new JLI_* methods 
> have to be JLI methods? I would have hoped that everything could be 
> hidden/handled inside CreateApplicationArgs/

We need JLI_* methods because all of the launcher's implementation is in 
the library libjli.so on Unix
and on windows, jli.dll.

Now, main.c is a common stub which provides the main/Winmain for all the 
launchers, meaning java
as well as javac, javap etc. therefore main.c is linked with libjli.so 
and  all of them call into the JLI_Launch an
entry point which starts the launch, with the argc, argv, Note that 
substantial argument processing is performed much before we reach 
CreateApplicationArgs

Since this expansion is required before we call into JLI_Launch, we need 
to call JLI_CmdToArgs
specifically for Windows, for our parsed arguments, so that we can 
substitute argc, argv with our parsed version.

Does that answer your question ? So do you have reservations about 
exposing the JLI_* interfaces,
I think it is possible to  encapsulate these completely within the jli 
library, thus not needing to
export those interfaces, but that will complicate the logic within 
JLI_Launch, requiring platform
specific expansions functions. I think what we have now is a lot cleaner.

>
> One specific comment:
>
> share/bin/main.c:
>
>   99 #ifdef _WIN32
>  100     {
>  101         int i = 0;
>  102         if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>  103             printf("Windows original main args:\n");
>  104             for (i = 0 ; i < __argc ; i++) {
>  105                 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>  106             }
>  107         }
>  108     }
>
> Does MSC not permit declaration of i inside the for loop? It avoids 
> the need for the extra scope.
MSC permits,  there are two uses of the for-loop counters, I guess I can 
create one variable to handle
both, and eliminate the scopes.

Kumar

>
> David
> -----
>
> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>> Hi,
>>
>> Please review the fix
>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>
>> to address:
>> 7146424: Wildcard expansion for single entry classpath
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>> and
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>
>>
>> Notes:
>> a. cmdtoargs.c will be pushed as a separate changeset using a 
>> separate CR
>> and with contributor attribution to akhil.arora at oracle.com
>>
>> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
>> webrev for whatever reason is not reporting it.
>>
>> Thanks
>>
>> Kumar
>>
>>
>>



From ahughes at redhat.com  Mon Jul 30 12:35:24 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 30 Jul 2012 08:35:24 -0400 (EDT)
Subject: Native zlib libraries
In-Reply-To: <BF6FC743-0964-493E-8AA1-47049EAD3DD0@oracle.com>
Message-ID: <1918842039.5121189.1343651724469.JavaMail.root@redhat.com>

----- Original Message -----
> Two other obvious candidates are the bundled jpeg and gif libraries.
> Please suggest a patch for build-infra/jdk8!
> 
> Backporting the new build system for jdk7/jdk6 is not even on the
> horizon. It
> would be nice though, and probably not impossible.
> 
> //Fredrik
> 
> 9 jul 2012 kl. 01:52 skrev Andrew Hughes:
> 
> > 
> > 
> > ----- Original Message -----
> >> The new build system offers a convenient option to the configure
> >> script:
> >> --with-zlib=system
> >> this will pickup the zlib libraries from the system.
> >> 
> >> The default behavior is: --with-zlib=bundled
> >> 
> > 
> > Have you done any others?  And is this available from the old bug
> > system?
> > 
> > This is the first I've heard of this being done and we need it in 6
> > & 7 too.
> > 
> >> //Fredrik
> >> 
> >> 2012/7/5 Andrew Hughes <ahughes at redhat.com>:
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>>> Is there a way to get the native zlib libraries to get picked up
> >>>> instead of the hardcoded version within the JVM?
> >>>> 
> >>>> --
> >>>> Azeem Jiva
> >>>> @javawithjiva
> >>> 
> >>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
> >>> it
> >>> upstream.
> >>> 
> >>> However, I don't see how this is related to HotSpot, as the zlib
> >>> usage
> >>> is in the jdk tree.
> >>> --
> >>> Andrew :)
> >>> 
> >>> Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>> 
> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
> >>> 
> >> 
> > 

It looks like most of our zlib work has already been reproduced by your good
self.  Saves me a job! :-D (for 8 anyway)

The main differences seem to be a minor naming one (USE_SYSTEM_ZLIB/SYSTEM_ZLIB) and
the hardcoding of -lz over ZLIB_CFLAGS/ZLIB_LIBS (I'll suggest a patch for this).

However, I'm not clear as to which version of zlib you used, because, in its current
form, SYSTEM_ZLIB doesn't work for me:

In file included from ../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:37:0:
../../../../../src/share/native/com/sun/java/util/jar/pack/defines.h:98:22: error: conflicting declaration 'typedef unsigned int uLong'
In file included from ../../../../../src/share/native/com/sun/java/util/jar/pack/defines.h:36:0,
                 from ../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:37:
/usr/include/zconf.h:368:24: error: 'uLong' has a previous declaration as 'typedef long unsigned int uLong'
../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:449:1: warning: missing initializer for member 'band_init::defc' [-Wmissing-field-initializers]
../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:449:1: warning: missing initializer for member 'band_init::index' [-Wmissing-field-initializers]

In our patch, we did:

-#ifdef _LP64
-typedef unsigned int uLong; // Historical zlib, should be 32-bit.
+#ifdef USE_SYSTEM_ZLIB
+ #include <zlib.h>
#else
-typedef unsigned long uLong;
+ #ifdef _LP64
+ typedef unsigned int uLong; // Historical zlib, should be 32-bit.
+ #else
+ typedef unsigned long uLong;
+ #endif 

(see http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/3a2014eddd87)

so that uLong was only defined locally if zlib was in-tree.  There is some odd logic in 8:

#if !defined(MACOSX) || (defined(MACOSX) && defined(NO_ZLIB))

Should this not just be #if defined(NO_ZLIB)?

It works for me if I change to that.

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From david.holmes at oracle.com  Mon Jul 30 12:48:03 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jul 2012 22:48:03 +1000
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <50167EE8.10306@oracle.COM>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM>
Message-ID: <50168283.3060501@oracle.com>

Hi Kumar,

I'm always uncomfortable when I see common code that is effectively a 
no-op on all but one platform - as it means it isn't really common, we 
just factored it that way. But I'm not vehemently opposed. :)

David

On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
> HI David,
>
>> I can't comment on the details of the actual expansion logic, nor the
>> tests.
>
> Akhil and I have gone over this.
>
>>
>> Looking at the overall structure I'm still unclear why more of this
>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>> have to be JLI methods? I would have hoped that everything could be
>> hidden/handled inside CreateApplicationArgs/
>
> We need JLI_* methods because all of the launcher's implementation is in
> the library libjli.so on Unix
> and on windows, jli.dll.
>
> Now, main.c is a common stub which provides the main/Winmain for all the
> launchers, meaning java
> as well as javac, javap etc. therefore main.c is linked with libjli.so
> and all of them call into the JLI_Launch an
> entry point which starts the launch, with the argc, argv, Note that
> substantial argument processing is performed much before we reach
> CreateApplicationArgs
>
> Since this expansion is required before we call into JLI_Launch, we need
> to call JLI_CmdToArgs
> specifically for Windows, for our parsed arguments, so that we can
> substitute argc, argv with our parsed version.
>
> Does that answer your question ? So do you have reservations about
> exposing the JLI_* interfaces,
> I think it is possible to encapsulate these completely within the jli
> library, thus not needing to
> export those interfaces, but that will complicate the logic within
> JLI_Launch, requiring platform
> specific expansions functions. I think what we have now is a lot cleaner.
>
>>
>> One specific comment:
>>
>> share/bin/main.c:
>>
>> 99 #ifdef _WIN32
>> 100 {
>> 101 int i = 0;
>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>> 103 printf("Windows original main args:\n");
>> 104 for (i = 0 ; i < __argc ; i++) {
>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>> 106 }
>> 107 }
>> 108 }
>>
>> Does MSC not permit declaration of i inside the for loop? It avoids
>> the need for the extra scope.
> MSC permits, there are two uses of the for-loop counters, I guess I can
> create one variable to handle
> both, and eliminate the scopes.
>
> Kumar
>
>>
>> David
>> -----
>>
>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>> Hi,
>>>
>>> Please review the fix
>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>
>>> to address:
>>> 7146424: Wildcard expansion for single entry classpath
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>> and
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>
>>>
>>> Notes:
>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>> separate CR
>>> and with contributor attribution to akhil.arora at oracle.com
>>>
>>> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
>>> webrev for whatever reason is not reporting it.
>>>
>>> Thanks
>>>
>>> Kumar
>>>
>>>
>>>
>


From kumar.x.srinivasan at oracle.COM  Mon Jul 30 12:53:31 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 30 Jul 2012 05:53:31 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <50168283.3060501@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
Message-ID: <501683CB.2020600@oracle.COM>

Hi David,

> Hi Kumar,
>
> I'm always uncomfortable when I see common code that is effectively a 
> no-op on all but one platform - as it means it isn't really common, we 
> just factored it that way. But I'm not vehemently opposed. :)

I hear you, but this is the way have managed to eliminate cpp conditionals.

Any more comments from others ? Please let me know today, I would like 
to sew this
up with one more webrev.

Thanks
Kumar

>
> David
>
> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>> HI David,
>>
>>> I can't comment on the details of the actual expansion logic, nor the
>>> tests.
>>
>> Akhil and I have gone over this.
>>
>>>
>>> Looking at the overall structure I'm still unclear why more of this
>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>> have to be JLI methods? I would have hoped that everything could be
>>> hidden/handled inside CreateApplicationArgs/
>>
>> We need JLI_* methods because all of the launcher's implementation is in
>> the library libjli.so on Unix
>> and on windows, jli.dll.
>>
>> Now, main.c is a common stub which provides the main/Winmain for all the
>> launchers, meaning java
>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>> and all of them call into the JLI_Launch an
>> entry point which starts the launch, with the argc, argv, Note that
>> substantial argument processing is performed much before we reach
>> CreateApplicationArgs
>>
>> Since this expansion is required before we call into JLI_Launch, we need
>> to call JLI_CmdToArgs
>> specifically for Windows, for our parsed arguments, so that we can
>> substitute argc, argv with our parsed version.
>>
>> Does that answer your question ? So do you have reservations about
>> exposing the JLI_* interfaces,
>> I think it is possible to encapsulate these completely within the jli
>> library, thus not needing to
>> export those interfaces, but that will complicate the logic within
>> JLI_Launch, requiring platform
>> specific expansions functions. I think what we have now is a lot 
>> cleaner.
>>
>>>
>>> One specific comment:
>>>
>>> share/bin/main.c:
>>>
>>> 99 #ifdef _WIN32
>>> 100 {
>>> 101 int i = 0;
>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>> 103 printf("Windows original main args:\n");
>>> 104 for (i = 0 ; i < __argc ; i++) {
>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>> 106 }
>>> 107 }
>>> 108 }
>>>
>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>> the need for the extra scope.
>> MSC permits, there are two uses of the for-loop counters, I guess I can
>> create one variable to handle
>> both, and eliminate the scopes.
>>
>> Kumar
>>
>>>
>>> David
>>> -----
>>>
>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>> Hi,
>>>>
>>>> Please review the fix
>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>
>>>> to address:
>>>> 7146424: Wildcard expansion for single entry classpath
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>> and
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>
>>>>
>>>> Notes:
>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>> separate CR
>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>
>>>> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
>>>> webrev for whatever reason is not reporting it.
>>>>
>>>> Thanks
>>>>
>>>> Kumar
>>>>
>>>>
>>>>
>>



From kumar.x.srinivasan at oracle.COM  Mon Jul 30 20:11:43 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 30 Jul 2012 13:11:43 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <50168283.3060501@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
Message-ID: <5016EA7F.2050108@oracle.COM>

Hi David,

Here are the changes you suggested, removed 2 scopes in
main.c

The delta from last reviewed revision:
http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html

The full webrev:
http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html

Thanks
Kumar

> Hi Kumar,
>
> I'm always uncomfortable when I see common code that is effectively a 
> no-op on all but one platform - as it means it isn't really common, we 
> just factored it that way. But I'm not vehemently opposed. :)
>
> David
>
> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>> HI David,
>>
>>> I can't comment on the details of the actual expansion logic, nor the
>>> tests.
>>
>> Akhil and I have gone over this.
>>
>>>
>>> Looking at the overall structure I'm still unclear why more of this
>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>> have to be JLI methods? I would have hoped that everything could be
>>> hidden/handled inside CreateApplicationArgs/
>>
>> We need JLI_* methods because all of the launcher's implementation is in
>> the library libjli.so on Unix
>> and on windows, jli.dll.
>>
>> Now, main.c is a common stub which provides the main/Winmain for all the
>> launchers, meaning java
>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>> and all of them call into the JLI_Launch an
>> entry point which starts the launch, with the argc, argv, Note that
>> substantial argument processing is performed much before we reach
>> CreateApplicationArgs
>>
>> Since this expansion is required before we call into JLI_Launch, we need
>> to call JLI_CmdToArgs
>> specifically for Windows, for our parsed arguments, so that we can
>> substitute argc, argv with our parsed version.
>>
>> Does that answer your question ? So do you have reservations about
>> exposing the JLI_* interfaces,
>> I think it is possible to encapsulate these completely within the jli
>> library, thus not needing to
>> export those interfaces, but that will complicate the logic within
>> JLI_Launch, requiring platform
>> specific expansions functions. I think what we have now is a lot 
>> cleaner.
>>
>>>
>>> One specific comment:
>>>
>>> share/bin/main.c:
>>>
>>> 99 #ifdef _WIN32
>>> 100 {
>>> 101 int i = 0;
>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>> 103 printf("Windows original main args:\n");
>>> 104 for (i = 0 ; i < __argc ; i++) {
>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>> 106 }
>>> 107 }
>>> 108 }
>>>
>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>> the need for the extra scope.
>> MSC permits, there are two uses of the for-loop counters, I guess I can
>> create one variable to handle
>> both, and eliminate the scopes.
>>
>> Kumar
>>
>>>
>>> David
>>> -----
>>>
>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>> Hi,
>>>>
>>>> Please review the fix
>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>
>>>> to address:
>>>> 7146424: Wildcard expansion for single entry classpath
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>> and
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>
>>>>
>>>> Notes:
>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>> separate CR
>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>
>>>> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
>>>> webrev for whatever reason is not reporting it.
>>>>
>>>> Thanks
>>>>
>>>> Kumar
>>>>
>>>>
>>>>
>>



From david.holmes at oracle.com  Mon Jul 30 21:19:19 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jul 2012 07:19:19 +1000
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5016EA7F.2050108@oracle.COM>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
	<5016EA7F.2050108@oracle.COM>
Message-ID: <5016FA57.6090900@oracle.com>

Hi Kumar,

Don't meant to be difficult but a global int i shared across the two 
loops is not what I was suggesting rather that the loop variable be 
declared in the loop eg:

  114     for (int i = 0 ; i < margc ; i++) {
  115         margv[i] = stdargs[i].arg;
  116     }

then you can change 117 to not use i

  117     margv[i] = NULL;

becomes

          margv[margc] = NULL;

David

On 31/07/2012 6:11 AM, Kumar Srinivasan wrote:
> Hi David,
>
> Here are the changes you suggested, removed 2 scopes in
> main.c
>
> The delta from last reviewed revision:
> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html
>
> The full webrev:
> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html
>
> Thanks
> Kumar
>
>> Hi Kumar,
>>
>> I'm always uncomfortable when I see common code that is effectively a
>> no-op on all but one platform - as it means it isn't really common, we
>> just factored it that way. But I'm not vehemently opposed. :)
>>
>> David
>>
>> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>>> HI David,
>>>
>>>> I can't comment on the details of the actual expansion logic, nor the
>>>> tests.
>>>
>>> Akhil and I have gone over this.
>>>
>>>>
>>>> Looking at the overall structure I'm still unclear why more of this
>>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>>> have to be JLI methods? I would have hoped that everything could be
>>>> hidden/handled inside CreateApplicationArgs/
>>>
>>> We need JLI_* methods because all of the launcher's implementation is in
>>> the library libjli.so on Unix
>>> and on windows, jli.dll.
>>>
>>> Now, main.c is a common stub which provides the main/Winmain for all the
>>> launchers, meaning java
>>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>>> and all of them call into the JLI_Launch an
>>> entry point which starts the launch, with the argc, argv, Note that
>>> substantial argument processing is performed much before we reach
>>> CreateApplicationArgs
>>>
>>> Since this expansion is required before we call into JLI_Launch, we need
>>> to call JLI_CmdToArgs
>>> specifically for Windows, for our parsed arguments, so that we can
>>> substitute argc, argv with our parsed version.
>>>
>>> Does that answer your question ? So do you have reservations about
>>> exposing the JLI_* interfaces,
>>> I think it is possible to encapsulate these completely within the jli
>>> library, thus not needing to
>>> export those interfaces, but that will complicate the logic within
>>> JLI_Launch, requiring platform
>>> specific expansions functions. I think what we have now is a lot
>>> cleaner.
>>>
>>>>
>>>> One specific comment:
>>>>
>>>> share/bin/main.c:
>>>>
>>>> 99 #ifdef _WIN32
>>>> 100 {
>>>> 101 int i = 0;
>>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>>> 103 printf("Windows original main args:\n");
>>>> 104 for (i = 0 ; i < __argc ; i++) {
>>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>>> 106 }
>>>> 107 }
>>>> 108 }
>>>>
>>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>>> the need for the extra scope.
>>> MSC permits, there are two uses of the for-loop counters, I guess I can
>>> create one variable to handle
>>> both, and eliminate the scopes.
>>>
>>> Kumar
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix
>>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>>
>>>>> to address:
>>>>> 7146424: Wildcard expansion for single entry classpath
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>>> and
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>>
>>>>>
>>>>> Notes:
>>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>>> separate CR
>>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>>
>>>>> b. src/solaris/bin/java_md.c is a redundant file and will be removed,
>>>>> webrev for whatever reason is not reporting it.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Kumar
>>>>>
>>>>>
>>>>>
>>>
>


From dan.xu at oracle.com  Mon Jul 30 21:22:41 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Mon, 30 Jul 2012 14:22:41 -0700
Subject: Code Review Request For 7185340
In-Reply-To: <50162709.4070407@oracle.com>
References: <5014B3B0.1010307@oracle.com> <5016026B.1040309@oracle.com>
	<50160B8D.4020904@oracle.com> <50162709.4070407@oracle.com>
Message-ID: <5016FB21.6070406@oracle.com>

On 07/29/2012 11:17 PM, David Holmes wrote:
> Hi Dan,
>
> On 30/07/2012 2:20 PM, Dan Xu wrote:
>> Thank you, Alan. I see the change is already pushed into the repository.
>> I am going to move the bug status to 10-Fix Delivered. But I don't know
>> what values I need put into "Commit To Fix In Build", "Fixed In Build",
>> and "Integrated In Build". In glisten, I see the latest build under
>> /java/re/jdk/8/promoted/all is b49. Shall I put b49 to those fields?
>
> While Alan is likely sleeping ... :)
>
> Change the bug to "Fix Available". It is marked "Fix Delivered" after 
> the TL repository integrates. b49 is already promoted and I would not 
> expect TL to integrate again before the next promotion (b50), so b51 
> is a reasonable guesstimate for both "commit to fix in build" and 
> "fixed in build". RE will fill in "Integrated in build" when the bug 
> is moved to Fix Delivered after integration. It is "Integrated in 
> build" that is the important value for tracking purposes.
>
> Cheers,
> David Holmes
>
>> Thanks!
>>
>> - Dan
Thank you, David. I have moved the bug to 8-Fix Available.

- Dan


From kumar.x.srinivasan at oracle.COM  Mon Jul 30 21:32:49 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 30 Jul 2012 14:32:49 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5016FA57.6090900@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
	<5016EA7F.2050108@oracle.COM> <5016FA57.6090900@oracle.com>
Message-ID: <5016FD81.2020008@oracle.COM>

Hi David,
> Hi Kumar,
>
> Don't meant to be difficult but a global int i shared across the two 
> loops is not what I was suggesting rather that the loop variable be 
> declared in the loop eg:
>
>  114     for (int i = 0 ; i < margc ; i++) {
>  115         margv[i] = stdargs[i].arg;
>  116     }
>
> then you can change 117 to not use i
>
>  117     margv[i] = NULL;
>
> becomes
>
>          margv[margc] = NULL;

Ah!, oh sorry that won't fly this is c code :-( , not c++, MSC does  not 
allow it.

Kumar


>
> David
>
> On 31/07/2012 6:11 AM, Kumar Srinivasan wrote:
>> Hi David,
>>
>> Here are the changes you suggested, removed 2 scopes in
>> main.c
>>
>> The delta from last reviewed revision:
>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html 
>>
>>
>> The full webrev:
>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html
>>
>> Thanks
>> Kumar
>>
>>> Hi Kumar,
>>>
>>> I'm always uncomfortable when I see common code that is effectively a
>>> no-op on all but one platform - as it means it isn't really common, we
>>> just factored it that way. But I'm not vehemently opposed. :)
>>>
>>> David
>>>
>>> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>>>> HI David,
>>>>
>>>>> I can't comment on the details of the actual expansion logic, nor the
>>>>> tests.
>>>>
>>>> Akhil and I have gone over this.
>>>>
>>>>>
>>>>> Looking at the overall structure I'm still unclear why more of this
>>>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>>>> have to be JLI methods? I would have hoped that everything could be
>>>>> hidden/handled inside CreateApplicationArgs/
>>>>
>>>> We need JLI_* methods because all of the launcher's implementation 
>>>> is in
>>>> the library libjli.so on Unix
>>>> and on windows, jli.dll.
>>>>
>>>> Now, main.c is a common stub which provides the main/Winmain for 
>>>> all the
>>>> launchers, meaning java
>>>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>>>> and all of them call into the JLI_Launch an
>>>> entry point which starts the launch, with the argc, argv, Note that
>>>> substantial argument processing is performed much before we reach
>>>> CreateApplicationArgs
>>>>
>>>> Since this expansion is required before we call into JLI_Launch, we 
>>>> need
>>>> to call JLI_CmdToArgs
>>>> specifically for Windows, for our parsed arguments, so that we can
>>>> substitute argc, argv with our parsed version.
>>>>
>>>> Does that answer your question ? So do you have reservations about
>>>> exposing the JLI_* interfaces,
>>>> I think it is possible to encapsulate these completely within the jli
>>>> library, thus not needing to
>>>> export those interfaces, but that will complicate the logic within
>>>> JLI_Launch, requiring platform
>>>> specific expansions functions. I think what we have now is a lot
>>>> cleaner.
>>>>
>>>>>
>>>>> One specific comment:
>>>>>
>>>>> share/bin/main.c:
>>>>>
>>>>> 99 #ifdef _WIN32
>>>>> 100 {
>>>>> 101 int i = 0;
>>>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>>>> 103 printf("Windows original main args:\n");
>>>>> 104 for (i = 0 ; i < __argc ; i++) {
>>>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>>>> 106 }
>>>>> 107 }
>>>>> 108 }
>>>>>
>>>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>>>> the need for the extra scope.
>>>> MSC permits, there are two uses of the for-loop counters, I guess I 
>>>> can
>>>> create one variable to handle
>>>> both, and eliminate the scopes.
>>>>
>>>> Kumar
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the fix
>>>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>>>
>>>>>> to address:
>>>>>> 7146424: Wildcard expansion for single entry classpath
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>>>> and
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>>>
>>>>>>
>>>>>> Notes:
>>>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>>>> separate CR
>>>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>>>
>>>>>> b. src/solaris/bin/java_md.c is a redundant file and will be 
>>>>>> removed,
>>>>>> webrev for whatever reason is not reporting it.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>>
>>>>>>
>>>>
>>



From michael.x.mcmahon at oracle.com  Mon Jul 30 21:40:02 2012
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Mon, 30 Jul 2012 21:40:02 +0000
Subject: hg: jdk8/tl/jdk: 7120665: Change Java SE spec so that external
	networking not required
Message-ID: <20120730214022.D8D65472B3@hg.openjdk.java.net>

Changeset: 38263aa28324
Author:    michaelm
Date:      2012-07-30 22:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38263aa28324

7120665: Change Java SE spec so that external networking not required
Reviewed-by: alanb

! src/share/classes/java/net/NetworkInterface.java
! src/share/classes/java/net/package.html



From david.holmes at oracle.com  Mon Jul 30 21:43:41 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jul 2012 07:43:41 +1000
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5016FD81.2020008@oracle.COM>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
	<5016EA7F.2050108@oracle.COM> <5016FA57.6090900@oracle.com>
	<5016FD81.2020008@oracle.COM>
Message-ID: <5017000D.4060707@oracle.com>

On 31/07/2012 7:32 AM, Kumar Srinivasan wrote:
> Hi David,
>> Hi Kumar,
>>
>> Don't meant to be difficult but a global int i shared across the two
>> loops is not what I was suggesting rather that the loop variable be
>> declared in the loop eg:
>>
>> 114 for (int i = 0 ; i < margc ; i++) {
>> 115 margv[i] = stdargs[i].arg;
>> 116 }
>>
>> then you can change 117 to not use i
>>
>> 117 margv[i] = NULL;
>>
>> becomes
>>
>> margv[margc] = NULL;
>
> Ah!, oh sorry that won't fly this is c code :-( , not c++, MSC does not
> allow it.

Wow that is unbelievable! for-loop variable declarations are part of C99 :(

David
-----

> Kumar
>
>
>>
>> David
>>
>> On 31/07/2012 6:11 AM, Kumar Srinivasan wrote:
>>> Hi David,
>>>
>>> Here are the changes you suggested, removed 2 scopes in
>>> main.c
>>>
>>> The delta from last reviewed revision:
>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html
>>>
>>>
>>> The full webrev:
>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html
>>>
>>> Thanks
>>> Kumar
>>>
>>>> Hi Kumar,
>>>>
>>>> I'm always uncomfortable when I see common code that is effectively a
>>>> no-op on all but one platform - as it means it isn't really common, we
>>>> just factored it that way. But I'm not vehemently opposed. :)
>>>>
>>>> David
>>>>
>>>> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>>>>> HI David,
>>>>>
>>>>>> I can't comment on the details of the actual expansion logic, nor the
>>>>>> tests.
>>>>>
>>>>> Akhil and I have gone over this.
>>>>>
>>>>>>
>>>>>> Looking at the overall structure I'm still unclear why more of this
>>>>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>>>>> have to be JLI methods? I would have hoped that everything could be
>>>>>> hidden/handled inside CreateApplicationArgs/
>>>>>
>>>>> We need JLI_* methods because all of the launcher's implementation
>>>>> is in
>>>>> the library libjli.so on Unix
>>>>> and on windows, jli.dll.
>>>>>
>>>>> Now, main.c is a common stub which provides the main/Winmain for
>>>>> all the
>>>>> launchers, meaning java
>>>>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>>>>> and all of them call into the JLI_Launch an
>>>>> entry point which starts the launch, with the argc, argv, Note that
>>>>> substantial argument processing is performed much before we reach
>>>>> CreateApplicationArgs
>>>>>
>>>>> Since this expansion is required before we call into JLI_Launch, we
>>>>> need
>>>>> to call JLI_CmdToArgs
>>>>> specifically for Windows, for our parsed arguments, so that we can
>>>>> substitute argc, argv with our parsed version.
>>>>>
>>>>> Does that answer your question ? So do you have reservations about
>>>>> exposing the JLI_* interfaces,
>>>>> I think it is possible to encapsulate these completely within the jli
>>>>> library, thus not needing to
>>>>> export those interfaces, but that will complicate the logic within
>>>>> JLI_Launch, requiring platform
>>>>> specific expansions functions. I think what we have now is a lot
>>>>> cleaner.
>>>>>
>>>>>>
>>>>>> One specific comment:
>>>>>>
>>>>>> share/bin/main.c:
>>>>>>
>>>>>> 99 #ifdef _WIN32
>>>>>> 100 {
>>>>>> 101 int i = 0;
>>>>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>>>>> 103 printf("Windows original main args:\n");
>>>>>> 104 for (i = 0 ; i < __argc ; i++) {
>>>>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>>>>> 106 }
>>>>>> 107 }
>>>>>> 108 }
>>>>>>
>>>>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>>>>> the need for the extra scope.
>>>>> MSC permits, there are two uses of the for-loop counters, I guess I
>>>>> can
>>>>> create one variable to handle
>>>>> both, and eliminate the scopes.
>>>>>
>>>>> Kumar
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the fix
>>>>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>>>>
>>>>>>> to address:
>>>>>>> 7146424: Wildcard expansion for single entry classpath
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>>>>> and
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>>>>
>>>>>>>
>>>>>>> Notes:
>>>>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>>>>> separate CR
>>>>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>>>>
>>>>>>> b. src/solaris/bin/java_md.c is a redundant file and will be
>>>>>>> removed,
>>>>>>> webrev for whatever reason is not reporting it.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Kumar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>


From mike.duigou at oracle.com  Mon Jul 30 21:55:40 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 30 Jul 2012 14:55:40 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5017000D.4060707@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
	<5016EA7F.2050108@oracle.COM> <5016FA57.6090900@oracle.com>
	<5016FD81.2020008@oracle.COM> <5017000D.4060707@oracle.com>
Message-ID: <D226584F-C6AD-496B-BB56-24C31435AFC2@oracle.com>


On Jul 30 2012, at 14:43 , David Holmes wrote:

> On 31/07/2012 7:32 AM, Kumar Srinivasan wrote:
>> Hi David,
>>> Hi Kumar,
>>> 
>>> Don't meant to be difficult but a global int i shared across the two
>>> loops is not what I was suggesting rather that the loop variable be
>>> declared in the loop eg:
>>> 
>>> 114 for (int i = 0 ; i < margc ; i++) {
>>> 115 margv[i] = stdargs[i].arg;
>>> 116 }
>>> 
>>> then you can change 117 to not use i
>>> 
>>> 117 margv[i] = NULL;
>>> 
>>> becomes
>>> 
>>> margv[margc] = NULL;
>> 
>> Ah!, oh sorry that won't fly this is c code :-( , not c++, MSC does not
>> allow it.
> 
> Wow that is unbelievable! for-loop variable declarations are part of C99 :(
> 
> David

Sadly Microsoft does not and will will not be providing a C99 compiler.

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Mike

> -----
> 
>> Kumar
>> 
>> 
>>> 
>>> David
>>> 
>>> On 31/07/2012 6:11 AM, Kumar Srinivasan wrote:
>>>> Hi David,
>>>> 
>>>> Here are the changes you suggested, removed 2 scopes in
>>>> main.c
>>>> 
>>>> The delta from last reviewed revision:
>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html
>>>> 
>>>> 
>>>> The full webrev:
>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html
>>>> 
>>>> Thanks
>>>> Kumar
>>>> 
>>>>> Hi Kumar,
>>>>> 
>>>>> I'm always uncomfortable when I see common code that is effectively a
>>>>> no-op on all but one platform - as it means it isn't really common, we
>>>>> just factored it that way. But I'm not vehemently opposed. :)
>>>>> 
>>>>> David
>>>>> 
>>>>> On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
>>>>>> HI David,
>>>>>> 
>>>>>>> I can't comment on the details of the actual expansion logic, nor the
>>>>>>> tests.
>>>>>> 
>>>>>> Akhil and I have gone over this.
>>>>>> 
>>>>>>> 
>>>>>>> Looking at the overall structure I'm still unclear why more of this
>>>>>>> isn't just hidden in win32 only files. Why do the new JLI_* methods
>>>>>>> have to be JLI methods? I would have hoped that everything could be
>>>>>>> hidden/handled inside CreateApplicationArgs/
>>>>>> 
>>>>>> We need JLI_* methods because all of the launcher's implementation
>>>>>> is in
>>>>>> the library libjli.so on Unix
>>>>>> and on windows, jli.dll.
>>>>>> 
>>>>>> Now, main.c is a common stub which provides the main/Winmain for
>>>>>> all the
>>>>>> launchers, meaning java
>>>>>> as well as javac, javap etc. therefore main.c is linked with libjli.so
>>>>>> and all of them call into the JLI_Launch an
>>>>>> entry point which starts the launch, with the argc, argv, Note that
>>>>>> substantial argument processing is performed much before we reach
>>>>>> CreateApplicationArgs
>>>>>> 
>>>>>> Since this expansion is required before we call into JLI_Launch, we
>>>>>> need
>>>>>> to call JLI_CmdToArgs
>>>>>> specifically for Windows, for our parsed arguments, so that we can
>>>>>> substitute argc, argv with our parsed version.
>>>>>> 
>>>>>> Does that answer your question ? So do you have reservations about
>>>>>> exposing the JLI_* interfaces,
>>>>>> I think it is possible to encapsulate these completely within the jli
>>>>>> library, thus not needing to
>>>>>> export those interfaces, but that will complicate the logic within
>>>>>> JLI_Launch, requiring platform
>>>>>> specific expansions functions. I think what we have now is a lot
>>>>>> cleaner.
>>>>>> 
>>>>>>> 
>>>>>>> One specific comment:
>>>>>>> 
>>>>>>> share/bin/main.c:
>>>>>>> 
>>>>>>> 99 #ifdef _WIN32
>>>>>>> 100 {
>>>>>>> 101 int i = 0;
>>>>>>> 102 if (getenv(JLDEBUG_ENV_ENTRY) != NULL) {
>>>>>>> 103 printf("Windows original main args:\n");
>>>>>>> 104 for (i = 0 ; i < __argc ; i++) {
>>>>>>> 105 printf("wwwd_args[%d] = %s\n", i, __argv[i]);
>>>>>>> 106 }
>>>>>>> 107 }
>>>>>>> 108 }
>>>>>>> 
>>>>>>> Does MSC not permit declaration of i inside the for loop? It avoids
>>>>>>> the need for the extra scope.
>>>>>> MSC permits, there are two uses of the for-loop counters, I guess I
>>>>>> can
>>>>>> create one variable to handle
>>>>>> both, and eliminate the scopes.
>>>>>> 
>>>>>> Kumar
>>>>>> 
>>>>>>> 
>>>>>>> David
>>>>>>> -----
>>>>>>> 
>>>>>>> On 27/07/2012 10:41 PM, Kumar Srinivasan wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Please review the fix
>>>>>>>> http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/
>>>>>>>> 
>>>>>>>> to address:
>>>>>>>> 7146424: Wildcard expansion for single entry classpath
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146424
>>>>>>>> and
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167744
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Notes:
>>>>>>>> a. cmdtoargs.c will be pushed as a separate changeset using a
>>>>>>>> separate CR
>>>>>>>> and with contributor attribution to akhil.arora at oracle.com
>>>>>>>> 
>>>>>>>> b. src/solaris/bin/java_md.c is a redundant file and will be
>>>>>>>> removed,
>>>>>>>> webrev for whatever reason is not reporting it.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>> Kumar
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 



From kelly.ohair at oracle.com  Mon Jul 30 21:59:20 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 30 Jul 2012 14:59:20 -0700
Subject: Please review fix for 7146424: Wildcard expansion for single
	entry classpath
In-Reply-To: <5017000D.4060707@oracle.com>
References: <50128C8B.10603@oracle.COM> <5015ACAC.5030603@oracle.com>
	<50167EE8.10306@oracle.COM> <50168283.3060501@oracle.com>
	<5016EA7F.2050108@oracle.COM> <5016FA57.6090900@oracle.com>
	<5016FD81.2020008@oracle.COM> <5017000D.4060707@oracle.com>
Message-ID: <8D5FCEA4-ACDA-4BA8-9447-51264D48CBC2@oracle.com>


On Jul 30, 2012, at 2:43 PM, David Holmes wrote:

>> Ah!, oh sorry that won't fly this is c code :-( , not c++, MSC does not
>> allow it.
> 
> Wow that is unbelievable! for-loop variable declarations are part of C99 :(

Until recently we told the Solaris compilers to not allow any C99 features so we might catch
this kind of stuff more consistently.

Not sure what the status is with Visual Studio 2010 and C99 features.

-kto



From darryl.mocek at oracle.com  Mon Jul 30 22:27:52 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 30 Jul 2012 15:27:52 -0700
Subject: Code Review Request 7187876: ClassCastException in
	TCPTransport.executeAcceptLoop
Message-ID: <50170A68.1080508@oracle.com>

Hello core-libs.  Please review this webrev to fix Bug #7187876. Webrev 
can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.

The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test 
throws ClassCastException due to the Throwable not being of type Error 
in TCPTransport.

Thanks,
Darryl


From ahughes at redhat.com  Mon Jul 30 23:24:27 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 30 Jul 2012 19:24:27 -0400 (EDT)
Subject: [PATCH FOR REVIEW] System Zlib Support
In-Reply-To: <352694517.5561350.1343690236140.JavaMail.root@redhat.com>
Message-ID: <488466687.5562242.1343690667873.JavaMail.root@redhat.com>

Hi all,

In OpenJDK 8, some support has already been added for using the system installation of zlib
(see the thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html),
which is very similar to the support we've had in IcedTea for the last five years (wow, has
it really been that long?).

This is great news for us, as it's less work we have to do in upstreaming the patch (though
7 still needs to be dealt with).  As is, the following webrev:

http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/

just fixes a few minor issues to match our existing setup, and fixes a bug found when testing
the existing support.  In detail, the webrev:

* Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and $(ZLIB_CFLAGS), now set in
make_jdk_generic_profile.sh.
* Replaces "zlib.h" usage with <zlib.h> (mainly to reduce difference, searching '.' has no effect either way)
* Stops uLong being defined if SYSTEM_ZLIB is set, even if we're not on Mac OS X.  Without this fix, the build fails.

Ok for the build forest?  If so, can I please have a bug ID for this?

Thanks,  
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From david.holmes at oracle.com  Mon Jul 30 23:43:07 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jul 2012 09:43:07 +1000
Subject: Code Review Request 7187876: ClassCastException in
	TCPTransport.executeAcceptLoop
In-Reply-To: <50170A68.1080508@oracle.com>
References: <50170A68.1080508@oracle.com>
Message-ID: <50171C0B.4010401@oracle.com>

Hi Darryl,

On 31/07/2012 8:27 AM, Darryl Mocek wrote:
> Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev
> can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.
>
> The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test
> throws ClassCastException due to the Throwable not being of type Error
> in TCPTransport.

Just wondering what type it was? Something that extends Throwable directly?

This:

throw new Error(t.getMessage(), t.getCause());

loses the type of exception that was thrown. It is better to use:

throw new Error(t);

Cheers,
David

> Thanks,
> Darryl


From xueming.shen at oracle.com  Tue Jul 31 04:32:23 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 30 Jul 2012 21:32:23 -0700
Subject: Native zlib libraries
In-Reply-To: <1236740822.5028742.1343643614692.JavaMail.root@redhat.com>
References: <1236740822.5028742.1343643614692.JavaMail.root@redhat.com>
Message-ID: <50175FD7.1030500@oracle.com>


totalbytes_Read/Written are being tested though not the size > 4G. That 
test mainly tests
the > 64K entries and total size > 4G (lots of > 32-bit offsets...), but 
the total bytes read/
written are all < 4G (for each entry). An easy manual test I always do 
after run that test is to
jar the resulting > 6g file and unjar it. That will actually check the 
total bytes read/written
 > 4G case.

If you keep using the same JRE  which uses the system zlib, you might 
still be able to jar and
unjar a single > 4G file. The total bytes read/written are used as one 
of the validation in zip
format, ZipOutputStream writes these two number as size/csize fields of 
the loc and cen
table, the ZipInputStream then verifies these numbers when inflating. 
This round-trip happens
to work if the zos and zis both use the same JRE, in which both throw 
away the high bits of
the total numbers (but their low bits are still match) But a simple jar 
tvf tells you the size number
is incorrect. Also , if you jar some other files together with this > 4G 
file,  you probably will
get error when trying to extract individual entry file(s) out, as the 
position info of  those files
probably will get messed up.

Btw, the code to support > 4G total_in/out at java level is ready here, 
need some more tests
and the bugid for this one and yours.

http://cr.openjdk.java.net/~sherman/undozip/webrev/

-Sherman


On 7/30/12 3:20 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 07/27/2012 10:37 AM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> The zip64 support (total_in/out) part probably can be done at Java
>>>> level
>>>> (ignore
>>>> the total_in/out in z_tream_s).  Need to remove this dependency.
>>>> Will
>>>> take a look later.
>>>>
>>> Yes, it seems they still mention the size of total_in/out on the
>>> website on the zlib site, and that they shouldn't be relied on:
>>>
>>> http://www.zlib.net/zlib_faq.html#faq32
>>>
>>> "Note however that the strm.total_in and strm_total_out counters
>>> may be limited to 4 GB. These counters are provided as a
>>> convenience and are not used internally by inflate() or deflate().
>>> The application can easily set up its own counters updated after
>>> each call of inflate() or deflate() to count beyond 4 GB"
>>>
>>> "The word "may" appears several times above since there is a 4 GB
>>> limit only if the compiler's long type is 32 bits. If the
>>> compiler's long type is 64 bits, then the limit is 16 exabytes."
>>>
>>> I notice a test went in with the 64-bit support, but I assume it
>>> can't test these counters as the Deflater for a ZipStream is
>>> protected.  At least, they aren't failing on our builds with
>>> system zlib.
>> That test is not configured to be run for "auto testing", it just
>> takes
>> too long to zip/unzip
>> a 4G+ file. I use it manually to test the ZIP64 support.
>>
> Yes, sorry, I noticed this after posting.  I've since run it manually and it passes
> with a system zlib, both on the zip it creates and one I created containing just
> a single 4.2gb file (a RHEL ISO image zipped).  But I'm not sure if it's testing total bytes
> read for overflow.
>
>> I will give it a try to remove this dependency next week.
> Thanks.
>
>> It would be
>> helpful if you can
>> help "migrate" the icetea patch. How does the icetea patch work now?
>> Always use the
>> system zlib, if it presents? any configurable option to switch on and
>> off?
> It adds a switch and also support for setting the CFLAGS/LIBS:
>
>      USE_SYSTEM_ZLIB=true \
>      ZLIB_LIBS="$(pkg-config --libs zlib)" \
>      ZLIB_CFLAGS="$(pkg-config --cflags zlib)" \
>
> This is the same nomenclature we use for the other libraries too
> (lcms, jpeg, png, gif, cups, etc.)
>
> I'll try and post the patch later today.
>
>> -Sherman
>>
>>> Are you actively working on this now or shall I take a look?
>>>
>>>> -Sherman
>>>>
>>>> On 7/11/2012 12:47 AM, Alan Bateman wrote:
>>>>> On 05/07/2012 17:11, Andrew Hughes wrote:
>>>>>> ----- Original Message -----
>>>>>>> Is there a way to get the native zlib libraries to get picked
>>>>>>> up
>>>>>>> instead of the hardcoded version within the JVM?
>>>>>>>
>>>>>>> --
>>>>>>> Azeem Jiva
>>>>>>> @javawithjiva
>>>>>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
>>>>>> it
>>>>>> upstream.
>>>>>>
>>>>>> However, I don't see how this is related to HotSpot, as the zlib
>>>>>> usage
>>>>>> is in the jdk tree.
>>>>> I think we need to (re)start the discussion on core-libs-dev with
>>>>> a
>>>>> view to eliminating the patches that the JDK has to zlib, see:
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java
>>>>>
>>>>>
>>>>> One of these changes relates to the zip64 support and I believe
>>>>> there
>>>>> are corner cases when inflating or deflating>2GB that won't work
>>>>> if
>>>>> using the system zlib. Sherman will likely recall the details.
>>>>> Given
>>>>> that the new build already supports using the system zlib (at
>>>>> least
>>>>> on
>>>>> Linux) then it would be good to sort this out so that it just
>>>>> works.
>>>>>
>>>>> -Alan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>



From Alan.Bateman at oracle.com  Tue Jul 31 04:40:53 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Jul 2012 05:40:53 +0100
Subject: [PATCH FOR REVIEW] System Zlib Support
In-Reply-To: <488466687.5562242.1343690667873.JavaMail.root@redhat.com>
References: <488466687.5562242.1343690667873.JavaMail.root@redhat.com>
Message-ID: <501761D5.7000004@oracle.com>

On 31/07/2012 00:24, Andrew Hughes wrote:
> Ok for the build forest?
Once reviewed then I think jdk8/tl would be better as that's the route 
that the changes to the zip code take.

-Alan.


From ahughes at redhat.com  Tue Jul 31 17:41:25 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 31 Jul 2012 13:41:25 -0400 (EDT)
Subject: [PATCH FOR REVIEW] System Zlib Support
In-Reply-To: <501761D5.7000004@oracle.com>
Message-ID: <426656422.6284239.1343756485911.JavaMail.root@redhat.com>

----- Original Message -----
> On 31/07/2012 00:24, Andrew Hughes wrote:
> > Ok for the build forest?
> Once reviewed then I think jdk8/tl would be better as that's the
> route
> that the changes to the zip code take.
> 

Ok, no problem.  I just suggest build as most of the changes are to
the build machinery.

> -Alan.
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07