Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi,

A release note would be a good idea to explain the change in behavior of 
SMART mode,

I added label "release-note=yes"

Regards, Roger

On 05/30/2019 09:50 AM, Roger Riggs wrote:

Hi,

The behavior is within the spec and seems more just like a bug in the 
implementation.

Also, an exception was thrown but it was for the wrong reason.

$.02, Roger


On 05/29/2019 06:55 PM, naoto.s...@oracle.com wrote:

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This 
is a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[naoto . sato]

Thanks, Roger.

On 5/30/19 6:55 AM, Roger Riggs wrote:

Hi Naoto,

This looks ok.
Typically, it is not necessary to check the exception message text.


I just wanted to make sure that the thrown DateTimeParseException is 
none other than the exception that is expected. There seems no other way 
to check that.


Naoto



Thanks, Roger

On 05/29/2019 05:21 PM, Lance Andersen wrote:

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are 
consistent with other tests.


No need to spin a webrev again though


Best
Lance

On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is 
a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

  
   

  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: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi Naoto,

This looks ok.
Typically, it is not necessary to check the exception message text.

Thanks, Roger

On 05/29/2019 05:21 PM, Lance Andersen wrote:

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are consistent 
with other tests.

No need to spin a webrev again though


Best
Lance

On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is apparently 
incorrect. Fixing it will change the behavior of parsing with SMART resolver 
style to throw a DateTimeParseException. This is a change in which an app will 
start to see an exception with incorrect data, but that is what should be in 
the first place.

Naoto

  
   

  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: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi,

The behavior is within the spec and seems more just like a bug in the 
implementation.

Also, an exception was thrown but it was for the wrong reason.

$.02, Roger


On 05/29/2019 06:55 PM, naoto.s...@oracle.com wrote:

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is 
a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Stephen Colebourne]

+1

On Wed, 29 May 2019, 22:13 ,  wrote:

> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8223773
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>
> Checking the range of HourOfAmPm with the range of AmPmOfDay is
> apparently incorrect. Fixing it will change the behavior of parsing with
> SMART resolver style to throw a DateTimeParseException. This is a change
> in which an app will start to see an exception with incorrect data, but
> that is what should be in the first place.
>
> Naoto
>

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[naoto . sato]

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is a 
change in which an app will start to see an exception with incorrect 
data, but that is what should be in the first place.


Naoto

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Joseph D. Darcy]

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is a 
change in which an app will start to see an exception with incorrect 
data, but that is what should be in the first place.


Naoto

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[naoto . sato]

Thanks, Lance.

Sure, will update the test case with @summary.

Naoto

On 5/29/19 2:21 PM, Lance Andersen wrote:

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are 
consistent with other tests.


No need to spin a webrev again though


Best
Lance
On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com 
 wrote:


Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is a 
change in which an app will start to see an exception with incorrect 
data, but that is what should be in the first place.


Naoto




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: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Lance Andersen]

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are consistent 
with other tests.

No need to spin a webrev again though


Best
Lance
> On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com wrote:
> 
> Hi,
> 
> Please review the fix for the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8223773
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
> 
> Checking the range of HourOfAmPm with the range of AmPmOfDay is apparently 
> incorrect. Fixing it will change the behavior of parsing with SMART resolver 
> style to throw a DateTimeParseException. This is a change in which an app 
> will start to see an exception with incorrect data, but that is what should 
> be in the first place.
> 
> Naoto

 
  

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

[13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[naoto . sato]

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing with 
SMART resolver style to throw a DateTimeParseException. This is a change 
in which an app will start to see an exception with incorrect data, but 
that is what should be in the first place.


Naoto