<Swing Dev> [9] Review request for 8167176 Exported elements referring to inaccessible types in java.desktop
Alexandr Scherbatiy
alexandr.scherbatiy at oracle.com
Tue Oct 18 10:54:24 UTC 2016
On 10/18/2016 12:42 AM, Philip Race wrote:
> Hi,
>
> First note that any of the alternatives here require an approved CCC
> before pushing.
>
> As I wrote in the bug the fields in JRootPane are not used. Making it
> a public supertype
> is no more useful than just deleting it. This like hiding the peers
> which was a much
> bigger change so please just delete these fields.
>
> I don't understand the reasoning behind changing "bumps" to be of the
> super-class type Icon
> and introducing a new variable that is what is then used.
>
> Since "MetalBumps" is package private we should be able to safely
> assume no one has
> been using these fields without the aid of reflection and I doubt
> anyone found a need.
> And that won't work in JDK 9 with upcoming jigsaw changes
> If you wanted people to usefully access these then you'd need to make
> MetalBumps public.
> I *am not* suggesting that .. just pointing out that the alternatives
> I see are either
> make it entirely public, or entirely hide is as being a mistake.
> So make the fields all private and do not provide the non-useful
> public replacement.
> And I mean remove today. In JDK 9. This is not as radical as it seems
> since left as
> it is they are useless to anyone as you cannot use them.
>
> Also createDirectoryComboBoxRenderer(..) can be made private too.
All these fields and methods can be used with the public super-class
type in a user code.
For example the code below successfully compiled with JDK 8 and 9:
-------------
public class Test {
static class CustomToolBarBorder extends MetalBorders.ToolBarBorder {
public void doSomething(Graphics g) {
Icon metalBumps = bumps;
metalBumps.paintIcon(new JLabel(), g, 0, 0);
}
}
static class CustomMetalFileChooserUI extends MetalFileChooserUI {
public CustomMetalFileChooserUI(JFileChooser filechooser) {
super(filechooser);
}
public void doSomething() {
DefaultListCellRenderer listCellRenderer =
createDirectoryComboBoxRenderer(getFileChooser());
// do something with the listCellRenderer
}
}
static class CustomJRootPane extends JRootPane {
public void doSomething() {
AbstractAction pressAction = defaultPressAction != null
? defaultPressAction
: new CustomAction();
AbstractAction releaseAction = defaultReleaseAction != null
? defaultReleaseAction
: new CustomAction();
}
}
}
-------------
I just need to be sure that the incompatible change introduced by
removing these fields or making them private is acceptable.
>
> Finally, when these are resolved you should be able to re-enable lint !
> http://hg.openjdk.java.net/jdk9/dev/rev/81435a812f59
I prepared the hint enabling fix but I believe it should be reviewed
on the build-dev and jigsaw-dev aliases after the current fix is pushed.
Thanks,
Alexandr.
>
> -phil.
>
> On 10/17/16, 4:22 AM, Alexandr Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8167176/webrev.01
>>
>> MetalBorders.bumps and MetalScrollBarUI.bumps fields are nor marked
>> for removal any more.
>>
>> Thanks,
>> Alexandr.
>>
>> On 10/14/2016 3:23 PM, Sergey Bylokhov wrote:
>>> Is it necessary to remove tese fields? For example
>>> MetalScrollBarUI.bumps looks similar to other fields
>>> MetalScrollButton.increaseButton/decreaseButton.
>>>
>>> On 13.10.16 16:15, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8167176
>>>> webrev: http://cr.openjdk.java.net/~alexsch/8167176/webrev.00
>>>> - Inaccessible classes returned by public API in swing are
>>>> changed to
>>>> their public super classes.
>>>> - Fields which expose inaccessible classes are deprecated and marked
>>>> for removal.
>>>>
>>>> Changing a public field type to its superclass is incompatible
>>>> change
>>>> with previous releases. However it is not possible to use a class
>>>> which
>>>> is not exported in JDK 9 because of the modularization feature.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>>
>>
More information about the swing-dev
mailing list