I believe it is equivalent - just a bit more clear to be explicit.
At least that is what I found with the deprecation one on the same line.
-phil.
On 10/19/2016 10:24 AM, Sergey Bylokhov wrote:
On 19.10.16 20:05, Phil Race wrote:
is it necessary to add "exports" to "-Xlint:"? I assumed that
On 19.10.16 20:05, Phil Race wrote:
is it necessary to add "exports" to "-Xlint:"? I assumed that it
should be added somewhere else and disabled if necessary per module.
Alexander is just reversing the previous change and that is per module
http://hg.openjdk.java.net/jdk9/dev/rev/81435a812f59
On 10/19/2016 09:16 AM, Sergey Bylokhov wrote:
Did you check this fix on other platforms?
For example what about WindowsFileChooserUI.java:
DirectoryComboBoxRenderer createDirectoryComboBoxRenderer()
Note than DirectoryComboBoxRenderer is not public.
I looked at those the other day and I
Did you check this fix on other platforms?
For example what about WindowsFileChooserUI.java:
DirectoryComboBoxRenderer createDirectoryComboBoxRenderer()
Note than DirectoryComboBoxRenderer is not public.
is it necessary to add "exports" to "-Xlint:"? I assumed that it should
be added somewhere
+1 from me ...
-phil.
On 10/19/16, 8:22 AM, Alexandr Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8167176/webrev.02
- JRootPane.defaultPressAction/defaultReleaseAction fields are removed
- MetalBorders.bumps and MetalScrollBarUI.bumps
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8167176/webrev.02
- JRootPane.defaultPressAction/defaultReleaseAction fields are removed
- MetalBorders.bumps and MetalScrollBarUI.bumps are made private
- MetalFileChooserUI.createDirectoryComboBoxRenderer()
On 10/18/2016 03:54 AM, Alexandr Scherbatiy wrote:
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
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
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
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
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
Looks good.
--Semyon
On 13.10.2016 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
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
13 matches
Mail list logo
