RFR 8182999: SunEC throws ProviderException on invalid curves

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher
This is a bug fix related to invalid curves in the SunEC provider.
During ECKeyPairGenerator.initialize(), the provider only checks whether
the curve is known, but it doesn't check whether the curve is actually
supported by the native code. So the call to generateKeyPair() can fail
in the native code and throw a ProviderException. This change adds a new
native method to check whether the curve is supported. This method is
called by initialize(), which will set the state to uninitialized and
throw the expected exception when the curve is not supported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Seán Coffey
Adam,

would it be useful to get the curve name in the new exception ? I think
it would help with future debugging. Line 96 already gets the curve name
if we're dealing with ECGenParameterSpec instance. I think the same
approach could be applied to your new code.

Regards,
Sean.


On 07/07/2017 19:59, Adam Petcher wrote:

> This is a bug fix related to invalid curves in the SunEC provider.
> During ECKeyPairGenerator.initialize(), the provider only checks
> whether the curve is known, but it doesn't check whether the curve is
> actually supported by the native code. So the call to
> generateKeyPair() can fail in the native code and throw a
> ProviderException. This change adds a new native method to check
> whether the curve is supported. This method is called by initialize(),
> which will set the state to uninitialized and throw the expected
> exception when the curve is not supported.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher
New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/

Yes, this is a good idea. I made this work by printing out the value
from AlgorithmParameters.toString(), so hopefully that means you should
always get a useful string. At the moment (with SunEC
AlgorithmParameters), the string prints the friendly name followed by
the OID:

Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)

On 7/7/2017 4:12 PM, Seán Coffey wrote:

> Adam,
>
> would it be useful to get the curve name in the new exception ? I
> think it would help with future debugging. Line 96 already gets the
> curve name if we're dealing with ECGenParameterSpec instance. I think
> the same approach could be applied to your new code.
>
> Regards,
> Sean.
>
>
> On 07/07/2017 19:59, Adam Petcher wrote:
>> This is a bug fix related to invalid curves in the SunEC provider.
>> During ECKeyPairGenerator.initialize(), the provider only checks
>> whether the curve is known, but it doesn't check whether the curve is
>> actually supported by the native code. So the call to
>> generateKeyPair() can fail in the native code and throw a
>> ProviderException. This change adds a new native method to check
>> whether the curve is supported. This method is called by
>> initialize(), which will set the state to uninitialized and throw the
>> expected exception when the curve is not supported.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Seán Coffey
Thanks for the update! Looks fine to me.

Regards,
Sean.

On 10/07/17 16:13, Adam Petcher wrote:

> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>
> Yes, this is a good idea. I made this work by printing out the value
> from AlgorithmParameters.toString(), so hopefully that means you
> should always get a useful string. At the moment (with SunEC
> AlgorithmParameters), the string prints the friendly name followed by
> the OID:
>
> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>
> On 7/7/2017 4:12 PM, Seán Coffey wrote:
>> Adam,
>>
>> would it be useful to get the curve name in the new exception ? I
>> think it would help with future debugging. Line 96 already gets the
>> curve name if we're dealing with ECGenParameterSpec instance. I think
>> the same approach could be applied to your new code.
>>
>> Regards,
>> Sean.
>>
>>
>> On 07/07/2017 19:59, Adam Petcher wrote:
>>> This is a bug fix related to invalid curves in the SunEC provider.
>>> During ECKeyPairGenerator.initialize(), the provider only checks
>>> whether the curve is known, but it doesn't check whether the curve
>>> is actually supported by the native code. So the call to
>>> generateKeyPair() can fail in the native code and throw a
>>> ProviderException. This change adds a new native method to check
>>> whether the curve is supported. This method is called by
>>> initialize(), which will set the state to uninitialized and throw
>>> the expected exception when the curve is not supported.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Michael StJohns
Actually - wouldn't it make a lot more sense to generalize the provider
so it can take ANY set of curve data?  Locking this to only what has an
OID to parameters mapping doesn't seem to be actually meeting the
contract for an EC key generator.

I understand a number of tools (e.g. PKIX related/keytool) can't be used
without the OID, but this isn't at that level.

The webrev feels more like a bandaid than a solution.

Mike


On 7/10/2017 12:03 PM, Seán Coffey wrote:

> Thanks for the update! Looks fine to me.
>
> Regards,
> Sean.
>
> On 10/07/17 16:13, Adam Petcher wrote:
>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>
>> Yes, this is a good idea. I made this work by printing out the value
>> from AlgorithmParameters.toString(), so hopefully that means you
>> should always get a useful string. At the moment (with SunEC
>> AlgorithmParameters), the string prints the friendly name followed by
>> the OID:
>>
>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>
>> On 7/7/2017 4:12 PM, Seán Coffey wrote:
>>> Adam,
>>>
>>> would it be useful to get the curve name in the new exception ? I
>>> think it would help with future debugging. Line 96 already gets the
>>> curve name if we're dealing with ECGenParameterSpec instance. I
>>> think the same approach could be applied to your new code.
>>>
>>> Regards,
>>> Sean.
>>>
>>>
>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>> This is a bug fix related to invalid curves in the SunEC provider.
>>>> During ECKeyPairGenerator.initialize(), the provider only checks
>>>> whether the curve is known, but it doesn't check whether the curve
>>>> is actually supported by the native code. So the call to
>>>> generateKeyPair() can fail in the native code and throw a
>>>> ProviderException. This change adds a new native method to check
>>>> whether the curve is supported. This method is called by
>>>> initialize(), which will set the state to uninitialized and throw
>>>> the expected exception when the curve is not supported.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher
This fix addresses an issue in which the provider behaves incorrectly
when initialized with parameters for a curve that is not supported by
the provider. If I am interpreting your suggestion correctly, it sounds
like you are requesting a change to the set of curves that is supported
by the provider. While this change may be a good idea, it is not within
the scope of this ticket.

If you want SunEC to support arbitrary curve parameters, you will need
to create a separate ticket for that. I suspect this change would
require a fair amount of work (if it is even possible), and it may not
be worth the effort.


On 7/10/2017 12:17 PM, Michael StJohns wrote:

> Actually - wouldn't it make a lot more sense to generalize the
> provider so it can take ANY set of curve data? Locking this to only
> what has an OID to parameters mapping doesn't seem to be actually
> meeting the contract for an EC key generator.
>
> I understand a number of tools (e.g. PKIX related/keytool) can't be
> used without the OID, but this isn't at that level.
>
> The webrev feels more like a bandaid than a solution.
>
> Mike
>
>
> On 7/10/2017 12:03 PM, Seán Coffey wrote:
>> Thanks for the update! Looks fine to me.
>>
>> Regards,
>> Sean.
>>
>> On 10/07/17 16:13, Adam Petcher wrote:
>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>>
>>> Yes, this is a good idea. I made this work by printing out the value
>>> from AlgorithmParameters.toString(), so hopefully that means you
>>> should always get a useful string. At the moment (with SunEC
>>> AlgorithmParameters), the string prints the friendly name followed
>>> by the OID:
>>>
>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>
>>> On 7/7/2017 4:12 PM, Seán Coffey wrote:
>>>> Adam,
>>>>
>>>> would it be useful to get the curve name in the new exception ? I
>>>> think it would help with future debugging. Line 96 already gets the
>>>> curve name if we're dealing with ECGenParameterSpec instance. I
>>>> think the same approach could be applied to your new code.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>>
>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>> This is a bug fix related to invalid curves in the SunEC provider.
>>>>> During ECKeyPairGenerator.initialize(), the provider only checks
>>>>> whether the curve is known, but it doesn't check whether the curve
>>>>> is actually supported by the native code. So the call to
>>>>> generateKeyPair() can fail in the native code and throw a
>>>>> ProviderException. This change adds a new native method to check
>>>>> whether the curve is supported. This method is called by
>>>>> initialize(), which will set the state to uninitialized and throw
>>>>> the expected exception when the curve is not supported.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Michael StJohns
On 7/10/2017 12:59 PM, Adam Petcher wrote:

> This fix addresses an issue in which the provider behaves incorrectly
> when initialized with parameters for a curve that is not supported by
> the provider. If I am interpreting your suggestion correctly, it
> sounds like you are requesting a change to the set of curves that is
> supported by the provider. While this change may be a good idea, it is
> not within the scope of this ticket.
>
> If you want SunEC to support arbitrary curve parameters, you will need
> to create a separate ticket for that. I suspect this change would
> require a fair amount of work (if it is even possible), and it may not
> be worth the effort.

EC is designed around a general set of math.  The math depends on the
actual curve data (e.g. an EllipticCurve, a basepoint ECPoint g and an
order and cofactor  - all the components of ECParameterSpec).  
ECGenParameterSpec is a simple wrapper around a string that's meant to
provide a easy way for a human to specify a preexisting set of curve
data.  When you get down into the provider its the math and the bits in
the ECParameterSpec that matter, not the string or oid in the
ECGenParameterSpec.

In any event, if you already have the curve data, then the fix is to
replace the groupings of "if (EC_DecodeParams(...) {}" with a routine to
fill the ECParams structure from the encodedParams you're passing in.
(at lines 118, 233,346, 429 in ECC_JNI.cpp).

That would look like a different version of EC_FillParams  (in
impl/ecdecode.c) - which actually decoded the algorithm parameter data
rather than just looking for an OID choice and filling in from there.

*sigh* It looks like ECParameters.java is also incomplete.

What I'm mostly trying to get at here is to decouple  or remove the list
of curves in ecdecode.c in favor of the list in the java stuff
(CurveDB.java) (or elsewhere).   The C code should mostly only have to
deal with the math and not the housekeeping.

Mike






>
>
> On 7/10/2017 12:17 PM, Michael StJohns wrote:
>> Actually - wouldn't it make a lot more sense to generalize the
>> provider so it can take ANY set of curve data? Locking this to only
>> what has an OID to parameters mapping doesn't seem to be actually
>> meeting the contract for an EC key generator.
>>
>> I understand a number of tools (e.g. PKIX related/keytool) can't be
>> used without the OID, but this isn't at that level.
>>
>> The webrev feels more like a bandaid than a solution.
>>
>> Mike
>>
>>
>> On 7/10/2017 12:03 PM, Seán Coffey wrote:
>>> Thanks for the update! Looks fine to me.
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 10/07/17 16:13, Adam Petcher wrote:
>>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>>>
>>>> Yes, this is a good idea. I made this work by printing out the
>>>> value from AlgorithmParameters.toString(), so hopefully that means
>>>> you should always get a useful string. At the moment (with SunEC
>>>> AlgorithmParameters), the string prints the friendly name followed
>>>> by the OID:
>>>>
>>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>>
>>>> On 7/7/2017 4:12 PM, Seán Coffey wrote:
>>>>> Adam,
>>>>>
>>>>> would it be useful to get the curve name in the new exception ? I
>>>>> think it would help with future debugging. Line 96 already gets
>>>>> the curve name if we're dealing with ECGenParameterSpec instance.
>>>>> I think the same approach could be applied to your new code.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>>
>>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>>> This is a bug fix related to invalid curves in the SunEC
>>>>>> provider. During ECKeyPairGenerator.initialize(), the provider
>>>>>> only checks whether the curve is known, but it doesn't check
>>>>>> whether the curve is actually supported by the native code. So
>>>>>> the call to generateKeyPair() can fail in the native code and
>>>>>> throw a ProviderException. This change adds a new native method
>>>>>> to check whether the curve is supported. This method is called by
>>>>>> initialize(), which will set the state to uninitialized and throw
>>>>>> the expected exception when the curve is not supported.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher
On 7/10/2017 1:55 PM, Michael StJohns wrote:

>
> What I'm mostly trying to get at here is to decouple  or remove the
> list of curves in ecdecode.c in favor of the list in the java stuff
> (CurveDB.java) (or elsewhere).   The C code should mostly only have to
> deal with the math and not the housekeeping.
>

I agree that this would be a nice improvement, but I still think it is
outside of scope of this fix. What you propose is a significant
reorganization of the ECC code, and I don't think we should do that as
part of a bug fix. It should be considered as a standalone refactoring
effort, or maybe done as part of the next enhancement that adds support
for new curves.

> Mike
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Michael StJohns
On 7/10/2017 2:28 PM, Adam Petcher wrote:

> On 7/10/2017 1:55 PM, Michael StJohns wrote:
>
>>
>> What I'm mostly trying to get at here is to decouple  or remove the
>> list of curves in ecdecode.c in favor of the list in the java stuff
>> (CurveDB.java) (or elsewhere).   The C code should mostly only have
>> to deal with the math and not the housekeeping.
>>
>
> I agree that this would be a nice improvement, but I still think it is
> outside of scope of this fix. What you propose is a significant
> reorganization of the ECC code, and I don't think we should do that as
> part of a bug fix. It should be considered as a standalone refactoring
> effort, or maybe done as part of the next enhancement that adds
> support for new curves.

I'm not actually thinking this is an improvement rather than fixing an
incomplete or badly structured implementation, but I take your point.  I
also don't think it's much of a reorganization - again - rather removing
an interdependency that shouldn't be there rather than papering over it
with an explanatory error.  (Hmm.. have you checked to make sure that
the list of curves in ecdecode is a subset of the curves in CurveDB - if
not you may still have another problem).

I'd submit changes myself, but I don't currently have a good build
environment to test against.

WRT to new curves - the next effort will probably involve changes to the
public API to deal with the Curve25519 et al implementations. I'm not
sure any of the old curve stuff will get any attention at that point.

Thanks-  Mike


>
>> Mike
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher

I created JDK-8184122[1] to track this SunEC refactoring effort.

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

On 7/10/2017 2:51 PM, Michael StJohns wrote:

>  (Hmm.. have you checked to make sure that the list of curves in
> ecdecode is a subset of the curves in CurveDB - if not you may still
> have another problem).

What problem do you expect this will cause? If there is a curve that is
in ecdecode, but not in CurveDB, then that means it is not supported.
Any attempt to use it should result in the expected exception before
execution reaches the native code. So the code for this curve in
ecdecode is effectively dead, and there may be some technical debt here,
but are there other problems that I am not thinking of?


>
> Thanks-  Mike
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Vincent Ryan
In reply to this post by Seán Coffey
Looks fine to me too.

We should investigate how best to support similar behaviour for the SunPKCS11 provider.
To track this issue I’ve filed a related bug 8184290: SunPKCS11 throws ProviderException for unsupported curves



On 10 Jul 2017, at 17:03, Seán Coffey <[hidden email]> wrote:

Thanks for the update! Looks fine to me.

Regards,
Sean.

On 10/07/17 16:13, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/

Yes, this is a good idea. I made this work by printing out the value from AlgorithmParameters.toString(), so hopefully that means you should always get a useful string. At the moment (with SunEC AlgorithmParameters), the string prints the friendly name followed by the OID:

Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)

On 7/7/2017 4:12 PM, Seán Coffey wrote:
Adam,

would it be useful to get the curve name in the new exception ? I think it would help with future debugging. Line 96 already gets the curve name if we're dealing with ECGenParameterSpec instance. I think the same approach could be applied to your new code.

Regards,
Sean.


On 07/07/2017 19:59, Adam Petcher wrote:
This is a bug fix related to invalid curves in the SunEC provider. During ECKeyPairGenerator.initialize(), the provider only checks whether the curve is known, but it doesn't check whether the curve is actually supported by the native code. So the call to generateKeyPair() can fail in the native code and throw a ProviderException. This change adds a new native method to check whether the curve is supported. This method is called by initialize(), which will set the state to uninitialized and throw the expected exception when the curve is not supported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Adam Petcher

I made a minor tweak to the test. I realized that the test will still pass if the curve becomes supported in the future. I want the test to fail in this case because it would no longer be testing an unsupported curve.

latest webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.02/


On 7/12/2017 10:42 AM, Vincent Ryan wrote:
Looks fine to me too.

We should investigate how best to support similar behaviour for the SunPKCS11 provider.
To track this issue I’ve filed a related bug 8184290: SunPKCS11 throws ProviderException for unsupported curves



On 10 Jul 2017, at 17:03, Seán Coffey <[hidden email]> wrote:

Thanks for the update! Looks fine to me.

Regards,
Sean.

On 10/07/17 16:13, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/

Yes, this is a good idea. I made this work by printing out the value from AlgorithmParameters.toString(), so hopefully that means you should always get a useful string. At the moment (with SunEC AlgorithmParameters), the string prints the friendly name followed by the OID:

Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)

On 7/7/2017 4:12 PM, Seán Coffey wrote:
Adam,

would it be useful to get the curve name in the new exception ? I think it would help with future debugging. Line 96 already gets the curve name if we're dealing with ECGenParameterSpec instance. I think the same approach could be applied to your new code.

Regards,
Sean.


On 07/07/2017 19:59, Adam Petcher wrote:
This is a bug fix related to invalid curves in the SunEC provider. During ECKeyPairGenerator.initialize(), the provider only checks whether the curve is known, but it doesn't check whether the curve is actually supported by the native code. So the call to generateKeyPair() can fail in the native code and throw a ProviderException. This change adds a new native method to check whether the curve is supported. This method is called by initialize(), which will set the state to uninitialized and throw the expected exception when the curve is not supported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR 8182999: SunEC throws ProviderException on invalid curves

Vincent Ryan
+1

On 12 Jul 2017, at 15:51, Adam Petcher <[hidden email]> wrote:

I made a minor tweak to the test. I realized that the test will still pass if the curve becomes supported in the future. I want the test to fail in this case because it would no longer be testing an unsupported curve.

latest webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.02/


On 7/12/2017 10:42 AM, Vincent Ryan wrote:
Looks fine to me too.

We should investigate how best to support similar behaviour for the SunPKCS11 provider.
To track this issue I’ve filed a related bug 8184290: SunPKCS11 throws ProviderException for unsupported curves



On 10 Jul 2017, at 17:03, Seán Coffey <[hidden email]> wrote:

Thanks for the update! Looks fine to me.

Regards,
Sean.

On 10/07/17 16:13, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/

Yes, this is a good idea. I made this work by printing out the value from AlgorithmParameters.toString(), so hopefully that means you should always get a useful string. At the moment (with SunEC AlgorithmParameters), the string prints the friendly name followed by the OID:

Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)

On 7/7/2017 4:12 PM, Seán Coffey wrote:
Adam,

would it be useful to get the curve name in the new exception ? I think it would help with future debugging. Line 96 already gets the curve name if we're dealing with ECGenParameterSpec instance. I think the same approach could be applied to your new code.

Regards,
Sean.


On 07/07/2017 19:59, Adam Petcher wrote:
This is a bug fix related to invalid curves in the SunEC provider. During ECKeyPairGenerator.initialize(), the provider only checks whether the curve is known, but it doesn't check whether the curve is actually supported by the native code. So the call to generateKeyPair() can fail in the native code and throw a ProviderException. This change adds a new native method to check whether the curve is supported. This method is called by initialize(), which will set the state to uninitialized and throw the expected exception when the curve is not supported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/







Loading...