On 12/20/18, 4:10 PM, Sergey Bylokhov wrote:
On 20/12/2018 15:44, Phil Race wrote:
The peers were not part of the SE specification.
This class is, it just became obsolete so has been deprecated which
on its own has no spec impact. So I would not call it a similar
situation.
No it was not part of the spec(and the deprecation notion is unrelated).
The notion that it should not be used and internal use only, is there
from the moment the class was moved to the "javax.accessibility"
package in 1998.
It is a public class in a public package and so forth.
But you can argue it out with JCK, as it is a waste of time to discuss
it further here.
-phil.
As I pointed out in what might have been an off-list comment, we can
consider
the deprecation for removal route, but that wouldn't solve the
problem today.
But excluding the test is a possible option for 12, so we could defer
fixing
the underlying regression until 13.
-phil.
On 12/20/18 3:33 PM, Sergey Bylokhov wrote:
On 20/12/2018 15:25, Phil Race wrote:
On 12/20/18 2:51 PM, Sergey Bylokhov wrote:
I have checked the test which uses AccessibleResourceBundle and I
have two comments:
- This test should not be a part of jck since it is not a part of
public specification.
What isn't ? Do you mean the class ?
I meant the class and the test which use it. BTW this class is a
good candidate for "removal=true"
If you mean the comment that it is not supposed to be called by
external applications,
then yes, as I already pointed out, but the class does appear in
the spec.
It is there because we generate the javadoc for all public classes,
but the text for
this class clearly state that it should not be used. This situation
is similar
to the API which uses peers.
