I committed the following code to continue the implementation of DOM
Level 2 HTML.
2005-03-14 Chris Burdess [EMAIL PROTECTED]
* gnu/xml/dom/DomImpl.java,
gnu/xml/dom/html2/DomHTMLAnchorElement.java,
gnu/xml/dom/html2/DomHTMLDocument.java,
See discussion mailing list for further info.
2005-03-14 Robert Schuster [EMAIL PROTECTED]
* java/lang/Runtime.java: Added support for
gnu.classpath.boot.library.path system property.
cu
Robert
Index: java/lang/Runtime.java
===
Hi all,
Recent gtk peer code seems to have introduced a subtle bug, only visible
on VM's that verify that structured locking is properly done. I have
put a description of the bug in the bug tracker at:
http://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=12301
There seems to be an easy
Etienne Gagnon wrote:
Recent gtk peer code seems to have introduced a subtle bug, only visible
on VM's that verify that structured locking is properly done. I have
put a description of the bug in the bug tracker at:
http://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=12301
There seems
Bryce == Bryce McKinlay [EMAIL PROTECTED] writes:
Bryce Certainly, bytecode isn't allowed to do this kind of thing, but I'm
Bryce not sure if the structured locking rules in the VM spec are meant to
Bryce apply to native code. For example, wait() would be impossible to
Bryce implement if this
Tom Tromey wrote:
Bryce == Bryce McKinlay [EMAIL PROTECTED] writes:
Bryce Certainly, bytecode isn't allowed to do this kind of thing, but I'm
Bryce not sure if the structured locking rules in the VM spec are meant to
Bryce apply to native code. For example, wait() would be impossible to
Bryce
Chris Pickett wrote:
Tom Tromey wrote:
Bryce == Bryce McKinlay [EMAIL PROTECTED] writes:
Bryce Certainly, bytecode isn't allowed to do this kind of thing, but
I'm
Bryce not sure if the structured locking rules in the VM spec are
meant to
Bryce apply to native code. For example, wait() would be
Etienne Gagnon wrote:
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
So, the current
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
So, the current AWT code clearly does
On Monday 14 March 2005 22:44, Chris Pickett wrote:
As a trivial example: it is possible to define native methods that do
the equivalent of MONITORENTER and MONITOREXIT, so that you can lock and
unlock things without using synchronized methods or blocks. If these
are allowed to be
Etienne wrote:
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
Well
Etienne == Etienne Gagnon [EMAIL PROTECTED] writes:
Etienne Native code must not use MonitorExit to exit a monitor
Etienne entered through a synchronized method or a monitorenter
Etienne Java virtual machine instruction.
Interesting -- I usually consult some other page about JNI that
The current skip(int) implementation of BufferedInputStream reads and
ignores data from the underlying stream. We have a program that creates
a BufferedInputStream on an underlying FileInputStream where the file is
on a network mounted file system. Often we skip large portions of the
Hello,
as discussed on IRC GNU Classpath I introduced a system property named
gnu.classpath.boot.library.path which contains a path of directories
where Classpath's native libraries are located.
It is optional for a runtime to support. Actually it depends on the VM's
ability to run a
14 matches
Mail list logo
