Hi, Shashi.
Yes we need a fix for this, see my comments here:
http://mail.openjdk.java.net/pipermail/swing-dev/2018-December/009248.html
On 20/12/2018 21:57, Shashidhara Veerabhadraiah wrote:
Hi Phil, In that case I have put up the fix which fixes the problem as I was
unable to reproduce this p
Hi Phil, In that case I have put up the fix which fixes the problem as I was
unable to reproduce this problem after that fix. So it does work for this
situation. Can you please review it?
It adds the same missing element to the list which is being loaded to the cache
and the same is used. Anoth
No, we can't remove it in 13 unless we deprecate for removal in 12 and
we are
too late for that and in any case 6 months is very short.
This is not important enough to rush such a thing.
Removal before the next LTS should suffiice.
We can ask the JCK team as discussed but that does not mean we t
Hi Phil\Sergey, As I understand from this, we should remove the
AccessibleResourceBundle from JDK in 13(By using @Deprecated(forRemoval =
true)) and meanwhile ask the JCK team to remove this test from the test suite?
Should the forremoval needs to be done now or later?
Thanks and regards,
Shash
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 p
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 unre
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.
As I pointed out in what might have been an off-list comment, we can
consider
the deprecation for remova
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 ?
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 ?
If you mean the comment that it is
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.
- The bug is not directly related to this class, it can be reproduced using any
non-default resource bundle, which are
My understanding is that there is a JCK test that explicitly calls
AccessibleResourceBundle.getContents().
And yet the class docs for AccessibleResourceBundle state
* This is meant only for internal use by Java Accessibility and is not
* meant to be used by assistive technologies or applicatio
Hi, Shashi.
Can you please provide more details, why this deprecated resource bundle is
loaded by the test?
It is strange because it should not be used, and was replaced by
"com.sun.accessibility.internal.resources.accessibility".
The AccessibleBundle explicitly load it via ResourceBundle.getBun
Hi All, Please find the updated Webrev for this problem:
http://cr.openjdk.java.net/~sveerabhadra/8213516/webrev.01/
Per the comments @
http://hg.openjdk.java.net/jdk/client/file/b5c564a1367c/src/java.desktop/share/classes/javax/accessibility/AccessibleState.java#l49,
we need to update the miss
13 matches
Mail list logo