Name: bsC130419 Date: 07/11/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

We must subclass JViewport in order to make
diagonal scrolling work efficiently.

This is not easy!

All I needed to do was to replace the routine
JViewport.windowBlitPaint(Graphics g)
in order to change how repaint events are generated.

Unfortunately, this routine is *private*. Worse than that, several of the
member variables it uses are also private!

A class of type JViewport is of course needed in order to work with JScrollPane.

I was able to make this work by wholesale duplication of the code. By
duplicating almost HALF of JViewport, I was able to successfully subclass it.
Fortunately, all the private member variables were duplicate-able. But, I had
to not only make my own version of the private variable, I had to copy every
routine that *touched* those variables (to ensure the superclass's now
superfluous variables were not used). I was *extremely* fortunate that none of
the routines I needed to duplicate were declared final or package scope(and
there are some "final" routines in there)!!

This was incredibly painful, and not very Object-Oriented.

What's worse is, because of the wholesale duplication of code, my subclass is
extremely sensitive to changes in the JDK. I have not yet had time to work on a
JDK 1.4 version of it. It will take a significant effort (probably a week, at
least) to adapt my subclass to the changes in 1.4. A quick glance at the source
leads me to believe it is still possible, but I won't know this for sure until I
try.

The fix for this is simple. Use protected!!! There's no reason to make some of
these things private. windowBlitPaint() is the key to the whole class. Why not
allow us to modify its behavior as necessary? There are many protected
functions in JViewport, meaning that someone thought that it should be
subclassable. Well, finish the job! How can we subclass it if key parts are
private? (Also, there are some "final" methods, which are questionable... why
final? The HotSpot people say you shouldn't do that for performance reasons,
and I see no reason to restrict subclasses for these routines).

An alternative would be to make a Viewport interface which JViewport could
subclass, and JScrollPane could use. That's less desirable though, since I'd
still have to copy most of the code for my implementation.
(Review ID: 127336)
======================================================================