Hi,
On Wed, 2003-11-05 at 21:31, Bryce McKinlay wrote:
On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote:
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that don't (want to) use
JNI for their native methods. Having all
Mark Wielaard writes:
Hopefully we won't do it at the expense of elegance 'and' efficiency,
but I agree that sometimes it won't be possible to achieve both. As our
Hacker Guide puts it (even though it leaves out elegance):
When you write code for Classpath, write with three
On Thursday 06 November 2003 12:04, Sascha Brawer wrote:
Andrew Haley [EMAIL PROTECTED] wrote on Thu, 6 Nov 2003 10:28:24 +:
[having the VMInterfaces classes clearly marked as 'special'
would make it easy for VMs and compilers to just inline all calls
to them]
It's not particularly
On Mon, 27 Oct 2003 16:20:23 -0700
Tom Tromey [EMAIL PROTECTED] wrote:
Michael == Michael Koch [EMAIL PROTECTED] writes:
Michael From what I understood what Tom said to me our style would be to write:
Michael getToolkit().create (this);
Michael Empty brackets have no space
Hi,
On Sun, 2003-11-02 at 21:11, Guilhem Lavaux wrote:
Mark Wielaard wrote:
OK. Let me try to summarize the behavior we want so we can at least
create some good tests:
DataInputStream.readLine():
- Should not block when it has seen at least a \r but return as soon as
possible even
Sascha Brawer writes:
Andrew Haley [EMAIL PROTECTED] wrote on Thu, 6 Nov 2003 10:28:24 +:
[having the VMInterfaces classes clearly marked as 'special'
would make it easy for VMs and compilers to just inline all calls
to them]
It's not particularly difficult to do, but at the
Jikes RVM uses a mostly unmodifed classpath.
We don't require users to patch any classpath sources, but there
are currently 12 non-VM classes for which we provide our own implementation.
java.lang.ref:
PhantomReference, Reference, SoftReference, WeakReference
java.lang:
Class, Object,
Mark Wielaard wrote:
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that don't (want to) use
JNI for their native methods. Having all native methods in the VM*
classes makes this much easier.
I was suggesting that. Sorry for
I am also strongly in favor of putting all VM-specific
native methods in
VM* classes, and all library-specific native methods outside of VM*
classes.
I suspect the notion of a VM-specific native method
vs. a library-specific native method is pretty fuzzy. One example
is VMFloat, most VM's
David P Grove writes:
I don't think there is an easy solution to this as it is unlikely
that a single VMInterface will fit the needs of all VMs perfectly.
In some cases (java.lang.ref.* for example), I don't think that it
is reasonable for classpath to try to provide an implementation
Stuart Ballard wrote:
Nobody spoke up, so could someone apply the patch (attached)?
Anybody? :)
Stuart.
--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net
Index: HashMap.java
===
Hi,
This patch fixes various problems related to image loading. It also
implements Component.imageUpdate, GtkToolkit.prepareImage and the
byte-array GtkToolkit.createImage method.
Comments?
Tom
2003-11-06 Thomas Fitzsimmons [EMAIL PROTECTED]
* Makefile.am: Add GdkPixbufDecoder.java
Hi!
Has anybody already tried to import classpath under Eclipse? I tried to
create a project and import the files, but then Eclipse is far too
intelligent:
* gnu/java/lang classes are imported into package java.lang
* vm/reference/java/lang classes are imported into package vm.java.lang
Probably
Patrik Reali [EMAIL PROTECTED] writes:
Hi!
Has anybody already tried to import classpath under Eclipse? I tried to
create a project and import the files, but then Eclipse is far too
intelligent:
* gnu/java/lang classes are imported into package java.lang
* vm/reference/java/lang classes
14 matches
Mail list logo
