Re: RFR: JDK-8229750: Fix bad merge of JDK-8215447 patch

[Alexander Matveev]

Looks good.

On 8/14/2019 11:29 AM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- bad merge fix

[1] https://bugs.openjdk.java.net/browse/JDK-8229750

[2] http://cr.openjdk.java.net/~asemenyuk/8229750/webrev.00/

Thanks,
Alexey

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

[Frederic Parain]

Much cleaner!

Thumbs up!

Fred

> On Aug 14, 2019, at 15:42, Mandy Chung  wrote:
> 
> I have further discussion with Coleen and walkthrough the vframe 
> implementation.  Here is what we confirm and agree.
> 
> vframeStream::bci might return an invalid bci whereas javaVFrame::bci returns 
> a valid bci (compiledVFrame::bci adjusts invalid bci to 0).
> 
> An invalid bci could happen when hitting a safepoint on bci #0 on a 
> synchronized method either before or after the monitor is locked (implicit 
> synchronization without explicit monitorenter).   That might occur when 
> StackOverflowError is thrown for example.  However, that should never happen 
> when StackWalker is called and the top frame would be in the stack walking 
> code.
> 
> +1/-1 adjustment intends to address invalid bci case but such case is not 
> applicable for StackWalker API.  With that, I agree with Coleen that VM 
> should set the bci value to StackFrameInfo::bci field and no adjustment 
> needed:
>http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.05/
> 
> thanks
> Mandy
> 
> On 8/13/19 4:56 PM, coleen.phillim...@oracle.com wrote:
>> 
>> Hi, I saw my name in this thread and had a discussion with Mandy. I don't 
>> like that the VM and JDK having this special coordinated dance of +1/-1, and 
>> the reason for this is to differentiate the value of 0 in StackFrame meaning 
>> either uninitialized or invalid. If through some race, an unitialized value 
>> is observed, then the MemberName may not be filled in either.  In any case 
>> zero makes sense to return as the bci because it'll point to the line number 
>> beginning of the method, if used to get the line number.
>> 
>> The stackwalk API doesn't return invalid bci because it adjusts it:
>> 
>> int compiledVFrame::bci() const {
>>   int raw = raw_bci();
>>   return raw == SynchronizationEntryBCI ? 0 : raw;
>> }
>> 
>> At any rate, the 04 webrev looks good minus the +1/-1 dance and 
>> StackWalker.java comment.  Coupling the jdk and jvm like this feels like 
>> it's asking for bugs.  I like the simpler implementation that fixes the bug 
>> that we have.
>> 
>> Thanks,
>> Coleen
>> 
>> 
>> On 8/13/19 1:49 PM, Mandy Chung wrote:
>>> 
>>> 
>>> On 8/13/19 9:30 AM, Peter Levart wrote:
 Usually the StackFrameInfo(s) are consumed as soon as they are returned 
 from StackWalker API and never assigned to @Stable field. So there's no 
 purpose of @Stable for bci field use. Except documentation. But 
 documentation can be specified in the form of comments too.
 
>>> 
>>> There are several JDK classes whose fields are filled by VM and comment is 
>>> the form of documentation.  Until new use of StackFrame in the future shows 
>>> performance benefit, it's okay to stick with @Stable original intent and 
>>> keep the comment:
>>> 
>>> +private int bci;// zero and negative values 
>>> represent invalid BCI
>>> 
>>> Please also review CSR:
>>>https://bugs.openjdk.java.net/browse/JDK-8229487
>>> 
>>> Mandy
>> 
> 

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

[coleen . phillimore]

On 8/14/19 3:42 PM, Mandy Chung wrote:
I have further discussion with Coleen and walkthrough the vframe 
implementation.  Here is what we confirm and agree.


vframeStream::bci might return an invalid bci whereas javaVFrame::bci 
returns a valid bci (compiledVFrame::bci adjusts invalid bci to 0).


An invalid bci could happen when hitting a safepoint on bci #0 on a 
synchronized method either before or after the monitor is locked 
(implicit synchronization without explicit monitorenter).   That might 
occur when StackOverflowError is thrown for example. However, that 
should never happen when StackWalker is called and the top frame would 
be in the stack walking code.


+1/-1 adjustment intends to address invalid bci case but such case is 
not applicable for StackWalker API.  With that, I agree with Coleen 
that VM should set the bci value to StackFrameInfo::bci field and no 
adjustment needed:

   http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.05/


This looks good and straighforward.
Thank you!
Coleen



thanks
Mandy

On 8/13/19 4:56 PM, coleen.phillim...@oracle.com wrote:


Hi, I saw my name in this thread and had a discussion with Mandy. I 
don't like that the VM and JDK having this special coordinated dance 
of +1/-1, and the reason for this is to differentiate the value of 0 
in StackFrame meaning either uninitialized or invalid. If through 
some race, an unitialized value is observed, then the MemberName may 
not be filled in either.  In any case zero makes sense to return as 
the bci because it'll point to the line number beginning of the 
method, if used to get the line number.


The stackwalk API doesn't return invalid bci because it adjusts it:

int compiledVFrame::bci() const {
  int raw = raw_bci();
  return raw == SynchronizationEntryBCI ? 0 : raw;
}

At any rate, the 04 webrev looks good minus the +1/-1 dance and 
StackWalker.java comment.  Coupling the jdk and jvm like this feels 
like it's asking for bugs.  I like the simpler implementation that 
fixes the bug that we have.


Thanks,
Coleen


On 8/13/19 1:49 PM, Mandy Chung wrote:



On 8/13/19 9:30 AM, Peter Levart wrote:
Usually the StackFrameInfo(s) are consumed as soon as they are 
returned from StackWalker API and never assigned to @Stable field. 
So there's no purpose of @Stable for bci field use. Except 
documentation. But documentation can be specified in the form of 
comments too.




There are several JDK classes whose fields are filled by VM and 
comment is the form of documentation.  Until new use of StackFrame 
in the future shows performance benefit, it's okay to stick with 
@Stable original intent and keep the comment:


+    private int bci;    // zero and negative values 
represent invalid BCI


Please also review CSR:
   https://bugs.openjdk.java.net/browse/JDK-8229487

Mandy

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Roger Riggs]

Hi,

In the CSR, please include *only* the specification of the API.
Do not include the implementation or tests.
The specification text has to stand on it own merits.
Copy/paste patches are ok but the particular diff context information is 
unnecessary noise.


Thanks, Roger


On 8/14/19 3:21 PM, Daniel Fuchs wrote:

Hi Joe,

On 14/08/2019 20:15, Joe Wang wrote:

The 2nd part is not necessary as that's what the "@throws" tag is for.


Not withstanding the fact that this is a copy of the API doc from
java.lang.Math, I'd argue that the second part is quite important.
It's why the method is called exact, and is probably the only
reason why you would call that method in the first place.
So I think the 2nd part must be in the synopsis too.

best regards,

-- daniel

On 8/14/19 9:01 AM, Julia Boes wrote:
>
> Hi,
>
> This fix adds decrementExact(), incrementExact(), and negateExact() 
to java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229485
>
> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8229702
>
> Thanks,
>
> Julia
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8022109

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

[Mandy Chung]

I have further discussion with Coleen and walkthrough the vframe 
implementation.  Here is what we confirm and agree.


vframeStream::bci might return an invalid bci whereas javaVFrame::bci 
returns a valid bci (compiledVFrame::bci adjusts invalid bci to 0).


An invalid bci could happen when hitting a safepoint on bci #0 on a 
synchronized method either before or after the monitor is locked 
(implicit synchronization without explicit monitorenter).   That might 
occur when StackOverflowError is thrown for example.  However, that 
should never happen when StackWalker is called and the top frame would 
be in the stack walking code.


+1/-1 adjustment intends to address invalid bci case but such case is 
not applicable for StackWalker API.  With that, I agree with Coleen that 
VM should set the bci value to StackFrameInfo::bci field and no 
adjustment needed:

   http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.05/

thanks
Mandy

On 8/13/19 4:56 PM, coleen.phillim...@oracle.com wrote:


Hi, I saw my name in this thread and had a discussion with Mandy. I 
don't like that the VM and JDK having this special coordinated dance 
of +1/-1, and the reason for this is to differentiate the value of 0 
in StackFrame meaning either uninitialized or invalid. If through some 
race, an unitialized value is observed, then the MemberName may not be 
filled in either.  In any case zero makes sense to return as the bci 
because it'll point to the line number beginning of the method, if 
used to get the line number.


The stackwalk API doesn't return invalid bci because it adjusts it:

int compiledVFrame::bci() const {
  int raw = raw_bci();
  return raw == SynchronizationEntryBCI ? 0 : raw;
}

At any rate, the 04 webrev looks good minus the +1/-1 dance and 
StackWalker.java comment.  Coupling the jdk and jvm like this feels 
like it's asking for bugs.  I like the simpler implementation that 
fixes the bug that we have.


Thanks,
Coleen


On 8/13/19 1:49 PM, Mandy Chung wrote:



On 8/13/19 9:30 AM, Peter Levart wrote:
Usually the StackFrameInfo(s) are consumed as soon as they are 
returned from StackWalker API and never assigned to @Stable field. 
So there's no purpose of @Stable for bci field use. Except 
documentation. But documentation can be specified in the form of 
comments too.




There are several JDK classes whose fields are filled by VM and 
comment is the form of documentation.  Until new use of StackFrame in 
the future shows performance benefit, it's okay to stick with @Stable 
original intent and keep the comment:


+    private int bci;    // zero and negative values 
represent invalid BCI


Please also review CSR:
   https://bugs.openjdk.java.net/browse/JDK-8229487

Mandy

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Joe Wang]

Hi Daniel,

That makes sense. So it meant to say "converts the long to int only if 
it's within the range of an integer" (to be "exact"). It may then add 
"throws an exception if not". But the original is fine, just my 2 cents.


Best,
Joe

On 8/14/19 12:21 PM, Daniel Fuchs wrote:

Hi Joe,

On 14/08/2019 20:15, Joe Wang wrote:

The 2nd part is not necessary as that's what the "@throws" tag is for.


Not withstanding the fact that this is a copy of the API doc from
java.lang.Math, I'd argue that the second part is quite important.
It's why the method is called exact, and is probably the only
reason why you would call that method in the first place.
So I think the 2nd part must be in the synopsis too.

best regards,

-- daniel

On 8/14/19 9:01 AM, Julia Boes wrote:
>
> Hi,
>
> This fix adds decrementExact(), incrementExact(), and negateExact() 
to java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229485
>
> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8229702
>
> Thanks,
>
> Julia
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8022109

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Daniel Fuchs]

Hi Joe,

On 14/08/2019 20:15, Joe Wang wrote:

The 2nd part is not necessary as that's what the "@throws" tag is for.


Not withstanding the fact that this is a copy of the API doc from
java.lang.Math, I'd argue that the second part is quite important.
It's why the method is called exact, and is probably the only
reason why you would call that method in the first place.
So I think the 2nd part must be in the synopsis too.

best regards,

-- daniel

On 8/14/19 9:01 AM, Julia Boes wrote:
>
> Hi,
>
> This fix adds decrementExact(), incrementExact(), and negateExact() 
to java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229485
>
> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8229702
>
> Thanks,
>
> Julia
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8022109

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Joe Wang]

while you're here, could you please replace semicolon with comma:
 916  * Returns the value of the {@code long} argument;
 917  * throwing an exception if the value overflows an {@code int}.


It seems to me the first sentence shall be the synopsis. The 2nd part is 
not necessary as that's what the "@throws" tag is for. If it has to be 
there, should it be "throws" instead of "throwing" (I'm not a native 
speaker :-) )


Cheers,
Joe



With kind regards,
Ivan


On 8/14/19 9:01 AM, Julia Boes wrote:


Hi,

This fix adds decrementExact(), incrementExact(), and negateExact() 
to java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.


Bug: https://bugs.openjdk.java.net/browse/JDK-8229485

Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/

CSR: https://bugs.openjdk.java.net/browse/JDK-8229702

Thanks,

Julia

[1] https://bugs.openjdk.java.net/browse/JDK-8022109

Re: RFR 8184432: Remove references to j...@sun.com from javax.sql.rowset.spi.SyncProvider

[Lance Andersen]

Hi Iris,


Jon Gibbons reported the issue as part of some of his many clean-up activities 
to improve the javadocs

Best,
Lance.


> On Aug 14, 2019, at 3:03 PM, Iris Clark  wrote:
> 
> HI, Lance.
> 
> Looks good.
> 
> I'm curious.  How did you find this?
> 
> iris
> 
> -Original Message-
> From: Lance Andersen 
> Sent: Wednesday, August 14, 2019 7:34 AM
> To: core-libs-dev 
> Subject: RFR 8184432: Remove references to j...@sun.com from 
> javax.sql.rowset.spi.SyncProvider
> 
> Hi,
> 
> Please review this trivial patch which removes references to j...@sun.com 
>  and  mention of a list of available SyncProviders which 
> does not exist.
> 
> 
> $ hg diff
> diff -r cffcc4c5a5ba 
> src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java
> --- 
> a/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
> Wed Aug 07 14:04:10 2019 -0400
> +++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvide
> +++ r.java  Wed Aug 14 10:28:54 2019 -0400
> @@ -90,13 +90,6 @@
>  * com.sun.rowset.providers.RIOptimisticProvider
>  * 
>  * 
> - * A vendor can register a SyncProvider implementation class 
> name
> - * with Oracle Corporation by sending email to j...@sun.com.
> - * Oracle will maintain a database listing the
> - * available SyncProvider implementations for use with compliant
> - * RowSet implementations.  This database will be similar to the
> - * one already maintained to list available JDBC drivers.
> - * 
>  * Vendors should refer to the reference implementation synchronization
>  * providers for additional guidance on how to implement a new
>  * SyncProvider implementation.
> $
> —
> 
> Best
> Lance
> 
>  
> 
> Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
> 
> 
> 

 
  

 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: RFR 8184432: Remove references to j...@sun.com from javax.sql.rowset.spi.SyncProvider

[Iris Clark]

HI, Lance.

Looks good.

I'm curious.  How did you find this?

iris

-Original Message-
From: Lance Andersen 
Sent: Wednesday, August 14, 2019 7:34 AM
To: core-libs-dev 
Subject: RFR 8184432: Remove references to j...@sun.com from 
javax.sql.rowset.spi.SyncProvider

Hi,

Please review this trivial patch which removes references to j...@sun.com 
 and  mention of a list of available SyncProviders which 
does not exist.


$ hg diff
diff -r cffcc4c5a5ba 
src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java
--- a/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
Wed Aug 07 14:04:10 2019 -0400
+++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvide
+++ r.java  Wed Aug 14 10:28:54 2019 -0400
@@ -90,13 +90,6 @@
  * com.sun.rowset.providers.RIOptimisticProvider
  * 
  * 
- * A vendor can register a SyncProvider implementation class name
- * with Oracle Corporation by sending email to j...@sun.com.
- * Oracle will maintain a database listing the
- * available SyncProvider implementations for use with compliant
- * RowSet implementations.  This database will be similar to the
- * one already maintained to list available JDBC drivers.
- * 
  * Vendors should refer to the reference implementation synchronization
  * providers for additional guidance on how to implement a new
  * SyncProvider implementation.
$
—

Best
Lance
 
  

 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: RFR: JDK-8229750: Fix bad merge of JDK-8215447 patch

[Andy Herrick]

looks good

/Andy

On 8/14/19 2:29 PM, Alexey Semenyuk wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- bad merge fix

[1] https://bugs.openjdk.java.net/browse/JDK-8229750

[2] http://cr.openjdk.java.net/~asemenyuk/8229750/webrev.00/

Thanks,
Alexey

RFR: JDK-8229750: Fix bad merge of JDK-8215447 patch

[Alexey Semenyuk]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- bad merge fix

[1] https://bugs.openjdk.java.net/browse/JDK-8229750

[2] http://cr.openjdk.java.net/~asemenyuk/8229750/webrev.00/

Thanks,
Alexey

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Ivan Gerasimov]

A tiny addition:

On 8/14/19 10:56 AM, Ivan Gerasimov wrote:

Hi Julia!

In ExactArithTests.java
1)
169 long neg2 = -((long)x) ;
please remove the superfluous space at the end.

2)
176 long neg2 = (long) x - 1L;
should be `long neg2 = -((long)x);`

In StrictMath.java
3)

while you're here, could you please replace semicolon with comma:
 916  * Returns the value of the {@code long} argument;
 917  * throwing an exception if the value overflows an {@code int}.



In src/java.base/share/classes/java/lang/Math.java
4)

at line 1061
 * Returns the value of the {@code long} argument;
 * throwing an exception if the value overflows an {@code int}.

analogously to (3) above, could you please s/;/,/ ?

Thanks!



With kind regards,
Ivan


On 8/14/19 9:01 AM, Julia Boes wrote:


Hi,

This fix adds decrementExact(), incrementExact(), and negateExact() 
to java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.


Bug: https://bugs.openjdk.java.net/browse/JDK-8229485

Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/

CSR: https://bugs.openjdk.java.net/browse/JDK-8229702

Thanks,

Julia

[1] https://bugs.openjdk.java.net/browse/JDK-8022109



--
With kind regards,
Ivan Gerasimov

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Ivan Gerasimov]

Hi Julia!

In ExactArithTests.java
1)
169 long neg2 = -((long)x) ;
please remove the superfluous space at the end.

2)
176 long neg2 = (long) x - 1L;
should be `long neg2 = -((long)x);`

In StrictMath.java
3)

while you're here, could you please replace semicolon with comma:
 916  * Returns the value of the {@code long} argument;
 917  * throwing an exception if the value overflows an {@code int}.

With kind regards,
Ivan


On 8/14/19 9:01 AM, Julia Boes wrote:


Hi,

This fix adds decrementExact(), incrementExact(), and negateExact() to 
java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.


Bug: https://bugs.openjdk.java.net/browse/JDK-8229485

Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/

CSR: https://bugs.openjdk.java.net/browse/JDK-8229702

Thanks,

Julia

[1] https://bugs.openjdk.java.net/browse/JDK-8022109



--
With kind regards,
Ivan Gerasimov

Re: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Lance Andersen]

Hi Julia, Brian
> On Aug 14, 2019, at 12:08 PM, Brian Burkhalter  
> wrote:
> 
> Hi Julia,
> 
> I think you need “@since 14” on the new StrictMath methods
Yes, as these are new methods to this class the above would be correct vs 1.8

> . I don’t see any other problems.

Looks OK to me

For the CSR

Compatibility Risk Assessment

—
New public static methods are added to java.lang.StrictMath, which is a class 
that can't be instantiated. The compatibility risk should be minimal.
——

There are new methods, so there is no compatibility risk.

You might change to something similar as:

_—
There is no compatibility risk as this proposal adds new static methods to 
java.lang.StrictMath
———

For the specification, you may want to consider including the specdiff as an 
attachment, or what I do in some cases given it is a small  set of additions, 
just paste the javadoc in the spec section.

HTH

Lance
> 
> Thanks,
> 
> Brian
> 
>> On Aug 14, 2019, at 9:01 AM, Julia Boes  wrote:
>> 
>> This fix adds decrementExact(), incrementExact(), and negateExact() to 
>> java.lang.StrictMath. The methods were added to java.lang.Math previously 
>> [1] and should have been added to java.lang.StrictMath for consistency.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229485 
>> 
>> 
>> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/ 
>> 
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8229702 
>> 

 
  

 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: RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Brian Burkhalter]

Hi Julia,

I think you need “@since 14” on the new StrictMath methods. I don’t see any 
other problems.

Thanks,

Brian

> On Aug 14, 2019, at 9:01 AM, Julia Boes  wrote:
> 
> This fix adds decrementExact(), incrementExact(), and negateExact() to 
> java.lang.StrictMath. The methods were added to java.lang.Math previously [1] 
> and should have been added to java.lang.StrictMath for consistency.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229485 
> 
> 
> Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/ 
> 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8229702 
> 

RFR: 8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath

[Julia Boes]

Hi,

This fix adds decrementExact(), incrementExact(), and negateExact() to 
java.lang.StrictMath. The methods were added to java.lang.Math 
previously [1] and should have been added to java.lang.StrictMath for 
consistency.


Bug: https://bugs.openjdk.java.net/browse/JDK-8229485

Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8229485/webrev.01/

CSR: https://bugs.openjdk.java.net/browse/JDK-8229702

Thanks,

Julia

[1] https://bugs.openjdk.java.net/browse/JDK-8022109

Re: RFR 8184432: Remove references to j...@sun.com from javax.sql.rowset.spi.SyncProvider

[Roger Riggs]

+1

On 8/14/19 10:33 AM, Lance Andersen wrote:

Hi,

Please review this trivial patch which removes references to j...@sun.com 
 and  mention of a list of available SyncProviders which 
does not exist.


$ hg diff
diff -r cffcc4c5a5ba 
src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java
--- a/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
Wed Aug 07 14:04:10 2019 -0400
+++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
Wed Aug 14 10:28:54 2019 -0400
@@ -90,13 +90,6 @@
   * com.sun.rowset.providers.RIOptimisticProvider
   * 
   * 
- * A vendor can register a SyncProvider implementation class name
- * with Oracle Corporation by sending email to j...@sun.com.
- * Oracle will maintain a database listing the
- * available SyncProvider implementations for use with compliant
- * RowSet implementations.  This database will be similar to the
- * one already maintained to list available JDBC drivers.
- * 
   * Vendors should refer to the reference implementation synchronization
   * providers for additional guidance on how to implement a new
   * SyncProvider implementation.
$
—

Best
Lance
  
   

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

RFR 8184432: Remove references to j...@sun.com from javax.sql.rowset.spi.SyncProvider

[Lance Andersen]

Hi,

Please review this trivial patch which removes references to j...@sun.com 
 and  mention of a list of available SyncProviders which 
does not exist.


$ hg diff
diff -r cffcc4c5a5ba 
src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java
--- a/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
Wed Aug 07 14:04:10 2019 -0400
+++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java  
Wed Aug 14 10:28:54 2019 -0400
@@ -90,13 +90,6 @@
  * com.sun.rowset.providers.RIOptimisticProvider
  * 
  * 
- * A vendor can register a SyncProvider implementation class name
- * with Oracle Corporation by sending email to j...@sun.com.
- * Oracle will maintain a database listing the
- * available SyncProvider implementations for use with compliant
- * RowSet implementations.  This database will be similar to the
- * one already maintained to list available JDBC drivers.
- * 
  * Vendors should refer to the reference implementation synchronization
  * providers for additional guidance on how to implement a new
  * SyncProvider implementation.
$
—

Best
Lance
 
  

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