Oh, your testing is checking service type Cipher which is Java SE service.
It is not the case we discussed in the context: non-Java SE service types.
Xuelei
On Tue, Dec 17, 2024 at 2:47 PM Martin Balao wrote:
> On Tue, 17 Dec 2024 22:13:09 GMT, Xue-Lei Andrew Fan
> wrote:
>
> > Sorry, I meant
Let’s simplify the discussion. Just one question, is the filter able to
filter out FIPS unapproved crypto algorithms and parameters form a provide?
If the answer is yes, I will support this proposal and you take any
possible action to make it. If the answer is no, I will stop to discuss as
well a
On Tue, Dec 17, 2024 at 8:26 PM Xuelei Fan wrote:
>
>
> > I have to disable this feature, and don’t allow any security property
>> setting, which is not easy to me once an editable property is introduced.
>>
>> No need for this, the filter is disabled by default. I
>
>
> Hi @XueleiFan,
>
> > I did not see the benefit of the proposal yet, except the troublesome I
> have to handle with in practice.
>
> The benefit is the removal of the limitation described in the [section
> **What is the current limitation?** of the JBS enhancement issue](
> https://bugs.openjd
> On Jan 26, 2023, at 9:52 PM, Xuelei Fan wrote:
>
>
>
>> On Jan 26, 2023, at 9:27 PM, Glavo wrote:
>>
>> They only need to use "str".toLowerCase(Locale.ROOT).
>
> Sorry, with a workaround I meant to have toLowerCase() work without modifying
> On Jan 26, 2023, at 9:27 PM, Glavo wrote:
>
> They only need to use "str".toLowerCase(Locale.ROOT).
Sorry, with a workaround I meant to have toLowerCase() work without modifying
the existing source code to use toLowerCase(Locale.ROOT).
Xuelei
>
> On Fri, Jan 2
Just curious, this is a known issue for many years, how those areas like
Turkish survive? Is there a workaround for those areas or the use of the
methods is not common any longer?
Xuelei
> On Jan 26, 2023, at 4:35 AM, Glavo wrote:
>
> At present, the no-parameter toLowerCase and toUpperCase
