On 11/28/2022 1:10 PM, Sean Mullan wrote:
PCSCException is an internal API and is strongly encapsulated by
default as of JDK 17 [1]. Applications should not be accessing it.
Making an internal API public is not the solution.
Your suggestion to extend CardException with methods to provide/acces
PCSCException is an internal API and is strongly encapsulated by default
as of JDK 17 [1]. Applications should not be accessing it. Making an
internal API public is not the solution.
Your suggestion to extend CardException with methods to provide/access
the underlying error code seems more rea
I’m not very sure what the update public APIs may look like. If we are able to
collect the possible card exception reasons, the design of
CertPathValidatorException and CertPathValidatorException.BasicReason could be
a reference.
Xuelei
> On Nov 23, 2022, at 9:21 AM, Michael StJohns wrote:
>
On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns wrote:
… CardException doesn't always pass through the details in a comprehensible way
from the underlying cause, …
Does it sound like a cause that the public APIs are not sufficient?
Alterna
On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns wrote:
> … CardException doesn't always pass through the details in a comprehensible
> way from the underlying cause, …
Does it sound like a cause that the public APIs are not sufficient?
Alternatively, if it is possible to update the public AP
On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote:
On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel wrote:
Checking the instance is fundamental to find out the real cause.
Please don't do that in a serious application. The exception stack is belong
to implementation details, and may change
On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel wrote:
> Checking the instance is fundamental to find out the real cause.
Please don't do that in a serious application. The exception stack is belong
to implementation details, and may change any time.
-
PR: https://git.openjdk.o
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Exactly what wangwe
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Making an exception
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Can you explain in
On Sun, 13 Nov 2022 19:41:52 GMT, Andrey Turbanov wrote:
>> The `PCSCException` is thrown, but the error type is not visible due to the
>> "private-packe" access rule.
>> By changing the visibility it is possible to handle / access this exception
>> type explicitly in the catch.
>
> src/java.sm
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
src/java.smartcardi
The `PCSCException` is thrown, but the error type is not visible due to the
"private-packe" access rule.
By changing the visibility it is possible to handle / access this exception
type explicitly in the catch.
-
Commit messages:
- 8296408: Make the PCSCException public accessible
13 matches
Mail list logo
