Kimberley Burchett <[EMAIL PROTECTED]> writes:
> - What is the point of the peer architecture? If each peer has a
> non-peer counterpart, why not do everything directly in the
> non-peer?
It's easier to port that way. The peers provide the native layer, and
the non-peers provide the Java layer. The peer interfaces are
extremely simple (well, simple compared to the non-peers), and complex
calls to the non-peers end up being turned into lots of simple calls
to the peers. The peers need not handle housekeeping matters either
(such as what the current color is, or where on the screen a widget
resides).
> - Since a regular Java app only new's the non-peer classes, and you
> haven't started on them yet, how do you know the peers are working
> at all? Do you have test progs that new the peers directly,
> bypassing the non-peers?
All the peer development is done with the JDK 1.1.7 (native threads
port) for GNU/Linux. Currently, we require a JDK that uses
pthreads, and that won't change until we move to JDK 1.2.
Our peers are a drop in replacement for Sun's Motif peers, so we test
our peers using `normal' AWT code.
> - I don't have a Windows or Solaris box at home, so I can't run the
> JDK (as far as I know). I assume this would make it difficult to
> compare the behavior of a program under the JDK vs Classpath.
What kind of system do you have?
--
Paul Fisher * [EMAIL PROTECTED]
