Hi Petr,
tl;dr -- I've made the changes you've suggested and they're reflected in
http://cr.openjdk.java.net/~darcy/8043548.1/
I'll start the internal ccc paperwork now.
More comments below.
Thanks,
-Joe
On 06/24/2014 01:26 AM, Petr Pchelko wrote:
Hello, Joe.
Sorry for the delay. A couple of small comments:
BasicOptionPaneUI:1235 - is the the SuppressWarning needed here?
No; upon double-checked the line
JList<?> list = (JList)e.getSource();
will compile without warning; I've removed the SuppressWarnings annotation.
BasicScrollBarUI:1269 - why are you using <Object> here? <?> would allow work
the same and allow to avoid SuppressWarning
Yes; changed to just
JList<?> list = (JList)view;
without the annotation.
BasicTableHeaderUI, BasicTableUI - you can replace Enumeration<?> to
Enumeration<TableColumn> and avoid casts later. This applies to multiple places in
these files.
BasicTreeUI - you can replace Enumeration<?> with Enumeration<TreePath> and
avoid several cats.
Good suggestion; changed.
NimbusStyle:307 - do we need this SuppressWarning?
No; deleted.
:472 - you could reuse a helper function here too
Yeah; I wanted to keep the helper function private.
:863 - is this comment a leftover from your work? I don't
think it's good for production, it's not very self-explanatory.
Yes; it is a leftover comment which I've now removed. (The State type
has a bug in how it is generified; using raw types in this method is the
least-bad way of accommodating State.)
SynthComboBoxUI:223 - is this needed?
No; removed.
SynthTableHeaderUI:244 - is this SuppressWarning really needed? It looks like after
you've changed RowSorter to RowSorter<?> theres no warning on line 245 any more.
Removed.
Thank you.
With best regards. Petr.
On 23 июня 2014 г., at 19:43, Joe Darcy <[email protected]> wrote:
*ping*
I'd like to push this change soon. (I know it is tedious to review; it was also
tedious to generate ;-)
Thanks,
-Joe
On 06/18/2014 05:01 PM, Joe Darcy wrote:
Hello,
Any comments on these proposed changes?
Thanks,
-Joe
On 06/14/2014 06:13 PM, Joe Darcy wrote:
PS This change involves various API updates; once those are settled, I'll file
the internal ccc paperwork.
PPS The javax.swing.plaf.nimbus.State class is generified in an odd manner.
-Joe
On 06/14/2014 04:44 PM, Joe Darcy wrote:
Hello,
Please review the (unexpected large) fix for
JDK-8043548: Fix raw and unchecked lint warnings in javax.swing.plaf.*
http://cr.openjdk.java.net/~darcy/8043548.0/
In most of the javax.swing.multi.MultiFoo.java type, I replaced a raw Vector with a
Vector<ComponentUI> and was then able to delete a number of now redundant
casts. In some of the MultiFoo classes,
src/share/classes/javax/swing/plaf/multi/MultiPopupMenuUI.java
src/share/classes/javax/swing/plaf/multi/MultiTabbedPaneUI.java
src/share/classes/javax/swing/plaf/multi/MultiTextUI.java
src/share/classes/javax/swing/plaf/multi/MultiTreeUI.java
all the elements stored are actually a more specific type than ComponentUI, say,
PopupMenuUI. In those cases, I still used a Vector<ComponentUI> rather than, say, a
Vector<PopupMenuUI> to deal with other aspects of the API. In particular, the
MultiFoo classes have a method
ComponentUI[] getUIs() methods
which is computed over in MultiLookAndFeel. Generifying methods in
MultiLookAndFeel, particularly creatUIs, to work properly in the face of
generics would unfortunately be problematic.
A few classes in javax.swing had to be updated now to fully clear the warnings
in plaf; the rest of javax.swing will be handled in future work (JDK-8043550:
Fix raw and unchecked lint warnings in javax.swing.*).
Some additional changes were needed in sun/swing/BakedArrayList.java, but that
class should probably be removed from the platform.
I ran SwingSet2 with a build having these changes and nothing appeared
obviously wrong.
Thanks,
-Joe
