Hi !
Attached is a small patch which should be applied to the gnu classpath.
It corrects a method signature used in a GetMethodID.
Martin
--- gnu/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkFileDialogPeer.c
2004-11-07 11:51:37.763035568 +0100
+++
Hi (CCed classpath-patches),
On Sat, 2005-01-15 at 15:52 +0100, Martin Platter wrote:
Attached is a small patch which should be applied to the gnu classpath.
It corrects a method signature used in a GetMethodID.
Thanks! We were just debugging this on irc (#classpath irc.gnu.org).
Now that you
Mark Wielaard wrote:
Hi (CCed classpath-patches),
On Sat, 2005-01-15 at 15:52 +0100, Martin Platter wrote:
Attached is a small patch which should be applied to the gnu classpath.
It corrects a method signature used in a GetMethodID.
Thanks! We were just debugging this on irc (#classpath
Hi,
On Sat, 2005-01-15 at 17:31 +0100, Martin Platter wrote:
Mark Wielaard wrote:
Does this mean CACAO now does AWT?
AWT support is not complete yet (specially in the released version).
Mainly there are still some threading issues to solve. But with
portable-native-sync disabled,
Hi all,
Are there any plans or activities to include the javax.management api in
classpath?
Ewout
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Ewout Prangsma wrote:
Are there any plans or activities to include the javax.management api
in classpath?
This API would normally be developed under the auspices of the
classpathx project. Nobody has got around to writing it yet, are you
interested?
--
Chris Burdess
Am Samstag, 15. Januar 2005 18:59 schrieb Chris Burdess:
Ewout Prangsma wrote:
Are there any plans or activities to include the javax.management
api in classpath?
This API would normally be developed under the auspices of the
classpathx project. Nobody has got around to writing it yet, are
Mark Wielaard wrote:
Two is that currently the gtk+ peer code can sometimes use the wrong
JNIEnv. We store a global JNIEnv* when the event queue is started and
reuse that JNIEnv* almost everywhere. This is clearly wrong. We can only
FYI, I filed this issue in the bug database:
On Sat, 2005-01-15 at 17:59, Chris Burdess wrote:
Ewout Prangsma wrote:
Are there any plans or activities to include the javax.management api
in classpath?
This API would normally be developed under the auspices of the
classpathx project. Nobody has got around to writing it yet, are you
Mark Wielaard wrote:
Hi,
On Sat, 2005-01-01 at 16:01 +0100, Ewout Prangsma wrote:
Now; currently the URL class uses the system classloader to load
protocol handlers.
Must this really be the system classloader?
I have a protocol handler that is accessible via the context classloader
I propose adding a new class that may be optionally implemented by the
VM, gnu.classpath.VMStackBrowser. I say that it is optional because
I have here a reference implementation for it that uses the existing
gnu.classpath.VMStackWalker to do all the work:
/* VMStackBrowser.java -- Reference
11 matches
Mail list logo
