public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Interrupted IO and AWT
  2000-04-01  0:00           ` Jeff Sturm
@ 2000-03-20  6:19             ` Jon Beniston
  2000-03-20  7:07               ` Jeff Sturm
                                 ` (3 more replies)
  2000-04-01  0:00             ` libgcj for win32 Tom Tromey
  1 sibling, 4 replies; 115+ messages in thread
From: Jon Beniston @ 2000-03-20  6:19 UTC (permalink / raw)
  To: java-discuss

Hi,

I seem to recall reading somewhere on Sun's Bug list that the interrupting
of IO has in some form been deprecated. Does any one know whether this is
the case? I ask, because I'm wondering whether I should implement this in
the Win32 port. It seems as if there may be some overhead. Would this be
worth it it the general case? Personally, I've never made use of it.

Secondly, I'm quite interested in doing some work on implementing AWT (I'm
more intrested in Client stuff myself). I was wondering if someone could
clear up the position of this, esp. regarding the Classpath merger. I seem
to recall that everything from Classpath is available except the AWT code.
Now is this all AWT code or just the native implementation? IF I do use it
what is the final result? That the executable is cover by the GPL? I can
live with that for now...

Jon Beniston.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
@ 2000-03-20  7:07               ` Jeff Sturm
  2000-03-20  8:21                 ` Tom Tromey
  2000-04-01  0:00                 ` Jeff Sturm
  2000-03-20  8:22               ` Tom Tromey
                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-20  7:07 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> I seem to recall reading somewhere on Sun's Bug list that the interrupting
> of IO has in some form been deprecated. Does any one know whether this is
> the case? I ask, because I'm wondering whether I should implement this in
> the Win32 port. It seems as if there may be some overhead. Would this be
> worth it it the general case? Personally, I've never made use of it.

This was covered in the thread last week on Thread.interrupt():
 
http://sourceware.cygnus.com/ml/java-discuss/2000-q1/msg00418.html

I think the collective opinion on this list was that both interruptable
I/O and resource revocation are desirable in libgcj.  If I had my
choice, interruptable I/O would be a configure-time option that could be
turned off for strict JDK compatibility (or better
performance/robustness in the case of Win32).

I remember reading somewhere that interruptible I/O can be implemented
on NT with async I/O, but that it won't work for 95/98 (which I couldn't
care less about, personally).  That may have changed since I read it...

> Secondly, I'm quite interested in doing some work on implementing AWT (I'm
> more intrested in Client stuff myself). I was wondering if someone could
> clear up the position of this, esp. regarding the Classpath merger. I seem
> to recall that everything from Classpath is available except the AWT code.
> Now is this all AWT code or just the native implementation? IF I do use it
> what is the final result? That the executable is cover by the GPL? I can
> live with that for now...

From looking at Warren Levy's latest patches, I'd guess that the libgcj
maintainers haven't given up on doing their own AWT port, independently
of classpath.

AWT would be great... you might consider a portable toolkit (GTK?)
though before it becomes too Win32-centric, so that other platforms can
benefit.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  7:07               ` Jeff Sturm
@ 2000-03-20  8:21                 ` Tom Tromey
  2000-03-20 10:30                   ` Per Bothner
                                     ` (2 more replies)
  2000-04-01  0:00                 ` Jeff Sturm
  1 sibling, 3 replies; 115+ messages in thread
From: Tom Tromey @ 2000-03-20  8:21 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Jon Beniston, java-discuss

Jeff> If I had my choice, interruptable I/O would be a configure-time
Jeff> option that could be turned off for strict JDK compatibility (or
Jeff> better performance/robustness in the case of Win32).

I think this would be a reasonable approach.

>> Secondly, I'm quite interested in doing some work on implementing
>> AWT (I'm more intrested in Client stuff myself). I was wondering if
>> someone could clear up the position of this, esp. regarding the
>> Classpath merger. I seem to recall that everything from Classpath
>> is available except the AWT code.  Now is this all AWT code or just
>> the native implementation? IF I do use it what is the final result?
>> That the executable is cover by the GPL? I can live with that for
>> now...

Jeff> From looking at Warren Levy's latest patches, I'd guess that the
Jeff> libgcj maintainers haven't given up on doing their own AWT port,
Jeff> independently of classpath.

Warren's recent patches notwithstanding, we haven't started
implementing AWT.  Those were needed for something else.

Jeff> AWT would be great... you might consider a portable toolkit
Jeff> (GTK?)  though before it becomes too Win32-centric, so that
Jeff> other platforms can benefit.

My goal is to have a retargetable AWT -- one where we can plug in
different back ends.  So we might have a Gtk+ back end (the one I'd
like to see :-), a Windows back end, and even a back end running on a
framebuffer (for embedded folks).  I don't know enough about AWT to
say whether this is a realistic plan.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
  2000-03-20  7:07               ` Jeff Sturm
@ 2000-03-20  8:22               ` Tom Tromey
  2000-03-20 12:03                 ` Paul Fisher
  2000-04-01  0:00                 ` Tom Tromey
  2000-03-21  0:57               ` Interrupted IO and AWT -> Remote AWT Jens Wilke
  2000-04-01  0:00               ` Interrupted IO and AWT Jon Beniston
  3 siblings, 2 replies; 115+ messages in thread
From: Tom Tromey @ 2000-03-20  8:22 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon> Secondly, I'm quite interested in doing some work on implementing
Jon> AWT (I'm more intrested in Client stuff myself). I was wondering
Jon> if someone could clear up the position of this, esp. regarding
Jon> the Classpath merger. I seem to recall that everything from
Jon> Classpath is available except the AWT code.  Now is this all AWT
Jon> code or just the native implementation? IF I do use it what is
Jon> the final result? That the executable is cover by the GPL? I can
Jon> live with that for now...

All the AWT code in Classpath is under the GPL.  We aren't going to
merge it into libgcj.  It might be possible to get it to work with
libgcj; if you do so your resulting application will be GPL -- at
least, as I understand it.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:21                 ` Tom Tromey
@ 2000-03-20 10:30                   ` Per Bothner
  2000-03-20 12:42                     ` Jeff Sturm
  2000-04-01  0:00                     ` Per Bothner
       [not found]                   ` <38D681A9.1ED6097A@berger.to>
  2000-04-01  0:00                   ` Interrupted IO and AWT Tom Tromey
  2 siblings, 2 replies; 115+ messages in thread
From: Per Bothner @ 2000-03-20 10:30 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.

It is quite realistic - that is what the "peer" architecture
was meant to support.  However, Swing uses a different approach:
The actual widgets are written in "pure Java", using the operations
defined in java.awt.Graphics.

The two approaches have different trade-offs:
- Native peers can probably be implemented faster than a Swing-like
solution.
- Native peers may have better compatibility (both look-and-feel and
programming-wise) than pure Java widgets.
- Pure Java widgets as in Swing may make the system more coherent
and give better control.  It is probably is easier to get full
compatibility with Sun for the Swing widgets.
- Pure Java widgets allow compatibility with Swing's "pluggable-
look-and-feel" (PLAF).  However, I'm not sure that is important.
I would rather have PLAF built using (say) gtk's theability.

I suspect we may end up doing a little of both.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:22               ` Tom Tromey
@ 2000-03-20 12:03                 ` Paul Fisher
  2000-04-01  0:00                   ` Paul Fisher
  2000-04-01  0:00                 ` Tom Tromey
  1 sibling, 1 reply; 115+ messages in thread
From: Paul Fisher @ 2000-03-20 12:03 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> All the AWT code in Classpath is under the GPL.

The GTK+ Peers are LGPL'd.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 10:30                   ` Per Bothner
@ 2000-03-20 12:42                     ` Jeff Sturm
  2000-03-20 12:51                       ` Tom Tromey
                                         ` (3 more replies)
  2000-04-01  0:00                     ` Per Bothner
  1 sibling, 4 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-20 12:42 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> The two approaches have different trade-offs:
> - Native peers can probably be implemented faster than a Swing-like
> solution.

To my knowledge there exist no free or third-party implementations of
Swing.  It could be extremely difficult to do.

> - Native peers may have better compatibility (both look-and-feel and
> programming-wise) than pure Java widgets.

Especially if a toolkit (i.e. GTK+) is used.  It's also possible to
write native peers using Xlib or Win32/GDI directly... though this leads
to the same interoperability problems as Swing.

(Sun never really got this part right.  AWT applications on Linux don't
look right because Sun used the archaic Motif toolkit.  Early versions
of the Win32 JDK did use MFC to inherit a certain amount of Win32
behavior, but that was later scrapped for direct window/graphics calls.)

> - Pure Java widgets allow compatibility with Swing's "pluggable-
> look-and-feel" (PLAF).  However, I'm not sure that is important.
> I would rather have PLAF built using (say) gtk's theability.

Me too.

Let's say somebody wants to use gcj to write desktop apps for KDE or
Gnome.  How would they best proceed?  Swing is not a good fit because
apps written in Swing tend to look like, umm, Swing.  The PLAF's are a
bad idea because they don't leverage a native toolkit, they attempt to
reimplement it in Java.  Consequently Swing PLAFs are both difficult to
write and imperfect in their emulation.

AWT isn't so good either because it doesn't leverage much of the
capability of good toolkits out there... e.g. there is no tree widget or
image button in AWT.

I'd like to see real Java bindings in GTK and/or KDE so developers can
write first class Java apps for those environments.  Then implement AWT
and (possibly) Swing atop this native API to be compatibile with other
Java applications.

To me this is consistent with the apparent philosophy of the gcj
project: remain compatible with Java but innovate where appropriate. 
Gcj has already innovated with CNI.

(Those who are in the "pure Java" camp will likely disagree with me.  My
aim is not to compromise Java compatibility, but extend its reach to
application domains where it has flopped, like desktop programming.)


-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42                     ` Jeff Sturm
@ 2000-03-20 12:51                       ` Tom Tromey
  2000-04-01  0:00                         ` Tom Tromey
  2000-03-20 13:09                       ` Paul Fisher
                                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2000-03-20 12:51 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

Jeff> I'd like to see real Java bindings in GTK and/or KDE so developers can
Jeff> write first class Java apps for those environments.  Then implement AWT
Jeff> and (possibly) Swing atop this native API to be compatibile with other
Jeff> Java applications.

I believe there is a Java/Gnome effort, which provides Java bindings
for Gtk and Gnome.  I haven't looked to see how hard it would be to
make it work with gcj.

I think this is a reasonable approach as well.  We still need AWT and
Swing for compatibility and for people who want to write "Java
portable" applicatoins.

This also opens up the possibly weird capability of writing a pure
Java AWT on top of the Java Gtk package.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42                     ` Jeff Sturm
  2000-03-20 12:51                       ` Tom Tromey
@ 2000-03-20 13:09                       ` Paul Fisher
  2000-03-20 13:25                         ` Per Bothner
  2000-04-01  0:00                         ` Paul Fisher
  2000-03-20 13:17                       ` Per Bothner
  2000-04-01  0:00                       ` Jeff Sturm
  3 siblings, 2 replies; 115+ messages in thread
From: Paul Fisher @ 2000-03-20 13:09 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Let's say somebody wants to use gcj to write desktop apps for KDE or
> Gnome.  How would they best proceed?

Currently, using the standard Java AWT API is their best bet, with the
GTK+ Peer libraries from Classpath.  There's also the `java-gnome'
project <URL: http://www.lirmm.fr/~gutkneco/devpt/javagnome.html >,
which provides Java bindings for the GTK+ and Gnome APIs.

I read somewhere recently that the KDE project has started work on a
set of Qt AWT peers, but I don't have a URL handy.

> The PLAF's are a bad idea because they don't leverage a native
> toolkit, they attempt to reimplement it in Java.

There's no reason why a Swing PLAF couldn't be written that does
leverage the native toolkit.  (A GTK+ Swing PLAF is on the TODO list
for Classpath).

> AWT isn't so good either because it doesn't leverage much of the
> capability of good toolkits out there... e.g. there is no tree
> widget or image button in AWT.

Strictly speaking, it's permissible for getGraphics to return a valid
Graphics object for any Component.  The peer side, however, is only
required to return a valid Graphics object for Canvas and Container.
So, it is possible (and legal) to doodle on random widgets, assuming
the peer implementation supports it.

> Then implement AWT and (possibly) Swing atop this native API to be
> compatibile with other Java applications.

Swing, by design, only depends on the basic drawing primitives of the
AWT.

I don't believe it would be feasible to actually implement Swing using
GTK+ or Qt (for example, directly mapping the Swing tree widget to
GTK+'s tree widget).  However, I've often thought about this
possibility; it's certainly appealing.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42                     ` Jeff Sturm
  2000-03-20 12:51                       ` Tom Tromey
  2000-03-20 13:09                       ` Paul Fisher
@ 2000-03-20 13:17                       ` Per Bothner
  2000-03-20 17:48                         ` Bryce McKinlay
  2000-04-01  0:00                         ` Per Bothner
  2000-04-01  0:00                       ` Jeff Sturm
  3 siblings, 2 replies; 115+ messages in thread
From: Per Bothner @ 2000-03-20 13:17 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> To my knowledge there exist no free or third-party implementations of
> Swing.  It could be extremely difficult to do.

I know.  My recommendation is to write a subset of Swing (and AWT), and
enhancing it as people feel motivated.

> I'd like to see real Java bindings in GTK and/or KDE so developers can
> write first class Java apps for those environments.  Then implement AWT
> and (possibly) Swing atop this native API to be compatibile with other
> Java applications.

I agree with one slight modification:  Rather than write a direct
Java wrapper for gtk, I'd like us to use the AWT or Swing class
and method names whenever they match.  The main thing is I want to
avoid excess helper objects:  We would have a Window, which may
points to a WindowPeer, which may contain a RawData that points
to a gtk handle.  What I want to avoid when possible is an additional
Gtk Java wrapper; whatever class we use to wrap a gtk window
should implement the WindowPeer interface, without requiring yet
another class to do so.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:09                       ` Paul Fisher
@ 2000-03-20 13:25                         ` Per Bothner
  2000-03-21 14:21                           ` Paul Fisher
  2000-04-01  0:00                           ` Per Bothner
  2000-04-01  0:00                         ` Paul Fisher
  1 sibling, 2 replies; 115+ messages in thread
From: Per Bothner @ 2000-03-20 13:25 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> I don't believe it would be feasible to actually implement Swing using
> GTK+ or Qt (for example, directly mapping the Swing tree widget to
> GTK+'s tree widget).  However, I've often thought about this
> possibility; it's certainly appealing.

One of the fundamental ideas of Swing is the separation of "model"
and "view+controller".  For example two JTextPanes can both be using the
same Document.  How suitable are gtk widgets for doing things like that?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:17                       ` Per Bothner
@ 2000-03-20 17:48                         ` Bryce McKinlay
  2000-03-21  7:18                           ` Tom Tromey
  2000-04-01  0:00                           ` Bryce McKinlay
  2000-04-01  0:00                         ` Per Bothner
  1 sibling, 2 replies; 115+ messages in thread
From: Bryce McKinlay @ 2000-03-20 17:48 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:

> Rather than write a direct
> Java wrapper for gtk, I'd like us to use the AWT or Swing class
> and method names whenever they match.

I've been considering something similar to this. In addition to exposing
more of the native toolkits functionality to Java code, there's another good
reason reason to create an AWT/Swing-ALIKE API: performance. The AWT is slow
by design due both to the requirements of thread safety and its
event-dispatch queue based design. Because it isn't inherently thread-safe
(and probably never can be), virtually every call into the native peers
needs to be synchronized around a global lock using either either gtk's own
locking or java synchronization. This means calling gtk_threads_enter() and
gtk_threads_leave() inside every native peer method implementation, which no
doubt adds considerable overhead. The other problem is AWT's event-dispatch
queue based design. The native peers exist on a different thread to the
event-dispatch thread, and these communicate using a synchronized queue. For
every event generated by the native peer implementation (every keystroke,
every mouse movement, unmask event, refresh, etc), an event object must be
constructed, and the queue synchronized. The event dispatch thread then
synchronizes with the queue, grabs the oldest event, and calls into user
code to have it processed. The queue lock is always under contention by the
thread(s) putting events onto it and the E.D.T. pulling events off it, and
as we know, locking between native threads is slow. I suspect this is the
major reason why the user-threads based Sun/Borland JDK 1.2.2 performs so
well running JBuilder and other swing apps compared to the other, native
threaded JDKs like IBM 1.1.8 (which by all benchmarks has a much superior
JIT and memory management) - its thread synchronization is 5x or more faster
than linux native locks.

Despite the above problems, I'm still confident that we can do basic,
correct AWT functionality with reasonable performance, mainly because the
lack of JNI overhead will do much to make up for these other things. A good,
working AWT (that can run Swing 1.1) should attract a lot more people to gcj
and show off what can be done with it. I guess the only real way to see how
fast it will be is to implement it and see ;-)

However, by imposing a few restrictions on what can and can't be done wrt
threads and gui calls: like requiring the application to make all gui calls
from one master thread (which, I should point out, Swing already does), and
by having the application call a blocking "EventDispatch.start()" type
method instead of relying on an implicit event dispatch thread, it should be
possible to create an AWT-like API that can expose a lot more native
functionality and is also very fast. By doing this, and by adding swing-like
functionality to it, we would essentially be creating a new toolkit API -
but modeled after the existing ones to ease transition of code to it.

Of course the real solution to the synchronization problem lies in having
better threads support, ie an n:n threading model like Solaris/BeOS/Windows
- but this is something that needs to be done at the glibc/kernel level
rather than in libgcj. Using hybrid/user threads in libgcj would probably
suck because it would be very difficult to make them interact well with
existing native code. The BeOS toolkit for example is very multithreaded and
also very responsive, so it is possible...


> avoid excess helper objects:  We would have a Window, which may
> points to a WindowPeer, which may contain a RawData that points
> to a gtk handle.  What I want to avoid when possible is an additional
> Gtk Java wrapper; whatever class we use to wrap a gtk window
> should implement the WindowPeer interface, without requiring yet
> another class to do so.

Yes, I don't see any reason why there should (usually) be anything other
than AWT object -> peer interface -> Peer implementation object, where the
peer implementation class consists of part java/part native code.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
       [not found]                   ` <38D681A9.1ED6097A@berger.to>
@ 2000-03-20 20:59                     ` Cedric Berger
  2000-03-20 21:30                       ` Per Bothner
                                         ` (5 more replies)
  0 siblings, 6 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-20 20:59 UTC (permalink / raw)
  To: java-discuss

Nobody uses AWT widgets anymore. I've never seen a new AWT
application the last two years. In fact, Swing is widely recognized
as the better GUI toolkit availabe today (and I'm not speaking of
Java only). The main problem so far was speed, but JDK 1.3 is
much better, and having the code compiled with a tool like GCJ
will also make it much faster.

There has been a lot of discussion about AWT vs Swing design
option, and I think that most people agree that Swing has two
major advantages over AWT:
1) platform independence: you don't need to test thing on many
platform, the code is the same, the bugs are the same, ...
2) flexibility: there is not a single part of the Swing library that
I cannot replace or subclass in an application. Syntax coloring,
for example, can be done with 20-50 lines of code, by just
replacing the text RENDERER.

IMHO, the right way to develop a graphic library for Java today
is:

1) implementing the basic (low level) AWT functionalities.
Basically Window/Frame/Component/Container/Canvas and
event handling.

2) implementing Java2D (it's probably more difficult than 1),
but it can be done later and its probably a lot of fun to do.

3) implementing Swing on top of the minimal AWT (or
borrowing it from 1.1 as a temporary solution). Swing is not
a trivial piece of code, but the advantage is that since almost
all functions/members of Swing are either public or protected,
all the skeleton of the code can be written from the JavaDoc
output of swing. "only" filling the method's body is required.

4) if somebody really need it at that point, implementing
AWT widgets by calling Swing code: I believe that it is (or
was) Sun's plan too.

Cedric

Tom Tromey wrote:

> >> Secondly, I'm quite interested in doing some work on implementing
> >> AWT (I'm more intrested in Client stuff myself). I was wondering if
> >> someone could clear up the position of this, esp. regarding the
> >> Classpath merger. I seem to recall that everything from Classpath
> >> is available except the AWT code.  Now is this all AWT code or just
> >> the native implementation? IF I do use it what is the final result?
> >> That the executable is cover by the GPL? I can live with that for
> >> now...
>
> Jeff> From looking at Warren Levy's latest patches, I'd guess that the
> Jeff> libgcj maintainers haven't given up on doing their own AWT port,
> Jeff> independently of classpath.
>
> Warren's recent patches notwithstanding, we haven't started
> implementing AWT.  Those were needed for something else.
>
> Jeff> AWT would be great... you might consider a portable toolkit
> Jeff> (GTK?)  though before it becomes too Win32-centric, so that
> Jeff> other platforms can benefit.
>
> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.
>
> Tom


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
@ 2000-03-20 21:30                       ` Per Bothner
  2000-03-20 22:23                         ` Bryce McKinlay
                                           ` (4 more replies)
  2000-03-20 22:13                       ` Bryce McKinlay
                                         ` (4 subsequent siblings)
  5 siblings, 5 replies; 115+ messages in thread
From: Per Bothner @ 2000-03-20 21:30 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger <cedric@wireless-networks.com> writes:

> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.

I agree this comes first.

> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

It seems plausible to use libart (see http://www.levien.com/libart/
and http://developer.gnome.org/arch/imaging/libart.html ).

> 3) implementing Swing on top of the minimal AWT (or
> borrowing it from 1.1 as a temporary solution). Swing is not
> a trivial piece of code, but the advantage is that since almost
> all functions/members of Swing are either public or protected,
> all the skeleton of the code can be written from the JavaDoc
> output of swing. "only" filling the method's body is required.

Well, this is the "pure Java" approach.  It may make sense
to use existing Gtk widgets instead.  It may also make sense
to do provide both:  I.e. the toolkit by default uses Gtk
widgets, but that can be overridden.

I think the "model" classes should be pure Java (except perhaps
a few CNI methods for speed).  However, the "view" classes
should perhaps be based on gtk widgets.  At least the default
implementation of the view classes should use the gtk theme
framework.

One exciting idea I want to explore is to use the XSL
"formatting object" model for views.  See http://www.w3.org/TR/xsl/ 
We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
which is an open-source implementation in Java sponsored by the Apache
XML Project.  FOP can generate pdf - and it also includes
a viewer, so it could form the basis for a "view engine".
(However, I don't know if the Apache license is viewed as
being compatible with the modified-GPL of libgcj.)

Similarly, it might be cool to have the Element hierarchy of a
Swing Document implement the org.w3c.dom.Node.  This might provide
a nice integrated and efficient XML environment.

> 4) if somebody really need it at that point, implementing
> AWT widgets by calling Swing code

That is my suggestion, too.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
  2000-03-20 21:30                       ` Per Bothner
@ 2000-03-20 22:13                       ` Bryce McKinlay
  2000-04-01  0:00                         ` Bryce McKinlay
  2000-03-21  2:18                       ` David Pettersson
                                         ` (3 subsequent siblings)
  5 siblings, 1 reply; 115+ messages in thread
From: Bryce McKinlay @ 2000-03-20 22:13 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:

> Nobody uses AWT widgets anymore. I've never seen a new AWT
> application the last two years. In fact, Swing is widely recognized
> as the better GUI toolkit availabe today (and I'm not speaking of
> Java only). The main problem so far was speed, but JDK 1.3 is
> much better, and having the code compiled with a tool like GCJ
> will also make it much faster.

Definatly. Swing is a far superior toolkit to anything else I've ever seen.
Its weaknesses (apart from speed) are poor intergration with native
applications and poor integration between swing applications (eg cut &
paste, drag & drop, etc - although I think these are being remedied
somewhat in JDK 1.3). These are the things we'd be adressing with a "gcj
toolkit". I want to write native applications, but with a Swing API.

> IMHO, the right way to develop a graphic library for Java today
> is:
>
> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.
>
> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

Yeah, whatever the long term plans, we've got to start somewhere.
Implementing an AWT 1.1 using gtk native peers that can run Sun's Swing 1.1
distribution is a reasonable goal in the short term.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 21:30                       ` Per Bothner
@ 2000-03-20 22:23                         ` Bryce McKinlay
  2000-04-01  0:00                           ` Bryce McKinlay
  2000-03-20 22:25                         ` Cedric Berger
                                           ` (3 subsequent siblings)
  4 siblings, 1 reply; 115+ messages in thread
From: Bryce McKinlay @ 2000-03-20 22:23 UTC (permalink / raw)
  To: Per Bothner; +Cc: Cedric Berger, java-discuss

Per Bothner wrote:

> I think the "model" classes should be pure Java (except perhaps
> a few CNI methods for speed).  However, the "view" classes
> should perhaps be based on gtk widgets.  At least the default
> implementation of the view classes should use the gtk theme
> framework.

Why not do the view classes in Java as well? Implementing Swing's level
of elegance and complexity (even just the views) in C is not something
I'd consider either "fun" or "realistic". Given the elimination of the
synchronization issues, and good garbage collection, the Java
implementation would be allmost as fast. "view" classes written in Java
could even be used by traditional programs written in C(++) as if they
were native gtk widgets, given a bit of glue.

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.

Yes, this sounds very cool.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 21:30                       ` Per Bothner
  2000-03-20 22:23                         ` Bryce McKinlay
@ 2000-03-20 22:25                         ` Cedric Berger
  2000-03-20 22:56                           ` Per Bothner
  2000-04-01  0:00                           ` Cedric Berger
  2000-03-21  1:01                         ` Joerg Brunsmann
                                           ` (2 subsequent siblings)
  4 siblings, 2 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-20 22:25 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:

> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
>
> It seems plausible to use libart (see http://www.levien.com/libart/
> and http://developer.gnome.org/arch/imaging/libart.html ).

Wow, this looks great!

> > 3) implementing Swing on top of the minimal AWT (or
> > borrowing it from 1.1 as a temporary solution). Swing is not
> > a trivial piece of code, but the advantage is that since almost
> > all functions/members of Swing are either public or protected,
> > all the skeleton of the code can be written from the JavaDoc
> > output of swing. "only" filling the method's body is required.
>
> Well, this is the "pure Java" approach.  It may make sense
> to use existing Gtk widgets instead.  It may also make sense
> to do provide both:  I.e. the toolkit by default uses Gtk
> widgets, but that can be overridden.

What is the real advantage of Gtk over "pure Java"? Speed?
What can you do with Gtk that you can't do with "pure Java"?
I must say that I don't know a lot about Gtk (unfortunatly, the
only native toolkit I've ever programmed so far is Win32/MFC)
but having used Swing a lot, I can see a lot of adventages of
"pure Java" over any native toolkit.

> I think the "model" classes should be pure Java (except perhaps
> a few CNI methods for speed).  However, the "view" classes
> should perhaps be based on gtk widgets.  At least the default
> implementation of the view classes should use the gtk theme
> framework.

Do you thing it is feasible to implement that? Again, I don't know
Gtk very well, but I would have troubles doing that with Win32.

And it is sometimes interresting to be able to modify the "view"
part of a widget. If I take again my example of syntax coloring;
I've been able to implement that very easily with Swing because
I've change the *view* part of the simple (plain) text pane: the
document remains a list of lines of ascii text (without style info)
and I've just overriden the drawLine() method of the View. No
need to insert style info or anything special into the "model"

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.  FOP can generate pdf - and it also includes
> a viewer, so it could form the basis for a "view engine".
> (However, I don't know if the Apache license is viewed as
> being compatible with the modified-GPL of libgcj.)

I'm not quite sure I understand what you mean: the FOP viewer
is built on top of Java2D, but kind of GUI widget do you want to
build with FOP?
Or do you thing about generating PDFs from Java2D? that would
be very cool!

Cedric


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:25                         ` Cedric Berger
@ 2000-03-20 22:56                           ` Per Bothner
  2000-03-21  9:26                             ` Cedric Berger
  2000-04-01  0:00                             ` Per Bothner
  2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 2 replies; 115+ messages in thread
From: Per Bothner @ 2000-03-20 22:56 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger <cedric@wireless-networks.com> writes:

> What is the real advantage of Gtk over "pure Java"? Speed?

(Speed is not a major advantage - we always have the option of
replacing critical methods by CNI for a "mostly-Java" solution.)
(1) It may be easier to implement something useful if we build on gtk.
(2) Increased compatibility at the code level between C/C++/Java,
makes it more feasible to mix components in different languages.
(3) Better look+feel compatibility between Java apps and Gnome
apps.  Specifically, Swing L+F should follow gtk themes.

I think (3) is the most important, at least long-term.
At the very least, we need a default Swing look+feel that just
uses the current gtk theme.

> And it is sometimes interresting to be able to modify the "view"
> part of a widget. If I take again my example of syntax coloring;
> I've been able to implement that very easily with Swing because
> I've change the *view* part of the simple (plain) text pane: the
> document remains a list of lines of ascii text (without style info)
> and I've just overriden the drawLine() method of the View. No
> need to insert style info or anything special into the "model"

Yes, but that does not preclude having the default rendering
use the native (gtk) toolkit.  (I don't know what's involved though.)

> I'm not quite sure I understand what you mean: the FOP viewer
> is built on top of Java2D, but kind of GUI widget do you want to
> build with FOP?
> Or do you thing about generating PDFs from Java2D? that would
> be very cool!

I was thinking of using the the abstract "formatting object"
model specified for XSL as the way to organize the Swing View
hierarchies, and possibly using FOP as the basis for such an
implementation.

The idea is we use the XSL spec as a design document for how
to construct View hierarchies.  I.e. wherever XSL has an Area,
we create a sub-class of View with the corresponding semantics.
We have the option of using the FOP implementation (assuming the
licensing is ok), but the design is more important than the code.

This has the obvious advantage of making it easier to write tools
to process XML, but it may have a less obvious advantage in that a
lot of the Swing documentation is under-specified, and trying to
reverse engineer View hierachies is both painful and requires
care with the legalities.  (Though Topley's "Core Swing advanced
programming" gives a fair bit of information.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT -> Remote AWT
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
  2000-03-20  7:07               ` Jeff Sturm
  2000-03-20  8:22               ` Tom Tromey
@ 2000-03-21  0:57               ` Jens Wilke
  2000-04-01  0:00                 ` Jens Wilke
  2000-04-01  0:00               ` Interrupted IO and AWT Jon Beniston
  3 siblings, 1 reply; 115+ messages in thread
From: Jens Wilke @ 2000-03-21  0:57 UTC (permalink / raw)
  To: java-discuss

Hi!

Just a information for the "AWT-people". IBM has a so called "remote AWT"
implementation, which they
mainly intended to run graphic application on the AS/400 platform. Any AWT
and TCP/IP aware JRE
should serve as display client, and on the server side you only need TCP/IP.

Perhaps this is a nice short-term approach, and someone is interested in
experimenting with it. I have
no idea whether it is possible to get it running with gcj.

Look at:
http://www.alphaworks.ibm.com/formula/remoteawtforjava

--
Jens


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 21:30                       ` Per Bothner
  2000-03-20 22:23                         ` Bryce McKinlay
  2000-03-20 22:25                         ` Cedric Berger
@ 2000-03-21  1:01                         ` Joerg Brunsmann
  2000-04-01  0:00                           ` Joerg Brunsmann
  2000-03-21 14:33                         ` Paul Fisher
  2000-04-01  0:00                         ` Per Bothner
  4 siblings, 1 reply; 115+ messages in thread
From: Joerg Brunsmann @ 2000-03-21  1:01 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

Per Bothner wrote:

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.  FOP can generate pdf - and it also includes
> a viewer, so it could form the basis for a "view engine".

"A tool is a great tool if it is used in a context for which it wasn't
designed." Obviously FOP is a great tool implementing an ambitious idea,
I agree. 

Anyway, we've been using XSL for over one year now when it was *one* 
specification. Nowadays it has been splitted into *three* specifications: 
XSLT, XPath and XSL FO. We are quite happy with XML/XSL/XPath combination, 
although the XSL processor's performs weakly when used with big XML source 
documents. Due to modifications in the spec we were forced to rewrite our 
XSL a couple of times. XSLT and XPath are now recommendations so this 
doesn't apply anymore. XSL FO is still a working draft which has
had significant modifications over the time. FOP doesn't implement the
current XSL FO specification. I think James Tauber left as an active
developer. XSL FO is a *huge* specification and the implementation needs
a lot of skills, knowledge, time and energy.

If this all sounds too destructive let me say this: in a year from now libgcj 
might have AWT and/or Swing, the XSL FO specification is a W3C recommendation, 
FOP has implemented 60% of the specification and someone might want to start 
using FOP with libgcj.

Jörg

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
  2000-03-20 21:30                       ` Per Bothner
  2000-03-20 22:13                       ` Bryce McKinlay
@ 2000-03-21  2:18                       ` David Pettersson
  2000-04-01  0:00                         ` David Pettersson
  2000-03-21  6:48                       ` Jeff Sturm
                                         ` (2 subsequent siblings)
  5 siblings, 1 reply; 115+ messages in thread
From: David Pettersson @ 2000-03-21  2:18 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Hi,

On Mon, 20 Mar 2000, Cedric Berger wrote:

> Nobody uses AWT widgets anymore. I've never seen a new AWT
> application the last two years. In fact, Swing is widely recognized
> as the better GUI toolkit availabe today (and I'm not speaking of
> Java only). The main problem so far was speed, but JDK 1.3 is
> much better, and having the code compiled with a tool like GCJ
> will also make it much faster.
> 

-- cut --

I do use AWT. I started with Swing but change since I want my code to
run everywhere. Applet using AWT can be used in browsers like netscape
without any problems, extra downloads etc ... . Using AWT make it thus
possible to let costumers easy test a restricted version online before
purchasing the thing. With Swing, well I havn't got netscape to work with
it. AWT seems to be the most portable gui to use and therefore the first
thing that should be implemented. As noted in other answers, swing 1.1
is possible to use then to.

David.


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
                                         ` (2 preceding siblings ...)
  2000-03-21  2:18                       ` David Pettersson
@ 2000-03-21  6:48                       ` Jeff Sturm
  2000-03-21  9:00                         ` Cedric Berger
                                           ` (2 more replies)
  2000-03-21  8:56                       ` ks
  2000-04-01  0:00                       ` Cedric Berger
  5 siblings, 3 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21  6:48 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:
> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.
> 
> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

Is Java2D required for Swing?

> 3) implementing Swing on top of the minimal AWT (or
> borrowing it from 1.1 as a temporary solution). Swing is not
> a trivial piece of code, but the advantage is that since almost
> all functions/members of Swing are either public or protected,
> all the skeleton of the code can be written from the JavaDoc
> output of swing. "only" filling the method's body is required.

What are Kaffe and Classpath doing?  Are people using Swing with those?

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 17:48                         ` Bryce McKinlay
@ 2000-03-21  7:18                           ` Tom Tromey
  2000-03-21  8:06                             ` Jeff Sturm
  2000-04-01  0:00                             ` Tom Tromey
  2000-04-01  0:00                           ` Bryce McKinlay
  1 sibling, 2 replies; 115+ messages in thread
From: Tom Tromey @ 2000-03-21  7:18 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Per Bothner, java-discuss

Bryce> The queue lock is always under contention by the thread(s)
Bryce> putting events onto it and the E.D.T. pulling events off it,
Bryce> and as we know, locking between native threads is slow. I
Bryce> suspect this is the major reason why the user-threads based
Bryce> Sun/Borland JDK 1.2.2 performs so well running JBuilder and
Bryce> other swing apps compared to the other, native threaded JDKs
Bryce> like IBM 1.1.8 (which by all benchmarks has a much superior JIT
Bryce> and memory management) - its thread synchronization is 5x or
Bryce> more faster than linux native locks.

Sometimes I wonder if we should have two locking implementations, one
as fast as possible and one that is perhaps slower but SMP friendly.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  7:18                           ` Tom Tromey
@ 2000-03-21  8:06                             ` Jeff Sturm
  2000-04-01  0:00                               ` Jeff Sturm
  2000-04-01  0:00                             ` Tom Tromey
  1 sibling, 1 reply; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21  8:06 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
                                         ` (3 preceding siblings ...)
  2000-03-21  6:48                       ` Jeff Sturm
@ 2000-03-21  8:56                       ` ks
  2000-03-21  9:17                         ` Cedric Berger
                                           ` (2 more replies)
  2000-04-01  0:00                       ` Cedric Berger
  5 siblings, 3 replies; 115+ messages in thread
From: ks @ 2000-03-21  8:56 UTC (permalink / raw)
  To: cedric, java-discuss

> There has been a lot of discussion about AWT vs Swing design
> option, and I think that most people agree that Swing has two
> major advantages over AWT:
> 1) platform independence: you don't need to test thing on many
> platform, the code is the same, the bugs are the same, ...

This is the hazard of microsoft domination of the PC market for the
last ten years.  If it runs on one platform that covers 80% of the 
machines, it must be platform independent.

Take this clue.  Swing does not run on KVM.  Swing does not run on
Chai.  Swing does not run on IBM VM.  Swing does not run on Kaffe.
Swing does not run on jview.  Swing does not run on TowerJ.  

There are workarounds for some of these.  As long as Sun's licencing
for Swing/1.1 remains as it is you can distribute the swing jars with
your application, which would also work for gcj.  But the licensing 
was changed for JDK1.2, and as Kaffe, GCJ and others start adding 1.2
functionality, I don't think that Sun will hand them the rights to 
redistribute Swing without bringing along the rest of the JDK.

I'd like to see you use a swing based application from a system 360
on top of remote AWT though.  Molasses in winter comes to mind.

[...]
> 
> 4) if somebody really need it at that point, implementing
> AWT widgets by calling Swing code: I believe that it is (or
> was) Sun's plan too.
> 

What amazing hubris.  Who is implementing AWT on top of Swing supposed 
to help?

Cheers,
-kls

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  6:48                       ` Jeff Sturm
@ 2000-03-21  9:00                         ` Cedric Berger
  2000-03-21  9:47                           ` Jeff Sturm
  2000-04-01  0:00                           ` Cedric Berger
  2000-03-21 14:05                         ` Paul Fisher
  2000-04-01  0:00                         ` Jeff Sturm
  2 siblings, 2 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-21  9:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Jeff Sturm wrote:

> Cedric Berger wrote:
> > 1) implementing the basic (low level) AWT functionalities.
> > Basically Window/Frame/Component/Container/Canvas and
> > event handling.
> >
> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
>
> Is Java2D required for Swing?

No, but Graphics2D (the Java2D engine) is a superset of the
old Graphics class needed by everyone who want to paint on
a window. So only Graphics is needed for most Swing apps.
but Graphics2D re-implement (not just augment) all Graphics
methods; so if plan to develop Graphics first and Graphics2D
later, I would assumes that most of the work doing Graphics
will be lost.
IMHO, it would be better to start implementing Java2D with
the latest specs (1.3), but starting with the pieces that are really
needed by Swing (bezier curves can be left for later...)

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  8:56                       ` ks
@ 2000-03-21  9:17                         ` Cedric Berger
  2000-03-21  9:57                           ` ks
  2000-04-01  0:00                           ` Cedric Berger
  2000-03-21  9:44                         ` Brian Sullivan
  2000-04-01  0:00                         ` ks
  2 siblings, 2 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-21  9:17 UTC (permalink / raw)
  To: ks; +Cc: java-discuss

ks@micky.rgv.hp.com wrote:

> Take this clue.  Swing does not run on KVM.  Swing does not run on
> Chai.  Swing does not run on IBM VM.  Swing does not run on Kaffe.
> Swing does not run on jview.  Swing does not run on TowerJ.

Swing do run very well on jview (I'm using Together/J in this
configuration).
I would be very very surprised if it didn't work on IBM VM or TowerJ
(even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
being designed for server apps).

On the other hand, I will agree with you that Sun's Swing is probably too
big
for most of today's embedded application. But it is probably possible to
make a reduced version of Swing if for example you remove Pluggable L&F

> >
> > 4) if somebody really need it at that point, implementing
> > AWT widgets by calling Swing code: I believe that it is (or
> > was) Sun's plan too.
> >
>
> What amazing hubris.  Who is implementing AWT on top of Swing supposed
> to help?

Simplest way to achieve backward compatibility with old apps that uses
AWT.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:56                           ` Per Bothner
@ 2000-03-21  9:26                             ` Cedric Berger
  2000-03-21  9:38                               ` Denis Balazuc
  2000-04-01  0:00                               ` Cedric Berger
  2000-04-01  0:00                             ` Per Bothner
  1 sibling, 2 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-21  9:26 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

> Cedric Berger <cedric@wireless-networks.com> writes:
>
> > What is the real advantage of Gtk over "pure Java"? Speed?
>
> (Speed is not a major advantage - we always have the option of
> replacing critical methods by CNI for a "mostly-Java" solution.)
> (1) It may be easier to implement something useful if we build on gtk.
> (2) Increased compatibility at the code level between C/C++/Java,
> makes it more feasible to mix components in different languages.
> (3) Better look+feel compatibility between Java apps and Gnome
> apps.  Specifically, Swing L+F should follow gtk themes.
>
> I think (3) is the most important, at least long-term.
> At the very least, we need a default Swing look+feel that just
> uses the current gtk theme.

I'm quite sure that a lot of peoples (including me) would *love* to
have a good Swing L&F that uses gtk themes, especially if it
can be plugged in other VM implementations...
I agree that the implementation of  L&F other than Metal has been
so far a very week part of Sun's implementation. But I don't see
any reasons for that except (wrong?) priorities at Sun.
I understand that Sun wanted to keep Swing in pure java up to
version 1.1, but now that it's integrated in the core, I don't see any
reasons why it cannot uses native method to query the platform's
desktop settings for things like themes, widget size, ...

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:26                             ` Cedric Berger
@ 2000-03-21  9:38                               ` Denis Balazuc
  2000-04-01  0:00                                 ` Denis Balazuc
  2000-04-01  0:00                               ` Cedric Berger
  1 sibling, 1 reply; 115+ messages in thread
From: Denis Balazuc @ 2000-03-21  9:38 UTC (permalink / raw)
  To: Cygnus-Java Mailing List

> I'm quite sure that a lot of peoples (including me) would *love* to
> have a good Swing L&F that uses gtk themes, especially if it
> can be plugged in other VM implementations...
> I agree that the implementation of  L&F other than Metal has been
> so far a very week part of Sun's implementation. But I don't see
> any reasons for that except (wrong?) priorities at Sun.
> I understand that Sun wanted to keep Swing in pure java up to
> version 1.1, but now that it's integrated in the core, I don't see any
> reasons why it cannot uses native method to query the platform's
> desktop settings for things like themes, widget size, ...


I thought that the idea behind Swing was to remove plateform-dependency and
heavy-weight components in the first place....
(and despite what was said, Windows's not the only plateform where you can
find many  AWT bugs...)
non 100% Pure Java Swing : is that really what one's want ?
Is there a plan from SUN to deviate from a 100% pure implementation ?



^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  8:56                       ` ks
  2000-03-21  9:17                         ` Cedric Berger
@ 2000-03-21  9:44                         ` Brian Sullivan
  2000-03-21 11:38                           ` Jonathan P. Olson
  2000-04-01  0:00                           ` Brian Sullivan
  2000-04-01  0:00                         ` ks
  2 siblings, 2 replies; 115+ messages in thread
From: Brian Sullivan @ 2000-03-21  9:44 UTC (permalink / raw)
  To: ks, java-discuss

ks@micky.rgv.hp.com wrote:

> > 4) if somebody really need it at that point, implementing
> > AWT widgets by calling Swing code: I believe that it is (or
> > was) Sun's plan too.
> >
>
> What amazing hubris.  Who is implementing AWT on top of Swing supposed
> to help?

I'm not the original poster, but I'll chime in here.

There are many special cases for AWT heavyweight/lightweight interactions
in the AWT code which I'm quite sure everyone at Sun responsible for it
would love to abandon.  All the special case code and hacks would
disappear.

Heavyweight and lightweight mixing together on the same form just doesn't
work particularly well; replacing AWT heavyweights with lightweights would

solve this.  Our GUI designer allows heavyweight to be mixed with
lightweight,
including live in the editor, but we sure recommend against it.

> Cheers,
> -kls

Regards,
Brian Sullivan

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:00                         ` Cedric Berger
@ 2000-03-21  9:47                           ` Jeff Sturm
  2000-03-21 10:12                             ` Cedric Berger
  2000-04-01  0:00                             ` Jeff Sturm
  2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 2 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21  9:47 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:
> > Is Java2D required for Swing?
> 
> No, but Graphics2D (the Java2D engine) is a superset of the
> old Graphics class needed by everyone who want to paint on
> a window. So only Graphics is needed for most Swing apps.
> but Graphics2D re-implement (not just augment) all Graphics
> methods; so if plan to develop Graphics first and Graphics2D
> later, I would assumes that most of the work doing Graphics
> will be lost.

OK.  It's becoming clear (to me) that there are folks who want to do
quite fancy graphics stuff in Java, maybe even game programming.

Not everybody is in that crowd (our requirements are fairly primitive
and easily met by java.awt).  Those who want a free Java2D may be stuck
implementing it themselves, since I kinda doubt its a high priority for
libgcj or classpath.

That said, the libart stuff that Per mentioned looks like it could be a
great starting point.  I wonder how much of Java2D could be implemented
by libart directly.

> IMHO, it would be better to start implementing Java2D with
> the latest specs (1.3), but starting with the pieces that are really
> needed by Swing (bezier curves can be left for later...)
  ^^^^^^^^^^^^^^^
Umm... you just said Swing doesn't require Java2D...

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:17                         ` Cedric Berger
@ 2000-03-21  9:57                           ` ks
  2000-03-21 10:22                             ` Cedric Berger
  2000-04-01  0:00                             ` ks
  2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 2 replies; 115+ messages in thread
From: ks @ 2000-03-21  9:57 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

> I would be very very surprised if it didn't work on IBM VM or TowerJ
> (even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
> being designed for server apps).

Perhaps I should more correctly say Swing is not distributed as a part
of those platforms.  If you get Swing from another source then of course
it will run since it is pure Java.

So if I write a Swing based app, and give it to someone who uses jview
they will not be able to run it unless they also have Swing, or unless
I provide Swing with my program.

My argument is that it should be possible to write simple GUIs (for 
system configuration, for monitoring/management, or for interactions
with small or remote machines) without forcing 13MB (compressed!) of
Swing classes on them.

Cheers,
-kls

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:47                           ` Jeff Sturm
@ 2000-03-21 10:12                             ` Cedric Berger
  2000-04-01  0:00                               ` Cedric Berger
  2000-04-01  0:00                             ` Jeff Sturm
  1 sibling, 1 reply; 115+ messages in thread
From: Cedric Berger @ 2000-03-21 10:12 UTC (permalink / raw)
  To: Jeff Sturm, java-discuss

Jeff Sturm wrote:

> > IMHO, it would be better to start implementing Java2D with
> > the latest specs (1.3), but starting with the pieces that are really
> > needed by Swing (bezier curves can be left for later...)
>   ^^^^^^^^^^^^^^^
> Umm... you just said Swing doesn't require Java2D...

Ok, I will try to be more clear.

AWT inplements the following draw methods:
   Graphics.drawLine(x1, y1, x2, y2)
   Graphics.drawArc()
   Graphics.drawPolygon()

I suspect that in JDK 1.0/1.1, these are all native methods.

In JDK 1.2/1.3, the basic primitive used by Java2D to draw is
   Graphics2D.draw(Shape)
and (for what I understand) drawLine() drawArc() are implemented
by creating the corresponding Shape object and calling
Graphics2D.draw().

So what I was suggesting is: let's go strait to the Graphics2D class,
with the Shape concept, but starting by implementing Shapes that are
useful for Swing (i.e. Rectangle and Line are useful, QuadCurve2D
is not).

Cedric


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:57                           ` ks
@ 2000-03-21 10:22                             ` Cedric Berger
  2000-03-21 10:41                               ` jean-marie sulmont
  2000-04-01  0:00                               ` Cedric Berger
  2000-04-01  0:00                             ` ks
  1 sibling, 2 replies; 115+ messages in thread
From: Cedric Berger @ 2000-03-21 10:22 UTC (permalink / raw)
  To: ks, java-discuss

ks@micky.rgv.hp.com wrote:

> > I would be very very surprised if it didn't work on IBM VM or TowerJ
> > (even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
> > being designed for server apps).
>
> My argument is that it should be possible to write simple GUIs (for
> system configuration, for monitoring/management, or for interactions
> with small or remote machines) without forcing 13MB (compressed!) of
> Swing classes on them.

If I remember correctly, JRE 1.3 ship (english version) in less than 5MB
(with everything: JVM, Swing, Java2D, .........)

But I agree that, because of the current Microsoft behavior, it's a pain
to have to ship this...
But we must not be making decisions based on M$ behavior, and,
with Netscape 6 and recent Linux deals, things are going to change,
hopefully...

Cedric

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 10:22                             ` Cedric Berger
@ 2000-03-21 10:41                               ` jean-marie sulmont
  2000-04-01  0:00                                 ` jean-marie sulmont
  2000-04-01  0:00                               ` Cedric Berger
  1 sibling, 1 reply; 115+ messages in thread
From: jean-marie sulmont @ 2000-03-21 10:41 UTC (permalink / raw)
  To: Cedric Berger; +Cc: ks, java-discuss

Why don't you take this topic off list?

-- 
jean-marie sulmont                      1211 SW 5th Ave, suite 900
developer                               Portland, Oregon 97204
Oracle Corporation                      Phone: (503) 525-8057
jsulmont@us.oracle.com                  Fax:   (503) 277-2300

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:44                         ` Brian Sullivan
@ 2000-03-21 11:38                           ` Jonathan P. Olson
  2000-03-21 11:46                             ` Nathan Meyers
  2000-04-01  0:00                             ` Jonathan P. Olson
  2000-04-01  0:00                           ` Brian Sullivan
  1 sibling, 2 replies; 115+ messages in thread
From: Jonathan P. Olson @ 2000-03-21 11:38 UTC (permalink / raw)
  To: Brian Sullivan, ks, java-discuss

On Tue, 21 Mar 2000, Brian Sullivan wrote:
>
>I'm not the original poster, but I'll chime in here.
>
>There are many special cases for AWT heavyweight/lightweight interactions
>in the AWT code which I'm quite sure everyone at Sun responsible for it
>would love to abandon.  All the special case code and hacks would
>disappear.
>
>Heavyweight and lightweight mixing together on the same form just doesn't
>work particularly well; replacing AWT heavyweights with lightweights would
>

I think that the "heavyweight" vs. "lightweight" terminology is really
misleading.  Seems like the Swing "lightweight" components are usually
heavier and slower than the native "heavyweight" components.
A better terminology would be "native" vs. "pure java" or "peer" vs. "non-peer".

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 11:38                           ` Jonathan P. Olson
@ 2000-03-21 11:46                             ` Nathan Meyers
  2000-04-01  0:00                               ` Nathan Meyers
  2000-04-01  0:00                             ` Jonathan P. Olson
  1 sibling, 1 reply; 115+ messages in thread
From: Nathan Meyers @ 2000-03-21 11:46 UTC (permalink / raw)
  To: Jonathan P. Olson, Brian Sullivan, ks, java-discuss

On Tue, Mar 21, 2000 at 05:27:53AM -0700, Jonathan P. Olson wrote:
> I think that the "heavyweight" vs. "lightweight" terminology is really
> misleading.  Seems like the Swing "lightweight" components are usually
> heavier and slower than the native "heavyweight" components.
> A better terminology would be "native" vs. "pure java" or "peer" vs. "non-peer".

The terms have outlived their original purpose, in the X Windows world,
where "heavyweight" components consumed actual windows resources in the
X server and "lightweight" did not. Unfortunately, they've stuck (and
even mutated).

Nathan Meyers
nmeyers@javalinux.net

> 
> -- 
> Jon Olson, Modular Mining Systems
> 	   3289 E. Hemisphere Loop
> 	   Tucson, AZ 85706
> olson@mmsi.com
> Phone:	(520)746-9127
> Fax:	(520)889-5790

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  6:48                       ` Jeff Sturm
  2000-03-21  9:00                         ` Cedric Berger
@ 2000-03-21 14:05                         ` Paul Fisher
  2000-04-01  0:00                           ` Paul Fisher
  2000-04-01  0:00                         ` Jeff Sturm
  2 siblings, 1 reply; 115+ messages in thread
From: Paul Fisher @ 2000-03-21 14:05 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> What are Kaffe and Classpath doing?  Are people using Swing with
> those?

Swing 1.1.1fcs reportedly works under the Kaffe Xlib-based AWT.

The majority of Swing 1.1.1fcs works under the Classpath GTK+ peer set
when the peer set is shoved in between Sun's non-peer AWT and Swing.

Screenshot of Metalworks running under the GTK+ peer set:
<URL: http://people.redhat.com/pnfisher/metalworks.png >

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:25                         ` Per Bothner
@ 2000-03-21 14:21                           ` Paul Fisher
  2000-04-01  0:00                             ` Paul Fisher
  2000-04-01  0:00                           ` Per Bothner
  1 sibling, 1 reply; 115+ messages in thread
From: Paul Fisher @ 2000-03-21 14:21 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> One of the fundamental ideas of Swing is the separation of "model"
> and "view+controller".  For example two JTextPanes can both be using
> the same Document.  How suitable are gtk widgets for doing things
> like that?

It depends on the widget.  More of an issue, however, is Swing's
allowance of arbitrarily overriding of drawLine() and other
primitives, as was mentioned in a previous post.  With GTK+ 1.2, it's
impossible to do printing the way Java wants it done, because there's
no way to change the semantics of the primitive GDK drawing routines.
This issue is being resolved in GTK+ 1.4, so there might be a way
around the Swing issues such that Java methods can control the drawing
of GTK+ widgets.

All the issues involved will probably be quite complex, and I really
haven't had enough time to throughly think through them.  I'm more
focused on the libgcj/Classpath merger and finishing up the 1.1 AWT
before swamping myself in the problems of reimplementing Swing.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 21:30                       ` Per Bothner
                                           ` (2 preceding siblings ...)
  2000-03-21  1:01                         ` Joerg Brunsmann
@ 2000-03-21 14:33                         ` Paul Fisher
  2000-04-01  0:00                           ` Paul Fisher
  2000-04-01  0:00                         ` Per Bothner
  4 siblings, 1 reply; 115+ messages in thread
From: Paul Fisher @ 2000-03-21 14:33 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
> 
> It seems plausible to use libart (see http://www.levien.com/libart/
> and http://developer.gnome.org/arch/imaging/libart.html ).

It has been Classpath's and RHAD Labs' intention to use libart to
implement Java2D; however, there's still much work that needs to be
done on libart in order to bring it up to the level of functionality
that Java2D requires.  There's also the possibility that a server-side
2D X extension might make its way to the community in the future,
which would alleviate a lot of the problems involved.

(From what I've heard, Sun's implementation of Java2D under Windows
was a relatively simple mapping of Windows 2D primitives onto the Java
2D API.  For X, Sun had to roll their own implementation; it's quite
slow.)

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:44                         ` Brian Sullivan
  2000-03-21 11:38                           ` Jonathan P. Olson
@ 2000-04-01  0:00                           ` Brian Sullivan
  1 sibling, 0 replies; 115+ messages in thread
From: Brian Sullivan @ 2000-04-01  0:00 UTC (permalink / raw)
  To: ks, java-discuss

ks@micky.rgv.hp.com wrote:

> > 4) if somebody really need it at that point, implementing
> > AWT widgets by calling Swing code: I believe that it is (or
> > was) Sun's plan too.
> >
>
> What amazing hubris.  Who is implementing AWT on top of Swing supposed
> to help?

I'm not the original poster, but I'll chime in here.

There are many special cases for AWT heavyweight/lightweight interactions
in the AWT code which I'm quite sure everyone at Sun responsible for it
would love to abandon.  All the special case code and hacks would
disappear.

Heavyweight and lightweight mixing together on the same form just doesn't
work particularly well; replacing AWT heavyweights with lightweights would

solve this.  Our GUI designer allows heavyweight to be mixed with
lightweight,
including live in the editor, but we sure recommend against it.

> Cheers,
> -kls

Regards,
Brian Sullivan

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:25                         ` Per Bothner
  2000-03-21 14:21                           ` Paul Fisher
@ 2000-04-01  0:00                           ` Per Bothner
  1 sibling, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> I don't believe it would be feasible to actually implement Swing using
> GTK+ or Qt (for example, directly mapping the Swing tree widget to
> GTK+'s tree widget).  However, I've often thought about this
> possibility; it's certainly appealing.

One of the fundamental ideas of Swing is the separation of "model"
and "view+controller".  For example two JTextPanes can both be using the
same Document.  How suitable are gtk widgets for doing things like that?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:47                           ` Jeff Sturm
  2000-03-21 10:12                             ` Cedric Berger
@ 2000-04-01  0:00                             ` Jeff Sturm
  1 sibling, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:
> > Is Java2D required for Swing?
> 
> No, but Graphics2D (the Java2D engine) is a superset of the
> old Graphics class needed by everyone who want to paint on
> a window. So only Graphics is needed for most Swing apps.
> but Graphics2D re-implement (not just augment) all Graphics
> methods; so if plan to develop Graphics first and Graphics2D
> later, I would assumes that most of the work doing Graphics
> will be lost.

OK.  It's becoming clear (to me) that there are folks who want to do
quite fancy graphics stuff in Java, maybe even game programming.

Not everybody is in that crowd (our requirements are fairly primitive
and easily met by java.awt).  Those who want a free Java2D may be stuck
implementing it themselves, since I kinda doubt its a high priority for
libgcj or classpath.

That said, the libart stuff that Per mentioned looks like it could be a
great starting point.  I wonder how much of Java2D could be implemented
by libart directly.

> IMHO, it would be better to start implementing Java2D with
> the latest specs (1.3), but starting with the pieces that are really
> needed by Swing (bezier curves can be left for later...)
  ^^^^^^^^^^^^^^^
Umm... you just said Swing doesn't require Java2D...

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT -> Remote AWT
  2000-03-21  0:57               ` Interrupted IO and AWT -> Remote AWT Jens Wilke
@ 2000-04-01  0:00                 ` Jens Wilke
  0 siblings, 0 replies; 115+ messages in thread
From: Jens Wilke @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi!

Just a information for the "AWT-people". IBM has a so called "remote AWT"
implementation, which they
mainly intended to run graphic application on the AS/400 platform. Any AWT
and TCP/IP aware JRE
should serve as display client, and on the server side you only need TCP/IP.

Perhaps this is a nice short-term approach, and someone is interested in
experimenting with it. I have
no idea whether it is possible to get it running with gcj.

Look at:
http://www.alphaworks.ibm.com/formula/remoteawtforjava

--
Jens


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  8:56                       ` ks
  2000-03-21  9:17                         ` Cedric Berger
  2000-03-21  9:44                         ` Brian Sullivan
@ 2000-04-01  0:00                         ` ks
  2 siblings, 0 replies; 115+ messages in thread
From: ks @ 2000-04-01  0:00 UTC (permalink / raw)
  To: cedric, java-discuss

> There has been a lot of discussion about AWT vs Swing design
> option, and I think that most people agree that Swing has two
> major advantages over AWT:
> 1) platform independence: you don't need to test thing on many
> platform, the code is the same, the bugs are the same, ...

This is the hazard of microsoft domination of the PC market for the
last ten years.  If it runs on one platform that covers 80% of the 
machines, it must be platform independent.

Take this clue.  Swing does not run on KVM.  Swing does not run on
Chai.  Swing does not run on IBM VM.  Swing does not run on Kaffe.
Swing does not run on jview.  Swing does not run on TowerJ.  

There are workarounds for some of these.  As long as Sun's licencing
for Swing/1.1 remains as it is you can distribute the swing jars with
your application, which would also work for gcj.  But the licensing 
was changed for JDK1.2, and as Kaffe, GCJ and others start adding 1.2
functionality, I don't think that Sun will hand them the rights to 
redistribute Swing without bringing along the rest of the JDK.

I'd like to see you use a swing based application from a system 360
on top of remote AWT though.  Molasses in winter comes to mind.

[...]
> 
> 4) if somebody really need it at that point, implementing
> AWT widgets by calling Swing code: I believe that it is (or
> was) Sun's plan too.
> 

What amazing hubris.  Who is implementing AWT on top of Swing supposed 
to help?

Cheers,
-kls

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:13                       ` Bryce McKinlay
@ 2000-04-01  0:00                         ` Bryce McKinlay
  0 siblings, 0 replies; 115+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:

> Nobody uses AWT widgets anymore. I've never seen a new AWT
> application the last two years. In fact, Swing is widely recognized
> as the better GUI toolkit availabe today (and I'm not speaking of
> Java only). The main problem so far was speed, but JDK 1.3 is
> much better, and having the code compiled with a tool like GCJ
> will also make it much faster.

Definatly. Swing is a far superior toolkit to anything else I've ever seen.
Its weaknesses (apart from speed) are poor intergration with native
applications and poor integration between swing applications (eg cut &
paste, drag & drop, etc - although I think these are being remedied
somewhat in JDK 1.3). These are the things we'd be adressing with a "gcj
toolkit". I want to write native applications, but with a Swing API.

> IMHO, the right way to develop a graphic library for Java today
> is:
>
> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.
>
> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

Yeah, whatever the long term plans, we've got to start somewhere.
Implementing an AWT 1.1 using gtk native peers that can run Sun's Swing 1.1
distribution is a reasonable goal in the short term.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Interrupted IO and AWT
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
                                 ` (2 preceding siblings ...)
  2000-03-21  0:57               ` Interrupted IO and AWT -> Remote AWT Jens Wilke
@ 2000-04-01  0:00               ` Jon Beniston
  3 siblings, 0 replies; 115+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi,

I seem to recall reading somewhere on Sun's Bug list that the interrupting
of IO has in some form been deprecated. Does any one know whether this is
the case? I ask, because I'm wondering whether I should implement this in
the Win32 port. It seems as if there may be some overhead. Would this be
worth it it the general case? Personally, I've never made use of it.

Secondly, I'm quite interested in doing some work on implementing AWT (I'm
more intrested in Client stuff myself). I was wondering if someone could
clear up the position of this, esp. regarding the Classpath merger. I seem
to recall that everything from Classpath is available except the AWT code.
Now is this all AWT code or just the native implementation? IF I do use it
what is the final result? That the executable is cover by the GPL? I can
live with that for now...

Jon Beniston.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 17:48                         ` Bryce McKinlay
  2000-03-21  7:18                           ` Tom Tromey
@ 2000-04-01  0:00                           ` Bryce McKinlay
  1 sibling, 0 replies; 115+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:

> Rather than write a direct
> Java wrapper for gtk, I'd like us to use the AWT or Swing class
> and method names whenever they match.

I've been considering something similar to this. In addition to exposing
more of the native toolkits functionality to Java code, there's another good
reason reason to create an AWT/Swing-ALIKE API: performance. The AWT is slow
by design due both to the requirements of thread safety and its
event-dispatch queue based design. Because it isn't inherently thread-safe
(and probably never can be), virtually every call into the native peers
needs to be synchronized around a global lock using either either gtk's own
locking or java synchronization. This means calling gtk_threads_enter() and
gtk_threads_leave() inside every native peer method implementation, which no
doubt adds considerable overhead. The other problem is AWT's event-dispatch
queue based design. The native peers exist on a different thread to the
event-dispatch thread, and these communicate using a synchronized queue. For
every event generated by the native peer implementation (every keystroke,
every mouse movement, unmask event, refresh, etc), an event object must be
constructed, and the queue synchronized. The event dispatch thread then
synchronizes with the queue, grabs the oldest event, and calls into user
code to have it processed. The queue lock is always under contention by the
thread(s) putting events onto it and the E.D.T. pulling events off it, and
as we know, locking between native threads is slow. I suspect this is the
major reason why the user-threads based Sun/Borland JDK 1.2.2 performs so
well running JBuilder and other swing apps compared to the other, native
threaded JDKs like IBM 1.1.8 (which by all benchmarks has a much superior
JIT and memory management) - its thread synchronization is 5x or more faster
than linux native locks.

Despite the above problems, I'm still confident that we can do basic,
correct AWT functionality with reasonable performance, mainly because the
lack of JNI overhead will do much to make up for these other things. A good,
working AWT (that can run Swing 1.1) should attract a lot more people to gcj
and show off what can be done with it. I guess the only real way to see how
fast it will be is to implement it and see ;-)

However, by imposing a few restrictions on what can and can't be done wrt
threads and gui calls: like requiring the application to make all gui calls
from one master thread (which, I should point out, Swing already does), and
by having the application call a blocking "EventDispatch.start()" type
method instead of relying on an implicit event dispatch thread, it should be
possible to create an AWT-like API that can expose a lot more native
functionality and is also very fast. By doing this, and by adding swing-like
functionality to it, we would essentially be creating a new toolkit API -
but modeled after the existing ones to ease transition of code to it.

Of course the real solution to the synchronization problem lies in having
better threads support, ie an n:n threading model like Solaris/BeOS/Windows
- but this is something that needs to be done at the glibc/kernel level
rather than in libgcj. Using hybrid/user threads in libgcj would probably
suck because it would be very difficult to make them interact well with
existing native code. The BeOS toolkit for example is very multithreaded and
also very responsive, so it is possible...


> avoid excess helper objects:  We would have a Window, which may
> points to a WindowPeer, which may contain a RawData that points
> to a gtk handle.  What I want to avoid when possible is an additional
> Gtk Java wrapper; whatever class we use to wrap a gtk window
> should implement the WindowPeer interface, without requiring yet
> another class to do so.

Yes, I don't see any reason why there should (usually) be anything other
than AWT object -> peer interface -> Peer implementation object, where the
peer implementation class consists of part java/part native code.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj for win32
  2000-04-01  0:00     ` libgcj for win32 Jon Beniston
@ 2000-04-01  0:00       ` Jeff Sturm
  2000-04-01  0:00         ` Jon Beniston
  0 siblings, 1 reply; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: Jeff Sturm, java-discuss

On Sun, 16 Jan 2000, Jon Beniston wrote:
> I've just updated my win32 port of libgcj. New exciting features include:
> Native threads, networking and exception handling. It's at last usable! GC
> will hopefully be implemented very soon. If you have any problems, feel free
> to have a moan.

That's great news, Jon.  Did you port to win32 threads or use the pthreads
compatibility library?  Are you using the Cygwin or Mingw32
compiler environment?

The GC should work without much hassle... but note that it currently
requires the DLL configuration on win32.  If you don't build libgcjgc as a
DLL, it won't get the DLL_THREAD_ATTACH messages and won't work in a
multithreaded VM.

--
Jeff Sturm
jsturm@sigma6.com


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:26                             ` Cedric Berger
  2000-03-21  9:38                               ` Denis Balazuc
@ 2000-04-01  0:00                               ` Cedric Berger
  1 sibling, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

> Cedric Berger <cedric@wireless-networks.com> writes:
>
> > What is the real advantage of Gtk over "pure Java"? Speed?
>
> (Speed is not a major advantage - we always have the option of
> replacing critical methods by CNI for a "mostly-Java" solution.)
> (1) It may be easier to implement something useful if we build on gtk.
> (2) Increased compatibility at the code level between C/C++/Java,
> makes it more feasible to mix components in different languages.
> (3) Better look+feel compatibility between Java apps and Gnome
> apps.  Specifically, Swing L+F should follow gtk themes.
>
> I think (3) is the most important, at least long-term.
> At the very least, we need a default Swing look+feel that just
> uses the current gtk theme.

I'm quite sure that a lot of peoples (including me) would *love* to
have a good Swing L&F that uses gtk themes, especially if it
can be plugged in other VM implementations...
I agree that the implementation of  L&F other than Metal has been
so far a very week part of Sun's implementation. But I don't see
any reasons for that except (wrong?) priorities at Sun.
I understand that Sun wanted to keep Swing in pure java up to
version 1.1, but now that it's integrated in the core, I don't see any
reasons why it cannot uses native method to query the platform's
desktop settings for things like themes, widget size, ...

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 14:05                         ` Paul Fisher
@ 2000-04-01  0:00                           ` Paul Fisher
  0 siblings, 0 replies; 115+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> What are Kaffe and Classpath doing?  Are people using Swing with
> those?

Swing 1.1.1fcs reportedly works under the Kaffe Xlib-based AWT.

The majority of Swing 1.1.1fcs works under the Classpath GTK+ peer set
when the peer set is shoved in between Sun's non-peer AWT and Swing.

Screenshot of Metalworks running under the GTK+ peer set:
<URL: http://people.redhat.com/pnfisher/metalworks.png >

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 11:46                             ` Nathan Meyers
@ 2000-04-01  0:00                               ` Nathan Meyers
  0 siblings, 0 replies; 115+ messages in thread
From: Nathan Meyers @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jonathan P. Olson, Brian Sullivan, ks, java-discuss

On Tue, Mar 21, 2000 at 05:27:53AM -0700, Jonathan P. Olson wrote:
> I think that the "heavyweight" vs. "lightweight" terminology is really
> misleading.  Seems like the Swing "lightweight" components are usually
> heavier and slower than the native "heavyweight" components.
> A better terminology would be "native" vs. "pure java" or "peer" vs. "non-peer".

The terms have outlived their original purpose, in the X Windows world,
where "heavyweight" components consumed actual windows resources in the
X server and "lightweight" did not. Unfortunately, they've stuck (and
even mutated).

Nathan Meyers
nmeyers@javalinux.net

> 
> -- 
> Jon Olson, Modular Mining Systems
> 	   3289 E. Hemisphere Loop
> 	   Tucson, AZ 85706
> olson@mmsi.com
> Phone:	(520)746-9127
> Fax:	(520)889-5790

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 21:30                       ` Per Bothner
                                           ` (3 preceding siblings ...)
  2000-03-21 14:33                         ` Paul Fisher
@ 2000-04-01  0:00                         ` Per Bothner
  4 siblings, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger <cedric@wireless-networks.com> writes:

> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.

I agree this comes first.

> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

It seems plausible to use libart (see http://www.levien.com/libart/
and http://developer.gnome.org/arch/imaging/libart.html ).

> 3) implementing Swing on top of the minimal AWT (or
> borrowing it from 1.1 as a temporary solution). Swing is not
> a trivial piece of code, but the advantage is that since almost
> all functions/members of Swing are either public or protected,
> all the skeleton of the code can be written from the JavaDoc
> output of swing. "only" filling the method's body is required.

Well, this is the "pure Java" approach.  It may make sense
to use existing Gtk widgets instead.  It may also make sense
to do provide both:  I.e. the toolkit by default uses Gtk
widgets, but that can be overridden.

I think the "model" classes should be pure Java (except perhaps
a few CNI methods for speed).  However, the "view" classes
should perhaps be based on gtk widgets.  At least the default
implementation of the view classes should use the gtk theme
framework.

One exciting idea I want to explore is to use the XSL
"formatting object" model for views.  See http://www.w3.org/TR/xsl/ 
We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
which is an open-source implementation in Java sponsored by the Apache
XML Project.  FOP can generate pdf - and it also includes
a viewer, so it could form the basis for a "view engine".
(However, I don't know if the Apache license is viewed as
being compatible with the modified-GPL of libgcj.)

Similarly, it might be cool to have the Element hierarchy of a
Swing Document implement the org.w3c.dom.Node.  This might provide
a nice integrated and efficient XML environment.

> 4) if somebody really need it at that point, implementing
> AWT widgets by calling Swing code

That is my suggestion, too.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 10:12                             ` Cedric Berger
@ 2000-04-01  0:00                               ` Cedric Berger
  0 siblings, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm, java-discuss

Jeff Sturm wrote:

> > IMHO, it would be better to start implementing Java2D with
> > the latest specs (1.3), but starting with the pieces that are really
> > needed by Swing (bezier curves can be left for later...)
>   ^^^^^^^^^^^^^^^
> Umm... you just said Swing doesn't require Java2D...

Ok, I will try to be more clear.

AWT inplements the following draw methods:
   Graphics.drawLine(x1, y1, x2, y2)
   Graphics.drawArc()
   Graphics.drawPolygon()

I suspect that in JDK 1.0/1.1, these are all native methods.

In JDK 1.2/1.3, the basic primitive used by Java2D to draw is
   Graphics2D.draw(Shape)
and (for what I understand) drawLine() drawArc() are implemented
by creating the corresponding Shape object and calling
Graphics2D.draw().

So what I was suggesting is: let's go strait to the Graphics2D class,
with the Shape concept, but starting by implementing Shapes that are
useful for Swing (i.e. Rectangle and Line are useful, QuadCurve2D
is not).

Cedric


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:09                       ` Paul Fisher
  2000-03-20 13:25                         ` Per Bothner
@ 2000-04-01  0:00                         ` Paul Fisher
  1 sibling, 0 replies; 115+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Let's say somebody wants to use gcj to write desktop apps for KDE or
> Gnome.  How would they best proceed?

Currently, using the standard Java AWT API is their best bet, with the
GTK+ Peer libraries from Classpath.  There's also the `java-gnome'
project <URL: http://www.lirmm.fr/~gutkneco/devpt/javagnome.html >,
which provides Java bindings for the GTK+ and Gnome APIs.

I read somewhere recently that the KDE project has started work on a
set of Qt AWT peers, but I don't have a URL handy.

> The PLAF's are a bad idea because they don't leverage a native
> toolkit, they attempt to reimplement it in Java.

There's no reason why a Swing PLAF couldn't be written that does
leverage the native toolkit.  (A GTK+ Swing PLAF is on the TODO list
for Classpath).

> AWT isn't so good either because it doesn't leverage much of the
> capability of good toolkits out there... e.g. there is no tree
> widget or image button in AWT.

Strictly speaking, it's permissible for getGraphics to return a valid
Graphics object for any Component.  The peer side, however, is only
required to return a valid Graphics object for Canvas and Container.
So, it is possible (and legal) to doodle on random widgets, assuming
the peer implementation supports it.

> Then implement AWT and (possibly) Swing atop this native API to be
> compatibile with other Java applications.

Swing, by design, only depends on the basic drawing primitives of the
AWT.

I don't believe it would be feasible to actually implement Swing using
GTK+ or Qt (for example, directly mapping the Swing tree widget to
GTK+'s tree widget).  However, I've often thought about this
possibility; it's certainly appealing.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 11:38                           ` Jonathan P. Olson
  2000-03-21 11:46                             ` Nathan Meyers
@ 2000-04-01  0:00                             ` Jonathan P. Olson
  1 sibling, 0 replies; 115+ messages in thread
From: Jonathan P. Olson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Brian Sullivan, ks, java-discuss

On Tue, 21 Mar 2000, Brian Sullivan wrote:
>
>I'm not the original poster, but I'll chime in here.
>
>There are many special cases for AWT heavyweight/lightweight interactions
>in the AWT code which I'm quite sure everyone at Sun responsible for it
>would love to abandon.  All the special case code and hacks would
>disappear.
>
>Heavyweight and lightweight mixing together on the same form just doesn't
>work particularly well; replacing AWT heavyweights with lightweights would
>

I think that the "heavyweight" vs. "lightweight" terminology is really
misleading.  Seems like the Swing "lightweight" components are usually
heavier and slower than the native "heavyweight" components.
A better terminology would be "native" vs. "pure java" or "peer" vs. "non-peer".

-- 
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00     ` Tom Tromey
@ 2000-04-01  0:00       ` Jeff Sturm
  0 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Alexandre Oliva, java-discuss

Tom Tromey wrote:
> Alexandre> Then, there's all the dllimport/dllexport mess, that must
> Alexandre> be explicitly taken care of in user's code, which is the
> Alexandre> reason why libtool requires AC_LIBTOOL_WIN32_DLL in
> Alexandre> configure.in to build DLLs.
> 
> It seems to me that we could (in theory) modify the Java compile to
> automatically do the appropriate dllexport thing (I have no clue what
> this attribute actually does) for Java methods.  Basically it would
> just follow Java visibility rules.

Just in case you wanted to know... consider a typical reference to an
external data symbol:

  extern int foo;

  printf("foo = %d", foo);

Specifying __attribute__((dllimport)) creates an undefined symbol
_imp__foo which points to the actual global variable, i.e. doing the
equivalent of:

  extern int *_imp__foo;
  #define foo (*_imp__foo)

  printf("foo = %d", foo);

The DLL loader then performs fixups on each _imp__xxx symbol at
runtime.  A similar fixup is done for text symbols, however this can be
done transparently without the need for dllimport/dllexport.

There is apparently no way to address a global variable in a DLL without
this indirection.  Moreover, it requires knowing at compile time which
symbols will be resolved statically, and which will be in a DLL.  That's
why MSVC and GCC have the language modifiers.  Java has no similar
modifiers (and never will I hope).

> However, it sounds like this isn't sufficient, given that we want to
> export objects from the data area (e.g., vtables).  Is it really not
> possible to do what we want on Windows?  That would suck.

It sucks all right.  Suppose we added a compile-time option to gcj so
class objects are resolved at runtime.  That would avoid the DLL mess,
but the resulting code would be slightly larger and slower, I'd guess.

--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42                     ` Jeff Sturm
                                         ` (2 preceding siblings ...)
  2000-03-20 13:17                       ` Per Bothner
@ 2000-04-01  0:00                       ` Jeff Sturm
  3 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> The two approaches have different trade-offs:
> - Native peers can probably be implemented faster than a Swing-like
> solution.

To my knowledge there exist no free or third-party implementations of
Swing.  It could be extremely difficult to do.

> - Native peers may have better compatibility (both look-and-feel and
> programming-wise) than pure Java widgets.

Especially if a toolkit (i.e. GTK+) is used.  It's also possible to
write native peers using Xlib or Win32/GDI directly... though this leads
to the same interoperability problems as Swing.

(Sun never really got this part right.  AWT applications on Linux don't
look right because Sun used the archaic Motif toolkit.  Early versions
of the Win32 JDK did use MFC to inherit a certain amount of Win32
behavior, but that was later scrapped for direct window/graphics calls.)

> - Pure Java widgets allow compatibility with Swing's "pluggable-
> look-and-feel" (PLAF).  However, I'm not sure that is important.
> I would rather have PLAF built using (say) gtk's theability.

Me too.

Let's say somebody wants to use gcj to write desktop apps for KDE or
Gnome.  How would they best proceed?  Swing is not a good fit because
apps written in Swing tend to look like, umm, Swing.  The PLAF's are a
bad idea because they don't leverage a native toolkit, they attempt to
reimplement it in Java.  Consequently Swing PLAFs are both difficult to
write and imperfect in their emulation.

AWT isn't so good either because it doesn't leverage much of the
capability of good toolkits out there... e.g. there is no tree widget or
image button in AWT.

I'd like to see real Java bindings in GTK and/or KDE so developers can
write first class Java apps for those environments.  Then implement AWT
and (possibly) Swing atop this native API to be compatibile with other
Java applications.

To me this is consistent with the apparent philosophy of the gcj
project: remain compatible with Java but innovate where appropriate. 
Gcj has already innovated with CNI.

(Those who are in the "pure Java" camp will likely disagree with me.  My
aim is not to compromise Java compatibility, but extend its reach to
application domains where it has flopped, like desktop programming.)


-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00   ` Alexandre Oliva
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: java-discuss

Tom Tromey wrote:
> Jeff> BUT... all of libgcj is static-linked so far.  Libtool has no
> Jeff> idea how to build a shared library on Win32, so I attempted to
> Jeff> convert libgcj.a into libgcj.dll somehow, knowing nothing about
> Jeff> DLLs in the process.
> 
> I thought libtool could do this.  In fact I thought Ian wrote a bunch
> of changes to libtool specifically so that it could do this.  Maybe
> this code doesn't work right now?  I admit I haven't kept up with it;
> I rarely develop for Windows.

The version of libtool we have seems to know about DLLs, but they have
been disabled, judging from the comments in the code.

But aside from libtool... I tried to build a libgcj DLL by hand, and
failed.  The reason is that global, shared data symbols are impossible
in DLLs.  Gcj relies extensively on global data symbols (like
__vt_Q34java4lang5Class) and there's just no way to link these from a
DLL.

G++ doesn't have this issue apparently because each object file computes
the needed vtables, so only text symbols are shared.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:51                       ` Tom Tromey
@ 2000-04-01  0:00                         ` Tom Tromey
  0 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

Jeff> I'd like to see real Java bindings in GTK and/or KDE so developers can
Jeff> write first class Java apps for those environments.  Then implement AWT
Jeff> and (possibly) Swing atop this native API to be compatibile with other
Jeff> Java applications.

I believe there is a Java/Gnome effort, which provides Java bindings
for Gtk and Gnome.  I haven't looked to see how hard it would be to
make it work with gcj.

I think this is a reasonable approach as well.  We still need AWT and
Swing for compatibility and for people who want to write "Java
portable" applicatoins.

This also opens up the possibly weird capability of writing a pure
Java AWT on top of the Java Gtk package.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:25                         ` Cedric Berger
  2000-03-20 22:56                           ` Per Bothner
@ 2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:

> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
>
> It seems plausible to use libart (see http://www.levien.com/libart/
> and http://developer.gnome.org/arch/imaging/libart.html ).

Wow, this looks great!

> > 3) implementing Swing on top of the minimal AWT (or
> > borrowing it from 1.1 as a temporary solution). Swing is not
> > a trivial piece of code, but the advantage is that since almost
> > all functions/members of Swing are either public or protected,
> > all the skeleton of the code can be written from the JavaDoc
> > output of swing. "only" filling the method's body is required.
>
> Well, this is the "pure Java" approach.  It may make sense
> to use existing Gtk widgets instead.  It may also make sense
> to do provide both:  I.e. the toolkit by default uses Gtk
> widgets, but that can be overridden.

What is the real advantage of Gtk over "pure Java"? Speed?
What can you do with Gtk that you can't do with "pure Java"?
I must say that I don't know a lot about Gtk (unfortunatly, the
only native toolkit I've ever programmed so far is Win32/MFC)
but having used Swing a lot, I can see a lot of adventages of
"pure Java" over any native toolkit.

> I think the "model" classes should be pure Java (except perhaps
> a few CNI methods for speed).  However, the "view" classes
> should perhaps be based on gtk widgets.  At least the default
> implementation of the view classes should use the gtk theme
> framework.

Do you thing it is feasible to implement that? Again, I don't know
Gtk very well, but I would have troubles doing that with Win32.

And it is sometimes interresting to be able to modify the "view"
part of a widget. If I take again my example of syntax coloring;
I've been able to implement that very easily with Swing because
I've change the *view* part of the simple (plain) text pane: the
document remains a list of lines of ascii text (without style info)
and I've just overriden the drawLine() method of the View. No
need to insert style info or anything special into the "model"

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.  FOP can generate pdf - and it also includes
> a viewer, so it could form the basis for a "view engine".
> (However, I don't know if the Apache license is viewed as
> being compatible with the modified-GPL of libgcj.)

I'm not quite sure I understand what you mean: the FOP viewer
is built on top of Java2D, but kind of GUI widget do you want to
build with FOP?
Or do you thing about generating PDFs from Java2D? that would
be very cool!

Cedric


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:56                           ` Per Bothner
  2000-03-21  9:26                             ` Cedric Berger
@ 2000-04-01  0:00                             ` Per Bothner
  1 sibling, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger <cedric@wireless-networks.com> writes:

> What is the real advantage of Gtk over "pure Java"? Speed?

(Speed is not a major advantage - we always have the option of
replacing critical methods by CNI for a "mostly-Java" solution.)
(1) It may be easier to implement something useful if we build on gtk.
(2) Increased compatibility at the code level between C/C++/Java,
makes it more feasible to mix components in different languages.
(3) Better look+feel compatibility between Java apps and Gnome
apps.  Specifically, Swing L+F should follow gtk themes.

I think (3) is the most important, at least long-term.
At the very least, we need a default Swing look+feel that just
uses the current gtk theme.

> And it is sometimes interresting to be able to modify the "view"
> part of a widget. If I take again my example of syntax coloring;
> I've been able to implement that very easily with Swing because
> I've change the *view* part of the simple (plain) text pane: the
> document remains a list of lines of ascii text (without style info)
> and I've just overriden the drawLine() method of the View. No
> need to insert style info or anything special into the "model"

Yes, but that does not preclude having the default rendering
use the native (gtk) toolkit.  (I don't know what's involved though.)

> I'm not quite sure I understand what you mean: the FOP viewer
> is built on top of Java2D, but kind of GUI widget do you want to
> build with FOP?
> Or do you thing about generating PDFs from Java2D? that would
> be very cool!

I was thinking of using the the abstract "formatting object"
model specified for XSL as the way to organize the Swing View
hierarchies, and possibly using FOP as the basis for such an
implementation.

The idea is we use the XSL spec as a design document for how
to construct View hierarchies.  I.e. wherever XSL has an Area,
we create a sub-class of View with the corresponding semantics.
We have the option of using the FOP implementation (assuming the
licensing is ok), but the design is more important than the code.

This has the obvious advantage of making it easier to write tools
to process XML, but it may have a less obvious advantage in that a
lot of the Swing documentation is under-specified, and trying to
reverse engineer View hierachies is both painful and requires
care with the legalities.  (Though Topley's "Core Swing advanced
programming" gives a fair bit of information.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  2:18                       ` David Pettersson
@ 2000-04-01  0:00                         ` David Pettersson
  0 siblings, 0 replies; 115+ messages in thread
From: David Pettersson @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Hi,

On Mon, 20 Mar 2000, Cedric Berger wrote:

> Nobody uses AWT widgets anymore. I've never seen a new AWT
> application the last two years. In fact, Swing is widely recognized
> as the better GUI toolkit availabe today (and I'm not speaking of
> Java only). The main problem so far was speed, but JDK 1.3 is
> much better, and having the code compiled with a tool like GCJ
> will also make it much faster.
> 

-- cut --

I do use AWT. I started with Swing but change since I want my code to
run everywhere. Applet using AWT can be used in browsers like netscape
without any problems, extra downloads etc ... . Using AWT make it thus
possible to let costumers easy test a restricted version online before
purchasing the thing. With Swing, well I havn't got netscape to work with
it. AWT seems to be the most portable gui to use and therefore the first
thing that should be implemented. As noted in other answers, swing 1.1
is possible to use then to.

David.


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:17                         ` Cedric Berger
  2000-03-21  9:57                           ` ks
@ 2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: ks; +Cc: java-discuss

ks@micky.rgv.hp.com wrote:

> Take this clue.  Swing does not run on KVM.  Swing does not run on
> Chai.  Swing does not run on IBM VM.  Swing does not run on Kaffe.
> Swing does not run on jview.  Swing does not run on TowerJ.

Swing do run very well on jview (I'm using Together/J in this
configuration).
I would be very very surprised if it didn't work on IBM VM or TowerJ
(even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
being designed for server apps).

On the other hand, I will agree with you that Sun's Swing is probably too
big
for most of today's embedded application. But it is probably possible to
make a reduced version of Swing if for example you remove Pluggable L&F

> >
> > 4) if somebody really need it at that point, implementing
> > AWT widgets by calling Swing code: I believe that it is (or
> > was) Sun's plan too.
> >
>
> What amazing hubris.  Who is implementing AWT on top of Swing supposed
> to help?

Simplest way to achieve backward compatibility with old apps that uses
AWT.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00 ` Tom Tromey
@ 2000-04-01  0:00   ` Alexandre Oliva
  2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 1 reply; 115+ messages in thread
From: Alexandre Oliva @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Jeff Sturm, java-discuss

On Jan 13, 2000, Tom Tromey <tromey@cygnus.com> wrote:

>>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> BUT... all of libgcj is static-linked so far.  Libtool has no
Jeff> idea how to build a shared library on Win32, so I attempted to
Jeff> convert libgcj.a into libgcj.dll somehow, knowing nothing about
Jeff> DLLs in the process.

> I thought libtool could do this.  In fact I thought Ian wrote a bunch
> of changes to libtool specifically so that it could do this.

It's note very simple to convince libtool to create a DLL on
MS-Windows.  The first problem is that MS-Windows doesn't support
`incomplete' DLLs, so you must use libtool's -no-undefined, as a
promise that the library is not incomplete.  Then, there's all the
dllimport/dllexport mess, that must be explicitly taken care of in
user's code, which is the reason why libtool requires
AC_LIBTOOL_WIN32_DLL in configure.in to build DLLs.  That's the way to
tell libtool that the project has been ported to MesSy-Windows.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 14:33                         ` Paul Fisher
@ 2000-04-01  0:00                           ` Paul Fisher
  0 siblings, 0 replies; 115+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
> 
> It seems plausible to use libart (see http://www.levien.com/libart/
> and http://developer.gnome.org/arch/imaging/libart.html ).

It has been Classpath's and RHAD Labs' intention to use libart to
implement Java2D; however, there's still much work that needs to be
done on libart in order to bring it up to the level of functionality
that Java2D requires.  There's also the possibility that a server-side
2D X extension might make its way to the community in the future,
which would alleviate a lot of the problems involved.

(From what I've heard, Sun's implementation of Java2D under Windows
was a relatively simple mapping of Windows 2D primitives onto the Java
2D API.  For X, Sun had to roll their own implementation; it's quite
slow.)

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 20:59                     ` AWT is dead now Cedric Berger
                                         ` (4 preceding siblings ...)
  2000-03-21  8:56                       ` ks
@ 2000-04-01  0:00                       ` Cedric Berger
  5 siblings, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Nobody uses AWT widgets anymore. I've never seen a new AWT
application the last two years. In fact, Swing is widely recognized
as the better GUI toolkit availabe today (and I'm not speaking of
Java only). The main problem so far was speed, but JDK 1.3 is
much better, and having the code compiled with a tool like GCJ
will also make it much faster.

There has been a lot of discussion about AWT vs Swing design
option, and I think that most people agree that Swing has two
major advantages over AWT:
1) platform independence: you don't need to test thing on many
platform, the code is the same, the bugs are the same, ...
2) flexibility: there is not a single part of the Swing library that
I cannot replace or subclass in an application. Syntax coloring,
for example, can be done with 20-50 lines of code, by just
replacing the text RENDERER.

IMHO, the right way to develop a graphic library for Java today
is:

1) implementing the basic (low level) AWT functionalities.
Basically Window/Frame/Component/Container/Canvas and
event handling.

2) implementing Java2D (it's probably more difficult than 1),
but it can be done later and its probably a lot of fun to do.

3) implementing Swing on top of the minimal AWT (or
borrowing it from 1.1 as a temporary solution). Swing is not
a trivial piece of code, but the advantage is that since almost
all functions/members of Swing are either public or protected,
all the skeleton of the code can be written from the JavaDoc
output of swing. "only" filling the method's body is required.

4) if somebody really need it at that point, implementing
AWT widgets by calling Swing code: I believe that it is (or
was) Sun's plan too.

Cedric

Tom Tromey wrote:

> >> Secondly, I'm quite interested in doing some work on implementing
> >> AWT (I'm more intrested in Client stuff myself). I was wondering if
> >> someone could clear up the position of this, esp. regarding the
> >> Classpath merger. I seem to recall that everything from Classpath
> >> is available except the AWT code.  Now is this all AWT code or just
> >> the native implementation? IF I do use it what is the final result?
> >> That the executable is cover by the GPL? I can live with that for
> >> now...
>
> Jeff> From looking at Warren Levy's latest patches, I'd guess that the
> Jeff> libgcj maintainers haven't given up on doing their own AWT port,
> Jeff> independently of classpath.
>
> Warren's recent patches notwithstanding, we haven't started
> implementing AWT.  Those were needed for something else.
>
> Jeff> AWT would be great... you might consider a portable toolkit
> Jeff> (GTK?)  though before it becomes too Win32-centric, so that
> Jeff> other platforms can benefit.
>
> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.
>
> Tom


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj for win32
  2000-04-01  0:00           ` Jeff Sturm
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
@ 2000-04-01  0:00             ` Tom Tromey
  1 sibling, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Jon Beniston, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Cool.  Yours could be the first thread port in libgcj other than
Jeff> pthreads, so we'll see how portable the thread interface can be.

There's actually a "qthreads" port internal to Red Hat, though this
might not count.  (It isn't a full port.)

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  7:18                           ` Tom Tromey
  2000-03-21  8:06                             ` Jeff Sturm
@ 2000-04-01  0:00                             ` Tom Tromey
  1 sibling, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Per Bothner, java-discuss

Bryce> The queue lock is always under contention by the thread(s)
Bryce> putting events onto it and the E.D.T. pulling events off it,
Bryce> and as we know, locking between native threads is slow. I
Bryce> suspect this is the major reason why the user-threads based
Bryce> Sun/Borland JDK 1.2.2 performs so well running JBuilder and
Bryce> other swing apps compared to the other, native threaded JDKs
Bryce> like IBM 1.1.8 (which by all benchmarks has a much superior JIT
Bryce> and memory management) - its thread synchronization is 5x or
Bryce> more faster than linux native locks.

Sometimes I wonder if we should have two locking implementations, one
as fast as possible and one that is perhaps slower but SMP friendly.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* libgcj, Win32 & dll's
@ 2000-04-01  0:00 Jeff Sturm
  2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00 ` Bryce McKinlay
  0 siblings, 2 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Having reached a point where I can benefit from a native Win32 port of
libgcj, I scanned the archives to see what had been done... apparently
nothing that is complete, ready, tested.  There was/is a web site for
libgcj on Win32, though it appears to be unreachable.

So I built a native (i686-mingw32) Win32 GCC toolchain successfully,
with the Java frontend and Win32 thread support.  I proceeded to build
libgcj.  The java.lang and java.io stuff all built with minor changes
(benefitting from the fact that CRTDLL.DLL is somewhat POSIX-ish). 
Threads and java.net need more work, and I haven't yet tried boehm-gc
(which _should_ handle Win32 out-of-the-box).  Simple Java programs now
link & execute just fine.  Everything else can probably be done without
too much effort, thanks to great work done by the GCC and Mingw32
coders.

BUT... all of libgcj is static-linked so far.  Libtool has no idea how
to build a shared library on Win32, so I attempted to convert libgcj.a
into libgcj.dll somehow, knowing nothing about DLLs in the process. 
I've since learned that Win32 DLLs require a stub library, and they
export library functions as a jump table, and data symbols via
indirection (sort of like early COFF shared libraries back in SVR3
days).

The trouble is that gcj-compiled classes share various global data
symbols, such as the vtable and class objects.  There's no way that I
can see to link Java classes in a DLL, since these data symbols are
generated internally by gcj.  C/C++ programmers work around the problem
by using the __declspec(dllimport) and __declspec(dllexport) modifiers,
which instructs gcc to generate the extra indirection code.  But there
are no similar modifiers for Java (and I certainly don't advocate
extending the language).

I'm not really sure what to do next... gcj for Win32 won't be very
useful with static linkage only.  I suppose I could move just the C/C++
portion of the runtime into a DLL, but that wouldn't shrink the
executables much.  Any other ideas?  Did I miss something obvious??

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:17                       ` Per Bothner
  2000-03-20 17:48                         ` Bryce McKinlay
@ 2000-04-01  0:00                         ` Per Bothner
  1 sibling, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> To my knowledge there exist no free or third-party implementations of
> Swing.  It could be extremely difficult to do.

I know.  My recommendation is to write a subset of Swing (and AWT), and
enhancing it as people feel motivated.

> I'd like to see real Java bindings in GTK and/or KDE so developers can
> write first class Java apps for those environments.  Then implement AWT
> and (possibly) Swing atop this native API to be compatibile with other
> Java applications.

I agree with one slight modification:  Rather than write a direct
Java wrapper for gtk, I'd like us to use the AWT or Swing class
and method names whenever they match.  The main thing is I want to
avoid excess helper objects:  We would have a Window, which may
points to a WindowPeer, which may contain a RawData that points
to a gtk handle.  What I want to avoid when possible is an additional
Gtk Java wrapper; whatever class we use to wrap a gtk window
should implement the WindowPeer interface, without requiring yet
another class to do so.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:21                 ` Tom Tromey
  2000-03-20 10:30                   ` Per Bothner
       [not found]                   ` <38D681A9.1ED6097A@berger.to>
@ 2000-04-01  0:00                   ` Tom Tromey
  2 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Jon Beniston, java-discuss

Jeff> If I had my choice, interruptable I/O would be a configure-time
Jeff> option that could be turned off for strict JDK compatibility (or
Jeff> better performance/robustness in the case of Win32).

I think this would be a reasonable approach.

>> Secondly, I'm quite interested in doing some work on implementing
>> AWT (I'm more intrested in Client stuff myself). I was wondering if
>> someone could clear up the position of this, esp. regarding the
>> Classpath merger. I seem to recall that everything from Classpath
>> is available except the AWT code.  Now is this all AWT code or just
>> the native implementation? IF I do use it what is the final result?
>> That the executable is cover by the GPL? I can live with that for
>> now...

Jeff> From looking at Warren Levy's latest patches, I'd guess that the
Jeff> libgcj maintainers haven't given up on doing their own AWT port,
Jeff> independently of classpath.

Warren's recent patches notwithstanding, we haven't started
implementing AWT.  Those were needed for something else.

Jeff> AWT would be great... you might consider a portable toolkit
Jeff> (GTK?)  though before it becomes too Win32-centric, so that
Jeff> other platforms can benefit.

My goal is to have a retargetable AWT -- one where we can plug in
different back ends.  So we might have a Gtk+ back end (the one I'd
like to see :-), a Windows back end, and even a back end running on a
framebuffer (for embedded folks).  I don't know enough about AWT to
say whether this is a realistic plan.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  1:01                         ` Joerg Brunsmann
@ 2000-04-01  0:00                           ` Joerg Brunsmann
  0 siblings, 0 replies; 115+ messages in thread
From: Joerg Brunsmann @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

Per Bothner wrote:

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.  FOP can generate pdf - and it also includes
> a viewer, so it could form the basis for a "view engine".

"A tool is a great tool if it is used in a context for which it wasn't
designed." Obviously FOP is a great tool implementing an ambitious idea,
I agree. 

Anyway, we've been using XSL for over one year now when it was *one* 
specification. Nowadays it has been splitted into *three* specifications: 
XSLT, XPath and XSL FO. We are quite happy with XML/XSL/XPath combination, 
although the XSL processor's performs weakly when used with big XML source 
documents. Due to modifications in the spec we were forced to rewrite our 
XSL a couple of times. XSLT and XPath are now recommendations so this 
doesn't apply anymore. XSL FO is still a working draft which has
had significant modifications over the time. FOP doesn't implement the
current XSL FO specification. I think James Tauber left as an active
developer. XSL FO is a *huge* specification and the implementation needs
a lot of skills, knowledge, time and energy.

If this all sounds too destructive let me say this: in a year from now libgcj 
might have AWT and/or Swing, the XSL FO specification is a W3C recommendation, 
FOP has implemented 60% of the specification and someone might want to start 
using FOP with libgcj.

Jörg

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00 libgcj, Win32 & dll's Jeff Sturm
@ 2000-04-01  0:00 ` Tom Tromey
  2000-04-01  0:00   ` Alexandre Oliva
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Bryce McKinlay
  1 sibling, 2 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

I'm way, way behind on my email.  I only remembered this message
because of Bryce's reply :-(

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> BUT... all of libgcj is static-linked so far.  Libtool has no
Jeff> idea how to build a shared library on Win32, so I attempted to
Jeff> convert libgcj.a into libgcj.dll somehow, knowing nothing about
Jeff> DLLs in the process.

I thought libtool could do this.  In fact I thought Ian wrote a bunch
of changes to libtool specifically so that it could do this.  Maybe
this code doesn't work right now?  I admit I haven't kept up with it;
I rarely develop for Windows.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:22               ` Tom Tromey
  2000-03-20 12:03                 ` Paul Fisher
@ 2000-04-01  0:00                 ` Tom Tromey
  1 sibling, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon> Secondly, I'm quite interested in doing some work on implementing
Jon> AWT (I'm more intrested in Client stuff myself). I was wondering
Jon> if someone could clear up the position of this, esp. regarding
Jon> the Classpath merger. I seem to recall that everything from
Jon> Classpath is available except the AWT code.  Now is this all AWT
Jon> code or just the native implementation? IF I do use it what is
Jon> the final result? That the executable is cover by the GPL? I can
Jon> live with that for now...

All the AWT code in Classpath is under the GPL.  We aren't going to
merge it into libgcj.  It might be possible to get it to work with
libgcj; if you do so your resulting application will be GPL -- at
least, as I understand it.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00 ` Bryce McKinlay
@ 2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00     ` libgcj for win32 Jon Beniston
  0 siblings, 1 reply; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: java-discuss

Bryce McKinlay wrote:
> 
> Jeff Sturm wrote:
> 
> > Having reached a point where I can benefit from a native Win32 port of
> > libgcj, I scanned the archives to see what had been done... apparently
> > nothing that is complete, ready, tested.  There was/is a web site for
> > libgcj on Win32, though it appears to be unreachable.
> 
> Jon Beniston was working on a native win32 port - his web page is at
> http://www.cs.bris.ac.uk/~jb7216/libgcj/
> 
> Native win32 threads are working but there is no exceptions or java.net support
> yet. His port is based on libgcj 2.95.

Thanks.  Jon did get in touch with me.  His thread work was based on the
pthreads compatibility layer, as I understand it... I'd like to have a
native win32-threads if time ever permits.

Also exceptions seem to be OK now with SJLJ_EXCEPTIONS defined.  I have
a few other issues left that are really compiler bugs... if I get
java.net, threads and the GC working I'll be happy (if I ever get the
time that is).  Also, DLL support looks improbable right now.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* libgcj for win32
  2000-04-01  0:00   ` Jeff Sturm
@ 2000-04-01  0:00     ` Jon Beniston
  2000-04-01  0:00       ` Jeff Sturm
  0 siblings, 1 reply; 115+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Hello all,

I've just updated my win32 port of libgcj. New exciting features include:
Native threads, networking and exception handling. It's at last usable! GC
will hopefully be implemented very soon. If you have any problems, feel free
to have a moan.

Jon Beniston.

http://www.cs.bris.ac.uk/~jb7216/libgcj/index.html


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 10:30                   ` Per Bothner
  2000-03-20 12:42                     ` Jeff Sturm
@ 2000-04-01  0:00                     ` Per Bothner
  1 sibling, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.

It is quite realistic - that is what the "peer" architecture
was meant to support.  However, Swing uses a different approach:
The actual widgets are written in "pure Java", using the operations
defined in java.awt.Graphics.

The two approaches have different trade-offs:
- Native peers can probably be implemented faster than a Swing-like
solution.
- Native peers may have better compatibility (both look-and-feel and
programming-wise) than pure Java widgets.
- Pure Java widgets as in Swing may make the system more coherent
and give better control.  It is probably is easier to get full
compatibility with Sun for the Swing widgets.
- Pure Java widgets allow compatibility with Swing's "pluggable-
look-and-feel" (PLAF).  However, I'm not sure that is important.
I would rather have PLAF built using (say) gtk's theability.

I suspect we may end up doing a little of both.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00 libgcj, Win32 & dll's Jeff Sturm
  2000-04-01  0:00 ` Tom Tromey
@ 2000-04-01  0:00 ` Bryce McKinlay
  2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 1 reply; 115+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Jeff Sturm wrote:

> Having reached a point where I can benefit from a native Win32 port of
> libgcj, I scanned the archives to see what had been done... apparently
> nothing that is complete, ready, tested.  There was/is a web site for
> libgcj on Win32, though it appears to be unreachable.

Jon Beniston was working on a native win32 port - his web page is at
http://www.cs.bris.ac.uk/~jb7216/libgcj/

Native win32 threads are working but there is no exceptions or java.net support
yet. His port is based on libgcj 2.95.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  6:48                       ` Jeff Sturm
  2000-03-21  9:00                         ` Cedric Berger
  2000-03-21 14:05                         ` Paul Fisher
@ 2000-04-01  0:00                         ` Jeff Sturm
  2 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

Cedric Berger wrote:
> 1) implementing the basic (low level) AWT functionalities.
> Basically Window/Frame/Component/Container/Canvas and
> event handling.
> 
> 2) implementing Java2D (it's probably more difficult than 1),
> but it can be done later and its probably a lot of fun to do.

Is Java2D required for Swing?

> 3) implementing Swing on top of the minimal AWT (or
> borrowing it from 1.1 as a temporary solution). Swing is not
> a trivial piece of code, but the advantage is that since almost
> all functions/members of Swing are either public or protected,
> all the skeleton of the code can be written from the JavaDoc
> output of swing. "only" filling the method's body is required.

What are Kaffe and Classpath doing?  Are people using Swing with those?

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:03                 ` Paul Fisher
@ 2000-04-01  0:00                   ` Paul Fisher
  0 siblings, 0 replies; 115+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> All the AWT code in Classpath is under the GPL.

The GTK+ Peers are LGPL'd.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 10:22                             ` Cedric Berger
  2000-03-21 10:41                               ` jean-marie sulmont
@ 2000-04-01  0:00                               ` Cedric Berger
  1 sibling, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: ks, java-discuss

ks@micky.rgv.hp.com wrote:

> > I would be very very surprised if it didn't work on IBM VM or TowerJ
> > (even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
> > being designed for server apps).
>
> My argument is that it should be possible to write simple GUIs (for
> system configuration, for monitoring/management, or for interactions
> with small or remote machines) without forcing 13MB (compressed!) of
> Swing classes on them.

If I remember correctly, JRE 1.3 ship (english version) in less than 5MB
(with everything: JVM, Swing, Java2D, .........)

But I agree that, because of the current Microsoft behavior, it's a pain
to have to ship this...
But we must not be making decisions based on M$ behavior, and,
with Netscape 6 and recent Linux deals, things are going to change,
hopefully...

Cedric

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21 10:41                               ` jean-marie sulmont
@ 2000-04-01  0:00                                 ` jean-marie sulmont
  0 siblings, 0 replies; 115+ messages in thread
From: jean-marie sulmont @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: ks, java-discuss

Why don't you take this topic off list?

-- 
jean-marie sulmont                      1211 SW 5th Ave, suite 900
developer                               Portland, Oregon 97204
Oracle Corporation                      Phone: (503) 525-8057
jsulmont@us.oracle.com                  Fax:   (503) 277-2300

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj for win32
  2000-04-01  0:00         ` Jon Beniston
@ 2000-04-01  0:00           ` Jeff Sturm
  2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
  2000-04-01  0:00             ` libgcj for win32 Tom Tromey
  0 siblings, 2 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> > That's great news, Jon.  Did you port to win32 threads or use the pthreads
> > compatibility library?  Are you using the Cygwin or Mingw32
> > compiler environment?
> 
> Win32 native. I use a cygwin environment to build, but use -mno-cygwin to
> target
> ming so there's no dependencies on cygwin.dll. (Oops, I forgot to mention
> that
> switch on the web page!). Also included in the binaries is a (hopefully)
> thread safe
> version of libgcc.a (/usr/local/libgccgcj.a).

Cool.  Yours could be the first thread port in libgcj other than
pthreads, so we'll see how portable the thread interface can be.

I assume you built your gcj with --enable-threads=win32 to get
thread-safe exception handling... recent snapshots should have this
option.

> > The GC should work without much hassle... but note that it currently
> > requires the DLL configuration on win32.  If you don't build libgcjgc as a
> > DLL, it won't get the DLL_THREAD_ATTACH messages and won't work in a
> > multithreaded VM.
> 
> Er, how do you do that?

Libtool should be able to do it, but probably won't without some
tweaking.  Check out boehm-gc/README.win32 for some pointers... there is
a Makefile.DLLs that was written for a fairly old version of Cygwin
(called GNU-Win32 back then) which may be helpful... failing that, get
dllwrap and try it yourself.  Mumit's site
( http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ ) has very good
information on GCC, Win32 and DLL's.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 14:21                           ` Paul Fisher
@ 2000-04-01  0:00                             ` Paul Fisher
  0 siblings, 0 replies; 115+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> One of the fundamental ideas of Swing is the separation of "model"
> and "view+controller".  For example two JTextPanes can both be using
> the same Document.  How suitable are gtk widgets for doing things
> like that?

It depends on the widget.  More of an issue, however, is Swing's
allowance of arbitrarily overriding of drawLine() and other
primitives, as was mentioned in a previous post.  With GTK+ 1.2, it's
impossible to do printing the way Java wants it done, because there's
no way to change the semantics of the primitive GDK drawing routines.
This issue is being resolved in GTK+ 1.4, so there might be a way
around the Swing issues such that Java methods can control the drawing
of GTK+ widgets.

All the issues involved will probably be quite complex, and I really
haven't had enough time to throughly think through them.  I'm more
focused on the libgcj/Classpath merger and finishing up the 1.1 AWT
before swamping myself in the problems of reimplementing Swing.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-20 22:23                         ` Bryce McKinlay
@ 2000-04-01  0:00                           ` Bryce McKinlay
  0 siblings, 0 replies; 115+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: Cedric Berger, java-discuss

Per Bothner wrote:

> I think the "model" classes should be pure Java (except perhaps
> a few CNI methods for speed).  However, the "view" classes
> should perhaps be based on gtk widgets.  At least the default
> implementation of the view classes should use the gtk theme
> framework.

Why not do the view classes in Java as well? Implementing Swing's level
of elegance and complexity (even just the views) in C is not something
I'd consider either "fun" or "realistic". Given the elimination of the
synchronization issues, and good garbage collection, the Java
implementation would be allmost as fast. "view" classes written in Java
could even be used by traditional programs written in C(++) as if they
were native gtk widgets, given a bit of glue.

> One exciting idea I want to explore is to use the XSL
> "formatting object" model for views.  See http://www.w3.org/TR/xsl/
> We could base the implementation on FOP ( http://xml.apache.org/fop/ ),
> which is an open-source implementation in Java sponsored by the Apache
> XML Project.

Yes, this sounds very cool.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj, Win32 & dll's
  2000-04-01  0:00   ` Alexandre Oliva
@ 2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00       ` Jeff Sturm
  0 siblings, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Alexandre Oliva; +Cc: Tom Tromey, Jeff Sturm, java-discuss

>>>>> "Alexandre" == Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:

Alexandre> Then, there's all the dllimport/dllexport mess, that must
Alexandre> be explicitly taken care of in user's code, which is the
Alexandre> reason why libtool requires AC_LIBTOOL_WIN32_DLL in
Alexandre> configure.in to build DLLs.

It seems to me that we could (in theory) modify the Java compile to
automatically do the appropriate dllexport thing (I have no clue what
this attribute actually does) for Java methods.  Basically it would
just follow Java visibility rules.

However, it sounds like this isn't sufficient, given that we want to
export objects from the data area (e.g., vtables).  Is it really not
possible to do what we want on Windows?  That would suck.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  7:07               ` Jeff Sturm
  2000-03-20  8:21                 ` Tom Tromey
@ 2000-04-01  0:00                 ` Jeff Sturm
  1 sibling, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> I seem to recall reading somewhere on Sun's Bug list that the interrupting
> of IO has in some form been deprecated. Does any one know whether this is
> the case? I ask, because I'm wondering whether I should implement this in
> the Win32 port. It seems as if there may be some overhead. Would this be
> worth it it the general case? Personally, I've never made use of it.

This was covered in the thread last week on Thread.interrupt():
 
http://sourceware.cygnus.com/ml/java-discuss/2000-q1/msg00418.html

I think the collective opinion on this list was that both interruptable
I/O and resource revocation are desirable in libgcj.  If I had my
choice, interruptable I/O would be a configure-time option that could be
turned off for strict JDK compatibility (or better
performance/robustness in the case of Win32).

I remember reading somewhere that interruptible I/O can be implemented
on NT with async I/O, but that it won't work for 95/98 (which I couldn't
care less about, personally).  That may have changed since I read it...

> Secondly, I'm quite interested in doing some work on implementing AWT (I'm
> more intrested in Client stuff myself). I was wondering if someone could
> clear up the position of this, esp. regarding the Classpath merger. I seem
> to recall that everything from Classpath is available except the AWT code.
> Now is this all AWT code or just the native implementation? IF I do use it
> what is the final result? That the executable is cover by the GPL? I can
> live with that for now...

From looking at Warren Levy's latest patches, I'd guess that the libgcj
maintainers haven't given up on doing their own AWT port, independently
of classpath.

AWT would be great... you might consider a portable toolkit (GTK?)
though before it becomes too Win32-centric, so that other platforms can
benefit.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:00                         ` Cedric Berger
  2000-03-21  9:47                           ` Jeff Sturm
@ 2000-04-01  0:00                           ` Cedric Berger
  1 sibling, 0 replies; 115+ messages in thread
From: Cedric Berger @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Jeff Sturm wrote:

> Cedric Berger wrote:
> > 1) implementing the basic (low level) AWT functionalities.
> > Basically Window/Frame/Component/Container/Canvas and
> > event handling.
> >
> > 2) implementing Java2D (it's probably more difficult than 1),
> > but it can be done later and its probably a lot of fun to do.
>
> Is Java2D required for Swing?

No, but Graphics2D (the Java2D engine) is a superset of the
old Graphics class needed by everyone who want to paint on
a window. So only Graphics is needed for most Swing apps.
but Graphics2D re-implement (not just augment) all Graphics
methods; so if plan to develop Graphics first and Graphics2D
later, I would assumes that most of the work doing Graphics
will be lost.
IMHO, it would be better to start implementing Java2D with
the latest specs (1.3), but starting with the pieces that are really
needed by Swing (bezier curves can be left for later...)

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:38                               ` Denis Balazuc
@ 2000-04-01  0:00                                 ` Denis Balazuc
  0 siblings, 0 replies; 115+ messages in thread
From: Denis Balazuc @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cygnus-Java Mailing List

> I'm quite sure that a lot of peoples (including me) would *love* to
> have a good Swing L&F that uses gtk themes, especially if it
> can be plugged in other VM implementations...
> I agree that the implementation of  L&F other than Metal has been
> so far a very week part of Sun's implementation. But I don't see
> any reasons for that except (wrong?) priorities at Sun.
> I understand that Sun wanted to keep Swing in pure java up to
> version 1.1, but now that it's integrated in the core, I don't see any
> reasons why it cannot uses native method to query the platform's
> desktop settings for things like themes, widget size, ...


I thought that the idea behind Swing was to remove plateform-dependency and
heavy-weight components in the first place....
(and despite what was said, Windows's not the only plateform where you can
find many  AWT bugs...)
non 100% Pure Java Swing : is that really what one's want ?
Is there a plan from SUN to deviate from a 100% pure implementation ?



^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: AWT is dead now
  2000-03-21  9:57                           ` ks
  2000-03-21 10:22                             ` Cedric Berger
@ 2000-04-01  0:00                             ` ks
  1 sibling, 0 replies; 115+ messages in thread
From: ks @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Cedric Berger; +Cc: java-discuss

> I would be very very surprised if it didn't work on IBM VM or TowerJ
> (even it doesn't make a lot of sense to use TowerJ with Swing, towerJ
> being designed for server apps).

Perhaps I should more correctly say Swing is not distributed as a part
of those platforms.  If you get Swing from another source then of course
it will run since it is pure Java.

So if I write a Swing based app, and give it to someone who uses jview
they will not be able to run it unless they also have Swing, or unless
I provide Swing with my program.

My argument is that it should be possible to write simple GUIs (for 
system configuration, for monitoring/management, or for interactions
with small or remote machines) without forcing 13MB (compressed!) of
Swing classes on them.

Cheers,
-kls

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: libgcj for win32
  2000-04-01  0:00       ` Jeff Sturm
@ 2000-04-01  0:00         ` Jon Beniston
  2000-04-01  0:00           ` Jeff Sturm
  0 siblings, 1 reply; 115+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

> On Sun, 16 Jan 2000, Jon Beniston wrote:
> > I've just updated my win32 port of libgcj. New exciting features
include:
> > Native threads, networking and exception handling. It's at last usable!
GC
> > will hopefully be implemented very soon. If you have any problems, feel
free
> > to have a moan.
>
> That's great news, Jon.  Did you port to win32 threads or use the pthreads
> compatibility library?  Are you using the Cygwin or Mingw32
> compiler environment?

Win32 native. I use a cygwin environment to build, but use -mno-cygwin to
target
ming so there's no dependencies on cygwin.dll. (Oops, I forgot to mention
that
switch on the web page!). Also included in the binaries is a (hopefully)
thread safe
version of libgcc.a (/usr/local/libgccgcj.a).

> The GC should work without much hassle... but note that it currently
> requires the DLL configuration on win32.  If you don't build libgcjgc as a
> DLL, it won't get the DLL_THREAD_ATTACH messages and won't work in a
> multithreaded VM.

Er, how do you do that?

Cheers,
Jon.


^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  8:06                             ` Jeff Sturm
@ 2000-04-01  0:00                               ` Jeff Sturm
  0 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 13:23     ` Tom Tromey
@ 2000-04-01  0:00       ` Tom Tromey
  0 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Tom Tromey, Boehm, Hans, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Surely the compiler could detect this in some cases... are you
Jeff> saying it could be detected at runtime as well?

The compiler can detect it, but my understanding is that in some
situations you must dynamically mark the object to get the real
benefit.  It's probable I misunderstood the paper, though.

Jeff> Tom, I think you mentioned once the use of locks for Java string
Jeff> concatenation:

Yeah, but this is one we should do preemptively -- it might be a while
before we implement stack allocation &c in the compiler, but for this
we can just generate calls to a non-locking StringBuffer analogue.
Unfortunately this has been pretty low priority.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 20:49 ` Jeff Sturm
@ 2000-04-01  0:00   ` Jeff Sturm
  0 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Tom Tromey', Jeff Sturm, Bryce McKinlay, java-discuss

On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com


^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:20 Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:17 ` Jeff Sturm
@ 2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 0 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Tom Tromey; +Cc: Bryce McKinlay, java-discuss

I'm still planning on looking at this.  But I've been busy with other
things.  (I have a very partial implementation of an alternate locking
scheme, but it's not in any kind of usable shape.  And I'm far less than
100% sure that it will turn out to be the right scheme.)

The rest of this is based on way too few anecdotes, and no real
measurements:

My general impression is that if you don't care much about fairness (and I
suspect we usually don't), spin locks with exponential back-off work quite
well, in that they tend to automatically reduce contention to a reasonable
level.  (It does seem to have the disadvantage that with lots of contention,
you sometimes see individual threads going to very long backoffs.  The net
result is that one or two threads keep the lock for long periods, thus
reducing the need to move the cache line back and forth.  This is probably
the right thing for throughput, but not fairness.)  I tend to implement
short backoff intervals as spins, and longer ones using some sort of sleep
primitive.

For some strange reason, that's a scheme that's rarely discussed in the
literature.  Does anyone have some real measurements that include something
like this scheme?

I'm still looking at a scheme that maintains a global, non-resizable hash
table of locks, with no per-object space for locks.  (Collisions do force
memory allocation.)  My impression is that shrinking objects is very
worthwhile, since it increases the effectiveness of the cache, and decreases
memory bandwidth requirements.  Also I suspect that many Java locks are very
short-lived.  Thus it's important to avoid memory allocation when an object
is first locked (statistics anyone?).  Again this probably favors throughput
over predictability, fairness, etc.  But fairness doesn't help much if the
throughput goes to zero.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:10 AM
To: Tom Tromey
Cc: Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:17 ` Jeff Sturm
  2000-03-21 13:30   ` Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

"Boehm, Hans" wrote:
> My general impression is that if you don't care much about fairness (and I
> suspect we usually don't), spin locks with exponential back-off work quite
> well, in that they tend to automatically reduce contention to a reasonable
> level.  (It does seem to have the disadvantage that with lots of contention,
> you sometimes see individual threads going to very long backoffs.  The net
> result is that one or two threads keep the lock for long periods, thus
> reducing the need to move the cache line back and forth.  This is probably
> the right thing for throughput, but not fairness.)  I tend to implement
> short backoff intervals as spins, and longer ones using some sort of sleep
> primitive.

A very large number of locks are extremely short duration, in my
experience.  It makes sense to just spin on them... since the
probability of contention approaches zero as the duration shrinks,
fairness may be of negligible concern for locks that cover just a few
instructions.  This is especially true of a uniprocessor, in which
contention only takes place if a thread is preempted within a critical
section.

Even on SMP, there is no value to using suspend/resume on a thread that
will claim the lock just as fast by spinning, if the duration is much
less than a millisecond there's little chance the spinning processor
could have done any useful work anyway, given the overhead of system
calls and context switching.

Unfortunately Java supports just one synchronization primitive which
must behave reasonably in all scenarios, even if (e.g.) a thread blocks
on I/O.  But large portions of libgcj are C++, in which case we have
more options.  All critical sections in libgcj are currently handled
with _Jv_MonitorEnter/_Jv_MonitorExit, (outside of boehm-gc, which
relies on a local spinlock implementation).  There may be room for
improvement there.

> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

> I'm still looking at a scheme that maintains a global, non-resizable hash
> table of locks, with no per-object space for locks.  (Collisions do force
> memory allocation.)  My impression is that shrinking objects is very
> worthwhile, since it increases the effectiveness of the cache, and decreases
> memory bandwidth requirements.  Also I suspect that many Java locks are very
> short-lived.  Thus it's important to avoid memory allocation when an object
> is first locked (statistics anyone?).  Again this probably favors throughput
> over predictability, fairness, etc.  But fairness doesn't help much if the
> throughput goes to zero.

Sounds interesting.

In the Java code we develop, I consider long-term synchronization blocks
a bug, and favor rewriting them using a Mutex implementation we have
based on Doug Lea's concurrent package.  By keeping synchronized blocks
short we can tune the algorithm (whenever possible) and avoid deadlock
conditions.  Our Mutex class has some deadlock detection built in. 
OTOH, deadlocks around Java monitors are easy to produce and extremely
difficult to debug.

That's not to say our code is typical... I fear that long synchronized
blocks are common in Java code because that is the path of least
resistance.  Coarse-grained locking simply takes more work.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:39     ` Per Bothner
@ 2000-04-01  0:00       ` Per Bothner
  0 siblings, 0 replies; 115+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Tom, I think you mentioned once the use of locks for Java string
> concatenation:
> 
> String f(int i) {
>   return "f(" + i + ") called";
> }
> 
> That method will normally do a monitorenter/monitorexit twice.  Lock
> avoidance may eliminate the useless locks in string contentation
> completely.

That is certainly a special case we can do by just having the compiler
emit non-locking calls.  That should be straight-forward to fix.

We can also "inline" the StringBuffer on the stack (though not
necessarily the buffer's data, of course), by using a special
(non-Java) C++ class.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 16:05 Boehm, Hans
  2000-03-21 20:49 ` Jeff Sturm
@ 2000-04-01  0:00 ` Boehm, Hans
  1 sibling, 0 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Tom Tromey', Jeff Sturm; +Cc: Bryce McKinlay, java-discuss

It seems to me that a spin lock with exponential back-off (and sleeps for
longer wait times) doesn't behave that badly, even in this case.  There'll
be some unneeded wakeups on the part of the waiting thread near the
beginning, and it may sleep for up to about twice as long as it should
(assuming the base of the exponential is 2).  Clearly this is suboptimal in
this case.  But are there cases in which it's a serious problem?

Hans 

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 21, 2000 1:30 PM
To: Jeff Sturm
Cc: Boehm, Hans; Tom Tromey; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 13:30   ` Tom Tromey
@ 2000-04-01  0:00     ` Tom Tromey
  0 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Boehm, Hans, Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-22 17:30 Interrupted IO and AWT Boehm, Hans
@ 2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 0 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: 'Tom Tromey', Bryce McKinlay, java-discuss

I haven't done much performance testing of GC_lock().  It does seem to be
appreciably faster than the pthread_mutex locking, apparently because there
is somewhat less work being done, there is one less level of procedure call,
it's less likely to enter the kernel on an SMP, and it doesn't need to do a
compare_and_swap on exit.

GC_lock isn't quite the strategy I had in mind, since it does something more
complicated than exponential back-off when it's spinning.  It tries to be
adaptive, but doesn't really back off between successive test_and_set
attempts while it's still spinning.  I have no idea how this compares to the
simpler straight exponential back-off strategy.

I agree that the current value of SLEEP_THRESHOLD is problematic on an SMP.
The problem with making it much larger is that sched_yield may be repatedly
yielding to another thread also waiting on the lock.  (This can definitely
happen with strict priorities.  Hopefully it's unlikely with normal
timesharing priorities.)  This may still be a better choice.  It would be
nice to be able to sleep for shorter intervals than 500 context switches.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:54 PM
To: Boehm, Hans
Cc: 'Tom Tromey'; Jeff Sturm; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: RE: Interrupted IO and AWT




On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal
in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:31   ` Jeff Sturm
@ 2000-04-01  0:00   ` Tom Tromey
  1 sibling, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Jeff Sturm', Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> I'm still looking at a scheme that maintains a global,
Hans> non-resizable hash table of locks, with no per-object space for
Hans> locks.

FYI the compiler side of this work has been checked in.
All that remains is the implementation in the runtime.

Hans> Also I suspect that many Java locks are very short-lived.  Thus
Hans> it's important to avoid memory allocation when an object is
Hans> first locked (statistics anyone?).

A paper I read recently suggests that in some situations it is
worthwhile to avoid locks altogether when you can prove that an object
is method- or thread-local ("Escape Analysis for Java", Choi et al --
one of the Jalapeno papers).  In this case we'd need to steal a bit
somewhere (the gc header?) to indicate that the lock should be
avoided.  This is probably even more worthwhile if locks are heavy.

I'm also curious to find literature on how long a Java lock is
typically held (I haven't really looked).  I'm also curious to know
how concerned I should be about the other cases (e.g., if a lock is
held when doing I/O, is this a major concern?  What if it is an
SMP-unfriendly lock?).

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
  2000-03-21 13:23     ` Tom Tromey
@ 2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 0 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Boehm, Hans, Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Hans> Also I suspect that many Java locks are very short-lived.  Thus
> Hans> it's important to avoid memory allocation when an object is
> Hans> first locked (statistics anyone?).
> 
> A paper I read recently suggests that in some situations it is
> worthwhile to avoid locks altogether when you can prove that an object
> is method- or thread-local ("Escape Analysis for Java", Choi et al --
> one of the Jalapeno papers).  In this case we'd need to steal a bit
> somewhere (the gc header?) to indicate that the lock should be
> avoided.  This is probably even more worthwhile if locks are heavy.

Surely the compiler could detect this in some cases... are you saying it
could be detected at runtime as well?

Tom, I think you mentioned once the use of locks for Java string
concatenation:

String f(int i) {
  return "f(" + i + ") called";
}

That method will normally do a monitorenter/monitorexit twice.  Lock
avoidance may eliminate the useless locks in string contentation
completely.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-22 17:10 Boehm, Hans
@ 2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 0 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: Tom Tromey, Bryce McKinlay, java-discuss

Ideally, I'd like to see measurements of collections of representative real
applications with various locking strategies :-).

Realistically, any measurements are much better than none.  My guess is that
even the following microbenchmark would yield some insight:

1) Acquire and release a single lock in a single thread in a tight loop.
2) Do (1) concurrently with different numbers of threads on different number
of processors, all acquiring the same lock. 

This is hopefully an unrealistically bad case, but it's probably more
representative of real applications than it should be.  

(Running a bunch of allocation tests concurrently essentially behaves like
this, if there is no per-thread allocation buffer.  I've certainly seen
interesting variation in the results.  I also thought someone posted test
results along these lines for some other locking schemes, but not spin locks
with exponential backoff.)

Hans

-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 12:20 PM
To: Boehm, Hans
Cc: Tom Tromey; Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


"Boehm, Hans" wrote:
[Exponential back-off spin locks:]
> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include
something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-22 17:30 Boehm, Hans
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 1 reply; 115+ messages in thread
From: Boehm, Hans @ 2000-03-22 17:30 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: 'Tom Tromey', Bryce McKinlay, java-discuss

I haven't done much performance testing of GC_lock().  It does seem to be
appreciably faster than the pthread_mutex locking, apparently because there
is somewhat less work being done, there is one less level of procedure call,
it's less likely to enter the kernel on an SMP, and it doesn't need to do a
compare_and_swap on exit.

GC_lock isn't quite the strategy I had in mind, since it does something more
complicated than exponential back-off when it's spinning.  It tries to be
adaptive, but doesn't really back off between successive test_and_set
attempts while it's still spinning.  I have no idea how this compares to the
simpler straight exponential back-off strategy.

I agree that the current value of SLEEP_THRESHOLD is problematic on an SMP.
The problem with making it much larger is that sched_yield may be repatedly
yielding to another thread also waiting on the lock.  (This can definitely
happen with strict priorities.  Hopefully it's unlikely with normal
timesharing priorities.)  This may still be a better choice.  It would be
nice to be able to sleep for shorter intervals than 500 context switches.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:54 PM
To: Boehm, Hans
Cc: 'Tom Tromey'; Jeff Sturm; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: RE: Interrupted IO and AWT




On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal
in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-22 17:10 Boehm, Hans
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 1 reply; 115+ messages in thread
From: Boehm, Hans @ 2000-03-22 17:10 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: Tom Tromey, Bryce McKinlay, java-discuss

Ideally, I'd like to see measurements of collections of representative real
applications with various locking strategies :-).

Realistically, any measurements are much better than none.  My guess is that
even the following microbenchmark would yield some insight:

1) Acquire and release a single lock in a single thread in a tight loop.
2) Do (1) concurrently with different numbers of threads on different number
of processors, all acquiring the same lock. 

This is hopefully an unrealistically bad case, but it's probably more
representative of real applications than it should be.  

(Running a bunch of allocation tests concurrently essentially behaves like
this, if there is no per-thread allocation buffer.  I've certainly seen
interesting variation in the results.  I also thought someone posted test
results along these lines for some other locking schemes, but not spin locks
with exponential backoff.)

Hans

-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 12:20 PM
To: Boehm, Hans
Cc: Tom Tromey; Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


"Boehm, Hans" wrote:
[Exponential back-off spin locks:]
> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include
something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 16:05 Boehm, Hans
@ 2000-03-21 20:49 ` Jeff Sturm
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  1 sibling, 1 reply; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21 20:49 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Tom Tromey', Jeff Sturm, Bryce McKinlay, java-discuss

On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com


^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-21 16:05 Boehm, Hans
  2000-03-21 20:49 ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 2 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-03-21 16:05 UTC (permalink / raw)
  To: 'Tom Tromey', Jeff Sturm; +Cc: Bryce McKinlay, java-discuss

It seems to me that a spin lock with exponential back-off (and sleeps for
longer wait times) doesn't behave that badly, even in this case.  There'll
be some unneeded wakeups on the part of the waiting thread near the
beginning, and it may sleep for up to about twice as long as it should
(assuming the base of the exponential is 2).  Clearly this is suboptimal in
this case.  But are there cases in which it's a serious problem?

Hans 

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 21, 2000 1:30 PM
To: Jeff Sturm
Cc: Boehm, Hans; Tom Tromey; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:17 ` Jeff Sturm
@ 2000-03-21 13:30   ` Tom Tromey
  2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2000-03-21 13:30 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Boehm, Hans, Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
@ 2000-03-21 13:23     ` Tom Tromey
  2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2000-03-21 13:23 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Tom Tromey, Boehm, Hans, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Surely the compiler could detect this in some cases... are you
Jeff> saying it could be detected at runtime as well?

The compiler can detect it, but my understanding is that in some
situations you must dynamically mark the object to get the real
benefit.  It's probable I misunderstood the paper, though.

Jeff> Tom, I think you mentioned once the use of locks for Java string
Jeff> concatenation:

Yeah, but this is one we should do preemptively -- it might be a while
before we implement stack allocation &c in the compiler, but for this
we can just generate calls to a non-locking StringBuffer analogue.
Unfortunately this has been pretty low priority.

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
@ 2000-03-21 12:39     ` Per Bothner
  2000-04-01  0:00       ` Per Bothner
  2000-03-21 13:23     ` Tom Tromey
  2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 1 reply; 115+ messages in thread
From: Per Bothner @ 2000-03-21 12:39 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Tom, I think you mentioned once the use of locks for Java string
> concatenation:
> 
> String f(int i) {
>   return "f(" + i + ") called";
> }
> 
> That method will normally do a monitorenter/monitorexit twice.  Lock
> avoidance may eliminate the useless locks in string contentation
> completely.

That is certainly a special case we can do by just having the compiler
emit non-locking calls.  That should be straight-forward to fix.

We can also "inline" the StringBuffer on the stack (though not
necessarily the buffer's data, of course), by using a special
(non-Java) C++ class.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  9:52 ` Tom Tromey
@ 2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
                       ` (2 more replies)
  2000-04-01  0:00   ` Tom Tromey
  1 sibling, 3 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21 12:31 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Boehm, Hans, Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Hans> Also I suspect that many Java locks are very short-lived.  Thus
> Hans> it's important to avoid memory allocation when an object is
> Hans> first locked (statistics anyone?).
> 
> A paper I read recently suggests that in some situations it is
> worthwhile to avoid locks altogether when you can prove that an object
> is method- or thread-local ("Escape Analysis for Java", Choi et al --
> one of the Jalapeno papers).  In this case we'd need to steal a bit
> somewhere (the gc header?) to indicate that the lock should be
> avoided.  This is probably even more worthwhile if locks are heavy.

Surely the compiler could detect this in some cases... are you saying it
could be detected at runtime as well?

Tom, I think you mentioned once the use of locks for Java string
concatenation:

String f(int i) {
  return "f(" + i + ") called";
}

That method will normally do a monitorenter/monitorexit twice.  Lock
avoidance may eliminate the useless locks in string contentation
completely.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  9:20 Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
@ 2000-03-21 12:17 ` Jeff Sturm
  2000-03-21 13:30   ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 2 replies; 115+ messages in thread
From: Jeff Sturm @ 2000-03-21 12:17 UTC (permalink / raw)
  To: Boehm, Hans; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

"Boehm, Hans" wrote:
> My general impression is that if you don't care much about fairness (and I
> suspect we usually don't), spin locks with exponential back-off work quite
> well, in that they tend to automatically reduce contention to a reasonable
> level.  (It does seem to have the disadvantage that with lots of contention,
> you sometimes see individual threads going to very long backoffs.  The net
> result is that one or two threads keep the lock for long periods, thus
> reducing the need to move the cache line back and forth.  This is probably
> the right thing for throughput, but not fairness.)  I tend to implement
> short backoff intervals as spins, and longer ones using some sort of sleep
> primitive.

A very large number of locks are extremely short duration, in my
experience.  It makes sense to just spin on them... since the
probability of contention approaches zero as the duration shrinks,
fairness may be of negligible concern for locks that cover just a few
instructions.  This is especially true of a uniprocessor, in which
contention only takes place if a thread is preempted within a critical
section.

Even on SMP, there is no value to using suspend/resume on a thread that
will claim the lock just as fast by spinning, if the duration is much
less than a millisecond there's little chance the spinning processor
could have done any useful work anyway, given the overhead of system
calls and context switching.

Unfortunately Java supports just one synchronization primitive which
must behave reasonably in all scenarios, even if (e.g.) a thread blocks
on I/O.  But large portions of libgcj are C++, in which case we have
more options.  All critical sections in libgcj are currently handled
with _Jv_MonitorEnter/_Jv_MonitorExit, (outside of boehm-gc, which
relies on a local spinlock implementation).  There may be room for
improvement there.

> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

> I'm still looking at a scheme that maintains a global, non-resizable hash
> table of locks, with no per-object space for locks.  (Collisions do force
> memory allocation.)  My impression is that shrinking objects is very
> worthwhile, since it increases the effectiveness of the cache, and decreases
> memory bandwidth requirements.  Also I suspect that many Java locks are very
> short-lived.  Thus it's important to avoid memory allocation when an object
> is first locked (statistics anyone?).  Again this probably favors throughput
> over predictability, fairness, etc.  But fairness doesn't help much if the
> throughput goes to zero.

Sounds interesting.

In the Java code we develop, I consider long-term synchronization blocks
a bug, and favor rewriting them using a Mutex implementation we have
based on Doug Lea's concurrent package.  By keeping synchronized blocks
short we can tune the algorithm (whenever possible) and avoid deadlock
conditions.  Our Mutex class has some deadlock detection built in. 
OTOH, deadlocks around Java monitors are easy to produce and extremely
difficult to debug.

That's not to say our code is typical... I fear that long synchronized
blocks are common in Java code because that is the path of least
resistance.  Coarse-grained locking simply takes more work.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:20 Boehm, Hans
@ 2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:31   ` Jeff Sturm
  2000-04-01  0:00   ` Tom Tromey
  2000-03-21 12:17 ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 2 replies; 115+ messages in thread
From: Tom Tromey @ 2000-03-21  9:52 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Jeff Sturm', Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> I'm still looking at a scheme that maintains a global,
Hans> non-resizable hash table of locks, with no per-object space for
Hans> locks.

FYI the compiler side of this work has been checked in.
All that remains is the implementation in the runtime.

Hans> Also I suspect that many Java locks are very short-lived.  Thus
Hans> it's important to avoid memory allocation when an object is
Hans> first locked (statistics anyone?).

A paper I read recently suggests that in some situations it is
worthwhile to avoid locks altogether when you can prove that an object
is method- or thread-local ("Escape Analysis for Java", Choi et al --
one of the Jalapeno papers).  In this case we'd need to steal a bit
somewhere (the gc header?) to indicate that the lock should be
avoided.  This is probably even more worthwhile if locks are heavy.

I'm also curious to find literature on how long a Java lock is
typically held (I haven't really looked).  I'm also curious to know
how concerned I should be about the other cases (e.g., if a lock is
held when doing I/O, is this a major concern?  What if it is an
SMP-unfriendly lock?).

Tom

^ permalink raw reply	[flat|nested] 115+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-21  9:20 Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
                   ` (2 more replies)
  0 siblings, 3 replies; 115+ messages in thread
From: Boehm, Hans @ 2000-03-21  9:20 UTC (permalink / raw)
  To: 'Jeff Sturm', Tom Tromey; +Cc: Bryce McKinlay, java-discuss

I'm still planning on looking at this.  But I've been busy with other
things.  (I have a very partial implementation of an alternate locking
scheme, but it's not in any kind of usable shape.  And I'm far less than
100% sure that it will turn out to be the right scheme.)

The rest of this is based on way too few anecdotes, and no real
measurements:

My general impression is that if you don't care much about fairness (and I
suspect we usually don't), spin locks with exponential back-off work quite
well, in that they tend to automatically reduce contention to a reasonable
level.  (It does seem to have the disadvantage that with lots of contention,
you sometimes see individual threads going to very long backoffs.  The net
result is that one or two threads keep the lock for long periods, thus
reducing the need to move the cache line back and forth.  This is probably
the right thing for throughput, but not fairness.)  I tend to implement
short backoff intervals as spins, and longer ones using some sort of sleep
primitive.

For some strange reason, that's a scheme that's rarely discussed in the
literature.  Does anyone have some real measurements that include something
like this scheme?

I'm still looking at a scheme that maintains a global, non-resizable hash
table of locks, with no per-object space for locks.  (Collisions do force
memory allocation.)  My impression is that shrinking objects is very
worthwhile, since it increases the effectiveness of the cache, and decreases
memory bandwidth requirements.  Also I suspect that many Java locks are very
short-lived.  Thus it's important to avoid memory allocation when an object
is first locked (statistics anyone?).  Again this probably favors throughput
over predictability, fairness, etc.  But fairness doesn't help much if the
throughput goes to zero.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:10 AM
To: Tom Tromey
Cc: Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 115+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 115+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 libgcj, Win32 & dll's Jeff Sturm
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Alexandre Oliva
2000-04-01  0:00     ` Tom Tromey
2000-04-01  0:00       ` Jeff Sturm
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00 ` Bryce McKinlay
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00     ` libgcj for win32 Jon Beniston
2000-04-01  0:00       ` Jeff Sturm
2000-04-01  0:00         ` Jon Beniston
2000-04-01  0:00           ` Jeff Sturm
2000-03-20  6:19             ` Interrupted IO and AWT Jon Beniston
2000-03-20  7:07               ` Jeff Sturm
2000-03-20  8:21                 ` Tom Tromey
2000-03-20 10:30                   ` Per Bothner
2000-03-20 12:42                     ` Jeff Sturm
2000-03-20 12:51                       ` Tom Tromey
2000-04-01  0:00                         ` Tom Tromey
2000-03-20 13:09                       ` Paul Fisher
2000-03-20 13:25                         ` Per Bothner
2000-03-21 14:21                           ` Paul Fisher
2000-04-01  0:00                             ` Paul Fisher
2000-04-01  0:00                           ` Per Bothner
2000-04-01  0:00                         ` Paul Fisher
2000-03-20 13:17                       ` Per Bothner
2000-03-20 17:48                         ` Bryce McKinlay
2000-03-21  7:18                           ` Tom Tromey
2000-03-21  8:06                             ` Jeff Sturm
2000-04-01  0:00                               ` Jeff Sturm
2000-04-01  0:00                             ` Tom Tromey
2000-04-01  0:00                           ` Bryce McKinlay
2000-04-01  0:00                         ` Per Bothner
2000-04-01  0:00                       ` Jeff Sturm
2000-04-01  0:00                     ` Per Bothner
     [not found]                   ` <38D681A9.1ED6097A@berger.to>
2000-03-20 20:59                     ` AWT is dead now Cedric Berger
2000-03-20 21:30                       ` Per Bothner
2000-03-20 22:23                         ` Bryce McKinlay
2000-04-01  0:00                           ` Bryce McKinlay
2000-03-20 22:25                         ` Cedric Berger
2000-03-20 22:56                           ` Per Bothner
2000-03-21  9:26                             ` Cedric Berger
2000-03-21  9:38                               ` Denis Balazuc
2000-04-01  0:00                                 ` Denis Balazuc
2000-04-01  0:00                               ` Cedric Berger
2000-04-01  0:00                             ` Per Bothner
2000-04-01  0:00                           ` Cedric Berger
2000-03-21  1:01                         ` Joerg Brunsmann
2000-04-01  0:00                           ` Joerg Brunsmann
2000-03-21 14:33                         ` Paul Fisher
2000-04-01  0:00                           ` Paul Fisher
2000-04-01  0:00                         ` Per Bothner
2000-03-20 22:13                       ` Bryce McKinlay
2000-04-01  0:00                         ` Bryce McKinlay
2000-03-21  2:18                       ` David Pettersson
2000-04-01  0:00                         ` David Pettersson
2000-03-21  6:48                       ` Jeff Sturm
2000-03-21  9:00                         ` Cedric Berger
2000-03-21  9:47                           ` Jeff Sturm
2000-03-21 10:12                             ` Cedric Berger
2000-04-01  0:00                               ` Cedric Berger
2000-04-01  0:00                             ` Jeff Sturm
2000-04-01  0:00                           ` Cedric Berger
2000-03-21 14:05                         ` Paul Fisher
2000-04-01  0:00                           ` Paul Fisher
2000-04-01  0:00                         ` Jeff Sturm
2000-03-21  8:56                       ` ks
2000-03-21  9:17                         ` Cedric Berger
2000-03-21  9:57                           ` ks
2000-03-21 10:22                             ` Cedric Berger
2000-03-21 10:41                               ` jean-marie sulmont
2000-04-01  0:00                                 ` jean-marie sulmont
2000-04-01  0:00                               ` Cedric Berger
2000-04-01  0:00                             ` ks
2000-04-01  0:00                           ` Cedric Berger
2000-03-21  9:44                         ` Brian Sullivan
2000-03-21 11:38                           ` Jonathan P. Olson
2000-03-21 11:46                             ` Nathan Meyers
2000-04-01  0:00                               ` Nathan Meyers
2000-04-01  0:00                             ` Jonathan P. Olson
2000-04-01  0:00                           ` Brian Sullivan
2000-04-01  0:00                         ` ks
2000-04-01  0:00                       ` Cedric Berger
2000-04-01  0:00                   ` Interrupted IO and AWT Tom Tromey
2000-04-01  0:00                 ` Jeff Sturm
2000-03-20  8:22               ` Tom Tromey
2000-03-20 12:03                 ` Paul Fisher
2000-04-01  0:00                   ` Paul Fisher
2000-04-01  0:00                 ` Tom Tromey
2000-03-21  0:57               ` Interrupted IO and AWT -> Remote AWT Jens Wilke
2000-04-01  0:00                 ` Jens Wilke
2000-04-01  0:00               ` Interrupted IO and AWT Jon Beniston
2000-04-01  0:00             ` libgcj for win32 Tom Tromey
  -- strict thread matches above, loose matches on Subject: below --
2000-03-22 17:30 Interrupted IO and AWT Boehm, Hans
2000-04-01  0:00 ` Boehm, Hans
2000-03-22 17:10 Boehm, Hans
2000-04-01  0:00 ` Boehm, Hans
2000-03-21 16:05 Boehm, Hans
2000-03-21 20:49 ` Jeff Sturm
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00 ` Boehm, Hans
2000-03-21  9:20 Boehm, Hans
2000-03-21  9:52 ` Tom Tromey
2000-03-21 12:31   ` Jeff Sturm
2000-03-21 12:39     ` Per Bothner
2000-04-01  0:00       ` Per Bothner
2000-03-21 13:23     ` Tom Tromey
2000-04-01  0:00       ` Tom Tromey
2000-04-01  0:00     ` Jeff Sturm
2000-04-01  0:00   ` Tom Tromey
2000-03-21 12:17 ` Jeff Sturm
2000-03-21 13:30   ` Tom Tromey
2000-04-01  0:00     ` Tom Tromey
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00 ` Boehm, Hans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).