David Holmes wrote:
Just revisiting the split between using a VMxxx method for
XXX to forward to versus declaring a native method. I thought,
from past discussions the intent was to use VMxxx methods in
preference to native methods. I just noticed that
Object.getClass is still a native
David Holmes writes:
Jeroen Frijters wrote:
Andrew Haley wrote:
David Holmes writes:
static native Class getClassFromContext(int pos);
This seems like a reasonable idea. In several cases we need to say
who is our caller? and some VM assistance is useful here.
Andrew Haley wrote:
David Holmes writes:
That was my initial thought but the generalization is
trivial and useful.
For example, given the XXX/VMxxx split having only
getCallerClass wouldn't
allow XXX to defer to VMxxx and have VMxxx find the real caller.
Perhaps we don't need to
Jeroen Frijters writes:
Andrew Haley wrote:
David Holmes writes:
That was my initial thought but the generalization is
trivial and useful.
For example, given the XXX/VMxxx split having only
getCallerClass wouldn't allow XXX to defer to VMxxx and have
VMxxx find the
Hi Graydon
have you happen to come across http://stsf.sourceforge.net/? (BSD-
licensed font library on top of the X11 rendering extension; by Sun).
IMHO it looks nice from a coarse view, and the documentation is
interesting to read.
-- Sascha
Sascha Brawer, [EMAIL PROTECTED],
Hi all,
there's several places in the Java API where users can write custom plug-
ins, or service providers. Examples include java.nio.charset,
javax.print, javax.imageio, com.sun.jdi (the client side API for
connecting to remote debugging targets), and some other packages. Plug-
ins are usually
On Fri, Mar 19, 2004 at 12:05:55PM +0100, Sascha Brawer wrote:
4. The Mauve tests #5 and #8 fail both on JamVM and on gcj. (Thanks to
Michael Koch for testing on gcj, by the way). Basically, what happens is
something like the following:
Class c = myClassLoader.loadClass(name);
Sascha Brawer writes:
4. The Mauve tests #5 and #8 fail both on JamVM and on gcj. (Thanks to
Michael Koch for testing on gcj, by the way). Basically, what happens is
something like the following:
Class c = myClassLoader.loadClass(name);
harness.check(c.getClassLoader() ==
On Friday 19 March 2004 12:05, Sascha Brawer wrote:
4. The Mauve tests #5 and #8 fail both on JamVM and on gcj. (Thanks to
Michael Koch for testing on gcj, by the way). Basically, what happens is
something like the following:
Class c = myClassLoader.loadClass(name);
If Object.getClass() were to forward to VMObject then I could probably
quickly implement VMObject in Jikes RVM and be done with yet another
private version of an important system class. We have a Java
implementation of Object.getClass(), so native is not appropriate for
our system.
--Steve
Chris Gray [EMAIL PROTECTED] wrote on Fri, 19 Mar 2004 13:59:28 +0100:
c.getClassLoader() returns the class loader which defined the class. Since
your CustomClassLoader quite properly uses the default loadClass()
implementation, Class c may be loaded by an ancestor. So your test needs to
match
reopen 235395
reassign 235395 automake1.7
tag 235395 patch
thanks
While creating dist tarball tar is called with chof options.
The option o forces OLD archive format which only allows for
maximum of 100 chars in a path.
This problem does not show up if one is using old-enough version of
tar,
Hi!
I'm currently porting parts of GNU classpath to OVM (http://www.ovmj.org). In
the process I hit a problem with the access modifier of
FileDescriptor.setNativeFd(long). In order to avoid having to set that field
using reflection, I would need that method to be default (currently private).
13 matches
Mail list logo
