
	Miscellaneous Java language (and JDK) notes:


=======================

problems related to the "private" access modifier:

there's a bug in Sun's JDK 1.1.8 javac compiler (javac itself
crashes!) that sometimes occurs when private fields of the top class
are accessed by a local/anonymous inner class ...  A possible
workaround (the only one?) is to use the default "package" (or higher,
e.g protected or public) visibility for those fields. 

there's a problem if inside an anon. class we call methods of the
enclosing class of the enclosing class of the anon class: the code
that sun jdk's javac optimizer (-O) generates throws an
IllegalAccessError when running in the Netscape 4.61 JVM ...

Conclusion: better to avoid using "private" altogether!!

=======================

<code>javac</code> doesn't allow inner classes to have any static
members, but inner interfaces are Ok; In Java, all the fields
declared in an interface are implicitly <code>static final</code>.

=======================

       IndividualDataVolumePanel.ColormapDisplay
       VerticalLineComponent

Say we want a Component that will be notified when its size changes.
One way to do it is to make it a <code>Container</code> and do the
size change operations in the <code>doLayout()</code> method.
We can subclass <code>Panel</code> or <code>LightweightPanel</code>:
<ul> <li> if using <code>Panel</code>, <code>update()</code> is
reliably called, so we can save some CPU cycles; however, appletviewer
sometimes calls it twice in a row (why?).  <li> if using
<code>LightweightPanel</code>, appletviewer calls <code>paint()</code>
instead of <code>update()</code>, and netscape4 calls
<code>paint()</code> twice and then <code>update()</code> once!! </ul>
Hence, <code>Panel</code> seems a better choice.

       Slice2DViewport :

<i>Notes:</i><br> We want a Component that will be notified when its
size changes.  One way to do it is to make it a <code>Container</code>
and do the size change operations in the <code>doLayout()</code>
method. <br> This could be a "lightweight"
<code>Container/Component</code> (which doesn't have a native peer,
hence requires fewer system resources).  BUT: lightweight components
cannot manage their own paint/repaint requests, and the first
"regular" parent container does it for them.  What this seems to mean
is that our overriden <code>update()</code> is <i>not</i> called, but
that parent's <code>update()</code>, which (by default) clears our
area before calling our <code>paint()</code> -- hence annoying flicker
which cannot be eliminated (we don't have control over parent's
update) <code>:-(</code> The only solution is to make this a regular
container (non-lightweight) by subclassing <code>Panel</code> which is
the most basic <code>Container</code> ...

=======================

// this may be a better way to build small vectors: they'll probably 
// end up allocated on the stack instead of the heap, hence will
// relieve some pressure off the garbage collector... (?)
/*private*/ TextField[] 			tf= { null, null};

=======================

we _cannot_ rely on the scrollbar to produce values strictly in the
range that we specified! (e.g. NS on Win32 can produce values of max+1
...)

=======================

DataVolumePanel:

*NB* something poorly documented: "a popup menu can only be owned by
one component at a time" (which is stored in the MenuComponent::parent
field) and Component::add( PopupMenu) does *not* make a copy of its
argument!  If we add 'popup_menu' to each of our 4 panels,
PopupMenu::show() will generate exception: "IllegalArgumentException:
origin not in parent's hierarchy" on all panels except the last one we
added the popup to ...

However, we can call show( origin, ...) with an origin which is a
"child" of popup menu 's "parent", and several distinct popup menus
can have the same parent Component/Container !  The problem of making
sure that only the correct menu is poppedup for the area where the
menu click was made, one way to do it is to register the
mouselisteners with the individual panels and not with the
parent_container (otherwise parent_container's listener will have to
figure out which popup_menu to pop/show...)

=======================

DataVolumePanel.CoordinateFields: 
Note about the setText() calls for world coordinates text fields:

currently the full-precision float value is displayed; this can be a
minor inconvenience on some platforms if the user enters a long float
value that doesn't fit in the displayable no of columns of the
TextField -- e.g. Unix Netscape doesn't return the cursor to the
beginning of the field after Enter is hit, so the tail of the number
remains visible, which can be confusing... This could be avoided by
rounding-up the displayed String to a certain (e.g. 3 or 4) number of
significant digits of the float, like C's printf or like we do in
this._voxel2string().
	       
However, since this is (in a way) user's fault, and also since we
store internally the full float value, unlike voxel values which are
internally stored in 8bit, it's better to leave this the way it is
now...

=======================

DataVolumePanel.CoordinateFields:

why use a readonly textfield here instead of a awt.Label?
because textfield's dimensions don't change when the displayed
text changes! with a Label, we would have to re-validate
(i.e. redo!) the entire layout whenever we change its text...

=======================

Slice2DViewport :
note about "new" (Java 1.1) Image#drawImage( Image, 8xint, ...)
methods versus the "older" (Java 1.0) Image#drawImage().
	
Sun is a bit unclear about what's the difference between the two in
Java 1.1.x ... In Java 1.0, drawImage used to create a separate image
representation, in screen format (i.e. matching the depth of the
actual screen), at the final dimensions, for each size that was drawn
-- this can easily get memory intensive, especially for this
application. However, it's unclear if this is still the case in java
1.1.x ...  The "new" drawImage methods always perform scaling
on-the-fly (at render time) starting directly from the original image
representation. By the way, these new methods can also do clipping
themselves, unlike the older ones.

=======================

Slice2DViewport -- about drawImage() :

MUSING: if you use <code>this</code> instead of <code>null</code> as
the ImageObserver, _and_ this class is a lighweight Container, then
the applet goes into an endless repaint loop !????????  If this class
is a regular (heavy) Container, then using <code>this</code> is Ok but
it significantly slows down the slice updating !!??  on the other
hand, loading a memory image shouldn't take a "long" time (like net or
disk images do), so we shouldn't really need to "keep an eye" and see
when the loading is done... (???)  Update: example 12.3, O'Reilly's
AWT 12.3, also uses null when displaying an animated image produced by
MemoryImageSource...

=======================

drawImage(): 

In jdk1.1 there was some confusion regarding what a negative width
and/or height means for the "scaling" Java1.0 drawImage calls... Fact
is that in Java1.1 it worked (i.e. the negative value was replaced
with a value proportional with the other, non-negative, dimension),
but with the Java1.2 API it doesn't work anymore!

=======================

Multi-threading issues:

- instance fields are shared amoung threads; however, local variables
  are <i>not</i> shared amoung threads!

- assignments are atomic for all primitive Java types, except double &
  long.

- apparently Netscape does not allow applets to create other
  threadgroups

- on some browsers (win98 netscape, macos ie5), calling this from the
  applet will crash/freeze the entire browser:
       Thread.currentThread().getThreadGroup().stop();

=======================

Menu-bar woes:

- Netscape 4.7 on win98 : if the jiv frame has a menu-bar, the popup
  menus don't work properly (their text labels are not visible!)
  It appears that one cannot simultaneously use a menu-bar and popup
  menus directly attached to the same Frame !?

- MacOS (with apple's mrj) : the menu-bar menus get included in the
  system menu-bar; this is very confusing, as one cannot tell which
  menu comes from which application (e.g. there are 2 file menus, 2
  help menus, etc)

=======================




