I checked in the aforementioned assertion patch.
2005-07-25 Archie Cobbs <[EMAIL PROTECTED]>
* native/jni/classpath/native_state.c: add assertion for object type
-Archie
__
Archie Cobbs *CTO, Awa
Hi,
On Sun, 2005-07-24 at 00:19 +0200, Sven de Marothy wrote:
[...]
> Method: getClasspathFontPeer(), getClasspathTextLayoutPeer(), getFont()
> Comment: We need these. No way around that. But they could perhaps be
> put in a seperate ClasspathFontInterface or something.
OK.
>
> Method: creat
Hi,
I'll let Thomas reply with more details since he knows a lot more about
this. But here are some quick references that might help.
On Sun, 2005-07-24 at 00:19 +0200, Sven de Marothy wrote:
> Method: getClasspathFontPeer(), getClasspathTextLayoutPeer(), getFont()
> Comment: We need these. No w
Hi,
On Mon, 2005-07-25 at 14:46 +0200, Jean-Philippe Deblonde wrote:
> In fact, it's a lot more than a simple refactoring, because I need, by
> example, to rewrite the String.java to use an array of bytes (coded
> with UTF-8) instead of an array of char, to save some space for the
> smartcards...
The idea was to save memory space & execution time, so the String.java
use *internally* UTF format.
2005/7/25, Meskauskas Audrius <[EMAIL PROTECTED]>:
> Jean-Philippe Deblonde wrote:
>
> >In fact, it's a lot more than a simple refactoring, because I need, by
> >example, to rewrite the String.java
Jean-Philippe Deblonde wrote:
In fact, it's a lot more than a simple refactoring, because I need, by
example, to rewrite the String.java to use an array of bytes (coded
with UTF-8) instead of an array of char, to save some space for the
smartcards..
Maybe I do not understand properly, but why o
Hi Sven,
Ok, I've been looking into the issue of our AWT peer interface now that
I've been running my peers on Classpath in earnest.
The goal here is to try to bring our peer interface as close to Sun's
as possible. And simplify things for potential peer-authors.
...
Summary: So, my opinion
Oups..., I completely forget to answer to the mailing list *too*...
So, here's what I answered to Tom...
-- Forwarded message --
From: Jean-Philippe Deblonde <[EMAIL PROTECTED]>
Date: 21 juil. 2005 19:21
Subject: Re: Using GNU Classpath while changing his hierarchy
To: [EMAIL PROTE
Am Montag, den 25.07.2005, 10:16 +0200 schrieb Jeroen Frijters:
> Ingo Prötel wrote:
> > I just implemented VMStackWalker for our VM and have some questions.
> >
> > The reference implementation of 'getCallingClass()' and
> > 'getCallingClassLoader()' just look at the third entry in the class
> >
Andrew Haley wrote:
> Of course, yes. But it's security issues that I'm concerned about
> here: what we want to know is the first caller of Foo.method() that is
> not Foo.
Not necessarily. Typically what's important is the supplier of the arguments to
the method. In the subclassing scenario, the
Ingo Prötel wrote:
> I really like the idea of having a stack walker so I would like to use
> it wherever possible. For example in java.util.logging.Logger. If a
> class calls 'logger.warning("some warning")' this call will
> be forwarded through a couple of calls until it will call
> 'Logger.log(
Andrew Haley wrote:
> Which is the Right Answer: the caller of baz *is* Frob.
It *may* be the right answer, but how can you be certain that the coder of
class Foo intended this? IMNSHO, code like this is completely unauditable
(remember, this isn't just a correctness issue, access to class loade
Jeroen Frijters writes:
> Andrew Haley wrote:
> > Which is the Right Answer: the caller of baz *is* Frob.
>
> It *may* be the right answer, but how can you be certain that the
> coder of class Foo intended this?
Ah, well that is a totally different matter.
> IMNSHO, code like this is compl
Jeroen Frijters writes:
> Andrew Haley wrote:
> > However, as for overhead -- I don't believe it. I doubt that not
> > having this parameter saves anything much on any VM.
>
> That's just your lack of imagination ;-) I was concerned with two
> aspects wrt performance:
> 1) Class literals a
Hi!
We have some problems with the spec jvm applet and i think i've found a
problem. Java_gnu_java_awt_peer_gtk_GdkGraphics_setFGColor uses
NSA_GET_PTR to get the graphics pointer, which calls cp_gtk_get_state.
This function may return NULL in exception case, which lets this code
crash:
g = (st
Archie Cobbs wrote:
> Dalibor Topic wrote:
>
>> Doesn't GetObjectClass change the state of env? If that's the case, it
>> maybe shouldn't be an assert.
>
>
> Not sure what you mean.. but there is a bug: we need to delete the
> local native reference obtained by calling GetObjectClass.
>
> Attac
Jeroen Frijters writes:
> Andrew Haley wrote:
> > In gcj, we have a method called GetCallingClass(Class c). It searches
> > firstly for a method declared in class c, then for a method not
> > declared in c. We have found, after a certain amount of trouble, that
> > this is the right way to d
Andrew Haley wrote:
> However, as for overhead -- I don't believe it. I doubt that not
> having this parameter saves anything much on any VM.
That's just your lack of imagination ;-) I was concerned with two
aspects wrt performance:
1) Class literals are inefficient -- this is no longer an issue
Andrew Haley wrote:
> In gcj, we have a method called GetCallingClass(Class c). It searches
> firstly for a method declared in class c, then for a method not
> declared in c. We have found, after a certain amount of trouble, that
> this is the right way to do things; it means that an arbitrary nu
Ingo Prötel wrote:
> I just implemented VMStackWalker for our VM and have some questions.
>
> The reference implementation of 'getCallingClass()' and
> 'getCallingClassLoader()' just look at the third entry in the class
> context. Would it not be better to return the first class that is not
> assi
Sven de Marothy wrote:
> Ok, I've been looking into the issue of our AWT peer
> interface now that I've been running my peers on Classpath
> in earnest.
>
> The goal here is to try to bring our peer interface as close to Sun's
> as possible. And simplify things for potential peer-authors.
>
[...]
21 matches
Mail list logo
