Hi, Chris.
Yes there is a room for improvements and some cleanup can be done in the
client related libraries: AWT, Java2D, Swing, JavaSound. As far as I
know there are no any projects to cleanup the code. So usually it is
done one by one.(small request to cleanup is filed and fixed, etc)
As an example you can see something like this:
https://bugs.openjdk.java.net/browse/JDK-8163949
http://mail.openjdk.java.net/pipermail/sound-dev/2016-August/000459.html
A few notes:
- You should not expect that the fix will be reviewed fast enough
because there are some more priority bugs to review. So it will be good
if the fix will be limited by small type of issues, and will cover a
reasonable number of files.
- Such fixes should not change the public API of the library(classes,
methods, fields). So you should take into account serialization for example.
- Sometimes it is possible to tweak a public API but in this case,
such requests should be filed and discussed separately.
- This is a good starting point to understand how the processes work
in OpenJDK, and later you will be able to fix some more important bugs.
On 20.10.16 14:32, Chris wrote:
While working on SkinJob, I ran IntelliJ's Code Inspector tool over
OpenJDK AWT, and I found lots of room for improvement, much of which
could be automated. Unused imports and weird indentation are the order
of the day. Raw types are often used in place of generics, leading to a
lot of unnecessary explicit casts. The deprecated Vector and Hashtable
are used in a number of places where I'm pretty sure ArrayList<> and
HashMap<> would work fine and perform better. Many abstract classes have
only one implementation. Switch statements are often missing a default
case, which means methods will fail silently if a parameter value comes
from the wrong pseudo-enum. When they do have a default case, it seems
to be at the top as often as the bottom. Magic numbers that I can easily
see a developer wanting to change (e.g. the default font size of 12) are
copied in many different places. Even when named constants for things
like color-channel bit masks exist, they aren't consistently used. There
also seem to be a fair number of unused methods that aren't public or
are buried in sun.* (and thus should be safe to delete), and a few
inconsistencies involving equals and hashCode.
Is there a project underway to clean up these sorts of issues? If so,
I'd like to help.
--
Best regards, Sergey.
