I will go with the what the group agrees with, but I still think the one
in the docs should be the one we use. I think that has more public
exposure than the misspelled one. Was the MFLN property added because
of user request?
I don't think we need two properties. I doubt the property is used that
much and if we hear problems, we can always add the misspelled one back.
Tony
On 11/7/19 5:29 PM, Xuelei Fan wrote:
If there are two properties used for the same function, we need to
respect one and discard another one. Which one should be respected? As
could be confused.
For example, property "pro-A" is set to "value-A", and property "pro-B"
is set to "value-B", which value should be used? If "pro-A" is not set,
while "pro-B" is set to "value-B", should "value-B" be used? We may be
able to workaround and documentation be behaviors clearly. But it might
be not necessary if there is a acceptable one-property-name solution.
Xuelei
On 11/7/2019 1:32 PM, Sean Mullan wrote:
On 11/7/19 12:34 PM, Xuelei Fan wrote:
As the property has a default value, so there is a problem to use two
properties for the same purpose. We don't really know if an
application uses the misspelled name, or intended to use the default
value.
But you know if an application has set the property (the misspelled
one or the correct one), so I don't see the issue, but maybe I am
missing something. Can you be more specific, or give an example where
it would be an issue?
--Sean
For the current applications, if the implementation name get used,
okay, they get the expected behavior if we change to use the impl
name, and no worries. However, if we change to use the doc name, the
behavior get changed, and problems come out.
For the current applications, if the doc named get used.
Applications may expect it to work, but actually not. If we change
to use the impl name, the application still does not work, no
additional risks. If we change to use the doc name, the
configuration works but the application behavior also get changed
(although it is the expected behavior).
I think the risk is pretty low if change to use the impl name.
Xuelei
On 11/7/2019 8:46 AM, Sean Mullan wrote:
I guess another option is to not change the name that is used in the
docs, but change the code to look for both properties, trying the
docs name first, and then the misspelled name.
Not great, but probably the safest and least disruptive option.
--Sean
On 11/5/19 8:07 PM, Xuelei Fan wrote:
I understand your points. Between using the doc name and the code
name, I think using the code name is a little bit safer if someone
really use the impl name. However, just a little bit. I’m open to
use the doc name if we could get an agreement.
Xuelei
On Nov 5, 2019, at 4:32 PM, Anthony Scarpino
<anthony.scarp...@oracle.com> wrote:
I understand the desire to change this, but are we sure the doc
should be changed instead of the property? I would tend to
believe users code to the doc and don’t notice it wasn’t
working. Not reading the source code and code to that
implemented name. Otherwise I’d assume someone would have filed a
bug already in the 2yrs.
I don’t want us to support two properties, I’m just not confident
which way is right.
Tony
On Nov 5, 2019, at 4:00 PM, Xuelei Fan <xuelei....@oracle.com>
wrote:
Hi,
May I have the CSR reviewed?
https://bugs.openjdk.java.net/browse/JDK-8233652
The system property, "jsse.enableMFLNExtension", was introduced
in JDK 9 (See JSSE Reference Guides). However, the implementation
code uses "jsse.enableMFLExtension" (without 'N') instead.
As the system property may have been used in practice, it may be
better to change the CSR and doc accordingly.
Thanks,
Xuelei
