Martijn Verburg | 1 Jul 13:05 2012
Picon

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

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
(Continue reading)

David Holmes | 2 Jul 02:39 2012
Picon

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

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
(Continue reading)

Deven You | 2 Jul 11:04 2012
Picon

Re: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream

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.
>
(Continue reading)

Lance Andersen - Oracle | 2 Jul 12:25 2012
Picon

Re: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream

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.
>> 
(Continue reading)

Anthony Petrov | 2 Jul 16:33 2012
Picon

Re: [8] Review request for 7162111 change tests run in headless mode [macosx]

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
>>>>
(Continue reading)

rob.mckenna | 2 Jul 20:31 2012
Picon

hg: jdk8/tl/jdk: 7174887: Deadlock in jndi ldap connection cleanup

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

Stuart Marks | 2 Jul 23:08 2012
Picon

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

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

(Continue reading)

stuart.marks | 2 Jul 23:33 2012
Picon

hg: jdk8/tl/jdk: 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip

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

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

Stuart Marks | 2 Jul 23:55 2012
Picon

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

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
(Continue reading)

David Holmes | 3 Jul 04:38 2012
Picon

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

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.

(Continue reading)


Gmane