See the emails:
Fix for precise scrolling on Mac Sierra 10.12.2
http://mail.openjdk.java.net/pipermail/awt-dev/2017-January/012540.html
----------
Hello all,

A precise scrolling (introduced in Sierra) caused a fast scrolling in
old applications including Java. It was fixed in JDK by introducing an
accumulator for deltas. But Apple fixed this issue in 10.12.2 by
introducing own accumulator. So, the deltaX/Y do not correspond to the
scrollingDeltaX/Y for now. It does not affect current scrolling
implementation in Swing, but it breaks precise scrolling values in
MouseWheelEvent.

Java API assumes that all scrolling deltas are declared in terms of
unit scroll (i.e. a line height), so we should use deltaX/Y, but not
recommended scrollingDeltaX/Y. But since 10.12.2 these values are not
precise. Moreover, these values do not correspond to scrolling delta.

Actual Results:
deltaY = 0.4, scrollingDeltaY = 5,
deltaY = 0.4, scrollingDeltaY = 5,
deltaY = 0.0, scrollingDeltaY = 5,
deltaY = 0.0, scrollingDeltaY = 4,
deltaY = 0.0, scrollingDeltaY = 4,
deltaY = 1.4, scrollingDeltaY = 4,
deltaY = 0.0, scrollingDeltaY = 3,
deltaY = 0.0, scrollingDeltaY = 3,
deltaY = 0.0, scrollingDeltaY = 3,
deltaY = 0.0, scrollingDeltaY = 3,
deltaY = 1.1, scrollingDeltaY = 2,
deltaY = 0.0, scrollingDeltaY = 2,
deltaY = 0.0, scrollingDeltaY = 2,
deltaY = 0.0, scrollingDeltaY = 2,
deltaY = 0.0, scrollingDeltaY = 1,
deltaY = 0.0, scrollingDeltaY = 0,

Expected Results:
deltaY = 0.5, scrollingDeltaY = 5,
deltaY = 0.5, scrollingDeltaY = 5,
deltaY = 0.5, scrollingDeltaY = 5,
deltaY = 0.4, scrollingDeltaY = 4,
deltaY = 0.4, scrollingDeltaY = 4,
deltaY = 0.4, scrollingDeltaY = 4,
deltaY = 0.3, scrollingDeltaY = 3,
deltaY = 0.3, scrollingDeltaY = 3,
deltaY = 0.3, scrollingDeltaY = 3,
deltaY = 0.3, scrollingDeltaY = 3,
deltaY = 0.2, scrollingDeltaY = 2,
deltaY = 0.2, scrollingDeltaY = 2,
deltaY = 0.2, scrollingDeltaY = 2,
deltaY = 0.2, scrollingDeltaY = 2,
deltaY = 0.1, scrollingDeltaY = 1,
deltaY = 0.0, scrollingDeltaY = 0,

I suggest to calculate delta from the corresponding scrollingDelta if
a native event has precise scrolling deltas. Could you please review
attached webrev.zip ?
----------

MacOS: precise scrolling is too fast
http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html
----------
Hi guys,

JetBrains has some problems to continue Oracle support, and I have no
ability to submit a CR for now. But there is a critical issue in AWT
scrolling after Sierra have been released.
http://bugs.openjdk.java.net/browse/JDK-8166591

I solved this issue in our custom JDK:
http://sites.google.com/site/malenkov/java/160926

This fix is safe for existing third-party code, but it removes support
of precise scrolling. It is OK for now, because Swing does not support
it. I can provide another fix, but it may affect third-party
developers and requires additional changes in Swing. For example, the
following bug must be fixed in another way:
http://bugs.openjdk.java.net/browse/JDK-7141296
I think there are may be other issues, but I have not access to
test/closed repository to check this. Could you please move UI tests
to open-source like I did for java.beans?


I see the following steps to do:
1. fix 8166591 for comfortable scrolling in Sierra
- apply my fix (simple and almost safe) or update it
  to restore precise scrolling and fix all usages of MouseWheelEvent
2. implement new feature: Precise scrolling in Swing
- now it uses integers only
3. implement new feature: Imitate native scroll bars on Mac


I'll try to raise the issue severity as soon as we restore access to
Oracle support.
----------
Fix for DeltaAccumulator
http://mail.openjdk.java.net/pipermail/awt-dev/2017-January/012539.html
----------
Hello Alexander,

I want to suggest a change for your fix. It fixes the following issue:
http://youtrack.jetbrains.com/issue/IDEA-162490

My change updates processing of scrolling phase.
We should process events from PHASE_BEGIN to PHASE_END,
and ignore other events like PHASE_MAY_BEGIN.

Could you please review attached webrev.zip ?
----------