RFR: Release note for 8164705: Remove pathname canonicalization from FilePermission

[Weijun Wang]

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

I added more words, please take another look.

Thanks
Max

On 9/13/2016 2:13, Brian Burkhalter wrote:

Only picky comments: not sure but maybe change:

1) vice versa -> and vice versa
2) When it’s set to true -> When true
3) just like before -> as before

Brian

On Sep 12, 2016, at 12:23 AM, Weijun Wang > wrote:


BTW, please also review the release note at

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

Thanks
Max

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

[Brent Christian]

On 10/10/16 3:51 PM, Mandy Chung wrote:


Do you mind fixing @return in the registerAsParallelCapable method
with {@code true} amd {@code false} since you are in this method.  No
need for a new webrev.



Sure, no problem.

Thanks,
-Brent

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

[Mandy Chung]

> On Oct 10, 2016, at 3:44 PM, Brent Christian  
> wrote:
> 
> Thanks for having a look, and for the suggestions.  I also added an @see 
> #isParallelCapable in registerAsParallelCapable().
> 
> Webrev updated in place:
> http://cr.openjdk.java.net/~bchristi/8165793/webrev.00/
> 

+1

Do you mind fixing @return in the registerAsParallelCapable method with {@code 
true} amd {@code false} since you are in this method.  No need for a new webrev.

thanks
Mandy

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

[Brent Christian]

On 10/10/16 2:30 PM, Mandy Chung wrote:


The patch looks fine.  It would be good to add @see
#registerAsParallelCapable in this new method.  Also the first
“parallel capable” occurrance in the class spec and the
registerAsParallelCapable method spec to @linkplain
#isParallelCapable.


Thanks for having a look, and for the suggestions.  I also added an @see 
#isParallelCapable in registerAsParallelCapable().


Webrev updated in place:
http://cr.openjdk.java.net/~bchristi/8165793/webrev.00/

-Brent

Re: RFR: 8166460: jdk/internal/util/jar/TestVersionedStream gets Assertion error

[Paul Sandoz]

> On 10 Oct 2016, at 14:50, Steve Drach  wrote:
> 
> As a consequence of some conversations about this test, I’ve removed the part 
> that specifically depended on the order of the entries and now just verify 
> that the order of the versioned entries is the same relative order as all the 
> entries in the jar file.   The updated changeset is 
> http://cr.openjdk.java.net/~sdrach/8166460/webrev.03/ 
> 
> 

This looks better (crossing fingers JPRT passes).

Thanks,
Paul.

>> On Oct 5, 2016, at 12:27 PM, Steve Drach  wrote:
>> 
>> Hi,
>> 
>> Please review the following changeset that creates a replacement for the 
>> TestVersionedStream test.  The previous test occasionally failed on Linux 
>> hotspot nightly testing due to jar tool sometimes changing the order of the 
>> entries.  The new test specifically sets the order of the entries and tests 
>> both possible orders.
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8166460 
>> 
>> webrev: http://cr.openjdk.java.net/~sdrach/8166460/webrev.00/ 
>> 
>> 
>> Thanks,
>> Steve
>> 
> 

Re: RFR: 8166460: jdk/internal/util/jar/TestVersionedStream gets Assertion error

[Steve Drach]

As a consequence of some conversations about this test, I’ve removed the part 
that specifically depended on the order of the entries and now just verify that 
the order of the versioned entries is the same relative order as all the 
entries in the jar file.   The updated changeset is 
http://cr.openjdk.java.net/~sdrach/8166460/webrev.03/ 


> On Oct 5, 2016, at 12:27 PM, Steve Drach  wrote:
> 
> Hi,
> 
> Please review the following changeset that creates a replacement for the 
> TestVersionedStream test.  The previous test occasionally failed on Linux 
> hotspot nightly testing due to jar tool sometimes changing the order of the 
> entries.  The new test specifically sets the order of the entries and tests 
> both possible orders.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8166460 
> 
> webrev: http://cr.openjdk.java.net/~sdrach/8166460/webrev.00/ 
> 
> 
> Thanks,
> Steve
> 

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

[Mandy Chung]

> On Oct 10, 2016, at 1:36 PM, Brent Christian  
> wrote:
> 
> Hi,
> 
> Please review my fix for 8165793.  This follows the discussion here:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009328.html
> 
> The proposal is to add a new public method on ClassLoader:
> 
> /**
> * Returns {@code true} if this class loader is
> * {@linkplain #registerAsParallelCapable parallel capable}, otherwise
> * {@code false}.
> *
> * @return  {@code true} if this class loader is parallel capable,
> *  otherwise {@code false}.
> * @since   9
> */
> public final boolean isParallelCapable();

The patch looks fine.  It would be good to add @see #registerAsParallelCapable 
in this new method.  Also the first “parallel capable” occurrance in the class 
spec and the registerAsParallelCapable method spec to @linkplain 
#isParallelCapable.

Mandy

RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

[Brent Christian]

Hi,

Please review my fix for 8165793.  This follows the discussion here:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009328.html

The proposal is to add a new public method on ClassLoader:

/**
 * Returns {@code true} if this class loader is
 * {@linkplain #registerAsParallelCapable parallel capable}, otherwise
 * {@code false}.
 *
 * @return  {@code true} if this class loader is parallel capable,
 *  otherwise {@code false}.
 * @since   9
 */
public final boolean isParallelCapable();

Bug:
https://bugs.openjdk.java.net/browse/JDK-8165793
Webrev:
http://cr.openjdk.java.net/~bchristi/8165793/webrev.00/

Thanks!

-Brent

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

[Stuart Marks]

OK, I'll sponsor this. I need to run this through our internal testing system 
before pushing it. I'll follow up here with results.


s'marks


On 10/10/16 1:34 AM, Jonathan Bluett-Duncan wrote:

Hi all,

Would you kindly review the latest webrev now?

http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02 



Thanks in advance.

Kind regards,
Jonathan

On 7 October 2016 at 21:59, Patrick Reinhart > wrote:


Here is the latest webrev:

http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02


-Patrick



> Am 07.10.2016 um 12:00 schrieb Jonathan Bluett-Duncan
>:
>
> Hi all,
>
> Sorry for the delayed response, I've been busy lately with university
and other things.
>
> Thank you all for your comments. I'll leave the DateTimeFormatter
comment in, as you requested Stephen and Roger, and I'll work again with
Patrick as soon as I'm ready.
>
> Kind regards,
> Jonathan
>
> On 6 October 2016 at 09:38, Stephen Colebourne > wrote:
> On 6 October 2016 at 00:00, Stuart Marks > wrote:
> >> I think you should perform no change to DateTimeFormatter (other than
> >> a comment) as part of this changeset. The behaviour of that
> >> DateTimeFormatter method is subtle, and I now suspect that what we
> >> have there might be the best option.
> >
> > I had recommended removing the comment from DateTimeFormatter, but if
> > Stephen wants the comment in, that's fine with me. In fact I'll defer to
> > what Stephen (and Roger Riggs) want with this code, since they're the
> > maintainers.
>
> I think it makes sense to leave the new comment in. All further change
> should be under 8167222.
>
> Stephen
>

Re: RFR: 8062389,8029459,8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

[Martin Buchholz]

Does core reflection have an active maintainer?  Or is Peter that
maintainer?

On Mon, Oct 10, 2016 at 1:04 AM, Peter Levart 
wrote:

> Just a note that this is still ready to be reviewed.
>
> I was also told that JCK tests pass with the patch applied.
>
> Regards, Peter
>
>
> On 10/04/2016 03:40 PM, Peter Levart wrote:
>
>> Hi,
>>
>> I have a fix for conformance (P2) bug (8062389 <
>> https://bugs.openjdk.java.net/browse/JDK-8062389>) that also fixes a
>> conformance (P3) bug (8029459 > /browse/JDK-8029459>) and a performance issue (8061950 <
>> https://bugs.openjdk.java.net/browse/JDK-8061950>):
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethod
>> s.new/webrev.04/
>>
>> As Daniel Smith writes in 8029459 > /browse/JDK-8029459>, the following situation is as expected:
>>
>> interface I { void m(); }
>> interface J extends I { void m(); }
>> interface K extends J {}
>> K.class.getMethods() = [ J.m ]
>>
>> But the following has a different result although it should probably have
>> the same:
>>
>> interface I { void m(); }
>> interface J extends I { void m(); }
>> interface K extends I, J {}
>> K.class.getMethods() = [ I.m, J.m ]
>>
>> He then suggests the following algorithm:
>>
>> An implementation of getMethods consistent with JLS 8 would include the
>> following (see Lambda Spec, Part H, 9.4.1 and 8.4.8):
>> 1) The class's/interface's declared (public) methods
>> 2) The getMethods() of the superclass (if this is a class), minus any
>> that have a match in (1)
>> 3) The getMethods() of each superinterface, minus any that have a match
>> in (1) or a _concrete_ match in (2) or a match from a more-specific
>> class/interface in (2) or (3)
>>
>> But even that is not sufficient for the following situation:
>>
>> interface E { void m(); }
>> interface F extends E { void m(); }
>> abstract class G implements E {}
>> abstract class H extends G implements F {}
>> H.class.getMethods() = [ E.m, F.m ]
>>
>> The desired result of H.class.getMethods() = [ F.m ]
>>
>> So a more precise definition is required which is implemented in the fix.
>>
>> The getMethods() implementation partitions the union of the following
>> methods:
>>
>> 1) The class's/interface's declared public methods
>> 2) The getMethods() of the superclass (if this is a class)
>> 3) The non-static getMethods() of each direct superinterface
>>
>> ...into equivalence classes (sets) of methods with same signature (return
>> type, name, parameter types). Within each such set, only the "most
>> specific" methods are kept and others are discarded. The union of the kept
>> methods is the result.
>>
>> The "more specific" is defined as a partial order within a set of methods
>> of same signature:
>>
>> Method A is more specific than method B if:
>> - A is declared by a class and B is declared by an interface; or
>> - A is declared by the same type as or a subtype of B's declaring type
>> and both are either declared by classes or both by interfaces (clearly if A
>> and B are declared by the same type and have the same signature, they are
>> the same method)
>>
>> If A and B are distinct elements from the set of methods with same
>> signature, then either:
>> - A is more specific than B; or
>> - B is more specific than A; or
>> - A and B are incomparable
>>
>> A sub-set of "most specific" methods are the methods from the set where
>> for each such method M, there is no method N != M such that N is "more
>> specific" than M.
>>
>> There can be more than one "most specific" method for a particular
>> signature as they can be inherited from multiple unrelated interfaces, but:
>> - javac prevents compilation when among multiply inherited methods with
>> same signature there is at least one default method, so in practice,
>> getMethods() will only return multiple methods with same signature if they
>> are abstract interface methods. With one exception: bridge methods that are
>> created by javac for co-variant overrides are default methods in
>> interfaces. For example:
>>
>> interface I { Object m(); }
>> interface J1 extends I { Map m(); }
>> interface J2 extends I { HashMap m(); }
>> interface K extends J1, J2 {}
>>
>> K.class.getMethods() = [ default Object j1.m, abstract Map j1.m, default
>> Object j2.m, abstract HashMap j2.m ]
>>
>> But this is an extreme case where one can still expect multiple
>> non-abstract methods with same signature, but different declaring type,
>> returned from getMethods().
>>
>> In order to also fix 8062389 > /browse/JDK-8062389>, getMethod() and getMethods() share the same
>> consolidation logic that results in a set of "most specific" methods. The
>> partitioning in getMethods() is partially performed by collecting Methods
>> into a HashMap where the keys are (name, parameter types) tuples and values
>> are linked lists of Method objects with possibly varying return and
>> 

Re: RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

[Sergei Kovalev]

You are right. I'll rollback the change for the file.


10.10.16 18:05, Alan Bateman wrote:
sun.reflect.generics.parser is in java.base, I don't see anything 
using jdk.unsupported/sun.reflect. You can check this quickly by 
running the test without your change.


-Alan


--
With best regards,
Sergei

Re: RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

[Alan Bateman]

On 10/10/2016 15:55, Sergei Kovalev wrote:


Hi Alan,

sun.reflect.*

./jdk9_latest/bin/jmod describe ./jdk9_latest/jmods/jdk.unsupported.jmod

jdk.unsupported@9-ea
  requires mandated java.base
  exports com.sun.nio.file
  exports sun.misc
*  exports sun.reflect*
  operating-system-name Linux
  operating-system-architecture amd64
  operating-system-version 2.6
sun.reflect.generics.parser is in java.base, I don't see anything using 
jdk.unsupported/sun.reflect. You can check this quickly by running the 
test without your change.


-Alan

Re: RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

[Sergei Kovalev]

Hi Alan,

sun.reflect.*

./jdk9_latest/bin/jmod describe ./jdk9_latest/jmods/jdk.unsupported.jmod

jdk.unsupported@9-ea
  requires mandated java.base
  exports com.sun.nio.file
  exports sun.misc
*  exports sun.reflect*
  operating-system-name Linux
  operating-system-architecture amd64
  operating-system-version 2.6


10.10.16 17:51, Alan Bateman wrote:

On 10/10/2016 14:55, Sergei Kovalev wrote:


Hello team,

Could you please review fix for:

BugID: https://bugs.openjdk.java.net/browse/JDK-8167437
WebRev: http://cr.openjdk.java.net/~skovalev/8167437/webrev.00/

Issue: two tests from java/lang uses internal API but have no 
declaration in jtreg header.

Solution: add missed declaration.


For TestBadSignatures then what is being used in jdk.unsupported?

-Alan


--
With best regards,
Sergei

Re: RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

[Alan Bateman]

On 10/10/2016 14:55, Sergei Kovalev wrote:


Hello team,

Could you please review fix for:

BugID: https://bugs.openjdk.java.net/browse/JDK-8167437
WebRev: http://cr.openjdk.java.net/~skovalev/8167437/webrev.00/

Issue: two tests from java/lang uses internal API but have no 
declaration in jtreg header.

Solution: add missed declaration.


For TestBadSignatures then what is being used in jdk.unsupported?

-Alan

RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

[Sergei Kovalev]

Hello team,

Could you please review fix for:

BugID: https://bugs.openjdk.java.net/browse/JDK-8167437
WebRev: http://cr.openjdk.java.net/~skovalev/8167437/webrev.00/

Issue: two tests from java/lang uses internal API but have no 
declaration in jtreg header.

Solution: add missed declaration.

--
With best regards,
Sergei

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

[Chris Hegarty]

Roger,

I addressed all, or most, of your comments in the following
webrev.

 1) Refactored out the use of sun.nio.ch in the test library,
   so that a reduced number of tests need their @modules tag
   updated. ( @modules support with test library usage it a
   pain )

 2) Use Boolean.getBoolean to retrieve the new property

 3) fix typos and remove stray debugging statements

  http://cr.openjdk.java.net/~chegar/8085192_webrev.03/


...
I'm vaguely not very comfortable with scraping the port number off stdout
and the inherited channel pieces seem like a lot of moving parts.


Right, I was a little uneasy with this too, to being with, but
it has grown on me ( since it appears stable and reliable in
all my builds and tests ). Also the surface area of the code
change is very small, and the inherit channel mechanism is well
specified and stable.


Roger

p.s.  Anyother idea
I assume not all platforms can allow separate processes to open server
sockets to the same port.
If so, we would just have the client allocate a port (0), mark it
non-exclusive and keep it open
while passing the port number to RMID. Only after RMID is started close
the allocating socket.


I believe Stuart did look at this in some detail a while back [1], and
it was somewhat dismissed because of the lack of cross platform support
for SO_REUSEPORT. Maybe things have move on, but I don't think so?

The use of inherit channel is somewhat akin to loading an agent into
the target, but more straightforward.

What do others think, that will have to maintain these tests? I don't
want to make them every harder to maintain. Hamlin's approach is still
on the table too.

-Chris.

[1] 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016251.html

using jshell in executable UNIX scripts

[Peter Levart]

Hi,

I don't know if this is the right list to discuss this, so please direct 
me to a more suitable place if there is one.


"jshell" command is a very nice interactive Java shell, but it could 
also be used for scripting. An executable script in any major UNIX OS is 
a textual file with executable permissions that starts with the 
following two characters: #!
The rest of the 1st line is the path to the interpreter executable and 
any arguments passed to it. The last argument passed to the interpreter 
is the path to the executable script. In case of jshell, one would want 
such script to be written like:


#!/home/peter/Apps64/jdk9/bin/jshell

System.out.println("Hello World!");

/exit


The problem is that jshell tries to parse the 1st line using jshell 
syntax and the result of running above executable script is:


| Error:
|  illegal character: '#'
| #!/home/peter/Apps64/jdk9/bin/jshell
|  ^
|  Error:
|  illegal start of expression
|  #!/home/peter/Apps64/jdk9/bin/jshell
|^
Hello World!


The script is actually executed, but the syntax error encountered in the 
1st line is printed too.


Would it be possible for jshell to skip 1st line if it starts with 
characters #! like other shells do?



Regards, Peter

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

[Jonathan Bluett-Duncan]

Hi all,

Would you kindly review the latest webrev now?

http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02

Thanks in advance.

Kind regards,
Jonathan

On 7 October 2016 at 21:59, Patrick Reinhart  wrote:

> Here is the latest webrev:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02
>
> -Patrick
>
>
>
> > Am 07.10.2016 um 12:00 schrieb Jonathan Bluett-Duncan <
> jbluettdun...@gmail.com>:
> >
> > Hi all,
> >
> > Sorry for the delayed response, I've been busy lately with university
> and other things.
> >
> > Thank you all for your comments. I'll leave the DateTimeFormatter
> comment in, as you requested Stephen and Roger, and I'll work again with
> Patrick as soon as I'm ready.
> >
> > Kind regards,
> > Jonathan
> >
> > On 6 October 2016 at 09:38, Stephen Colebourne 
> wrote:
> > On 6 October 2016 at 00:00, Stuart Marks 
> wrote:
> > >> I think you should perform no change to DateTimeFormatter (other than
> > >> a comment) as part of this changeset. The behaviour of that
> > >> DateTimeFormatter method is subtle, and I now suspect that what we
> > >> have there might be the best option.
> > >
> > > I had recommended removing the comment from DateTimeFormatter, but if
> > > Stephen wants the comment in, that's fine with me. In fact I'll defer
> to
> > > what Stephen (and Roger Riggs) want with this code, since they're the
> > > maintainers.
> >
> > I think it makes sense to leave the new comment in. All further change
> > should be under 8167222.
> >
> > Stephen
> >
>
>

Re: RFR: 8062389,8029459,8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

[Peter Levart]

Just a note that this is still ready to be reviewed.

I was also told that JCK tests pass with the patch applied.

Regards, Peter

On 10/04/2016 03:40 PM, Peter Levart wrote:

Hi,

I have a fix for conformance (P2) bug (8062389 
) that also fixes a 
conformance (P3) bug (8029459 
) and a performance 
issue (8061950 ):


http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.04/

As Daniel Smith writes in 8029459 
, the following 
situation is as expected:


interface I { void m(); }
interface J extends I { void m(); }
interface K extends J {}
K.class.getMethods() = [ J.m ]

But the following has a different result although it should probably 
have the same:


interface I { void m(); }
interface J extends I { void m(); }
interface K extends I, J {}
K.class.getMethods() = [ I.m, J.m ]

He then suggests the following algorithm:

An implementation of getMethods consistent with JLS 8 would include 
the following (see Lambda Spec, Part H, 9.4.1 and 8.4.8):

1) The class's/interface's declared (public) methods
2) The getMethods() of the superclass (if this is a class), minus any 
that have a match in (1)
3) The getMethods() of each superinterface, minus any that have a 
match in (1) or a _concrete_ match in (2) or a match from a 
more-specific class/interface in (2) or (3)


But even that is not sufficient for the following situation:

interface E { void m(); }
interface F extends E { void m(); }
abstract class G implements E {}
abstract class H extends G implements F {}
H.class.getMethods() = [ E.m, F.m ]

The desired result of H.class.getMethods() = [ F.m ]

So a more precise definition is required which is implemented in the fix.

The getMethods() implementation partitions the union of the following 
methods:


1) The class's/interface's declared public methods
2) The getMethods() of the superclass (if this is a class)
3) The non-static getMethods() of each direct superinterface

...into equivalence classes (sets) of methods with same signature 
(return type, name, parameter types). Within each such set, only the 
"most specific" methods are kept and others are discarded. The union 
of the kept methods is the result.


The "more specific" is defined as a partial order within a set of 
methods of same signature:


Method A is more specific than method B if:
- A is declared by a class and B is declared by an interface; or
- A is declared by the same type as or a subtype of B's declaring type 
and both are either declared by classes or both by interfaces (clearly 
if A and B are declared by the same type and have the same signature, 
they are the same method)


If A and B are distinct elements from the set of methods with same 
signature, then either:

- A is more specific than B; or
- B is more specific than A; or
- A and B are incomparable

A sub-set of "most specific" methods are the methods from the set 
where for each such method M, there is no method N != M such that N is 
"more specific" than M.


There can be more than one "most specific" method for a particular 
signature as they can be inherited from multiple unrelated interfaces, 
but:
- javac prevents compilation when among multiply inherited methods 
with same signature there is at least one default method, so in 
practice, getMethods() will only return multiple methods with same 
signature if they are abstract interface methods. With one exception: 
bridge methods that are created by javac for co-variant overrides are 
default methods in interfaces. For example:


interface I { Object m(); }
interface J1 extends I { Map m(); }
interface J2 extends I { HashMap m(); }
interface K extends J1, J2 {}

K.class.getMethods() = [ default Object j1.m, abstract Map j1.m, 
default Object j2.m, abstract HashMap j2.m ]


But this is an extreme case where one can still expect multiple 
non-abstract methods with same signature, but different declaring 
type, returned from getMethods().


In order to also fix 8062389 
, getMethod() and 
getMethods() share the same consolidation logic that results in a set 
of "most specific" methods. The partitioning in getMethods() is 
partially performed by collecting Methods into a HashMap where the 
keys are (name, parameter types) tuples and values are linked lists of 
Method objects with possibly varying return and declaring types. The 
consolidation, i.e. keeping only the set of most specific methods as 
new methods are encountered, is performed only among methods in the 
list that share same return type and also removes duplicates. 
getMethod() uses only one such list, consolidates methods that match 
given name and parameter types and returns the 1st method from the 
resulting list that has the most specific return type.


That's it for 

Re: DateTimeFormatter.format() uses exceptions for flow control

[Clément MATHIEU]

On Mon, 2016-10-10 at 06:47 +1000, David Holmes wrote:

Hi David,

> Please note that patches can only be accepted if they are sent
> through, or hosted upon OpenJDK infrastructure. If the patch is small
> enough can you send it inline in the email (attachments are often
> stripped) 

Here it is: 

--- old/src/java.base/share/classes/java/time/format/DateTimePrintContext.java  
2016-10-09 17:01:30.326739656 +0200
+++ new/src/java.base/share/classes/java/time/format/DateTimePrintContext.java  
2016-10-09 17:01:30.228738595 +0200
@@ -302,13 +302,10 @@
  * @throws DateTimeException if the field is not available and the section 
is not optional
  */
 Long getValue(TemporalField field) {
-try {
+if (optional == 0) {
 return temporal.getLong(field);
-} catch (DateTimeException ex) {
-if (optional > 0) {
-return null;
-}
-throw ex;
+} else {
+return temporal.isSupported(field) ? temporal.getLong(field) : 
null;
 }
 }

Clément MATHIEU