Re: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently

[Eric Wang]

Hi Stuart,

Thank you for help to publish the fix, my pleasure to contribute to 
OpenJDK project.


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

Re: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently

[Stuart Marks]

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

hg: jdk8/tl/corba: 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8

[sean . coffey]

Changeset: 47adb42076f1
Author:coffeys
Date:  2012-06-27 21:09 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/47adb42076f1

7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8
Reviewed-by: lancea

! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java
! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java
! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java
! 
src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java
! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java
! 
src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java
! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java
! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java
! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc
! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java
! 
src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java
! src/share/classes/com/sun/corba/se/spi/orb/ORB.java
! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java
! 
src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java
! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java
! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java

hg: jdk8/tl/jdk: 6893617: JDK 6 CNCtx always uses the default ORB

[sean . coffey]

Changeset: 612e56cf284c
Author:coffeys
Date:  2012-06-27 21:10 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/612e56cf284c

6893617: JDK 6 CNCtx always uses the default ORB
Reviewed-by: lancea

! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java

Re: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String

[Peter Levart]

Hi Mike,

Yes, all that you say below is true. CharSequence is an interface that does 
not define the contract of identity when implementations/subtypes of 
CharSequence do - each in it's own way. Much like java.util.Collection and 
List vs. Set. It's always dangerous for methods that return such interfaces 
when the implementation class of the returned instance changes so that it 
defines a different "hidden" contract.

It is unfortunately also true that now there is no "official" way of 
comparing/equating/hashing a substring without copying the characters. It 
feels like standard Java SE API is lacking a part of functionality.

Maybe this space could be filled with the addition of a new public immutable 
CharSequence subtype - like Rope: http://ahmadsoft.org/ropes/doc/index.html

Regards, Peter

 
On Friday, June 22, 2012 03:15:40 PM Mike Duigou wrote:
> I've made a test implementation of subSequence() utilizing an inner class
> with offset and count fields to try to understand all the parts that would
> be impacted. My observations thus far:
> 
> - The specification of the subSequence() method is currently too specific.
> It says that the result is a subString(). This would no longer be true.
> Hopefully nobody assumed that this meant they could cast the result to
> String. I know, why would you if you can just call subString() instead?
> I've learned to assume that somebody somewhere does always does the most
> unexpected thing. - The CharSequences returned by subSequence would follow
> only the general CharSequence rules for equals()/hashCode(). Any current
> usages of the result of subSequence for equals() or hashing, even though
> it's not advised, would break. We could add equals() and hashCode()
> implementations to the CharSequence returned but they would probably be
> expensive. - In general I wonder if parsers will be satisfied with a
> CharSequence that only implements identity equals(). - I also worry about
> applications that currently do use subSequence currently and which will
> fail when the result is not a String instance as String.equals() will
> return false for all CharSequences that aren't Strings. ie. CharSequence
> token = line.subSequence(line, start, end); if (keyword.equals(token)) ...
> This would now fail.
> 
> At this point I wonder if this is a feature worth pursuing.
> 
> Mike
> 
> On Jun 3 2012, at 13:44 , Peter Levart wrote:
> > On Thursday, May 31, 2012 03:22:35 AM mike.dui...@oracle.com wrote:
> >> Changeset: 2c773daa825d
> >> Author:mduigou
> >> Date:  2012-05-17 10:06 -0700
> >> URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d
> >> 
> >> 6924259: Remove offset and count fields from java.lang.String
> >> Summary: Removes the use of shared character array buffers by String
> >> along
> >> with the two fields needed to support the use of shared buffers.
> > 
> > Wow, that's quite a change.
> > 
> > So .substring() is not O(1) any more?
> > 
> > Doesn't this have impact on the performance of parsers and such that rely
> > on the performance caracteristics of the .substring() ?
> > 
> > Have you considered then implementing .subSequence() not in terms of just
> > delegating to .substring() but returning a special CharSequence view over
> > the chars of the sub-sequence?

Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

[Gregg Wonderly]

On Jun 26, 2012, at 10:02 AM, Alan Bateman wrote:
> 
> Do the tests assume they are run on HFS? Just wondering if you you need to 
> look at the FileStore name/type to check. 

TensComplement's ZFS port (ZEVO) to MacOSX may need some consideration if HFS 
is going to be the only test bed.

Gregg Wonderly

Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

[David Kocher]

Will this address issue MACOSX_PORT-165 [1]? 

[1] http://java.net/jira/browse/MACOSX_PORT-165

-- David

On 22.06.2012, at 19:01, Xueming Shen wrote:

> Hi
> 
> Here is the proposed change to support Unicode nfd/nfc and case insensitive
> file path on MacOSX file system.
> 
> 7130915: File.equals does not give expected results when path contains 
> Non-English characters on Mac OS X
> 7168427: FileInputStream cannot open file where the file path contains asian 
> characters [macosx]
> 
> While these two bug reports are only against java.io, we have the same issue 
> in javax.nio.file.
> Here is the webrev
> 
> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/
> 
> Here is the brief summary of the changes
> 
> java.io.File:
> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means
> we are now passing nfc/composite characters directly into macosx file 
> system APIs
> without  normalize them to nfd. It appears macosx fs APIs do take nfc, 
> though it uses
> nfd.
> 
> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd 
> before passing
> back to java.io.File (File.list() and canonicalize()), so we deal with 
> nfdc file name
> (as "usual")  for java.io classes/APIs.
> 
> (3) fs.compare()/hashCode() was updated to be case insensitive
> 
> (4) hasCode() was updated to use the new String.hash32().
> 
> java.nio.file:
> 
> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An 
> alternative is to
> update those BsdFile... classes directly to address the macosx specific 
> issues. But given
> there might be developers over there might work on open jdk BSD port and have 
> dependency
> on these classes, it might be desirable to have another separate layer of 
> MacOSXFile...
> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider 
> and
> MacOSXFileSystem.
> 
> (6)  the "main" changes are in MacOSXFileSystem, in which the corresponding 
> methods
> were added to handle, case insensitive and nfd<=>nfc normalization, including 
> the
> pathmatcher.
> 
> (7) compare is now are case-insensitive
> 
> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and 
> maxosx.
> 
> 
> Though lots of files have been touched, but the line of changes are actually 
> relatively
> small.
> 
> The proposed change only deals with the default case-sensitiveness seting, 
> which is
> case insensitive. On MaxOSX, you actually can configure the HFS+ file system 
> or the
> mounted vol to be case-sensitive. A possible approach is to have some extra 
> FileStore
> attributes, such as a isCaseSensitive and to use case sensitive compare/equal 
> on
> such fs, but this can be dealt with separately later.
> 
> Thanks,
> -Sherman
> 

Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

[David Kocher]

I welcome this issue is getting some serious attention then. When will this be 
backported to 7u?

-- David

On 24.06.2012, at 18:58, Xueming Shen wrote:

> 
> Yes, I believe the issue described in MACOSX_PORT-165 is the
> same issue this patch is trying to solve.
> 
> Btw, it appears there are typos in the note(2), my mini keyboard obviously
> is too sticky:-)
> 
> (2) normalize the resulting file name from macosx fs APIs from nfd->nfc 
> before passing
>back to java.io.File (File.list() and canonicalize()), so we deal with nfc 
> file name
>(as "usual")  for java.io classes/APIs.
> 
> -sherman
> 
> On 6/24/12 7:50 AM, David Kocher wrote:
>> Will this address issue MACOSX_PORT-165 [1]?
>> 
>> [1] http://java.net/jira/browse/MACOSX_PORT-165
>> 
>> -- David
>> 
>> On 22.06.2012, at 19:01, Xueming Shen wrote:
>> 
>>> Hi
>>> 
>>> Here is the proposed change to support Unicode nfd/nfc and case insensitive
>>> file path on MacOSX file system.
>>> 
>>> 7130915: File.equals does not give expected results when path contains 
>>> Non-English characters on Mac OS X
>>> 7168427: FileInputStream cannot open file where the file path contains 
>>> asian characters [macosx]
>>> 
>>> While these two bug reports are only against java.io, we have the same 
>>> issue in javax.nio.file.
>>> Here is the webrev
>>> 
>>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/
>>> 
>>> Here is the brief summary of the changes
>>> 
>>> java.io.File:
>>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which 
>>> means
>>> we are now passing nfc/composite characters directly into macosx file 
>>> system APIs
>>> without  normalize them to nfd. It appears macosx fs APIs do take nfc, 
>>> though it uses
>>> nfd.
>>> 
>>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd 
>>> before passing
>>> back to java.io.File (File.list() and canonicalize()), so we deal with 
>>> nfdc file name
>>> (as "usual")  for java.io classes/APIs.
>>> 
>>> (3) fs.compare()/hashCode() was updated to be case insensitive
>>> 
>>> (4) hasCode() was updated to use the new String.hash32().
>>> 
>>> java.nio.file:
>>> 
>>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An 
>>> alternative is to
>>> update those BsdFile... classes directly to address the macosx specific 
>>> issues. But given
>>> there might be developers over there might work on open jdk BSD port and 
>>> have dependency
>>> on these classes, it might be desirable to have another separate layer of 
>>> MacOSXFile...
>>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider 
>>> and
>>> MacOSXFileSystem.
>>> 
>>> (6)  the "main" changes are in MacOSXFileSystem, in which the corresponding 
>>> methods
>>> were added to handle, case insensitive and nfd<=>nfc normalization, 
>>> including the
>>> pathmatcher.
>>> 
>>> (7) compare is now are case-insensitive
>>> 
>>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux 
>>> and maxosx.
>>> 
>>> 
>>> Though lots of files have been touched, but the line of changes are 
>>> actually relatively
>>> small.
>>> 
>>> The proposed change only deals with the default case-sensitiveness seting, 
>>> which is
>>> case insensitive. On MaxOSX, you actually can configure the HFS+ file 
>>> system or the
>>> mounted vol to be case-sensitive. A possible approach is to have some extra 
>>> FileStore
>>> attributes, such as a isCaseSensitive and to use case sensitive 
>>> compare/equal on
>>> such fs, but this can be dealt with separately later.
>>> 
>>> Thanks,
>>> -Sherman
>>> 
> 
> 

Re: RFR : 7162902 / 6893617 Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8

[Lance Andersen - Oracle]

Hi Sean,

I think this looks good.  ship it :-)

Best
Lance
On Jun 25, 2012, at 4:26 PM, Sean Coffey wrote:

> Hi,
> 
> I'm looking for a code review around the following corba changes. It turns 
> out that we've a few bug fixes in corba area for jdk6 that were never forward 
> ported to jdk7 or 8. The port is pretty much identical to what was used in 
> JDK6. Some formatting and diamond operator changes introduced but that's 
> about it. There were a few bug fixes to follow up on regressions around the 
> initial fix but this umbrella port should cover all issues.
> 
> The initial bugs fixes were fixed under the "jets" category in the bug tool 
> and that category entered read only mode over a year ago. Hence the 
> requirement for a new bug ID.
> 
> The main bug fix is 6725987 which is an issue where references to the ORB 
> were being kept after ORB.destroy was called.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162902
> An accompanying CNCtx fix in JDK repo is also made to correct an issue where 
> the java.naming.corba.orb system property wasn't used correctly. (CR 6893617)
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6893617
> 
> Corba testsuites run and no issues seen. I've also run some JCK testing and 
> saw no issues.
> 
> http://cr.openjdk.java.net/~coffeys/webrev.7162902.jdk8/ (corba)
> http://cr.openjdk.java.net/~coffeys/webrev.6893617.jdk8/ (jdk)
> 
> The corba codebase code formatting seems to vary quite a bit. I've 
> reformatted in a small number of areas but the whole corba repo probably 
> warrants it's own clean up project at a later date.
> 
> regards,
> Sean.


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

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi all,

We've been working on improving the workflow for our patch review
system and so the new locations for the patches are at:

https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_text.patch
https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_util.patch

Cheers,
Martijn

On 27 June 2012 08:58, Martijn Verburg  wrote:
> Hi Kurchi,
>
>> Thanks for updating this. This looks good to me. I guess Stuart will be
>> sponsoring the patch.
>
> For his sins he's kindly offered to do so yes :-)
>
>> There are a couple of other switch statements in
>>  src/share/classes/java/util/regex/Pattern.java.
>> which are not throwing fallthrough warnings (in Netbeans at least),
>> although there is fallthrough happening from one case to another. From what
>> I notice, only if there is a break statement
>> missing before the "default" case, does Netbeans throw some warning. Is the
>> fallthrough warning technically
>> supposed to be thrown only when the logic falls through to the default case
>> then?
>
> That's my understanding with the javac compiler yes. I think it was the 
> balance
> that the javac folk thought was a sensible compromise in terms of not
> generating
> too many false positive warnings.
>
> Cheers,
> Martijn

Re: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently

[Eric Wang]

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
 which is same 
root

cause as bug 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

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi Kurchi,

> Thanks for updating this. This looks good to me. I guess Stuart will be
> sponsoring the patch.

For his sins he's kindly offered to do so yes :-)

> There are a couple of other switch statements in
>  src/share/classes/java/util/regex/Pattern.java.
> which are not throwing fallthrough warnings (in Netbeans at least),
> although there is fallthrough happening from one case to another. From what
> I notice, only if there is a break statement
> missing before the "default" case, does Netbeans throw some warning. Is the
> fallthrough warning technically
> supposed to be thrown only when the logic falls through to the default case
> then?

That's my understanding with the javac compiler yes. I think it was the balance
that the javac folk thought was a sensible compromise in terms of not
generating
too many false positive warnings.

Cheers,
Martijn

Re: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently

[David Holmes]

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
 which is same root
cause as bug 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

hg: jdk8/tl/jdk: 36 new changesets

[lana . steuck]

Changeset: 9d88f2ce6338
Author:katleman
Date:  2012-06-21 17:08 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d88f2ce6338

Added tag jdk8-b44 for changeset db471a7af031

! .hgtags

Changeset: eb50eeb2eb7d
Author:prr
Date:  2012-06-13 12:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb50eeb2eb7d

7027300: Unsynchronized HashMap access causes endless loop
Reviewed-by: bae, jgodinez

! src/share/classes/sun/font/SunLayoutEngine.java

Changeset: 5959fec806d8
Author:bae
Date:  2012-06-14 11:14 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5959fec806d8

7153693: Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* 
Unbreakable Kernel x64
Reviewed-by: jgodinez, prr

! src/share/native/sun/awt/image/jpeg/jpegdecoder.c

Changeset: 2aa89f018a2f
Author:prr
Date:  2012-06-14 16:34 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa89f018a2f

7158366: [macosx] Print-to-file dialog doesn't have an entry field for a name
Reviewed-by: bae, jgodinez

! src/share/classes/sun/print/ServiceDialog.java

Changeset: e42563f8ec12
Author:lana
Date:  2012-06-17 22:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e42563f8ec12

Merge

- makefiles/altclasses/Makefile
- makefiles/apple/Makefile
- makefiles/apple/applescript/Makefile
- makefiles/com/Makefile
- makefiles/com/apple/Makefile
- makefiles/com/apple/osx/Makefile
- makefiles/com/apple/osxui/Makefile
- makefiles/com/oracle/Makefile
- makefiles/com/oracle/jfr/Makefile
- makefiles/com/oracle/security/ucrypto/FILES_c.gmk
- makefiles/com/oracle/security/ucrypto/Makefile
- makefiles/com/oracle/security/ucrypto/mapfile-vers
- makefiles/com/sun/Makefile
- makefiles/common/shared/Defs-utils.gmk
- makefiles/java/fdlibm/FILES_c.gmk
- makefiles/java/fdlibm/Makefile
- makefiles/java/instrument/Makefile
- makefiles/java/instrument/mapfile-vers
- makefiles/java/java/Exportedfiles.gmk
- makefiles/java/java/FILES_c.gmk
- makefiles/java/java/FILES_java.gmk
- makefiles/java/java/Makefile
- makefiles/java/java/localelist.sh
- makefiles/java/java/mapfile-vers
- makefiles/java/java/reflect/Makefile
- makefiles/java/java/reorder-i586
- makefiles/java/java/reorder-sparc
- makefiles/java/java/reorder-sparcv9
- makefiles/java/java_crw_demo/Makefile
- makefiles/java/java_crw_demo/mapfile-vers
- makefiles/java/java_hprof_demo/Makefile
- makefiles/java/java_hprof_demo/mapfile-vers
- makefiles/java/jexec/Makefile
- makefiles/java/jli/Makefile
- makefiles/java/jli/mapfile-vers
- makefiles/java/jobjc/Makefile
- makefiles/java/jvm/Makefile
- makefiles/java/main/Makefile
- makefiles/java/main/java/Makefile
- makefiles/java/main/java/mapfile-amd64
- makefiles/java/main/java/mapfile-i586
- makefiles/java/main/java/mapfile-sparc
- makefiles/java/main/java/mapfile-sparcv9
- makefiles/java/main/javaw/Makefile
- makefiles/java/management/Exportedfiles.gmk
- makefiles/java/management/FILES_c.gmk
- makefiles/java/management/Makefile
- makefiles/java/management/mapfile-vers
- makefiles/java/net/FILES_c.gmk
- makefiles/java/net/Makefile
- makefiles/java/net/mapfile-vers
- makefiles/java/nio/Exportedfiles.gmk
- makefiles/java/nio/FILES_c.gmk
- makefiles/java/nio/FILES_java.gmk
- makefiles/java/nio/Makefile
- makefiles/java/nio/addNotices.sh
- makefiles/java/nio/genBuffer.sh
- makefiles/java/nio/genCharsetProvider.sh
- makefiles/java/nio/genCoder.sh
- makefiles/java/nio/genExceptions.sh
- makefiles/java/nio/mapfile-bsd
- makefiles/java/nio/mapfile-linux
- makefiles/java/nio/mapfile-solaris
- makefiles/java/nio/reorder-i586
- makefiles/java/nio/reorder-sparc
- makefiles/java/nio/reorder-sparcv9
- makefiles/java/npt/Makefile
- makefiles/java/npt/mapfile-vers
- makefiles/java/redist/fonts/Makefile
- makefiles/java/security/Makefile
- makefiles/java/sun_nio/FILES_java.gmk
- makefiles/java/sun_nio/Makefile
- makefiles/java/util/FILES_java.gmk
- makefiles/java/util/FILES_properties.gmk
- makefiles/java/util/Makefile
- makefiles/java/verify/Makefile
- makefiles/java/verify/mapfile-vers
- makefiles/java/verify/reorder-i586
- makefiles/java/verify/reorder-sparc
- makefiles/java/verify/reorder-sparcv9
- makefiles/javax/Makefile
- makefiles/javax/imageio/Makefile
- makefiles/javax/management/Makefile
- makefiles/javax/sound/FILES_c.gmk
- makefiles/javax/sound/Makefile
- makefiles/javax/sound/SoundDefs.gmk
- makefiles/javax/sound/jsoundalsa/Makefile
- makefiles/javax/sound/jsoundalsa/mapfile-vers
- makefiles/javax/sound/jsoundds/Makefile
- makefiles/javax/sound/mapfile-vers
- makefiles/javax/sql/Makefile
- makefiles/javax/swing/FILES.gmk
- makefiles/javax/swing/Makefile
- makefiles/javax/swing/beaninfo/FILES.gmk
- makefiles/javax/swing/beaninfo/Makefile
- makefiles/javax/swing/beaninfo/SwingBeans.gmk
- makefiles/javax/swing/beaninfo/manifest
- makefiles/javax/swing/html32dtd/Makefile
- makefiles/javax/swing/plaf/FILES.gmk
- makefiles/javax/swing/plaf/Makefile
- makefiles/sun/Makefile
- makefiles/sun/awt/Condens

hg: jdk8/tl/hotspot: 45 new changesets

[lana . steuck]

Changeset: 6e2633440960
Author:amurillo
Date:  2012-06-01 15:30 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e2633440960

7173438: new hotspot build - hs24-b14
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: fab99b17c1de
Author:mikael
Date:  2012-06-01 20:17 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fab99b17c1de

7155453: [macosx] re-enable jbb tests in JPRT
Summary: Run SPECjbb in headless mode and enable SPECjbb runs on OSX
Reviewed-by: dcubed, dholmes

! make/jprt.properties

Changeset: 4434fdad6b37
Author:dholmes
Date:  2012-06-02 07:32 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4434fdad6b37

Merge

! make/jprt.properties

Changeset: e17b61ba7bb3
Author:kamg
Date:  2012-06-04 10:22 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e17b61ba7bb3

7166498: JVM crash in ClassVerifier
Summary: Fixed raw pointer being used after potential safepoint/GC
Reviewed-by: acorn, fparain, dholmes

! src/share/vm/classfile/verifier.cpp

Changeset: a297b0e14605
Author:mgerdin
Date:  2012-06-04 09:21 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a297b0e14605

7172226: HotSpot fails to build with GCC 4.7 because of stricter c++ argument 
dependent lookup
Summary: Add "using" keyword to import base class functions from FreeList to 
fix template name lookup in gcc 4.7
Reviewed-by: brutisso, iveresov

! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp

Changeset: 37552638d24a
Author:brutisso
Date:  2012-06-05 22:30 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37552638d24a

7172388: G1: _total_full_collections should not be incremented for concurrent 
cycles
Reviewed-by: azeemj, jmasa

! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp

Changeset: b9442ac22f59
Author:brutisso
Date:  2012-06-04 13:29 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9442ac22f59

7173460: G1: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java 
failes with G1
Summary: The scope of TraceMemoryManagerStats in G1CollectedHeap need to cover 
the call to G1MonitoringSupport::update_sizes()
Reviewed-by: johnc, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 063451aefde8
Author:jcoomes
Date:  2012-06-08 09:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/063451aefde8

Merge


Changeset: 2fe087c3e814
Author:jiangli
Date:  2012-06-06 14:33 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fe087c3e814

7172967: Eliminate constMethod's _method backpointer to methodOop.
Summary: Eliminate constMethod's _method backpointer to methodOop, and move the 
_constant field from methodOop to constMethod.
Reviewed-by: roland, bdelsart, kamg

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/os/solaris/dtrace/libjvm_db.c
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constMethodOop.cpp
! src/share/vm/oops/constMethodOop.hpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ab6ab9f84b2d
Author:bdelsart
Date:  2012-06-11 04:47 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab6ab9f84b2d

Merge


Changeset: dcfcdd01af4b
Author:fparain
Date:  2012-06-05 06:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcfcdd01af4b

7171703: JNI DefineClass crashes client VM when first parameter is NULL
Reviewed-by: acorn, kamg, sspitsyn, dholmes

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

Changeset: de909f001528
Author:mikael
Date:  2012-06-06 05:21 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de909f001528

7170275: os::print_os_info needs to know about Windows 8
Summary: Recognize Windows 8 and Windows Server 2012
Reviewed-by: sla, kvn, azeemj

! src/os/windows/vm/os_windows.cpp

Changeset: 40b4aaf010e4
Author:dholmes
Date:  2012-06-08 02:06 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40b4aaf010e4

7172708: 32/64 bit type issues on Windows after Mac OS X port
Reviewed-by: dholmes, coleen

hg: jdk8/tl: 4 new changesets

[lana . steuck]

Changeset: 8fb4cd2f05a1
Author:mbykov
Date:  2012-06-19 14:24 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/8fb4cd2f05a1

7178241: Basic script for JDK source code legal headers conformance verification
Summary: A new script lic_check.sh to check license headers in JDK source code
Reviewed-by: ohair, darcy
Contributed-by: misha.by...@oracle.com

+ make/scripts/lic_check.sh

Changeset: e4f81a817447
Author:katleman
Date:  2012-06-20 15:22 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/e4f81a817447

Merge


Changeset: 1e989139ce0d
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/1e989139ce0d

Added tag jdk8-b44 for changeset e4f81a817447

! .hgtags

Changeset: 633f2378c904
Author:lana
Date:  2012-06-25 21:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/633f2378c904

Merge

hg: jdk8/tl/langtools: 2 new changesets

[lana . steuck]

Changeset: a39c99192184
Author:katleman
Date:  2012-06-21 17:08 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a39c99192184

Added tag jdk8-b44 for changeset 59cbead12ff4

! .hgtags

Changeset: e111e4587cca
Author:lana
Date:  2012-06-25 21:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e111e4587cca

Merge

- src/share/classes/com/sun/tools/javac/parser/EndPosTable.java

hg: jdk8/tl/corba: 9 new changesets

[lana . steuck]

Changeset: ad3ba4b392cc
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/ad3ba4b392cc

Added tag jdk8-b44 for changeset 439d9bf8e4ff

! .hgtags

Changeset: 5222b7d658d4
Author:coffeys
Date:  2012-03-26 14:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/5222b7d658d4

7143851: Improve IIOP stub and tie generation in RMIC
7149048: Changes to corba rmic stubGenerator class are not used during jdk 
build process
Reviewed-by: mschoene, robm

! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java

Changeset: e324dfb90c9e
Author:mbankal
Date:  2012-03-28 02:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/e324dfb90c9e

7079902: Refine CORBA data models
Reviewed-by: coffeys

! 
src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java
! 
src/share/classes/com/sun/corba/se/impl/interceptors/ServerRequestInfoImpl.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java
! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java
! src/share/classes/com/sun/corba/se/impl/oa/toa/TOAFactory.java
! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
! 
src/share/classes/com/sun/corba/se/impl/protocol/LocalClientRequestDispatcherBase.java
! src/share/classes/com/sun/corba/se/impl/util/RepositoryId.java
! src/share/classes/com/sun/corba/se/spi/logging/CORBALogDomains.java
! src/share/classes/sun/rmi/rmic/iiop/IDLNames.java

Changeset: 2846cb957582
Author:mbankal
Date:  2012-03-28 02:53 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/2846cb957582

Merge


Changeset: a00c5c0b1f30
Author:asaha
Date:  2012-04-10 10:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/a00c5c0b1f30

Merge

- make/tools/src/build/tools/stripproperties/StripProperties.java

Changeset: 3697feea6f54
Author:asaha
Date:  2012-05-08 07:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/3697feea6f54

Merge


Changeset: 787fb5a0602f
Author:asaha
Date:  2012-05-21 14:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/787fb5a0602f

Merge


Changeset: 25bb958d07de
Author:asaha
Date:  2012-06-07 12:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/25bb958d07de

Merge


Changeset: 747dad9e9d37
Author:lana
Date:  2012-06-26 10:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/747dad9e9d37

Merge

hg: jdk8/tl/jaxws: Added tag jdk8-b44 for changeset f6a417540ef1

[lana . steuck]

Changeset: e80ac58b5ba9
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e80ac58b5ba9

Added tag jdk8-b44 for changeset f6a417540ef1

! .hgtags

Re: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

[Xueming Shen]

Thanks Alan!

The webrev has been updated to throw OOME as your other nio native 
dispatcher does.


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

I can wait for your back from the vacation:-)

-Sherman


On 6/26/12 11:41 PM, Alan Bateman wrote:

On 27/06/2012 04:33, Xueming Shen wrote:

Alan,

Webrev has been updated accordingly at

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

with changes

(1) added a CFStringCreateMutable(...) != null check in both io and 
nio native, though it is
 unlikely  to fail here because we are passing a NULL and 0 
length, like new StringBuilder()
 invocation, if it fails the system probably goes very wrong. 
Both FStringAppendCharacters

 and CFStringNormalize are void return type.

(2) The first line of path.toCharArray in normalizeJavaPath is a 
typo, it is supposed to be
 deleted. The implementation only goes toCharArray when it needs 
to go native. Currently
 it uses >0x80 as the fast path criteria, it is possible to 
expose some sun.text.normalizer's
 internal methods to have a "quick nfc" check, but I'm not sure 
how much the performance

 gain would be, but might worth some investigation later.

(3) Comments have been added for those override-able methods in 
UnixFileSystem.


(4) blank lines have been removed from dispatcher.c

(5) I don't think we need to do the HFS check, given we are only 
doing nfc/nfd stuff now, as
 long as it is a MacOSX, I believe its nfc/nfd layer will be 
there. Copyright has been re-copy/

 pasted and we now only use only bugid.

-Sherman
I'm heading away on vacation now and only quickly scanned the updated 
webrev. All looks okay to me. On the calls to the CF functions then 
one thing is that if they fail (and this is unlikely I know) then you 
won't have an exception pending so may need to add code to call one of 
the JNU* functions to throw OOME, otherwise it might cause a NPE in 
the caller rather than throwing an exception as you would expect.


-Alan